Transitions

Transitions are how a State Tree moves from one state to another. Every state can have any number of outgoing transitions; the first one whose trigger fires and whose conditions pass is the one that’s taken.

Transition Triggers

Transitions listen for one of three kinds of event:

On State Completed

Fires when every task in the current state has reported completion. For the Play Vertex Animation task, completion means the clip finished. Which only happens when Loop is off. This is the right trigger for one-shot chained animations (idle → greet → idle).

On Event

Fires when a gameplay-tagged event is broadcast. Every state in the tree can listen; any transition whose tag matches the broadcast tag is eligible. This is how external gameplay code (triggers, Blueprints, C++) drives animations. See Triggering Events.

On Tick

Evaluates every tick; useful when paired with a condition. For example: every tick, check if a float parameter exceeded a threshold, and if so, transition. More expensive than event-based triggers. Prefer events when possible.

Note: This only fires if the State Tree is actually ticking. The Should Tick flag on the schema is computed from the tasks and evaluators in use, so a tree with only parameter-setting tasks and On Event transitions may not tick at all. See Schema & Settings.

Adding a Transition

1. Select the source state in the State Tree editor.
2. In the Transitions panel, click +.
3. Choose a Trigger (Completed / Event / Tick).
4. Choose a Target State. Any other state in the tree, or a parent/child.
5. (Optional) Choose an Event Tag if the trigger is On Event.
6. (Optional) Add Conditions to filter when this transition is allowed to fire.

Transition Conditions

Conditions are boolean checks evaluated when the transition’s trigger fires. If any condition returns false, the transition is skipped and the next eligible transition is considered. Conditions are drawn from the VA StateTree Schema’s Condition library.

Common conditions include parameter comparisons (IntEquals, FloatGreaterThan, BoolIsTrue) and gameplay-tag checks. You can stack multiple conditions. All must pass for the transition to fire.

Example: 50/50 Branching

A state that sometimes cheers after idling, using Randomize Bool (a fair 50/50 roll):

1. In the Idle state, add a Randomize Bool task and point Set Property at a bool parameter named WillCheer.
2. Add a Play Vertex Animation task that plays the idle clip with Loop off.
3. Add two outgoing transitions, both with trigger On State Completed:
   • Target: Cheer: Condition: WillCheer == true
   • Target: Idle (self). No condition (fallback)
4. Half of all idle loops cheer; the other half re-enter Idle.

Example: Weighted Branching

For probabilities other than 50/50, use Set Float Parameter with a random range instead:

1. In the Idle state, add a Set Float Parameter task. Point Set Property at a float parameter DecisionRoll. Enable Use Random Range, set Range 0.0 – 1.0.
2. Outgoing transitions:
   • Target: Cheer: Condition: DecisionRoll < 0.2
   • Target: Idle (self). Fallback.
3. Cheer fires roughly 20% of the time. Adjust the threshold to change the weighting.

Event Transitions in Detail

Event transitions are the primary way external gameplay talks to a State Tree.

1. Create a Gameplay Tag in Project Settings → Project → Gameplay Tags (for example Mannequin.Wave). You only need to do this once per tag.
2. In the state that should react, add a transition with Trigger = On Event and Event Tag set to your new tag.
3. From gameplay code, call BroadcastAnimEvent on the VA Mesh Component, passing the same tag.

All instances using this State Tree will hear the broadcast. States that are currently active and listening for that tag will transition.

Tag inheritance: Gameplay tags are hierarchical. A transition listening for Mannequin will also fire on Mannequin.Wave or Mannequin.Cheer. Use this for broad handlers like “react to anything in the Mannequin namespace.”

Transition Priority

Multiple outgoing transitions on the same state are evaluated in list order, top to bottom. The first one whose trigger and conditions both pass is taken.

Reorder transitions by dragging them in the Transitions panel. Put more specific conditions above broader fallbacks.

Evaluators: Continuous State Updates

Evaluators sit alongside tasks but run continuously while the tree is active, regardless of which state is current. They’re the right tool for reading external data into parameters every tick (for example, distance-to-player, current time of day, a gameplay scalar).

Use the Evaluator’s output parameters as condition inputs on your transitions. This lets gameplay state drive state transitions without any event broadcasts.

See the Creating a State Tree Example page for the soccer fan tree’s parameter-driven patterns.

See Also

• Tasks Reference - tasks that set parameters conditions can read.
• Triggering Events - how to broadcast event tags from Blueprints and C++.