In order to launch an FSM, you just need to use the Launch FSM node that you can find in GC FSM category. The combobox will automatically show all the FSMs that the target object implements. If the FSM that you want is not listed (for example, because the type of the target object can change at runtime) you can attach a name literal to the FSM pin.
Executing a Launch FSM node will immediately start the FSM execution flow. Typically, the flow will eventually reach a FSM State node and enter that state.
Every FSM on the target object runs by itself: you can have multiple FSMs running at the same time on the same object. Of course, different instances of the same blueprint each have their own set 0f FSMs.
Triggering FSM events
Once an FSM has started, you interact with it by triggering events on the object that runs the FSM. This is done using the Trigger FSM Event node, that is found in the GC FSM category.
The Trigger FSM Event is a very versatile custom node. The most important thing is the Event pin, which shall contain the name of the event that is going to be triggered. In addition to that, the node has five policies that can be used to tweak the node behaviour. The policies are an advanced topic that will be covered in Advanced Topics section. Most of the times the default policies are what you need, so you usually don’t need to bother about them. The five icons at the bottom of the node are a graphic reminder of the five policies, so that you can see at a glance if a node is using a non-default policy.
When you trigger an event, the event is sent to all FSMs of the effective target object. For each FSM, the active state node is considered:
- if the event is listed in the “Transition Event” array, the FSM will exit the state and the execution flow attached to the matching pin is executed;
- if the event is listed in the “Deferred Event” array, the event is kept in a queue, to be processed in a later event;
- if the state implements an “Internal Event” with a matching name, the corresponding handler is invoked. More on Internal Events in the State Classes section.
- otherwise, the event is discarded.
If an FSM receives an event while no state is active, for example if the execution is blocked in a latent function, the event is put in the queue and will be processed as soon as the FSM enters a state.
Debugging in the blueprint editor
Debugging with GC FSM is easy. Just select the actor or object you want to debug in the “Debug Filter” in the menu bar while the game is running and you will see the flow of execution inside the FSM. While the FSM is running a state, the state node will be highlighted with a red balloon reporting the time since activation.
In the video on the right side, an example of an FSM with three states is being debugged. See how, each time the “Hit” event is triggered on this actor, the execution flows from state to state.
