NeoOrigins 2.0 Condition Reference
Conditions evaluate to true/false against an entity (usually the power’s owning player). They gate power activation, action_on_event triggers, conditional wrappers, bientity interactions, and (as of v2.0.20) any power type via the universal condition gate.
Canonical namespace: neoorigins:* is the preferred form for new packs. Any other namespace (origins:, apace:, apoli:, medievalorigins:, …) is rewritten to neoorigins: plus the same name, and logs a one-shot [2.0-legacy] deprecation warning per distinct type. Bare type names (e.g. "type": "and") are auto-prefixed with neoorigins:. Section headers and JSON examples below use the canonical neoorigins:* form.
Fail-closed semantics: a malformed or unsupported condition logs a warning and returns false rather than throwing. Bientity / damage / food conditions that require a dispatch context also return false when evaluated outside that context.
Object or array. A power’s own condition field (condition, regen_condition, …) accepts either a single condition object or an array. An array is combined as logical AND (an implicit neoorigins:and): every element must pass. An empty array is treated as always-true. (Previously a bare array in these fields silently no-opped.) Inside a condition, a single-condition field (not’s condition, actor_condition’s condition, …) must be an object; the conditions list of and/or accepts an array or a single object.
Universal inverted field: every condition supports a top-level "inverted": true flag that flips its result. Compatible with the Apoli/Origins convention used by upstream packs.
Universal power condition gate (v2.0.20+)
Every power type (passive, toggle, active, persistent effect, compat) supports an optional top-level power_condition field and power_condition_mode field. This allows any power to be gated or blocked by entity conditions without needing per-type condition support.
Note: The field is named
power_condition(notcondition) to avoid colliding with power types that already useconditionin their own config (e.g.condition_passive,action_on_event,attribute_modifier). On types that do not claimconditionfor their own config, a top-levelconditionis accepted as an alias forpower_conditionwith modeallow. See the common-fields table in POWER_TYPES.md for the exact alias rules.
| Field | Type | Default | Description |
|---|---|---|---|
power_condition | condition object | (none) | Entity condition using the full DSL documented below |
power_condition_mode | "deny" or "allow" | "deny" | How the condition result maps to power operation |
Modes:
"deny"(default): the power is disabled when the condition evaluates to true. Use this to express “this power doesn’t work when X”."allow": the power only operates when the condition evaluates to true. Use this to express “this power only works when X”.
What gets gated: onTick, onActivated (keybind), onHit, onKill, and capability checks are all suppressed when the condition is not satisfied. Lifecycle methods (onGranted, onRevoked, onLogin, onRespawn) are never gated, so powers can still set up and tear down correctly.
Examples:
Block wraith phase when in water AND exposed to sun:
{
"type": "neoorigins:wraith_phase",
"blocked_blocks": ["minecraft:obsidian"],
"power_condition": {
"type": "neoorigins:and",
"conditions": [
{ "type": "neoorigins:in_water" },
{ "type": "neoorigins:exposed_to_sun" }
]
},
"power_condition_mode": "deny"
}
Flight only works in the Nether:
{
"type": "neoorigins:flight",
"power_condition": { "type": "neoorigins:dimension", "dimension": "minecraft:the_nether" },
"power_condition_mode": "allow"
}
Active teleport blocked while sneaking:
{
"type": "neoorigins:active_teleport",
"range": 32,
"cooldown_ticks": 60,
"power_condition": { "type": "neoorigins:sneaking" },
"power_condition_mode": "deny"
}
// "true when the player is NOT swimming"
{ "type": "neoorigins:swimming", "inverted": true }
// inside an AND, etc.
{ "type": "neoorigins:and", "conditions": [
{ "type": "neoorigins:creative_flying" },
{ "type": "neoorigins:on_fire", "inverted": true }
]}
The inverted flag is also honored on nested conditions inside and / or / not wrappers: every recursive parse pass checks for it.
Common comparison fields: most numeric conditions accept "comparison" (one of ==, !=, <, <=, >, >=) and "compare_to" (number). Defaults to ">=" and 0 unless stated otherwise.
Item conditions, the separate verb set that matches against an ItemStack (used inside equipped_item / inventory entity conditions, event-power item_condition filters, and if_else item actions), is documented in the Item conditions.
Pages
- Meta conditions: Combinators and constants:
and,or,not,actor_conditionandconstant. - Entity conditions: Conditions on an entity, usually the player: environment, state, equipment, resources and powers.
- Context, bientity & damage conditions: Conditions that need a dispatch context: the event in progress, a second entity, or a damage source. Outside that context they return false.