Zuerst die Entscheidung verstehen, dann die Datei bauen
In 1.21.4+ ist eine item definition nicht einfach nur ein längerer JSON-Block. Sie beantwortet eine klarere Frage: Bleibt das Item immer gleich, wechselt es über eine Eigenschaft, läuft es über numerische Schwellen oder reagiert es auf einen einfachen Wahr/Falsch-Zustand? Sobald diese Frage sauber formuliert ist, wirkt auch die Datei deutlich weniger schwer.
Genau dabei hilft der Builder. Er erfindet keine künstliche Logik, sondern hält die Hülle klein, zeigt den Zielpfad früh an und lenkt euch zu der Branch-Art, die wirklich zur Aufgabe passt — statt zu der, die nur vertraut aus alten Override-Mustern aussieht.
Eine schnelle mentale Karte vor dem ersten Klick
| Branch | Dann benutzen | Bestes Signal |
|---|---|---|
minecraft:model | Das Item braucht genau ein festes Aussehen. | Eigentlich findet gar kein Entscheidungsbaum statt. |
minecraft:select | Eine benannte Eigenschaft wählt zwischen Zweigen. | Die Zustände lassen sich mit Worten wie pass, relic, broken, ritual beschreiben. |
minecraft:range_dispatch | Eine Zahl überschreitet geordnete Schwellen. | Es gibt Stufen, Ladung, Abnutzung oder Fortschritt. |
minecraft:condition | Das Ergebnis hängt von Wahr/Falsch ab. | Das Item ist ausgewählt, wird benutzt, ist beschädigt oder grundsätzlich binär. |
Konkretes Beispiel: ein Relikt, drei sichtbare Zustände
Stellt euch ein Story-Item vor, das meistens versiegelt aussieht, während eines Rituals leuchtet und nach dem Ereignis aufreißt. Das sind nicht drei lose Dateien, sondern ein einziger Entscheidungsbaum. Wenn der Zustand aus einem stringartigen Custom-Wert kommt, landet ihr sehr wahrscheinlich bei
select.Der Builder hilft hier, weil der Baum lesbar bleibt: erst die Branch-Art wählen, dann den Fallback festlegen und danach die benannten Zustände ergänzen. Das Problem ist nicht das Tippen. Das Problem ist, dass das Team den Sinn der Definition auch eine Woche später noch ruhig lesen kann.
Ein sicherer Workflow im Builder
- Legt zuerst den Dateipfad unter
assets/<namespace>/items/fest. - Wählt die kleinste Branch-Art, die das Verhalten ehrlich beschreibt.
- Setzt den Fallback, bevor die schöneren Sonderfälle dazukommen.
- Verwendet die Quick Starts, wenn schon klar ist, dass ihr einen direkten Model-Fall, einen Zustandswechsel oder Schwellenwerte baut.
- Kopiert das JSON, testet ein einziges Item im Spiel und vervielfältigt das Muster erst danach im Pack.
Wann ihr zu anderen Tools wechseln solltet
Der Item-Model-Builder gehört zur visuellen Definitionsebene. Wenn euch noch die /give-Kommandoseite fehlt, wechselt zum Custom-Item-Builder. Wenn Texturen und Modelldateien noch in einen echten Browser-Resource-Pack-Workflow müssen, schließt das im Pack-Generator ab.
Diese Trennung ist gesund. Eine visuelle Definitionsdatei bleibt leichter lesbar und debugbar, wenn Befehlsebene und Pack-Verpackung nicht gleichzeitig an ihr ziehen.
Häufige Fehler
selectwählen, obwohl eine direktemodel-Datei vollkommen gereicht hätte.- Den Fallback auslassen und die Datei schon ab der ersten Zeile unnötig schwer lesbar machen.
- Numerische und benannte Erwartungen mischen, ohne festzulegen, welche Eigenschaft das Verhalten wirklich steuert.
- JSON-Datei, Modellpfad und internen Teamnamen so unterschiedlich benennen, dass die Verbindung verloren geht.
- Die Struktur auf viele Items kopieren, bevor überhaupt ein einziger Live-Fall im Spiel geprüft wurde.
FAQ
Brauche ich immer select, sobald CustomModelData vorkommt?
Nein. Wenn das Item nur eine visuelle Identität hat, ist eine direkte model-Datei sauberer. select lohnt sich, wenn eine Definition wirklich in mehrere Erscheinungen verzweigen muss.
Wann ist range_dispatch besser?
Immer dann, wenn die Veränderung geordnet und numerisch ist: Schaden, Ladung, Fortschritt oder jede andere Schwellenlogik.
Warum mit dem Fallback anfangen?
Weil der Fallback die ruhige Grundlesart des Items ist. Wenn dieser Anker stimmt, lassen sich alle weiteren Zweige leichter bewerten.
Kann ich die Item-Kommandos vom Definition-File trennen?
Ja, und genau das ist eine der stärksten Seiten des neuen Systems. Die visuelle Datei muss die Befehlslogik nicht mitschleppen.
Was ist, wenn ich nur einen einfachen Pass auf Paper-Basis brauche?
Dann reicht fast immer ein direktes minecraft:model-File. Ein kleiner Bedarf braucht keinen unnötig großen Entscheidungsbaum.