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 contienen una construcción, y al convertir entre ellos es donde la mayoría de los jugadores descubre que ambos formatos nunca coincidieron en qué es una construcción. Uno almacena una región de bloques. El otro almacena un historial de colocación. Traslada una aldea de uno a otro y las casas sobreviven, pero su contenido no.
Qué guarda realmente cada formato
| Formato | Dónde se usa | Estados de bloque | Entidades de bloque | Entidades |
|---|---|---|---|---|
.schem | Java, WorldEdit/Sponge | sí | sí | sí |
.litematic | Java, Litematica | sí | sí | sí |
Estructura .nbt | 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 la paleta y el espacio de coordenadas, no en la lista de características.
La paleta es la parte frágil
Todos estos formatos almacenan 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 con 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.
Esto 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 eliminarlo. El aire es el sustituto habitual, y un muro con bloques misteriosamente ausentes casi siempre se debe a esto, no a corrupción.
Java y Bedrock nombran el mismo bloque de forma distinta
Aquí es donde Java y Bedrock realmente divergen. 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 un conjunto de estados con otro orden en el otro.
Escaleras, losas, vallas, muros, puertas y componentes de redstone son los que se invierten. Una escalera que se renderiza al revés tras la conversión es un desajuste en el orden 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 tiene un límite de tamaño fijo por eje. Las construcciones más grandes que el cuadro no se guardan como un solo archivo: el juego las divide o las rechaza. Si a una construcción convertida le falta su extremo lejano, revisa el cuadro original antes de culpar al conversor.
Las entidades se almacenan por separado de los bloques en todos estos formatos. Los marcos de objetos, soportes de armadura, cuadros y criaturas no son bloques, y un conversor que solo recorra la paleta de bloques los omitirá sin avisar.
Previsualiza antes de fiarte
La lista de materiales es la comprobación más rápida: si los recuentos de bloques del archivo convertido no coinciden con los 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.