A extensão não revela o formato do schematic — 31 de 33 arquivos .schematic eram de outro formato
Cinco formatos, quatro maneiras diferentes de empacotar blocos, e .schematic é compartilhado por dois deles. Inspecionar a raiz NBT é melhor do que confiar no nome do arquivo, com evidências contadas.
Existem cinco formatos de schematic em circulação, e o nome do arquivo é apenas uma pista. O visualizador identifica o formato pelo conteúdo, e há uma razão mensurável para fazer isso.
Cinco formatos, cinco extensões
| extensão | formato |
|---|---|
.nbt | estrutura vanilla |
.schem | Sponge |
.schematic | Sponge — por padrão |
.litematic | Litematica |
.mcstructure | Bedrock |
A linha problemática é .schematic. Essa extensão é compartilhada pelo formato clássico MCEdit e pelo do Sponge, e os arquivos são renomeados por pessoas que não sabem ou não se importam.
Contado em um corpus real: de 33 arquivos .schematic, 31 eram MCEdit, um era uma estrutura vanilla e um era Litematica. Portanto, a suposição padrão da extensão está errada para quase todos eles, e dois arquivos não eram .schematic em nenhum sentido — apenas mal nomeados.
A solução é inspecionar a raiz NBT e deixar o que o arquivo é prevalecer sobre o que ele é chamado:
- uma chave
Regions→ Litematica paletteeblocks→ estrutura vanilla- caso contrário, o teste de formato MCEdit, depois volta para a extensão
Quatro maneiras de empacotar os mesmos blocos
Os formatos não diferem cosmeticamente. Cada um armazena dados de bloco de uma maneira genuinamente diferente, e cada escolha tem uma consequência:
Estrutura vanilla .nbt — uma lista esparsa. Uma entrada por bloco colocado, cada uma nomeando um índice de paleta. O ar está simplesmente ausente, então uma construção oca é barata.
Sponge .schem — um fluxo de varint. Índices de paleta empacotados como inteiros de largura variável: sete bits de carga útil por byte, bit de ordem superior definido para continuar. Paletas pequenas custam um byte por bloco; uma paleta com mais de 127 entradas começa a custar dois para os índices mais altos. Denso, mas autoexplicativo.
MCEdit .schematic — um array de bytes plano. Um byte por bloco, então 256 tipos de bloco no máximo — que é exatamente por que ele precisa de um array lateral AddBlocks empacotando um nono bit como um nibble por bloco. Este é um formato de ID numérico legado de antes dos estados de bloco, e seus IDs são resolvidos através de um composto SchematicaMapping em vez de serem nomes.
Litematica .litematic — longs empacotados por bits. Os índices são empacotados em exatamente max(2, bits needed for the palette) bits cada, LSB-first, e uma entrada pode ultrapassar o limite entre dois longs. Uma paleta de 5 entradas usa 3 bits por bloco; uma de 300 entradas usa 9.
O limite inferior de 2 bits importa: mesmo uma paleta de dois blocos não comprime abaixo de 2 bits por entrada, então uma construção monocromática não é tão pequena quanto a matemática sugere.
Bedrock é little-endian
.mcstructure é o diferente em um nível inferior: Bedrock escreve NBT little-endian onde todo formato Java escreve big-endian. Isso é decidido antes que qualquer análise de formato aconteça — leia os bytes com a endianness errada e você não obterá uma estrutura errada, você obterá lixo que falha completamente na análise.
O que isso significa na prática
Se um schematic não abrir, a primeira pergunta não deve ser “o arquivo está corrompido?”, mas “o conteúdo corresponde ao nome?”. Um .schematic baixado da internet tem muito mais chance de ser MCEdit do que Sponge, e uma ferramenta que confia apenas na extensão rejeita um arquivo perfeitamente válido.
E ao comparar duas exportações da mesma construção, as diferenças de tamanho são principalmente sobre codificação em vez de conteúdo — uma estrutura vanilla esparsa .nbt de uma construção oca e um .litematic empacotado por bits da mesma coisa estão resolvendo problemas diferentes.