UE5 Mass AI - How do I transition entities between behaviors (e.g. Wander → Dance) in a Mass StateTree?

UE5 Mass AI - How do I transition entities between behaviors (e.g. Wander → Dance) in a Mass StateTree?

I’m new to Mass AI and am using a Mass StateTree with the Mass Behavior Schema in UE5.8.

So far I’ve successfully spawned Mass entities and have them wandering around using a StateTree. What I’m struggling with is understanding the correct Mass workflow for changing an entity’s behavior at runtime.

For example, let’s say an entity is currently in a Wander state. When a gameplay event occurs, I want that entity to transition into a Dance state.

With a traditional AI Controller/Behavior Tree setup, I would simply update a variable or trigger an event on the AI. However, Mass is designed around entities rather than individual AI brains, so I’m trying to understand the Mass-native way to do this.

Specifically:

  • How should a Mass entity store its current behavior/state?

  • How can I modify that state at runtime?

  • How should a Mass StateTree detect that change and transition to another state?

  • Is this typically done with Fragments, Signals, StateTree Events, Tags, or something else?

  • Can this be done entirely in Blueprints, or is C++ required?

I am hoping to find a Blueprint only solution if possible.

Any examples, tutorials, or documentation references would be appreciated.

There is not a way to do this in Blueprints with the vanilla engine. There might be a community or marketplace plugin that enables you to do more from BP. You could also create a BP function that wraps a method for signaling entities.

As for some of the other questions, we use MassSignals to trigger the MassStateTree to run on an entity. There are signals configured in the engine already, and you can create your own custom signals as well.

Our approach is that composition of an entity dictates behavior. So the tasks/states for your MassStateTree should add and/or remove tags and fragments from the entity. Your processors should then run on the relevant entities based on their composition such as navigation processors running when there is a move request fragment. If you would transition to a new state such as taking cover, the move request fragment would get removed and a tag for InCover might be applied.

-James