Ang Bedrock skin pack ay apat na file, at dalawa sa mga failure mode nito ay tahimik
Dalawang UUID na kailangang magkaiba, isang lang file na hindi opsyonal, at mga skin key na nag-aalis ng bantas — kaya ang 'My Skin!' at 'My Skin?' ay nagiging iisang skin nang walang error.
A .mcpack is a zip with a different extension, and a skin pack inside one needs exactly four kinds of file:
manifest.json a header and a skin_pack module, each with its own UUID
skins.json one entry per skin: texture, geometry, and a KEY
texts/en_US.lang the display names — skins.json holds only keys
*.png the textures themselves
Madaling makuha nang tama ang tatlo sa apat. Ang mga kapansin-pansing error ay nagmumula sa ugnayan sa pagitan ng mga ito.
Dapat magkaiba ang dalawang UUID
manifest.json carries a UUID in its header and another in its skin_pack module:
{
"format_version": 1,
"header": { "name": "…", "uuid": "…", "version": [1, 0, 0] },
"modules": [ { "type": "skin_pack", "uuid": "…", "version": [1, 0, 0] } ]
}
Ang mga ito ay dalawang magkahiwalay na pagkakakilanlan — ang pack, at ang bagay sa loob ng pack — at ang muling paggamit ng iisang value para sa dalawa ay isang tunay na error kahit walang lumalabas na babala sa oras ng pag-build.
Mayroon pang pangalawa at mas banayad na resulta: ang muling pag-import gamit ang parehong mga UUID ay itinuturing bilang parehong pack, at tahimik na pinapanatili ng Minecraft ang kopyang mayroon na ito. Ang pag-edit ng isang pack, pag-rebuild nito gamit ang parehong mga identifier at muling pag-import ay mukhang walang nagawa. Bawat build mula sa pahinang ito ay nakakakuha ng mga bagong UUID sa mismong kadahilanang iyon, kaya naman ang muling pag-import ng na-edit na pack ay nangangailangan ng bagong download sa halip na muling i-zip ang luma.
Hindi opsyonal ang lang file
skins.json never contains a display name. It contains a key, at texts/en_US.lang maps that key to text:
skinpack.<PackKey>=My Pack
skin.<PackKey>.<SkinKey>=My First Skin
Ipadala ang pack nang walang lang file at walang mag-e-error — bawat skin ay lilitaw lamang sa laro sa ilalim ng raw key nito. Ito ang pinakakaraniwang dahilan kung bakit mukhang sira ang isang manu-manong binuong pack kahit pumapasa sa validation.
Tinatanggal ng mga key ang bantas, at nagsasama ang mga duplicate
Ang isang key ay dapat alphanumeric. Ang lahat ng iba pa ay tinatanggal:
| iyong pangalan | key |
|---|---|
My Skin! | MySkin |
My Skin? | MySkin |
Skin #2 | Skin2 |
!!! | Skin1 (fallback, by position) |
Ang unang dalawang hilera ang patibong. Ang dalawang skin na pinangalanan nang magkaiba ng tao ay nagiging iisang key, at ang duplicate na key ay hindi nag-e-error — tahimik itong nagsasama sa iisang skin sa laro. Nag-upload ka ng labindalawang skin, nakakuha ng labing-isa, at walang nagsasabi sa iyo kung alin ang nawala.
Pinoprotektahan ito ng builder dito sa pamamagitan ng pagdaragdag ng counter sa anumang key na nagamit na nito, kaya ang pangalawa MySkin becomes MySkin1. Worth knowing if you assemble a pack by hand: the check you need is on the tinanggal na mga pangalan, hindi ang mga tinype mo.
Ang isang pangalan na puro bantas ay walang iniiwan, kaya bumabalik ito sa Skin plus its position in the list.
Kailangan ng Slim ang tamang geometry string
Bawat entry ay nagpapangalan ng isang model, at mayroong dalawa:
geometry.humanoid.custom— classic, 4-pixel armsgeometry.humanoid.customSlim— slim, 3-pixel arms
Ang pagkakamali rito ang karaniwang sanhi ng isang skin na may proporsyon ni Alex na lumilitaw na may mala-blokeng mga braso ni Steve. Maayos ang texture; ang model ang siyang hinihingi. Hinihinuha ito ng pack builder sa pamamagitan ng pagsusuri sa ikaapat na column ng braso, ngunit ang isang manu-manong isinulat na skins.json has to say it explicitly, and the two strings differ by four characters at the end.
Naglalaman din ang mga entry ng "type": "free", and a cape is an optional extra PNG referenced from the same entry — the cape travels inside the skin pack rather than as a separate download.