linkPredicates

Predicates are JSON structures used in data packs to check conditions within the world. They return a pass or fail result to the invoker, which acts differently based on the result. In practical terms, predicates are a flexible way for data packs to encode "if this, then that" logic without needing custom code.

Predicates can be used in:

• Commands: Via execute if predicate or target selector argument predicate=
• Loot tables: As conditions for loot entries
• Advancements: As trigger conditions
• Other predicates: Via the reference condition

Kore provides a type-safe DSL to create predicates, eliminating the need to write raw JSON.

linkBasic Usage

Here's a simple example of creating a predicate that checks if a player is holding a diamond pickaxe:

val myPredicate = predicate("test") {
	matchTool {
		item(Items.DIAMOND_PICKAXE)
	}
}

The predicate function creates and registers a predicate in your DataPack. It produces a file at data/<namespace>/predicate/<fileName>.json and returns a PredicateArgument that can be used in commands.

linkConditions

Predicates can have multiple conditions that must be met. You can combine them using allOf or anyOf:

predicate("complex_test") {
	allOf {
		enchantmentActiveCheck(true)
		randomChance(0.5f)
		randomChanceWithEnchantedBonus(
           unenchantedChance = 0.3f,
			enchantedChance = 2,
			Enchantments.EFFICIENCY
		)
		weatherCheck(raining = true, thundering = false)
	}
}

You can also use the inverted condition to invert the result of a predicate:

predicate("inverted_test") {
	inverted {
		randomChance(0.5f)
	}
}

linkAvailable Conditions

Conditions are categorized by their **loot context requirements **. Some conditions can be invoked from any context, while others require specific data to be available.

linkUniversal Conditions (invokable from any context)

randomChance, timeCheck, and valueCheck accept a NumberProvider for their numeric arguments, so you can use dynamic values like scoreboard scores, enchantment levels, or environment attributes instead of plain floats.

linkEnvironment Attribute Check

environmentAttributeCheck passes when the specified environment attribute equals the given value. The value type is inferred from the attribute - booleans for toggle attributes, floats for numeric ones, strings for enum-like ones (moon phase, villager activity), and objects for compound ones (ambient sounds, background music).

predicate("is_daytime") {
   // Boolean attribute - convenience overload, no wrapping needed
   environmentAttributeCheck(EnvironmentAttributes.Gameplay.MONSTERS_BURN, true)
}

predicate("dim_sky") {
   // Float attribute - convenience overload, no wrapping needed
   environmentAttributeCheck(EnvironmentAttributes.Visual.SKY_LIGHT_FACTOR, 0.5f)
}

predicate("full_moon") {
   // Builder block: call exactly one typed helper from EnvironmentAttributesScope.
   // It sets both the attribute ID and the expected value automatically.
   environmentAttributeCheck {
      moonPhase(Textures.Environment.Celestial.Moon.FULL_MOON)
   }
}

The builder block accepts any number of calls from the same scope helpers used in dimension types and biomes ( moonPhase, beesStayInHive, fogColor, ambientSounds, etc.). Each attribute set in the block produces one environment_attribute_check condition, so multiple attributes are an implicit AND - all must match for the predicate to pass.

linkContext-Dependent Conditions

Most of these conditions require specific loot context data and will always fail if not provided. Three exceptions have optional context with graceful fallback behavior (noted in the table):

linkEntity Properties

The entityProperties condition allows you to check various properties of an entity. You must specify which entity to check using the entity parameter:

linkEntity Context Options

linkEntity Predicate Example

predicate("entity_check") {
	entityProperties {
		// Check entity components (e.g., axolotl variant)
		components {
			axolotlVariant(AxolotlVariants.CYAN)
			damage(12)
			!unbreakable()  // Negated component check
		}

		// Check effects
		effects {
			this[Effects.INVISIBILITY] = effect {
				amplifier = rangeOrInt(1)
			}
		}

		// Check equipment
		equipment {
			mainHand = itemStack(Items.DIAMOND_SWORD)
		}

		// Check entity flags
		flags {
			isBaby = true
		}

		// Check location
		location {
			block {
				blocks(Blocks.STONE)
			}
		}

		// Check movement
		movement {
			x(1.0, 4.0)
			horizontalSpeed(1.0)
		}

		// Check what affects entity movement
		movementAffectedBy {
			canSeeSky = true
		}

		// Check NBT data
		nbt {
			this["foo"] = "bar"
		}

		// Check entity passenger
		passenger {
			team("foo")
		}

		// Check custom data predicates
		predicates {
			customData {
				this["foo"] = "bar"
			}
		}

		// Check specific inventory slots
		slots {
			this[WEAPON.MAINHAND] = itemStack(Items.DIAMOND_SWORD)
		}

		// Check block the entity is standing on
		steppingOn {
			blocks(Blocks.STONE)
			components {
				damage(5)
			}
			predicates {
				customData {
					this["foo"] = "bar"
				}
			}
			state("up", "bottom")
		}

		// Check entity type
		entityType(EntityTypes.MARKER)

		// Check player-specific properties
		typeSpecific {
			player {
				gamemodes(Gamemode.SURVIVAL)
			}
		}

		// Check entity vehicle with distance
		vehicle {
			distance {
				x(1f..4f)
				z(1f)
			}
		}
	}
}

