Minecraft-CustomModelData-Guide

Was ist CustomModelData?

CustomModelData wurde in Minecraft 1.14 hinzugefügt und erlaubt Pack-Erstellern, unterschiedliche Texturen oder 3D-Modelle über Zahlen-IDs an ein Vanilla-Item zu hängen.

Ohne Tags sieht ein Eisenschwert wie das normale Vanilla-Schwert aus.
Mit CustomModelData: 1 kann es wie ein Katana aussehen.
Mit CustomModelData: 2 kann es als 3D-Kettensäge gerendert werden.

Für Server und Spielmechanik bleibt es ein Eisenschwert. Nur die visuelle Hülle auf Client-Seite ändert sich.

Wenn du CustomModelData nutzen willst, ohne alles von Hand zu verdrahten, ist die praktische Kombination auf der Seite so: der Resource-Pack-Generator kümmert sich um die visuelle Seite, und der Custom-Item-Builder hilft dir beim Befehls-Teil.

So funktioniert es

Das Resource-Pack nutzt Item-Modell-Overrides. Das Basismodell weist das Spiel an, ein anderes Modell zu laden, wenn ein bestimmter CustomModelData-Wert vorhanden ist.

{
  "parent": "item/handheld",
  "textures": { "layer0": "item/iron_sword" },
  "overrides": [
    { "predicate": { "custom_model_data": 1 }, "model": "item/custom_katana" },
    { "predicate": { "custom_model_data": 2 }, "model": "item/custom_chainsaw" }
  ]
}

NBT vs Components

Minecraft 1.20.5 hat Item-Daten von alter NBT-Syntax auf Data Components umgestellt. Das visuelle Ergebnis ist ähnlich, aber Befehle haben sich geändert.

Vor 1.20.5

/give @p minecraft:iron_sword{CustomModelData:1} 1

1.20.5 und neuer

/give @p minecraft:iron_sword[minecraft:custom_model_data=1] 1

Der Minecraft Resource-Pack-Generator berücksichtigt diese Umstellung, wenn er give-Befehle für deine Custom-Items zeigt.

Warum CustomModelData auch nach Components relevant bleibt

Wer vom großen Umstieg auf Data Components hört, bekommt leicht das Gefühl, CustomModelData gehöre vor allem in die alte Minecraft-Welt. In der Praxis ist das Kernproblem aber noch da. Ein einzelnes Vanilla-Item muss weiterhin zu Pass, Relikt, Währung, Quest-Hinweis, Shop-Bestand oder ungewöhnlicher Waffe werden können. Genau dafür bleibt CustomModelData einer der saubersten Brückenpfeiler zwischen Spielidee und Resource-Pack-Art.

Verändert hat sich weniger die Aufgabe selbst als der Workflow darum herum. Ältere Setups wollten aus einer einzigen Zahl gleichzeitig Art-Hook, versteckte Logik, Dokumentation und Team-Gedächtnis machen. Moderne Setups werden stärker, wenn diese Rollen getrennt sind. Das Pack entscheidet über das Aussehen. Der Befehl und die versteckten Daten entscheiden darüber, was der Server glauben soll. Sobald man in diesen Schichten denkt, fühlt sich CustomModelData nicht mehr wie obskures Zusatzwissen an, sondern wie ein nützlicher Vertrag zwischen Bild und Logik.

Ein praktischer Workflow: von der Art zum spielbaren Item

1. Mit dem visuellen Plan beginnen

Zuerst sollte klar sein, wie das Item in Hand oder Inventar eigentlich aussehen soll. Wenn ein eigenes Icon, eine Textur oder ein 3D-Modell nötig ist, startet das im Resource Pack. Der Pack-Generator ist hier hilfreich, weil er Ordnerstruktur und JSON-Verkabelung baut, ohne dass jede Datei per Hand verbunden werden muss.

2. Danach eine stabile versteckte Identität vergeben

