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