Module `Fsm`

This module contains the FSM (Finite State Machine) class and derived FSM_ classes.

Finite State Machines (FSM) are design patterns allowing efficient (long-lasting) processes and workflows.

Banner Image

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.

Workflow Example

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 GROUP and/or UNIT. These AI_ classes derive the #FSM_CONTROLLABLE class.
an acronym TASK_, which indicates an FSM implementation executing a 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 TASK, seated in a CLIENT (slot) or a UNIT (CA join). These ACT_ classes derive the #FSM_PROCESS class.

Detailed explanations and API specifics are further below clarified and FSM derived class specifics are described in those class documentation sections.

Dislaimer:

The FSM class development is based on a finite state machine implementation made by Conroy Kyle. The state machine can be found on github I've reworked this development (taken the concept), and created a hierarchical state machine out of it, embedded within the DCS simulator. Additionally, I've added extendability and created an API that allows seamless FSM implementation.

1) Core.Fsm#FSM class, extends Core.Base#BASE

Transition Rules and Transition Handlers and Event Triggers

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 seperate chapter explaining both transition modes, taking into account the Transition Rules, Transition Handlers and Event Triggers.

1.1) 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 Lineair 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.

1.1.1) 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".

1.1.2) Transition Handling

Transition Handlers

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.3.

