스펀지와 구조물 블록은 같은 파일이 아닙니다
.schem, .litematic, 그리고 Bedrock .mcstructure는 서로 호환되는 것처럼 보이지만, 변환하는 순간 모든 상자, 엔티티, 블록 상태가 사라집니다.
.schem와 .litematic는 둘 다 건축물을 담고 있지만, 이 둘 사이를 변환하다 보면 대부분의 플레이어가 두 형식이 '건축물이란 무엇인가'에 대해 한 번도 합의한 적이 없다는 사실을 깨닫게 됩니다. 하나는 블록 영역을 저장합니다. 다른 하나는 배치 이력을 저장합니다. 마을을 이 둘 사이로 옮기면 집은 살아남지만 그 안의 내용물은 그렇지 않습니다.
각 형식이 실제로 담고 있는 것
| 형식 | 실행 환경 | 블록 상태 | 블록 엔티티 | 엔티티 |
|---|---|---|---|---|
.schem | Java, WorldEdit/Sponge | 예 | 예 | 예 |
.litematic | Java, Litematica | 예 | 예 | 예 |
.nbt structure | Java, 구조물 블록 | 예 | 예 | 예 |
.mcstructure | Bedrock | 예 | 예 | 예 |
칼럼이 똑같아 보이는 것이 함정입니다. 차이는 기능 목록이 아니라 팔레트 처리와 좌표 공간에 있습니다.
팔레트가 취약한 부분입니다
이 형식들은 모두 블록을 팔레트(palette) 의 인덱스로 저장합니다. 팔레트란 파일이 사용하는 고유 블록 유형의 목록이며, 각 위치는 그 목록을 가리키는 숫자를 담고 있습니다. 수백 가지의 서로 다른 블록 유형을 사용하는 건축물은 그만한 크기의 팔레트를 가지며, 위치는 그저 정수일 뿐입니다.
즉, 파일을 읽으려면 읽는 쪽이 모든 팔레트 항목을 해석할 수 있어야 합니다. 최신 Java 버전에서 추가된 블록은 Bedrock에 대응하는 것이 아예 없으므로, Java에서 Bedrock으로 변환할 때는 이를 대체하거나 버려야 합니다. 보통은 공기가 대체물이 되며, 블록이 신비롭게 빠져 있는 벽은 거의 항상 손상이 아니라 이 때문입니다.
Java와 Bedrock은 같은 블록을 다르게 부릅니다
여기서 Java와 Bedrock이 진짜로 갈라집니다. Bedrock은 블록 상태를 block_type에 키-값 상태 집합을 더한 형태로 기록하고, Java는 네임스페이스가 붙은 ID에 상태 맵을 더한 형태로 기록합니다. 같은 물리적 블록이 한쪽에서는 minecraft:oak_stairs[facing=east,half=bottom]이고 다른 쪽에서는 순서가 다른 상태 집합일 수 있습니다.
계단, 반 블록, 울타리, 담장, 문, 레드스톤 부품이 특히 뒤집히는 것들입니다. 변환 후 거꾸로 렌더링되는 계단은 잘못된 파일이 아니라 상태 순서 불일치입니다.
구조물 블록은 생각하는 것을 저장하지 않습니다
구조물 블록이 .nbt로 저장할 때는 경계 상자를 기록하며, 그 상자에는 축마다 딱딱한 크기 제한이 있습니다. 상자보다 큰 건축물은 하나의 파일로 저장되지 않습니다. 게임이 나누거나 거부합니다. 변환된 건축물의 먼 쪽 끝이 없다면, 변환기를 의심하기 전에 원본 상자를 확인하세요.
엔티티는 이 모든 형식에서 블록과 별도로 저장됩니다. 아이템 액자, 갑옷 거치대, 그림, 몹은 블록이 아니며, 블록 팔레트만 훑는 변환기는 이들을 소리 없이 버립니다.
믿기 전에 미리 보세요
재료 목록이 가장 빠른 점검 방법입니다. 변환된 파일의 블록 수가 원본과 맞지 않으면 무언가가 대체된 것입니다. 레이어 미리 보기는 건축물을 월드에 불러오지 않고도 가로 한 층씩 즉시 보여줍니다.
.litematic, .schem, Java structure .nbt, Bedrock .mcstructure 사이를 레이어 미리 보기와 재료 목록과 함께 스키매틱 변환기에서 변환하세요.