Ein Prädikat mit einer Bedingung hat keinen Wrapper, und das ist eine echte Formänderung
Eine Bedingung ist das Objekt selbst. Zwei oder mehr werden in all_of oder any_of verpackt. Dazu die acht Bedingungstypen und warum Invertieren ein Wrapper statt eines Flags ist.
Eine Datapack-Prädikat ist eine JSON-Datei, die eine Bedingung beschreibt, und ihre Struktur ändert sich je nachdem, wie viele Bedingungen du hast. Genau das bringt Leute ins Stolpern, die ein Beispiel kopieren und erweitern.
Eins ist keine Liste mit einem Eintrag
| Bedingungen | Ausgabeform |
|---|---|
| 0 | {} |
| 1 | das Bedingungsobjekt selbst |
| 2+ | { "condition": "minecraft:all_of", "terms": [ … ] } |
Um eine einzelne Bedingung liegt kein Wrapper. Füge eine zweite hinzu und die ganze Datei ändert ihre Form — die ursprüngliche Bedingung wird zum ersten Element eines terms-Arrays unter einem neuen Root. Alles, was diese liest oder generiert, muss beide Formen verarbeiten, und ein Beispiel, das aus einer Bedingung gebaut wurde, zeigt dir nicht die Form, die du brauchst, sobald du eine weitere hinzufügst.
any_of ist der alternative Kombinator: alle Terme müssen bestehen, oder einer von ihnen.
Invertieren ist ebenfalls ein Wrapper, kein Flag
Es gibt kein "invert": true-Feld. Eine negierte Bedingung wird verpackt:
{ "condition": "minecraft:inverted", "term": { …the original condition… } }Beachte term, Singular — inverted nimmt genau einen, während all_of und any_of ein terms-Array nehmen. Zwei ähnlich aussehende Schlüssel mit unterschiedlichen Formen, und die Invertierung gilt pro Bedingung, sodass ein Prädikat invertierte und einfache Terme frei innerhalb eines all_of mischen kann.
Die acht Bedingungstypen, die der Builder anbietet
entity_properties random_chance
int_value_check random_chance_with_enchanted_bonus
weather_check time_check
location_check match_toolDas Spiel hat zwanzig Bedingungstypen; diese sind die acht, die die Auswahl des Builders abdeckt. Zwei von ihnen wurden umbenannt, und der Builder schreibt noch die alten IDs — random_chance_with_looting und value_check — die aktuelle Versionen ablehnen, also benenne diese beiden in der Ausgabe um.
random_chance_with_enchanted_bonus ist der, bei dem es sich lohnt innezuhalten: Er nimmt eine Chance ohne die Verzauberung und einen enchanted_chance, der mit dem Level einer Verzauberung skaliert (Plünderung, in Vanillas eigenen Tabellen), sodass die Wahrscheinlichkeit davon abhängt, was der Töter hält. Das macht ihn nur dort sinnvoll, wo im Kontext ein Töter existiert — er ist eine Drop-Rate-Bedingung, kein universelles Zufalls-Gate. Einfaches random_chance ist das, zu dem man überall sonst greifen sollte.
int_value_check (und float_value_check) prüfen, ob eine Zahl in einen Bereich fällt. Die Wertprüfung des Builders bietet eine Quelle für Verzauberungslevel oder einen benutzerdefinierten Ausdruck, den du nach dem Kopieren von Hand in das JSON einfügst.
Die Auswahlfelder sind genau die Vanilla-Sets
Wissenswert, wenn du prüfst, ob eine Biom- oder Struktur-ID echt ist: Die Dropdowns des Builders sind keine kuratierte Auswahl.
- 66 Biome — jedes Biom bis 26.2; 26.3s
dappled_forestfehlt, also tippe es von Hand ein - 34 Strukturen — ebenfalls bis 26.2; die 18
abandoned_camp_*-Strukturen, die 26.3 hinzugefügt hat, sind nicht aufgeführt - 18 Block-Tags und 15 Items, die tatsächlich eine funktionierende Teilmenge sind
Das wurde gegen die eigenen Registrierungsdaten des Spiels verifiziert statt angenommen, also wenn eine ID in der Biom- oder Strukturliste fehlt und keine der 26.3-Neuzugänge ist, existiert die ID nicht. Bei den Block-Tags und Items ist es das Gegenteil: Fehlen bedeutet nur, dass das Auswahlfeld sie nicht auflistet, und die ID selbst einzutippen ist in Ordnung.