리소스 팩 텍스처 경로 세 개는 평면적이다. 몹만 중첩되고, 그게 문제의 시작일 뿐이다
아이템, 블록, 그림은 파일 하나만 있으면 된다. 몹은 자기 이름을 딴 폴더에 들어가는데, 대부분의 몹은 그 폴더에 파일이 여러 개라서 파일 하나만 덮어쓰면 조용히 빠뜨리게 된다.
리소스 팩에서 텍스처를 덮어쓴다는 것은 게임이 찾는 정확한 경로에 PNG를 넣는 것이다. 흔한 네 종류 중 세 종류는 그 경로가 완전히 규칙적이다. 네 번째는 그렇지 않은데, 그 불규칙성은 처음 보이는 것보다 더 심각하다.
네 가지 경로
assets/minecraft/textures/item/<name>.png
assets/minecraft/textures/block/<name>.png
assets/minecraft/textures/painting/<name>.png
assets/minecraft/textures/entity/<name>/<name>.png ← note the folder아이템, 블록, 그림은 공용 디렉터리에 파일 하나씩이다. 몹은 자기만의 디렉터리로, 몹 이름을 딴 폴더 안에 보통 몹 이름을 딴 파일이 들어 있다. 그래서 좀비 텍스처는 entity/zombie/zombie.png이지 entity/zombie.png가 아니다.
몹은 mob/가 아니라 entity/ 아래에 있다는 점도 기억해 두자. 폴더 이름은 게임 개념이 아니라 코드 개념을 따른 것이다.
진짜 문제는 몹이 흔히 파일 하나가 아니라는 점이다
중첩 구조는 한 번 보면 외우기 쉽다. 실제로 덮어쓰기를 망가뜨리는 것은 그 폴더 안에 또 무엇이 들어 있느냐다.
<name>/<name>.png 경로는 다음 열 종류에 맞다:
좀비 · 스켈레톤 · 크리퍼 · 양 · 거미 · 엔더맨 · 늑대 · 마녀 · 블레이즈 · 주민
이 중 여섯 종류 — 크리퍼, 스켈레톤, 거미, 엔더맨, 마녀, 블레이즈 — 는 그 파일 하나가 몹 전체다(발광하는 눈과 충전된 크리퍼의 광택은 별도 오버레이다). 좀비, 양, 주민, 늑대는 옆에 더 많은 파일을 둔다. 아기 텍스처, 양털, 주민 직업과 바이옴 유형, 그리고 여덟 가지 늑대 변종이 더 있다 — wolf.png은 창백한 늑대일 뿐이다.
나머지는 텍스처를 다른 하위 폴더에 두거나 여러 파일에 흩어 놓을 수 있다. 아기 변종, 길들인 변종, 색상 변종 등이다. 말은 이미지 하나가 아니다. 고양이도 이미지 하나가 아니다. 그런 경우 파일 하나를 교체하면 몹의 한 상태만 바뀌고 나머지는 그대로 남는데, 게임에서는 "내 팩이 반만 적용됐다"로 보인다.
이 실패 유형을 꼭 새겨 두자. 경로가 틀리면 텍스처 변화가 아예 없지만, 경로 집합이 불완전하면 부분적으로만 바뀐다 — 그리고 후자가 진단하기 훨씬 어렵다. 팩이 작동하는 것처럼 보이기 때문이다.
우선순위는 위쪽이 먼저인데, zip이 암시하는 것과는 다르다
팩을 병합할 때 경로 충돌에서는 목록에 먼저 나온 팩이 이긴다. 인덱스 0이 가장 높은 우선순위다.
이 점을 분명히 짚을 필요가 있다. 파일을 겹쳐 쌓는 방식에서 사람들이 가져오는 사고 모델, 즉 나중에 쓴 것이 이긴다는 모델을 뒤집기 때문이다. 여기서는 목록의 첫 번째 팩의 item/diamond_sword.png 버전이 살아남고, 그 아래의 모든 팩은 위쪽이 차지하지 않은 경로만 채운다.
팩 정체성에 관한 두 가지 세부 사항
pack.png은 아이콘이며 zip 루트에 있다, assets/ 아래가 아니다. 64 × 64로 정사각형이 된다 — 정사각형이 아닌 이미지는 레터박스가 아니라 크기 조정이 되므로, 16:9로 디자인한 아이콘은 여백이 생기는 게 아니라 왜곡되어 나온다.
팩 이름의 색상 코드는 그대로의 텍스트다. § 문자는 입력한 그대로 pack.mcmeta에 들어가고 Minecraft가 표시할 때 렌더링한다: §a 초록, §c 빨강, §b 청록, §e 노랑, §d 분홍, §l 굵게, §r 초기화. 이스케이프 단계도 없고 JSON 텍스트 컴포넌트도 관여하지 않는다 — 평범한 문자열에 들어간 날것의 섹션 기호가 전부다.