A Finite State Machine (FSM) models a process flow that transitions between various States through triggered Events.

A FSM can only be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by an internal or external triggering event, which is called a transition. An FSM implementation is defined by a list of its states, its initial state, and the triggering events for each possible transition. An FSM implementation is composed out of two parts, a set of state transition rules, and an implementation set of state transition handlers, implementing those transitions.

The FSM class supports a hierarchical implementation of a Finite State Machine, that is, it allows to embed existing FSM implementations in a master FSM. FSM hierarchies allow for efficient FSM re-use, not having to re-invent the wheel every time again when designing complex processes.

The above diagram shows a graphical representation of a FSM implementation for a Task, which guides a Human towards a Zone, orders him to destroy x targets and account the results. Other examples of ready made FSM could be:

• route a plane to a zone flown by a human
• detect targets by an AI and report to humans
• account for destroyed targets by human players
• handle AI infantry to deploy from or embark to a helicopter or airplane or vehicle
• let an AI patrol a zone

The MOOSE framework uses extensively the FSM class and derived FSM_ classes, because the goal of MOOSE is to simplify mission design complexity for mission building. By efficiently utilizing the FSM class and derived classes, MOOSE allows mission designers to quickly build processes. Ready made FSM-based implementations classes exist within the MOOSE framework that can easily be re-used, and tailored by mission designers through the implementation of Transition Handlers. Each of these FSM implementation classes start either with:

• an acronym AI_, which indicates an FSM implementation directing AI controlled Wrapper.Group#GROUP and/or Wrapper.Unit#UNIT. These AI_ classes derive the #FSM_CONTROLLABLE class.
• an acronym TASK_, which indicates an FSM implementation executing a Tasking.Task#TASK executed by Groups of players. These TASK_ classes derive the #FSM_TASK class.
• an acronym ACT_, which indicates an Sub-FSM implementation, directing Humans actions that need to be done in a Tasking.Task#TASK, seated in a Wrapper.Client#CLIENT (slot) or a Wrapper.Unit#UNIT (CA join). These ACT_ classes derive the #FSM_PROCESS class.

The FSM class is the base class of all FSM_ derived classes. It implements the main functionality to define and execute Finite State Machines. The derived FSM_ classes extend the Finite State Machine functionality to run a workflow process for a specific purpose or component.

Finite State Machines have Transition Rules, Transition Handlers and Event Triggers.

The Transition Rules define the "Process Flow Boundaries", that is, the path that can be followed hopping from state to state upon triggered events. If an event is triggered, and there is no valid path found for that event, an error will be raised and the FSM will stop functioning.

The Transition Handlers are special methods that can be defined by the mission designer, following a defined syntax. If the FSM object finds a method of such a handler, then the method will be called by the FSM, passing specific parameters. The method can then define its own custom logic to implement the FSM workflow, and to conduct other actions.

The Event Triggers are methods that are defined by the FSM, which the mission designer can use to implement the workflow. Most of the time, these Event Triggers are used within the Transition Handler methods, so that a workflow is created running through the state machine.

As explained above, a FSM supports Linear State Transitions and Hierarchical State Transitions, and both can be mixed to make a comprehensive FSM implementation. The below documentation has a separate chapter explaining both transition modes, taking into account the Transition Rules, Transition Handlers and Event Triggers.

FSM Linear Transitions

Linear Transitions are Transition Rules allowing an FSM to transition from one or multiple possible From state(s) towards a To state upon a Triggered Event. The Linear transition rule evaluation will always be done from the current state of the FSM. If no valid Transition Rule can be found in the FSM, the FSM will log an error and stop.

FSM Transition Rules

The FSM has transition rules that it follows and validates, as it walks the process. These rules define when an FSM can transition from a specific state towards an other specific state upon a triggered event.

The method FSM.AddTransition() specifies a new possible Transition Rule for the FSM.

The initial state can be defined using the method FSM.SetStartState(). The default start state of an FSM is "None".

