Guías / Construcción y recursos
La esponja y el bloque estructural no son el mismo archivo
Un .schem, un .litematic y un .mcstructure de Bedrock parecen intercambiables hasta que conviertes uno y descubres que cada cofre, entidad y estado de bloque ha desaparecido.
Un .schem y un .litematic guardan una construcción, y convertir entre ellos es donde la mayoría de los jugadores descubre que los dos formatos nunca coincidieron en qué es una construcción. Uno almacena una única región de bloques. El otro puede contener varias regiones con nombre, cada una con su propia paleta. Traslada una aldea de uno a otro y las casas sobrevivirán, pero su contenido no.
Qué guarda realmente cada formato
| Formato | Dónde funciona | Estados de bloque | Entidades de bloque | Entidades |
|---|---|---|---|---|
.schem | Java, WorldEdit/Sponge | sí | sí | sí |
.litematic | Java, Litematica | sí | sí | sí |
.nbt structure | Java, bloques estructurales | sí | sí | sí |
.mcstructure | Bedrock | sí | sí | sí |
Las columnas parecen idénticas, y ahí está la trampa. La diferencia está en la gestión de paletas y el espacio de coordenadas, no en la lista de características.
La paleta es la parte frágil
Cada uno de estos formatos almacena los bloques como un índice dentro de una paleta: una lista de tipos de bloque únicos que usa el archivo, donde cada posición contiene un número que apunta a esa lista. Una construcción que usa unos cientos de tipos de bloque distintos lleva una paleta de ese tamaño, y las posiciones no son más que números enteros.
Eso significa que el archivo solo es legible si el lector puede resolver cada entrada de la paleta. Un bloque añadido en una versión reciente de Java no tiene equivalente en Bedrock, así que una conversión de Java a Bedrock tiene que sustituirlo o descartarlo. El aire es el sustituto habitual, y un muro al que le faltan bloques misteriosamente casi siempre se debe a esto, no a una corrupción.
Java y Bedrock nombran el mismo bloque de forma distinta
Aquí es donde Java y Bedrock divergen de verdad. Bedrock escribe los estados de bloque como block_type más un conjunto de estados clave-valor; Java escribe un ID con espacio de nombres más un mapa de estados. El mismo bloque físico puede ser minecraft:oak_stairs[facing=east,half=bottom] en un lado y weirdo_direction más upside_down_bit en el otro: nombres y valores de estado diferentes, no los mismos reordenados.
Las escaleras, losas, vallas, muros, puertas y componentes de redstone son los que se dan la vuelta. Una escalera que se renderiza boca abajo tras la conversión es un error de mapeo de estados, no un archivo defectuoso.
Los bloques estructurales no guardan lo que crees
Un bloque estructural que guarda en .nbt escribe un cuadro delimitador, y ese cuadro está limitado a 48 bloques por eje. El juego no divide una construcción más grande: lo que queda fuera del cuadro simplemente no está en el archivo. Si a una construcción convertida le falta su extremo lejano, revisa el cuadro original antes de sospechar del conversor.
Las entidades se almacenan por separado de los bloques en todos estos formatos. Los marcos de objetos, soportes para armaduras, cuadros y criaturas no son bloques, y un conversor que solo recorre la paleta de bloques los descartará sin avisar.
Previsualiza antes de fiarte
La lista de materiales es la comprobación más rápida: si el recuento de bloques del archivo convertido no coincide con el del original, algo se ha sustituido. La previsualización por capas lo muestra al instante, una franja horizontal a la vez, sin cargar la construcción en un mundo.
Convierte entre .litematic, .schem, estructura de Java .nbt y Bedrock .mcstructure, con previsualización por capas y lista de materiales, en el Conversor de esquemas.