L'extension ne dit pas le format du schéma — 31 des 33 fichiers .schematic étaient autre chose
Cinq formats, quatre façons différentes d'empaqueter les blocs, et .schematic est partagé par deux d'entre eux. Renifler la racine NBT vaut mieux que faire confiance au nom de fichier, preuves à l'appui.
Il existe cinq formats de schéma en circulation, et le nom de fichier est un indice plutôt qu'un fait. La visionneuse présentée ici détermine ce qu'est un fichier en regardant à l'intérieur, et il y a une raison mesurée à cela.
Cinq formats, cinq extensions
| extension | format |
|---|---|
.nbt | structure vanilla |
.schem | Sponge |
.schematic | Sponge — par défaut |
.litematic | Litematica |
.mcstructure | Bedrock |
La ligne problématique est .schematic. Cette extension est partagée par le format MCEdit classique et celui de Sponge, et les fichiers sont renommés par des gens qui ne le savent pas ou s'en moquent.
Compté sur un corpus réel : sur 33 fichiers .schematic, 31 étaient du MCEdit, un était une structure vanilla et un était du Litematica. Le choix par défaut de l'extension est donc faux pour la quasi-totalité d'entre eux, et deux fichiers n'étaient pas des .schematic au sens propre — juste mal nommés.
La solution consiste à renifler la racine NBT et à laisser ce que le fichier est l'emporter sur ce qu'il est appelé :
- une clé
Regions→ Litematica paletteetblocks→ structure vanilla- sinon le test de forme MCEdit, puis repli sur l'extension
Quatre façons d'empaqueter les mêmes blocs
Les formats ne diffèrent pas seulement en apparence. Chacun stocke les données de blocs d'une manière véritablement différente, et chaque choix a une conséquence :
Vanilla .nbt — une liste. Une entrée par position sauvegardée, chacune indiquant un index de palette. L'air est stocké comme n'importe quel autre bloc ; seul le vide de structure est omis, donc une construction creuse n'est économique que si son intérieur a été vidé avant la sauvegarde.
Sponge .schem — un flux de varints. Les index de palette empaquetés en entiers à largeur variable : sept bits de charge utile par octet, bit de poids fort mis à 1 pour continuer. Les petites palettes coûtent un octet par bloc ; une palette de plus de 127 entrées commence à coûter deux octets pour les index élevés. Compact, mais auto-descriptif.
MCEdit .schematic — un tableau d'octets plat. Un octet par bloc, donc 256 types de blocs maximum — c'est exactement pourquoi il possède un tableau annexe optionnel AddBlocks ajoutant quatre bits d'id supplémentaires sous forme de nibble par bloc, ce qui porte les ids à 4 095. C'est un format hérité à ids numériques d'avant les états de blocs : ses ids sont des nombres, résolus via un composé SchematicaMapping quand Schematica en a écrit un, et via la table d'ids vanilla 1.12 sinon.
Litematica .litematic — des longs empaquetés en bits. Les index sont empaquetés sur exactement max(2, bits needed for the palette) bits chacun, en commençant par le bit de poids faible, et une entrée peut chevaucher la frontière entre deux longs. Une palette de 5 entrées utilise 3 bits par bloc ; une de 300 entrées en utilise 9.
Le plancher de 2 bits compte : même une palette de deux blocs ne descend pas sous 2 bits par entrée, donc une construction monochrome n'est pas aussi petite que le calcul le suggère.
Bedrock est en little-endian
.mcstructure est l'exception à un niveau inférieur : Bedrock écrit du NBT little-endian là où tous les formats Java écrivent du big-endian. Cela se décide avant toute analyse de format — lisez les octets avec le mauvais boutisme et vous n'obtenez pas une structure erronée, vous obtenez du charabia qui échoue à l'analyse tout court.
Ce que cela signifie concrètement
Si un schéma ne s'ouvre pas quelque part, la première question n'est pas « le fichier est-il corrompu » mais « ce fichier est-il ce que son nom dit ». Un .schematic téléchargé sur une page de téléchargement a bien plus de chances d'être du MCEdit que du Sponge, et un outil qui fait confiance à l'extension rejettera un fichier parfaitement valide.
Et lorsqu'on compare deux exports de la même construction, les différences de taille tiennent surtout à l'encodage plutôt qu'au contenu — un .nbt vanilla vidé d'une construction creuse et un .litematic empaqueté en bits de la même chose résolvent des problèmes différents.