Find below an example of a Linear Transition Rule definition for an FSM.

 local Fsm3Switch = FSM:New() -- #FsmDemo
 FsmSwitch:SetStartState( "Off" )
 FsmSwitch:AddTransition( "Off", "SwitchOn", "On" )
 FsmSwitch:AddTransition( "Off", "SwitchMiddle", "Middle" )
 FsmSwitch:AddTransition( "On", "SwitchOff", "Off" )
 FsmSwitch:AddTransition( "Middle", "SwitchOff", "Off" )

The above code snippet models a 3-way switch Linear Transition:

• It can be switched On by triggering event SwitchOn.
• It can be switched to the Middle position, by triggering event SwitchMiddle.
• It can be switched Off by triggering event SwitchOff.
• Note that once the Switch is On or Middle, it can only be switched Off.

Some additional comments:

Note that Linear Transition Rules can be declared in a few variations:

• The From states can be a table of strings, indicating that the transition rule will be valid if the current state of the FSM will be one of the given From states.
• The From state can be a "*", indicating that the transition rule will always be valid, regardless of the current state of the FSM.

The below code snippet shows how the two last lines can be rewritten and condensed.

 FsmSwitch:AddTransition( { "On",  "Middle" }, "SwitchOff", "Off" )

Transition Handling

An FSM transitions in 4 moments when an Event is being triggered and processed. The mission designer can define for each moment specific logic within methods implementations following a defined API syntax. These methods define the flow of the FSM process; because in those methods the FSM Internal Events will be triggered.

• To handle State transition moments, create methods starting with OnLeave or OnEnter concatenated with the State name.
• To handle Event transition moments, create methods starting with OnBefore or OnAfter concatenated with the Event name.

The OnLeave and OnBefore transition methods may return false, which will cancel the transition!

Transition Handler methods need to follow the above specified naming convention, but are also passed parameters from the FSM. These parameters are on the correct order: From, Event, To:

• From = A string containing the From state.
• Event = A string containing the Event name that was triggered.
• To = A string containing the To state.

On top, each of these methods can have a variable amount of parameters passed. See the example in section 1.1.3.

Event Triggers

The FSM creates for each Event two Event Trigger methods. There are two modes how Events can be triggered, which is synchronous and asynchronous:

• The method FSM:Event() triggers an Event that will be processed synchronously or immediately.
• The method FSM:Event( __seconds ) triggers an Event that will be processed asynchronously over time, waiting x seconds.

The distinction between these 2 Event Trigger methods are important to understand. An asynchronous call will "log" the Event Trigger to be executed at a later time. Processing will just continue. Synchronous Event Trigger methods are useful to change states of the FSM immediately, but may have a larger processing impact.

The following example provides a little demonstration on the difference between synchronous and asynchronous Event Triggering.

  function FSM:OnAfterEvent( From, Event, To, Amount )
    self:T( { Amount = Amount } )
  end

  local Amount = 1
  FSM:__Event( 5, Amount )

  Amount = Amount + 1
  FSM:Event( Text, Amount )

In this example, the :OnAfterEvent() Transition Handler implementation will get called when Event is being triggered. Before we go into more detail, let's look at the last 4 lines of the example. The last line triggers synchronously the Event, and passes Amount as a parameter. The 3rd last line of the example triggers asynchronously Event. Event will be processed after 5 seconds, and Amount is given as a parameter.

The output of this little code fragment will be:

• Amount = 2
• Amount = 2

Because ... When Event was asynchronously processed after 5 seconds, Amount was set to 2. So be careful when processing and passing values and objects in asynchronous processing!

Linear Transition Example

This example is fully implemented in the MOOSE test mission on GitHub: FSM-100 - Transition Explanation

It models a unit standing still near Batumi, and flaring every 5 seconds while switching between a Green flare and a Red flare. The purpose of this example is not to show how exciting flaring is, but it demonstrates how a Linear Transition FSM can be build. Have a look at the source code. The source code is also further explained below in this section.

