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 disparaisse.
Un .schem et un .litematic contiennent tous deux une construction, et c'est en convertissant 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 seule région de blocs. L'autre peut contenir plusieurs régions nommées, chacune avec sa propre palette. 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 porte 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 réellement. 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 carte d'états. Le même bloc physique peut être minecraft:oak_stairs[facing=east,half=bottom] d'un côté et weirdo_direction plus upside_down_bit de l'autre — des noms et valeurs d'états différents, pas les mêmes réordonnés.
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 une erreur de mappage d'é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 est plafonnée à 48 blocs par axe. Le jeu ne découpe pas une construction plus grande — tout ce qui dépasse la zone n'est simplement pas dans le fichier. 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 de 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 de matériaux, dans le Convertisseur de schémas.