Guides / Commands & Data

A predicate with one condition has no wrapper, and that is a real shape change

One condition is the object itself. Two or more get wrapped in all_of or any_of. Plus the eight condition types, and why inverting is a wrapper rather than a flag.

2026-08-01

A datapack predicate is a JSON file describing a condition, and its structure changes depending on how many conditions you have. That is the part that trips people copying an example and extending it.

One is not a list of one

There is no wrapper around a single condition. Add a second and the whole file changes shape — the original condition becomes the first element of a terms array under a new root. Anything that reads or generates these has to handle both forms, and an example built from one condition does not show you the shape you will need the moment you add another.

any_of is the alternative combinator: all terms must pass, or any one of them.

Inverting is a wrapper too, not a flag

There is no "invert": true field. A negated condition is wrapped:

{ "condition": "minecraft:inverted", "term": { …the original condition… } }

Note term, singular — inverted takes exactly one, where all_of and any_of take a terms array. Two similar-looking keys with different shapes, and inversion applies per condition, so a predicate can mix inverted and plain terms freely inside one all_of.

The eight condition types the builder offers

entity_properties            random_chance
int_value_check              random_chance_with_enchanted_bonus
weather_check                time_check
location_check               match_tool

The game has twenty condition types; these are the eight the builder's picker covers. Two of them changed name, and the builder still writes the old ids — random_chance_with_looting and value_check — which current versions refuse, so rename those two in the output.

random_chance_with_enchanted_bonus is the one worth pausing on: it takes a chance without the enchantment and an enchanted_chance that scales with an enchantment's level (Looting, in vanilla's own tables), so the probability depends on what the killer is holding. That makes it meaningful only where a killer exists in context — it is a drop-rate condition, not a general-purpose random gate. Plain random_chance is the one to reach for everywhere else.

int_value_check (and float_value_check) test whether a number falls in a range. The builder's value check offers an enchantment-level source or a custom expression you edit into the JSON by hand after copying.

The pickers are exactly the vanilla sets

Worth knowing when you are checking whether a biome or structure id is real: the builder's dropdowns are not a curated sample.

• 66 biomes — every biome up to 26.2; 26.3's dappled_forest is missing, so type it by hand
• 34 structures — likewise up to 26.2; the 18 abandoned_camp_* structures 26.3 added are not listed
• 18 block tags and 15 items, which are a working subset

That was verified against the game's own registry data rather than assumed, so if an id is absent from the biome or structure list and is not one of 26.3's additions, the id does not exist. For the block tags and items it is the opposite: absence means only that the picker does not list it, and typing the id yourself is fine.

Predicate & Condition Builder →