linkSub-Predicates

Sub-predicates are nested data structures that allow you to define specific properties to check within a predicate condition. Each condition type can have its own set of sub-predicates.

linkEntity Sub-Predicates

The entityProperties condition supports various sub-predicates to check different aspects of an entity. Each one is serialized as its own identifier-keyed entry (minecraft:<name>) rather than a flat object:

The Entity class provides all the functions for these sub-predicates, backed by a single EntitySubPredicate sealed family - each call appends one entry to Entity.subPredicates.

linkEntity Type-Specific Properties

Entities can still expose a handful of hard-coded type-specific predicates (mainly utility ones such as fishing hooks, lightning, player, raider, sheep and slime). All the visual variant checks that existed before snapshot 25w04a were migrated by Mojang to the new **components ** system. Kore therefore removed the dedicated helpers (axolotlTypeSpecific, catTypeSpecific, …) in favor of component matching.

linkComponent-based variant checks (25w04a +)

You can now query an entity’s data components directly from entityProperties with the components block:

// Check axolotl variant via its component
predicate("axolotl_component_check") {
    entityProperties {
        components {
            axolotlVariant(AxolotlVariants.LUCY)
        }
    }
}

Any component you can put on an item can be matched on an **entity ** in exactly the same way - just call the corresponding extension inside the components {} scope.

linkRemaining built-in typeSpecific helpers

These helpers are still available because they cover information that is not represented by components. They're grouped under a typeSpecific { } scope, and each keys under minecraft:type_specific/<name> (except cubeMob, which keys under minecraft:cube_mob - Mojang's own replacement for the old minecraft:slime predicate):

linkFishing Hook

Check if a fishing hook is in open water:

predicate("fishing_hook_check") {
	entityProperties {
		typeSpecific {
			fishingHook(inOpenWater = true)
		}
	}
}

linkLightning

Check lightning bolt properties like blocks set on fire:

predicate("lightning_check") {
	entityProperties {
		typeSpecific {
			lightning {
				blocksSetOnFire = rangeOrInt(1..5)
			}
		}
	}
}

linkPlayer

Check player-specific properties including gamemode, food stats, unlocked recipes, and input state:

predicate("player_check") {
	entityProperties {
		typeSpecific {
			player {
				gamemodes(Gamemode.CREATIVE)
				food {
					level = rangeOrInt(5..15)
					saturation = rangeOrDouble(1.0, 10.0)
				}
				recipes {
					this[Recipes.BOW] = true
				}
				input {
					forward = true
					backward = false
					left = true
					right = false
					jump = true
					sneak = false
					sprint = true
				}
			}
		}
	}
}

linkRaider

Check raider properties like raid participation and captain status:

predicate("raider_check") {
	entityProperties {
		typeSpecific {
			raider(hasRaid = true, isCaptain = false)
		}
	}
}

linkSheep

Check if a sheep has been sheared:

predicate("sheep_check") {
	entityProperties {
		typeSpecific {
			sheep(sheared = true)
		}
	}
}

linkCube Mob (slimes and magma cubes)

Check cube mob size - renamed from minecraft:slime to minecraft:cube_mob in 26.2-snapshot-3:

predicate("cube_mob_check") {
	entityProperties {
		typeSpecific {
			cubeMob(rangeOrInt(2))
		}
	}
}

Note All former *TypeSpecific helpers that dealt with variants (axolotl, cat, fox, frog, horse, llama, mooshroom, painting, parrot, pig, rabbit, salmon, tropical fish, villager, wolf) have been removed. Update your predicates to use component matching instead.

linkItem Sub-Predicates

When using matchTool or checking equipment, you can use item sub-predicates. There are two main ways to check item properties:

