Guides / Construction et ressources
L'Éponge et le Bloc de structure ne sont pas le même fichier
Un .schem, un .litematic et un .mcstructure Bedrock semblent interchangeables jusqu'à ce qu'on en convertisse un et que chaque coffre, entité et état de bloc ait disparu.
Un .schem et un .litematic contiennent tous deux une construction, et c'est au moment de convertir de l'un à l'autre que la plupart des joueurs découvrent que les deux formats ne se sont jamais entendus sur ce qu'est une construction. L'un stocke une région de blocs. L'autre stocke un historique de placement. Transférez une ville de l'un à l'autre et les maisons survivent, mais pas leur contenu.
Ce que chaque format transporte réellement
| Format | Où il s'exécute | États de bloc | Blocs entités | Entités |
|---|---|---|---|---|
.schem | Java, WorldEdit/Sponge | oui | oui | oui |
.litematic | Java, Litematica | oui | oui | oui |
.nbt structure | Java, blocs de structure | oui | oui | oui |
.mcstructure | Bedrock | oui | oui | oui |
Les colonnes semblent identiques, et c'est là le piège. La différence réside dans la gestion de la palette et l'espace de coordonnées, pas dans la liste des fonctionnalités.
La palette est la partie fragile
Chacun de ces formats stocke les blocs sous forme d'index dans une palette — une liste des types de blocs uniques utilisés par le fichier, chaque position contenant un nombre pointant vers cette liste. Une construction utilisant quelques centaines de types de blocs distincts transporte une palette de cette taille, et les positions ne sont que des entiers.
Cela signifie que le fichier n'est lisible que si le lecteur peut résoudre chaque entrée de la palette. Un bloc ajouté dans une version Java plus récente n'a aucun équivalent Bedrock, donc une conversion Java vers Bedrock doit le substituer ou l'abandonner. L'air est le substitut habituel, et un mur avec des blocs mystérieusement manquants est presque toujours cela, pas une corruption.
Java et Bedrock nomment le même bloc différemment
C'est ici que Java et Bedrock divergent véritablement. Bedrock écrit les états de bloc sous la forme block_type plus un ensemble d'états clé-valeur ; Java écrit un ID avec espace de noms plus une table d'états. Le même bloc physique peut être minecraft:oak_stairs[facing=east,half=bottom] d'un côté et un ensemble d'états ordonné différemment de l'autre.
Les escaliers, dalles, clôtures, murets, portes et composants de redstone sont ceux qui basculent. Un escalier qui s'affiche à l'envers après conversion est un décalage dans l'ordre des états, pas un fichier défectueux.
Les blocs de structure ne stockent pas ce que vous croyez
Un bloc de structure sauvegardé en .nbt écrit une zone délimitée, et cette zone a une taille maximale stricte par axe. Les constructions plus grandes que la zone ne sont pas sauvegardées en un seul fichier — le jeu les découpe ou refuse. Si une construction convertie a perdu son extrémité, vérifiez la zone d'origine avant de suspecter le convertisseur.
Les entités sont stockées séparément des blocs dans chacun de ces formats. Les cadres, les porte-armures, les tableaux et les créatures ne sont pas des blocs, et un convertisseur qui ne parcourt que la palette de blocs les abandonnera silencieusement.
Prévisualisez avant de faire confiance
La liste des matériaux est le contrôle de cohérence le plus rapide : si le nombre de blocs du fichier converti ne correspond pas à celui de l'original, quelque chose a été substitué. L'aperçu par couches le montre immédiatement, une tranche horizontale à la fois, sans charger la construction dans un monde.
Convertissez entre .litematic, .schem, structure Java .nbt et Bedrock .mcstructure, avec un aperçu par couches et une liste des matériaux, dans le Convertisseur de schémas.