Guides / Building & Resources

Ein Bedrock-Skin-Pack besteht aus vier Dateien, und zwei seiner Fehler sind stillschweigend

Zwei UUIDs, die sich unterscheiden müssen, eine Lang-Datei, die nicht optional ist, und Skin-Schlüssel, die Satzzeichen entfernen – so werden „Mein Skin!“ und „Mein Skin?“ zu einem Skin ohne Fehler.

2026-08-01

Ein .mcpack ist ein Zip-Archiv mit einer anderen Erweiterung, und ein Skin-Pack darin benötigt genau vier Dateitypen:

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

Drei der vier sind leicht richtig zu machen. Die interessanten Fehler ergeben sich alle aus der Beziehung zwischen ihnen.

Die beiden UUIDs müssen sich unterscheiden

manifest.json enthält eine UUID in seinem header und eine weitere in seinem skin_pack Modul:

{
  "format_version": 1,
  "header":  { "name": "…", "uuid": "…", "version": [1, 0, 0] },
  "modules": [ { "type": "skin_pack", "uuid": "…", "version": [1, 0, 0] } ]
}

Es sind zwei separate Identitäten – das Pack und das Ding im Pack – und die Wiederverwendung eines Wertes für beide ist ein echter Fehler, auch wenn sich zur Bauzeit niemand beschwert.

Es gibt eine zweite, subtilere Konsequenz: Ein erneuter Import mit denselben UUIDs wird als dasselbe Pack behandelt, und Minecraft behält stillschweigend die Kopie, die es bereits hat. Das Bearbeiten eines Packs, das Neuerstellen mit denselben Identifikatoren und der erneute Import sieht so aus, als hätte es nichts bewirkt. Jeder Build von dieser Seite erhält aus genau diesem Grund neue UUIDs, weshalb ein erneuter Import eines bearbeiteten Packs einen neuen Download und kein erneutes Zippen des alten erfordert.

Die Lang-Datei ist nicht optional

skins.json enthält niemals einen Anzeigenamen. Es enthält einen Schlüssel, und texts/en_US.lang ordnet diesen Schlüssel Text zu:

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

Liefert man das Pack ohne die Lang-Datei aus, gibt es keine Fehler – jeder Skin erscheint einfach im Spiel unter seinem Rohschlüssel. Dies ist der häufigste Grund, warum ein handgefertigtes Pack fehlerhaft aussieht, obwohl es einwandfrei validiert wird.

Schlüssel entfernen Satzzeichen, und Duplikate kollabieren

Ein Schlüssel muss alphanumerisch sein. Alles andere wird entfernt:

Die ersten beiden Zeilen sind die Falle. Zwei von einem Menschen unterschiedlich benannte Skins werden zu einem Schlüssel, und ein doppelter Schlüssel führt nicht zu einem Fehler – er kollabiert stillschweigend zu einem einzigen Skin im Spiel. Sie laden zwölf Skins hoch, erhalten elf, und nichts sagt Ihnen, welcher fehlt.

Der Builder hier schützt sich davor, indem er jedem bereits verwendeten Schlüssel einen Zähler anhängt, sodass der zweite MySkin zu MySkin1 wird. Gut zu wissen, wenn Sie ein Pack von Hand zusammenstellen: Die Prüfung, die Sie benötigen, bezieht sich auf die bereinigten Namen, nicht auf die, die Sie eingegeben haben.

Ein Name, der ausschließlich aus Satzzeichen besteht, hinterlässt überhaupt nichts, sodass er auf Skin plus seine Position in der Liste zurückfällt.

Slim benötigt den richtigen Geometrie-String

Jeder Eintrag benennt ein Modell, und es gibt zwei:

• geometry.humanoid.custom – klassisch, 4-Pixel-Arme
• geometry.humanoid.customSlim – schlank, 3-Pixel-Arme

Dies falsch zu machen ist die übliche Ursache dafür, dass ein Skin mit Alex-Proportionen mit Steves klobigen Armen erscheint. Die Textur ist in Ordnung; das Modell ist das, wonach gefragt wird. Der Pack-Builder leitet es ab, indem er die vierte Armspalte abtastet, aber ein handgeschriebenes skins.json muss es explizit angeben, und die beiden Strings unterscheiden sich am Ende um vier Zeichen.

Einträge enthalten auch "type": "free", und ein Umhang ist eine optionale zusätzliche PNG-Datei, die vom selben Eintrag referenziert wird – der Umhang reist innerhalb des Skin-Packs und nicht als separater Download.

Skin-Paket-Ersteller →