The example creates a new FsmDemo object from class FSM. It will set the start state of FsmDemo to state Green. Two Linear Transition Rules are created, where upon the event Switch, the FsmDemo will transition from state Green to Red and from Red back to Green.

 local FsmDemo = FSM:New() -- #FsmDemo
 FsmDemo:SetStartState( "Green" )
 FsmDemo:AddTransition( "Green", "Switch", "Red" )
 FsmDemo:AddTransition( "Red", "Switch", "Green" )

In the above example, the FsmDemo could flare every 5 seconds a Green or a Red flare into the air. The next code implements this through the event handling method OnAfterSwitch.

 function FsmDemo:OnAfterSwitch( From, Event, To, FsmUnit )
   self:T( { From, Event, To, FsmUnit } )

   if From == "Green" then
     FsmUnit:Flare(FLARECOLOR.Green)
   else
     if From == "Red" then
       FsmUnit:Flare(FLARECOLOR.Red)
     end
   end
   self:__Switch( 5, FsmUnit ) -- Trigger the next Switch event to happen in 5 seconds.
 end

 FsmDemo:__Switch( 5, FsmUnit ) -- Trigger the first Switch event to happen in 5 seconds.

The OnAfterSwitch implements a loop. The last line of the code fragment triggers the Switch Event within 5 seconds. Upon the event execution (after 5 seconds), the OnAfterSwitch method is called of FsmDemo (cfr. the double point notation!!! ":"). The OnAfterSwitch method receives from the FSM the 3 transition parameter details ( From, Event, To ), and one additional parameter that was given when the event was triggered, which is in this case the Unit that is used within OnSwitchAfter.

 function FsmDemo:OnAfterSwitch( From, Event, To, FsmUnit )

For debugging reasons the received parameters are traced within the DCS.log.

    self:T( { From, Event, To, FsmUnit } )

The method will check if the From state received is either "Green" or "Red" and will flare the respective color from the FsmUnit.

   if From == "Green" then
     FsmUnit:Flare(FLARECOLOR.Green)
   else
     if From == "Red" then
       FsmUnit:Flare(FLARECOLOR.Red)
     end
   end

It is important that the Switch event is again triggered, otherwise, the FsmDemo would stop working after having the first Event being handled.

   FsmDemo:__Switch( 5, FsmUnit ) -- Trigger the next Switch event to happen in 5 seconds.

The below code fragment extends the FsmDemo, demonstrating multiple From states declared as a table, adding a Linear Transition Rule. The new event Stop will cancel the Switching process. The transition for event Stop can be executed if the current state of the FSM is either "Red" or "Green".

 local FsmDemo = FSM:New() -- #FsmDemo
 FsmDemo:SetStartState( "Green" )
 FsmDemo:AddTransition( "Green", "Switch", "Red" )
 FsmDemo:AddTransition( "Red", "Switch", "Green" )
 FsmDemo:AddTransition( { "Red", "Green" }, "Stop", "Stopped" )

The transition for event Stop can also be simplified, as any current state of the FSM is valid.

 FsmDemo:AddTransition( "*", "Stop", "Stopped" )

So... When FsmDemo:Stop() is being triggered, the state of FsmDemo will transition from Red or Green to Stopped. And there is no transition handling method defined for that transition, thus, no new event is being triggered causing the FsmDemo process flow to halt.

FSM Hierarchical Transitions

Hierarchical Transitions allow to re-use readily available and implemented FSMs. This becomes in very useful for mission building, where mission designers build complex processes and workflows, combining smaller FSMs to one single FSM.

The FSM can embed Sub-FSMs that will execute and return multiple possible Return (End) States. Depending upon which state is returned, the main FSM can continue the flow triggering specific events.

The method FSM.AddProcess() adds a new Sub-FSM to the FSM.

Models Finite State Machines for Wrapper.Controllables, which are Wrapper.Groups, Wrapper.Units, Wrapper.Clients.

FSM_PROCESS class models Finite State Machines for Tasking.Task actions, which control Wrapper.Clients.

FSM_SET class models Finite State Machines for Core.Sets.

Note that these FSMs control multiple objects!!! So State concerns here for multiple objects or the position of the state machine in the process.

Models Finite State Machines for Tasking.Tasks.