1.1.3) Event Triggers

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 destinction 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:E( { 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!

1.1.4) Linear Transitioning Example

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

Transition Example

 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.

Transition Flow

 function FsmDemo:OnAfterSwitch( From, Event, To, FsmUnit )
   self:E( { 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:E( { 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.

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

Some additional comments:

Note that transition rules can be declared with 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 fragment extends the FsmDemo, demonstrating multiple From states declared as a table, in an additional 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.

1.5) 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.

API CHANGE HISTORY

The underlying change log documents the API changes. Please read this carefully. The following notation is used:

Added parts are expressed in bold type face.
Removed parts are expressed in italic type face.

YYYY-MM-DD: CLASS:NewFunction( Params ) replaces CLASS:OldFunction( Params ) YYYY-MM-DD: CLASS:NewFunction( Params ) added

Hereby the change log:

2016-12-18: Released.

AUTHORS and CONTRIBUTIONS

Contributions:

Pikey: Review of documentation & advice for improvements.

Authors:

FlightControl: Design & Programming & documentation.

Global(s)

FSM
FSM_CONTROLLABLE
FSM_PROCESS
FSM_SET
FSM_TASK

Type `FSM`

FSM:AddEndState(State)	Adds an End state.
FSM:AddProcess(From, Event, Process, ReturnEvents)	Set the default Process template with key ProcessName providing the ProcessClass and the process object when it is assigned to a Controllable by the task.
FSM:AddScore(State, ScoreText, Score)	Adds a score for the FSM to be achieved.
FSM:AddScoreProcess(From, Event, State, ScoreText, Score)	Adds a score for the FSM_PROCESS to be achieved.
FSM:AddTransition(From, Event, To)	Add a new transition rule to the FSM.
FSM.ClassName
FSM:GetEndStates()	Returns the End states.
FSM:GetProcess(From, Event)
FSM:GetProcesses()	Returns a table of the SubFSM rules defined within the FSM.
FSM:GetScores()	Returns a table with the scores defined.
FSM:GetStartState()	Returns the start state of the FSM.
FSM:GetState()
FSM:GetSubs()	Returns a table with the Subs defined.
FSM:GetTransitions()	Returns a table of the transition rules defined within the FSM.
FSM:Is(State)
FSM:LoadCallBacks(CallBackTable)
FSM:New(FsmT)	Creates a new FSM object.
FSM:SetStartState(State)	Sets the start state of the FSM.
FSM._StartState
FSM:_add_to_map(Map, Event)
FSM:_call_handler(handler, params)
FSM:_create_transition(EventName)
FSM:_delayed_transition(EventName)
FSM:_eventmap(Events, EventStructure)
FSM:_gosub(ParentFrom, ParentEvent)
FSM:_handler(EventName, ...)
FSM:_isendstate(Current)
FSM:_submap(subs, sub, name)
FSM:can(e)
FSM:cannot(e)
FSM.current
FSM:is(state)

Type `FSM_CONTROLLABLE`

FSM_CONTROLLABLE.ClassName
FSM_CONTROLLABLE.Controllable
FSM_CONTROLLABLE:GetControllable()	Gets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.
FSM_CONTROLLABLE:New(FSMT, Controllable)	Creates a new FSM_CONTROLLABLE object.
FSM_CONTROLLABLE:SetControllable(FSMControllable)	Sets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.
FSM_CONTROLLABLE:_call_handler(handler, params)

Type `FSM_PROCESS`

FSM_PROCESS:AddScore(State, ScoreText, Score)	Adds a score for the FSM_PROCESS to be achieved.
FSM_PROCESS:Assign(Task, ProcessUnit)	Assign the process to a Unit and activate the process.
FSM_PROCESS.ClassName
FSM_PROCESS:Copy(Controllable, Task)	Creates a new FSMPROCESS object based on this FSMPROCESS.
FSM_PROCESS:GetCommandCenter()	Gets the mission of the process.
FSM_PROCESS:GetMission()	Gets the mission of the process.
FSM_PROCESS:GetTask()	Gets the task of the process.
FSM_PROCESS:Init(FsmProcess)
FSM_PROCESS:Message(Message)	Send a message of the Task to the Group of the Unit.
FSM_PROCESS:New(Controllable, Task)	Creates a new FSM_PROCESS object.
FSM_PROCESS:SetTask(Task)	Sets the task of the process.
FSM_PROCESS.Task
FSM_PROCESS:onenterAssigned(ProcessUnit)
FSM_PROCESS:onenterFailed(ProcessUnit)
FSM_PROCESS:onenterSuccess(ProcessUnit)
FSM_PROCESS:onstatechange(ProcessUnit, Event, From, To, Dummy)	StateMachine callback function for a FSM_PROCESS

Type `FSM_SET`

FSM_SET.ClassName
FSM_SET:Get()	Gets the SETBASE object that the FSMSET governs.
FSM_SET:New(FSMT, Set_SET_BASE, FSMSet)	Creates a new FSM_SET object.
FSM_SET.Set
FSM_SET:_call_handler(handler, params)

Type `FSM_TASK`

FSM_TASK.ClassName
FSM_TASK:New(FSMT, Task, TaskUnit)	Creates a new FSM_TASK object.
FSM_TASK.Task
FSM_TASK:_call_handler(handler, params)

Global(s)

#FSM FSM

#FSM_CONTROLLABLE FSM_CONTROLLABLE

#FSM_PROCESS FSM_PROCESS

#FSM_SET FSM_SET

#FSM_TASK FSM_TASK

Type `Fsm`

Type `FSM`

FSM class

Field(s)

FSM:AddEndState(State)

Adds an End state.

Parameter

State :

FSM:AddProcess(From, Event, Process, ReturnEvents)

Set the default Process template with key ProcessName providing the ProcessClass and the process object when it is assigned to a Controllable by the task.

Parameters

#table From : Can contain a string indicating the From state or a table of strings containing multiple From states.
#string Event : The Event name.
Core.Fsm#FSM_PROCESS Process : An sub-process FSM.
#table ReturnEvents : A table indicating for which returned events of the SubFSM which Event must be triggered in the FSM.

Return value

Core.Fsm#FSM_PROCESS: The SubFSM.

FSM:AddScore(State, ScoreText, Score)

Adds a score for the FSM to be achieved.

Parameters

#string State : is the state of the process when the score needs to be given. (See the relevant state descriptions of the process).
#string ScoreText : is a text describing the score that is given according the status.
#number Score : is a number providing the score of the status.

Return value

#FSM: self

FSM:AddScoreProcess(From, Event, State, ScoreText, Score)

Adds a score for the FSM_PROCESS to be achieved.

Parameters

#string From : is the From State of the main process.
#string Event : is the Event of the main process.
#string State : is the state of the process when the score needs to be given. (See the relevant state descriptions of the process).
#string ScoreText : is a text describing the score that is given according the status.
#number Score : is a number providing the score of the status.

Return value

#FSM: self

FSM:AddTransition(From, Event, To)

Add a new transition rule to the FSM.

A transition rule defines when and if the FSM can transition from a state towards another state upon a triggered event.

Parameters

#table From : Can contain a string indicating the From state or a table of strings containing multiple From states.
#string Event : The Event name.
#string To : The To state.

#string FSM.ClassName

FSM:GetEndStates(): Returns the End states.

FSM:GetProcess(From, Event)

Parameters

From :
Event :

FSM:GetProcesses()

Returns a table of the SubFSM rules defined within the FSM.

Return value

#table:

FSM:GetScores(): Returns a table with the scores defined.

FSM:GetStartState()

Returns the start state of the FSM.

Return value

#string: A string containing the start state.

FSM:GetState()

FSM:GetSubs(): Returns a table with the Subs defined.

FSM:GetTransitions()

Returns a table of the transition rules defined within the FSM.

Return value

#table:

FSM:Is(State)

Parameter

State :

FSM:LoadCallBacks(CallBackTable)

Parameter

CallBackTable :

FSM:New(FsmT)

Creates a new FSM object.

Parameter

FsmT :

Return value

#FSM:

FSM:SetStartState(State)

Sets the start state of the FSM.

Parameter

#string State : A string defining the start state.

FSM._StartState

FSM:_add_to_map(Map, Event)

Parameters

Map :
Event :

FSM:_call_handler(handler, params)

Parameters

handler :
params :

FSM:_create_transition(EventName)

Parameter

EventName :

FSM:_delayed_transition(EventName)

Parameter

EventName :

FSM:_eventmap(Events, EventStructure)

Parameters

Events :
EventStructure :

FSM:_gosub(ParentFrom, ParentEvent)

Parameters

ParentFrom :
ParentEvent :

FSM:_handler(EventName, ...)

Parameters

EventName :
... :

FSM:_isendstate(Current)

Parameter

Current :

FSM:_submap(subs, sub, name)

Parameters

subs :
sub :
name :

FSM:can(e)

Parameter

e :

FSM:cannot(e)

Parameter

e :

FSM.current

FSM:is(state)

Parameter

state :

Type `FSM_CONTROLLABLE`

FSM_CONTROLLABLE class

Field(s)

#string FSM_CONTROLLABLE.ClassName

Wrapper.Controllable#CONTROLLABLE FSM_CONTROLLABLE.Controllable

FSM_CONTROLLABLE:GetControllable()

Gets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.

Return value

Wrapper.Controllable#CONTROLLABLE:

FSM_CONTROLLABLE:New(FSMT, Controllable)

Creates a new FSM_CONTROLLABLE object.

Parameters

#table FSMT : Finite State Machine Table
Wrapper.Controllable#CONTROLLABLE Controllable : (optional) The CONTROLLABLE object that the FSM_CONTROLLABLE governs.

Return value

#FSM_CONTROLLABLE:

FSM_CONTROLLABLE:SetControllable(FSMControllable)

Sets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.

Parameter

Wrapper.Controllable#CONTROLLABLE FSMControllable :

Return value

#FSM_CONTROLLABLE:

FSM_CONTROLLABLE:_call_handler(handler, params)

Parameters

handler :
params :

Type `FSM_PROCESS`

FSM_PROCESS class

Field(s)

FSM_PROCESS:AddScore(State, ScoreText, Score)

Adds a score for the FSM_PROCESS to be achieved.

Parameters

#string State : is the state of the process when the score needs to be given. (See the relevant state descriptions of the process).
#string ScoreText : is a text describing the score that is given according the status.
#number Score : is a number providing the score of the status.