Bedrock 애드온은 zip이며, 매니페스트 때문에 실패한다
거부된 .mcaddon 가져오기 대부분은 유효한 zip이지만 헤더 한 줄이 잘못된 것이며, 오류 메시지는 어느 필드가 문제인지 알려주지 않는다. 헤더와 모듈 UUID 중복, 중첩된 팩 폴더가 흔한 원인이다.
.mcaddon은 확장자만 다른 zip 압축 파일이며, 게임이 이를 거부하는 이유는 zip과는 아무 관련이 없다. 보통의 원인은 manifest.json이다. 즉, 헤더 UUID와 모듈 UUID가 서로 달라야 하는 작은 파일인데, format_version이 대상으로 하는 게임 버전과 일치하지 않는 경우다.
두 개의 UUID, 절대 같은 것을 쓰지 말 것
매니페스트에는 header와 modules 배열이 들어 있다. 각각 고유한 uuid이 필요하며, 둘에 같은 것을 재사용하는 것이 가장 흔한 거부 사유다:
{
"format_version": 2,
"header": {
"name": "My Pack",
"description": "Example",
"uuid": "aaaaaaaa-0000-0000-0000-000000000000",
"version": [1, 0, 0],
"min_engine_version": [1, 21, 0]
},
"modules": [
{
"type": "data",
"uuid": "bbbbbbbb-0000-0000-0000-000000000001",
"version": [1, 0, 0]
}
]
}UUID는 32자리 16진수를 하이픈으로 구분된 다섯 그룹으로 표기한 128비트 값이다. 아무 생성기나 써도 되지만, 중복은 안 된다. version과 min_engine_version은 문자열이 아니라 정수 세 개짜리 배열이다. "1.0.0"는 거부된다.
Java에는 매니페스트가 아예 없다
이것이 에디션을 오가며 작업하는 사람들이 자주 걸리는 부분이다. Java 리소스 팩은 지원하는 형식을 선언하는 pack.mcmeta을 포함한다(현재 버전에서는 min_format과 max_format). Bedrock은 UUID와 모듈 목록이 담긴 manifest.json을 포함한다. 어느 쪽 파일도 다른 에디션에서는 읽지 않으며, 압축 파일 이름을 바꾼다고 팩이 이식되지도 않는다.
가져오기 전에 확인할 것
압축을 풀고 최상위 구조를 살펴보라. 한 단계 폴더 안에 중첩된 팩, 즉 manifest.json 대신 MyPack/manifest.json인 경우에는 오류 없이 아무것도 가져오지 않는다. 매니페스트는 각 팩의 루트, 즉 그것이 설명하는 폴더 옆에 있어야 한다.
블록 모델은 별개의 형식이다
Java 블록 모델 JSON은 Bedrock 지오메트리 파일이 아니며, 둘은 서로 호환되지 않는다. Java 모델은 보통 parent에 textures 맵을 더한 것에 불과하다. 즉, elements 육면체 목록은 사용자 지정 모양에만 필요하다. 반면 Bedrock은 자체 minecraft:geometry 형식으로 모양을 설명한다. 둘 다 한 블록을 16단위로 측정하기 때문에, 한 에디션에서는 제대로 보이던 모델이 다른 에디션에서는 아무것도 가져오지 못하는 일이 생긴다.
레지스트리 이름은 호환되지 않는다
Bedrock과 Java는 같은 콘텐츠에 대해 서로 다른 식별자를 사용한다. 마법 부여, 효과, 생물 군계에 Java 이름을 참조하는 팩은 로드된 뒤 아무 일도 하지 않는데, 그 이름이 어떤 항목으로도 해석되지 않기 때문이다. 레지스트리 자체도 에디션마다 크기가 다르므로, 한 에디션의 목록을 기준으로 만든 팩이 다른 에디션에서 완전하다고 가정할 수 없다.
매니페스트를 검증하고, 압축 파일 구조를 확인하고, Bedrock & Pack Tools에서 블록 모델을 생성하라.