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

Item-Model-Builder öffnen Hauptguide lesen

Zuerst das Signal verstehen

Bevor ihr eine Branch wählt, fragt euch: bleibt das Item immer gleich, wechselt es zwischen benannten Zuständen, läuft es über numerische Schwellen oder reagiert es auf ein Ja/Nein-Signal? Diese Antwort sollte die Struktur bestimmen.

Viele Definitions werden unnötig groß, weil sofort zur flexibelsten Branch gegriffen wird. Flexibel klingt sicher, ist aber oft nur schwerer lesbar als nötig.

Schnelle Entscheidungstabelle

Branch	Dann benutzen	Typischer Fall
`minecraft:model`	Das Item hat nur eine feste Optik.	Pass, Prop, einzelnes Relikt.
`minecraft:select`	Es gibt benannte Zustände.	sealed, awakened, broken, cursed.
`minecraft:range_dispatch`	Der Wechsel läuft über Zahlenstufen.	Ladung, Fortschritt, Schadensbänder.
`minecraft:condition`	Das Ergebnis ist wahr/falsch.	Ausgewählt, benutzt, beschädigt oder nicht.

Drei kleine Sprachtests

Wenn ihr den Wechsel mit Wörtern wie ritual, broken oder active beschreibt, seid ihr meist bei select.
Wenn ihr in Stufen wie 0-25-50-75 denkt, ist das oft range_dispatch.
Wenn das Item etwas tut oder nicht tut, reicht häufig condition.

Drei Beispiele

1. Relikt mit Story-Zuständen

Wenn das Relikt sealed, glowing oder cracked sein kann, sind das benannte Zustände. Das spricht klar für select.

2. Stab mit Ladephasen

Wenn die Optik bei bestimmten Ladungsstufen kippt, ist das ein Fall für range_dispatch.

3. Karte mit Hand-Kontext

Wenn sich die Optik nur ändert, solange das Item aktiv in der Hand ist, reicht meist condition.

Häufige Überbauten

select benutzen, obwohl ein einfaches model genügt hätte.
range_dispatch wählen, obwohl die Veränderung eigentlich benannt und nicht numerisch ist.
Eine binäre Logik unnötig in viele Zweige zerlegen.
Vergessen, dass ein guter Fallback auch der Lesbarkeit dient.

Wobei der Builder hilft

Der Builder ist am stärksten, wenn die Richtung fast klar ist, ihr aber die JSON-Hülle nicht jedes Mal neu schreiben wollt. Er hält den Fallback sichtbar, lässt Branches geordnet hinzufügen und macht schnelle Prototypen leichter.

Gerade bei Migrationen ist das angenehm: erst eine Definition sauber bauen, dann das Muster auf weitere Items übertragen.

FAQ

Brauche ich in 1.21.4+ immer Branches?

Nein. Viele Items bleiben einfache model-Dateien.

Kann ich benannte Zustände und Zahlenstufen kombinieren?

Ja, aber dann lohnt es sich besonders, die einfachste äußere Branch zuerst zu wählen.

Sollte die Branch vor der Textur feststehen?

Meistens ja. Das Aussehen kann später kommen, die Änderungslogik sollte früh klar sein.