Een Bedrock-skinpack bestaat uit vier bestanden, en twee foutmodi treden stilzwijgend op

Twee UUID's die moeten verschillen, een lang-bestand dat niet optioneel is en skin-sleutels die leestekens verwijderen — waardoor 'My Skin!' en 'My Skin?' zonder foutmelding één skin worden.

2026-08-01

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

Drie van de vier zijn eenvoudig goed te krijgen. De interessante fouten ontstaan allemaal door de relatie daartussen.

De twee UUID's moeten verschillen

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] } ]
}

Het zijn twee afzonderlijke identiteiten — het pack en datgene in het pack — en dezelfde waarde voor beide hergebruiken is een echte fout, ook al geeft niets een foutmelding tijdens het bouwen.

Er is een tweede, subtieler gevolg: een herimport met dezelfde UUID's wordt behandeld als hetzelfde pack, en Minecraft behoudt stilzwijgend de kopie die het al heeft. Een pack bewerken, opnieuw opbouwen met dezelfde identifiers en opnieuw importeren lijkt alsof het niets heeft gedaan. Elke build van deze pagina krijgt om precies die reden nieuwe UUID's, en daarom vereist het opnieuw importeren van een bewerkt pack een nieuwe download in plaats van het opnieuw inpakken van het oude.

Het lang-bestand is niet optioneel

skins.json never contains a display name. It contains a sleutel, en texts/en_US.lang maps that key to text:

skinpack.<PackKey>=My Pack
skin.<PackKey>.<SkinKey>=My First Skin

Lever het pack zonder het lang-bestand en er treedt geen fout op — elke skin verschijnt in het spel simpelweg onder de ruwe sleutel. Dit is de meest voorkomende reden waarom een handmatig samengesteld pack er kapot uitziet terwijl het wel valideert.

Sleutels verwijderen leestekens en duplicaten vallen samen

Een sleutel moet alfanumeriek zijn. Al het andere wordt verwijderd:

De eerste twee rijen vormen de valkuil. Twee skins met duidelijk verschillende namen door een mens worden één sleutel, en een dubbele sleutel geeft geen foutmelding — het valt in de game stilzwijgend samen tot één enkele skin. Je uploadt twaalf skins, krijgt er elf, en niets vertelt je welke er ontbreekt.

De maker hier beschermt daartegen door een teller toe te voegen aan elke sleutel die al is gebruikt, zodat de tweede MySkin becomes MySkin1. Worth knowing if you assemble a pack by hand: the check you need is on the gestript namen, niet degene die je hebt getypt.

Een naam die volledig uit leestekens bestaat laat helemaal niets over, dus valt terug op Skin plus its position in the list.

Slim heeft de juiste geometry-tekenreeks nodig

Elk item benoemt een model, en er zijn er twee:

• geometry.humanoid.custom — classic, 4-pixel arms
• geometry.humanoid.customSlim — slim, 3-pixel arms

Dit verkeerd doen is de gebruikelijke oorzaak van een skin met Alex-proporties die verschijnt met Steve's blokkerige armen. De textuur is prima; het model is waar om wordt gevraagd. De packbuilder leidt dit af door de vierde armkolom te controleren, maar een handgeschreven skins.json has to say it explicitly, and the two strings differ by four characters at the end.

Vermeldingen bevatten ook "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.