Für einen echten Server reicht der visuelle Hook fast nie allein. Pass, Token, Vertrag oder Relikt brauchen meist zusätzlich eine versteckte ID, die Quests, Händler und Skripte sauber lesen können. Genau hier ist der Custom Item Builder hilfreich: Die Befehlsseite bleibt lesbar und fällt nicht in eine rätselhafte Zahl zusammen.

3. Syntax passend zur Minecraft-Version wählen

Vor 1.20.5 lebten Item-Daten im älteren NBT-Stil. Danach wechselten sie in Komponenten, und in 1.21.4+ kann die visuelle Schicht mit neuen Modellrouten und erweiterten custom_model_data-Slots noch stärker werden. Wenn die Version falsch gewählt wird, ist die Item-Idee vielleicht richtig und der Befehl scheitert trotzdem.

4. Das Item testen, bevor es in größere Systeme wandert

Das Item einmal spawnen, den sichtbaren Text prüfen, das Pack-Rendering prüfen und erst danach in Villager-Trades, Quest-Belohnungen, Kisten oder Skripte einhängen. Diese Reihenfolge verhindert, dass drei Systeme gleichzeitig debuggt werden, obwohl der eigentliche Fehler noch im Item selbst sitzt.

Häufige Fehler rund um CustomModelData

Eine Zahl soll plötzlich das ganze System tragen

Der klassische Fehler besteht darin, von einer einzigen CustomModelData-Zahl zu verlangen, dass sie Art-Route, versteckte Logik, Dokumentation und Team-Erinnerung zugleich ist. Das skaliert schlecht. Sobald die Item-Bibliothek wächst, weiß niemand mehr, wofür die alten Zahlen überhaupt standen.

Den Befehl bauen, bevor die visuelle Route wirklich steht

Ein Item lässt sich viel leichter debuggen, wenn Modellpfad, Art-Absicht und Fallback schon entschieden sind. Sonst kann der Befehl technisch korrekt sein, während der Spieler immer noch das falsche Icon sieht — und plötzlich scheint “CustomModelData kaputt”, obwohl das Problem im Pack liegt.

Beispiele über verschiedene Syntax-Epochen hinweg kopieren

Viele Forenbeispiele stammen noch aus älteren Befehlsgenerationen. Wird Legacy-NBT in eine Komponentenwelt kopiert oder moderne Syntax in eine ältere Umgebung, bricht der Befehl, obwohl die zugrunde liegende Idee vollkommen legitim bleibt. Genau deshalb hilft ein visueller Builder: Er hält die Befehlsära sichtbar.

Zu glauben, CustomModelData allein genüge auch für Server-Validierung

CustomModelData spricht in erster Linie über Darstellung. Ein echter RP-Server braucht oft zusätzlich versteckte IDs, lesbare Namen und Hilfsdaten für Skripte. Die stärksten Setups lassen das Pack die Optik tragen und die Serverlogik die Validierung.

Kurzes FAQ

Brauche ich in neuen Minecraft-Versionen noch CustomModelData?

Ja, sobald ein einziges Vanilla-Item in mehrere unterschiedliche Looks verzweigen soll. Die Syntax außen herum hat sich geändert, aber das visuelle Grundproblem existiert weiterhin.

Welches praktische Tool-Paar auf der Seite hilft dabei am meisten?

Der Resource-Pack-Generator übernimmt die visuelle Seite, und der Custom Item Builder übernimmt Befehl plus versteckte Item-Logik. Zusammen decken sie den häufigsten echten Workflow ab.

Ist das nur für Waffen interessant?

Nein. Es ist genauso nützlich für Pässe, Gildenabzeichen, Währungen, Briefe, Relikte, Quest-Props, Tokens, dekoratives Essen oder Händler-Bestand. Waffen sind nur die leichtesten Beispiele zum Wiedererkennen.

Was prüfe ich zuerst, wenn das Item falsch aussieht?

Den Pack-Pfad, die Modellverlinkung, die Syntax für die richtige Version und ob der richtige Wert überhaupt wirklich am Item hängt. Oft ist die Idee völlig okay, aber eine dieser Brücken ist nicht verbunden.

Minecraft-CustomModelData-Guide: Was es ist und wie es funktioniert