Conditions¶

Conditions answer one question: should this happen? Stack multiple conditions to build complex rules without code.

For example, an attachment point might require all three of these to pass before accepting an object:

Is the slot available?
Does the object have the right tag?
Is the system in the correct phase?

If any single condition fails, the action is blocked. You add, remove, and reorder conditions in the Inspector - no scripting needed.

Invert toggle

Every condition has an invert checkbox. Check it and the condition flips its logic - "is within 5 meters" becomes "is farther than 5 meters." You only need the positive version; the inverse comes for free.

How Conditions Stack¶

When multiple conditions are applied to a single gate, they use AND logic: all conditions must pass for the gate to open. If any single condition evaluates to false, the action is blocked.

Condition A: Distance < 5m     ✓
Condition B: Is Carrying Item  ✓
Condition C: Zone Not Full     ✗
─────────────────────────────────
Result: BLOCKED (C failed)

This stacking model is simple and predictable. For OR logic, create a composite condition that internally evaluates multiple sub-conditions.

Built-in Conditions¶

Duration-Based¶

Condition	Stops When
DurationExecutionCondition	A specified number of seconds have elapsed since `OnStarted()`
ExecuteOnceExecutionCondition	Immediately after the first evaluation
NeverStopExecutionCondition	Never — always returns `true`

Distance-Based¶

Condition	Evaluates
DistanceToTargetCondition	Whether a transform is within a target distance
SustainedDistanceToTargetCondition	Whether the distance has been sustained for a required duration
TransformDistanceCondition	Distance between two transforms
SustainedTransformDistanceCondition	Sustained distance between two transforms

Event-Based¶

Condition	Stops When
EventFiredExecutionCondition	A specified `IEvent` fires
WhileConditionMetExecutionCondition	An external condition stops being met

Technical API¶

ExecutionCondition¶

The base class for conditions in Jungle:

public abstract class ExecutionCondition
{
    void OnStarted();
    void SetContext(object context);
    bool ShouldContinue();
    protected abstract bool Evaluate();
    void Reset();
}

Method	Purpose
`Evaluate()`	The core logic - override this to return `true` (continue) or `false` (stop)
`ShouldContinue()`	Public entry point that respects the invert toggle, then calls `Evaluate()`
`OnStarted()`	Called once when the host system begins execution - initialize state here
`SetContext(object)`	Receives the execution context (typically the owning process) for conditions that need it
`Reset()`	Resets internal state for reuse

Where Conditions Are Used¶

Conditions appear throughout Jungle and its plugins:

Process Execution¶

Every FlexibleProcess has an ExecutionCondition field that determines when the process should stop. See Processes & Commands for details.

Octoputs: Attachment Filtering¶

In Octoputs, attachment points use conditions to decide whether they accept an incoming object. The conditions list on an attachment point might include:

A capacity check — is the slot available?
A tag filter — does the object have the right tag?
A state check — is the system in the right phase?

All must pass for the attachment to proceed.

Octoputs: Phase Gating¶

Drag and drop phases (prepare, drag, drop) can be gated with conditions. For example, a drop preparation phase might require the object to be within a certain distance of the target before it begins.

How They Appear in the Inspector¶

Conditions are serialized with [SerializeReference] and [JungleClassSelection], so they render as TypeSelectableFields. When used in a list, they render as a JungleList with add/remove and drag reorder.

Each condition entry shows:

The condition type name (clickable to change)
The invert toggle
The condition's configuration fields (expanded via foldout)

Compatibility Validation¶

Some conditions require specific context from their host. For example, DistanceToTargetCondition needs the host process to implement a distance-measurable interface. Jungle validates compatibility at edit time:

If a condition is incompatible with its host process, a warning appears in the Inspector
The IsCompatibleWith(object host) method on ExecutionCondition drives this check

Watch for compatibility warnings

If you see an Inspector warning about an incompatible execution condition, switch to a condition that works with your process type. The warning text will indicate what the condition requires.

Creating Custom Conditions¶

Extend ExecutionCondition and implement Evaluate():

[Serializable]
[JungleClassInfo("Stops after a health threshold is reached", "Icons/health", "Gameplay")]
public class HealthThresholdCondition : ExecutionCondition
{
    [SerializeField] private float threshold = 0.5f;

    [SerializeReference] [JungleClassSelection]
    private IValue<float> health;

    protected override bool Evaluate()
    {
        return health.Value() > threshold;
    }
}

The condition will appear in the class selection popup under the "Gameplay" category and can be assigned to any FlexibleProcess execution condition slot.