1. Basic item properties:

predicate("basic_item_check") {
	matchTool {
		item(Items.DIAMOND_SWORD)
		count = rangeOrInt(1..64)
		durability = rangeOrInt(0..100)
	}
}

1. Component Matchers - A powerful system to check component properties:

predicate("component_check") {
	matchTool {
		item(Items.DIAMOND_SWORD)
		predicates {
			// Check damage and durability
			damage {
				durability(1)
				damage = rangeOrInt(4..5)
			}

			// Check enchantments
			enchantments {
				enchantment(Enchantments.SHARPNESS, level = 3)
			}
		}
	}
}

Component Matchers allow you to check various item components like:

• Attribute modifiers
• Container contents (bundles, shulker boxes)
• Damage and durability
• Enchantments
• Firework properties
• Book contents
• And many more

Each matcher corresponds to a component type in Minecraft and provides type-safe ways to check their properties. See the Available Component Matchers table in the Components guide for the full list.

linkUsing Predicates in Commands

Predicates can be invoked in commands in two ways:

linkExecute If Predicate

Use /execute if predicate to conditionally run commands. If you need a refresher on the surrounding execution DSL, the Commands page covers the broader command surface:

function("test") {
	execute {
		ifCondition {
			predicate(myPredicate)
		}
		run {
			debug("predicate validated!")
		}
	}
}

linkTarget Selector Argument

Use the predicate= selector argument to filter entities. This pairs naturally with Kore's typed Selectors:

function("filter_entities") {
	// Kill all entities matching the predicate
	kill(allEntities { predicate = myPredicate })
}

linkPairing with Inventory Manager

Predicates excel at validating complex item properties. When you need to both validate and actively manage inventories ( e.g., keep a GUI slot populated with an item matching specific Components), use them alongside the Inventory Manager.

linkItem Predicates

Item predicates check the item involved in a predicate context - most commonly the tool used to mine a block via matchTool, but the same shape is used for equipment slots and slots checks inside entityProperties (see Entity Predicate Example above).

A basic item predicate matches on the item type plus optional count/durability ranges:

predicate("enchanted_tool") {
	matchTool {
		item(Items.DIAMOND_PICKAXE)
		predicates {
			enchantments(enchantment(Enchantments.EFFICIENCY))
		}
	}
}

The predicates { } block accepts any component matcher

• damage, enchantments, storedEnchantments, customData, container, and more - so you can gate a predicate on arbitrary component state, not just enchantments. If you instead need the inline command-syntax form (minecraft:diamond_sword[damage=10]) for use outside a predicate file - e.g. in /give, /clear, or the items selector - see Item Predicates and Component Matchers (Sub-Predicates) in the Components guide, which cover both forms side by side with more examples (existence checks, partial matching, negation, OR).

linkReferencing Other Predicates

Use the reference condition to invoke another predicate file, which keeps larger predicate sets composable in the same spirit as helper extraction in the Cookbook:

val basePredicate = predicate("base_check") {
	weatherCheck(raining = true)
}

predicate("combined_check") {
	allOf {
		reference(basePredicate)
		randomChance(0.5f)
	}
}

Warning: Cyclic references (predicate A references B, which references A) will cause a parsing failure.

linkBest Practices

1. Descriptive names: Give your predicates names that reflect their purpose (e.g., is_holding_sword, in_rain_at_night)
2. Logical composition: Use allOf and anyOf to combine multiple conditions clearly
3. Reusability: Keep predicates focused on a single concern and use reference to compose them
4. **Context awareness **: Be mindful of which loot context your predicate will be invoked from. Context-dependent conditions will silently fail if required data is missing
5. Testing: Test your predicates in-game using /execute if predicate <name> to verify they work as expected

Predicates are powerful tools for creating complex conditions in your datapack. They enable sophisticated game mechanics and enhance player experience without requiring custom code.

linkSee Also

• Loot Tables - Use predicates as conditions for loot entries
• Advancements - Use predicates as trigger conditions
• Item Modifiers - Modify items conditionally with predicates
• Components - Item predicates and component matchers in depth: command-syntax predicates, sub-predicate matchers, existence checks, and a complete tool-upgrade example
• Inventory Manager - Pair predicates with inventory management
• Villager Trades - Gate trade availability via merchantPredicate

linkExternal Resources

• Minecraft Wiki: Predicate - Official JSON format reference
• Minecraft Wiki: Loot context - Understanding loot contexts for conditions