select, range_dispatch oder condition? Die richtige Branch für item definitions wählen

Item-Model-Builder öffnen Hauptguide lesen

Zuerst das Signal verstehen, dann die Syntax

Bevor du einen Branch-Typ wählst, stell dir eine einfachere Frage: Sieht das Item immer gleich aus, wechselt es zwischen benannten Zuständen, läuft es über Zahlenschwellen oder reagiert es auf ein Ja-oder-Nein-Signal? Wenn die Antwort ehrlich ist, wird meist auch das JSON deutlich ruhiger.

Genau deshalb wirken so viele neue Definitionen schwerer als nötig. Man greift zuerst zur flexibelsten Branch statt zur kleinsten, die wirklich zum Verhalten passt. Flexibilität klingt sicher, hinterlässt aber oft einen größeren Baum, als das Item braucht.

Schnelle Entscheidungstabelle

Branch	Passt am besten, wenn	Typisches Beispiel
`minecraft:model`	Das Item hat eine einzige feste Optik.	Ein Gildenpass, ein Requisitenbuch oder ein einzelnes Relikt-Icon.
`minecraft:select`	Das Item wechselt zwischen benannten Zuständen.	Versiegelt, erwacht, zerbrochen, verflucht.
`minecraft:range_dispatch`	Eine Zahl überschreitet klare Schwellen.	Ladestufen, Haltbarkeitsbereiche, Fortschrittsstufen.
`minecraft:condition`	Das Ergebnis hängt von wahr oder falsch ab.	In der Hand ausgewählt, in Benutzung, beschädigt oder nicht.

Drei einfache Sprachtests

Beschreibst du den Wechsel mit Wörtern wie Ritual, verbraucht oder aktiv, willst du wahrscheinlich select.
Beschreibst du ihn mit Zahlen wie 0-25-50-75, willst du wahrscheinlich range_dispatch.
Tut das Item entweder etwas oder eben nicht, reicht meist condition.

Beispiele, die die Wahl schnell klären

1. Ein Relikt mit Story-Zuständen

Ist das Relikt versiegelt, leuchtend oder gesprungen, sind das benannte Zustände. Ein sauberer Fall für select.

2. Ein Stab, der sich beim Aufladen verändert

Durchläuft der Stab vier sichtbare Ladestufen, ist das ein Fall für range_dispatch, weil der Wechsel an Schwellen passiert.

3. Eine Karte, die sich nur verändert, solange sie ausgewählt ist

Erscheint die andere Optik nur, wenn der Spieler das Item gerade hält oder benutzt, hält eine einfache condition-Branch die Definition meist kleiner und ruhiger.

Typische Überkonstruktionen

select für ein einzelnes festes Requisit benutzen, weil sich die Branch-Struktur zukunftssicher anfühlt.
range_dispatch wählen, obwohl die eigentliche Veränderung nicht numerisch, sondern benannt ist.
Einen binären Zustand in zu viele Zweige zerlegen und das Debuggen schwerer machen, als das Item es verdient.
Vergessen, dass ein gutes Fallback-Modell zur Lesbarkeit gehört und nicht nur ein Sicherheitsnetz ist.

Wobei der Builder am meisten hilft

Der item_model-Builder ist am stärksten, wenn die Entscheidung fast klar ist, die Hülle drumherum aber noch nervt. Du wählst die Branch, behältst das Fallback im Blick, fügst Fälle in einer kontrollierten Reihenfolge hinzu und kopierst das fertige JSON ins Pack, ohne die äußere Struktur aus dem Gedächtnis neu zu bauen.

Das hilft besonders bei Migrationen. Du baust eine Definition als Prototyp, prüfst, ob die Branch wirklich zum Verhalten passt, und überträgst das Muster erst danach auf eine größere Item-Familie.

FAQ

Brauche ich ab 1.21.4 immer Branches?

Nein. Viele Items sind weiterhin einfach eine direkte Modelldatei. Branches zählen erst, wenn sich das Aussehen wirklich ändert.

Kann ein Item benannte Zustände und Zahlenstufen kombinieren?

Ja, aber genau dann solltest du langsamer werden und zuerst die einfachste äußere Branch wählen, statt im ersten Entwurf alles ineinander zu stapeln.

Sollte die Branch feststehen, bevor die Textur existiert?

Meistens ja. Die Bilddatei kann später kommen, aber die Frage, wie sich das Item verändert, lohnt sich früh zu beantworten.