Module Fsm

Core -- The FSM (Finite State Machine) class and derived FSM_ classes are design patterns allowing efficient (long-lasting) processes and workflows.

Banner Image


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.

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.

The following derived classes are available in the MOOSE framework, that implement a specialised form of a FSM:


Author: FlightControl

Contributions:


Global(s)

FSM

FSM class, extends Base#BASE

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

FSM_CONTROLLABLE

FSM_CONTROLLABLE, extends #FSM

FSM_CONTROLLABLE class models Finite State Machines for Controllables, which are Groups, Units, Clients.

FSM_PROCESS

FSM_PROCESS, extends #FSM

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

FSM_SET

FSM_SET, extends #FSM

FSM_SET class models Finite State Machines for Sets.

FSM_TASK

FSM_TASK, extends #FSM

FSM_TASK class models Finite State Machines for Tasks.

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.CallScheduler
FSM.Events
FSM:GetCurrentState()
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()

Creates a new FSM object.

FSM.Scores
FSM:SetProcess(From, Event, Fsm)
FSM:SetStartState(State)

Sets the start state of the FSM.

FSM._EndStates
FSM._EventSchedules
FSM._Processes
FSM._Scores
FSM._StartState
FSM._Transitions
FSM:_add_to_map(Map, Event)
FSM:_call_handler(step, trigger, params, EventName)
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.endstates
FSM:is(state)
FSM.options
FSM.subs

Type FSM_CONTROLLABLE

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:OnAfterStop(Controllable, From, Event, To)

OnAfter Transition Handler for Event Stop.

FSM_CONTROLLABLE:OnBeforeStop(Controllable, From, Event, To)

OnBefore Transition Handler for Event Stop.

FSM_CONTROLLABLE:OnEnterStopped(Controllable, From, Event, To)

OnEnter Transition Handler for State Stopped.

FSM_CONTROLLABLE:OnLeaveStopped(Controllable, From, Event, To)

OnLeave Transition Handler for State Stopped.

FSM_CONTROLLABLE:SetControllable(FSMControllable)

Sets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.

FSM_CONTROLLABLE:Stop()

Synchronous Event Trigger for Event Stop.

FSM_CONTROLLABLE:__Stop(Delay)

Asynchronous Event Trigger for Event Stop.

FSM_CONTROLLABLE:_call_handler(step, trigger, params, EventName)

Type FSM_PROCESS

FSM_PROCESS:Assign(Task, ProcessUnit)

Assign the process to a Unit and activate the process.

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:Remove()

Removes an FSM_PROCESS object.

FSM_PROCESS:SetTask(Task)

Sets the task of the process.

FSM_PROCESS.Task
FSM_PROCESS:_call_handler(step, trigger, params, EventName)
FSM_PROCESS:onenterFailed(ProcessUnit, Task, From, Event, To)
FSM_PROCESS:onstatechange(ProcessUnit, Event, From, To, Task)

StateMachine callback function for a FSM_PROCESS

Type FSM_SET

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(step, trigger, params, EventName)

Type FSM_TASK

FSM_TASK:New(TaskName)

Creates a new FSM_TASK object.

FSM_TASK.Task
FSM_TASK:_call_handler(step, trigger, params, EventName)

Global(s)

#FSM FSM

FSM class, extends Base#BASE

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.

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.

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.

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.

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

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

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

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


#FSM_CONTROLLABLE FSM_CONTROLLABLE

FSM_CONTROLLABLE, extends #FSM

FSM_CONTROLLABLE class models Finite State Machines for Controllables, which are Groups, Units, Clients.


#FSM_PROCESS FSM_PROCESS

FSM_PROCESS, extends #FSM

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


#FSM_SET FSM_SET

FSM_SET, extends #FSM

FSM_SET class models Finite State Machines for 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.


#FSM_TASK FSM_TASK

FSM_TASK, extends #FSM

FSM_TASK class models Finite State Machines for Tasks.


Type Fsm

Type FSM

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.

FSM.CallScheduler
FSM.Events
FSM:GetCurrentState()
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()

Creates a new FSM object.

Return value

#FSM:

FSM.Scores
FSM:SetProcess(From, Event, Fsm)

Parameters

  • From :

  • Event :

  • Fsm :

FSM:SetStartState(State)

Sets the start state of the FSM.

Parameter

  • #string State : A string defining the start state.

FSM._EndStates
FSM._EventSchedules
FSM._Processes
FSM._Scores
#string FSM._StartState
FSM._Transitions
FSM:_add_to_map(Map, Event)

Parameters

  • Map :

  • Event :

FSM:_call_handler(step, trigger, params, EventName)

Parameters

  • step :

  • trigger :

  • params :

  • EventName :

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.endstates
FSM:is(state)

Parameter

  • state :

FSM.options
FSM.subs

Type FSM_CONTROLLABLE

Field(s)

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

Return value

#FSM_CONTROLLABLE:

FSM_CONTROLLABLE:OnAfterStop(Controllable, From, Event, To)

OnAfter Transition Handler for Event Stop.

Parameters

  • Wrapper.Controllable#CONTROLLABLE Controllable : The Controllable Object managed by the FSM.

  • #string From : The From State string.

  • #string Event : The Event string.

  • #string To : The To State string.

FSM_CONTROLLABLE:OnBeforeStop(Controllable, From, Event, To)

OnBefore Transition Handler for Event Stop.

Parameters

  • Wrapper.Controllable#CONTROLLABLE Controllable : The Controllable Object managed by the FSM.

  • #string From : The From State string.

  • #string Event : The Event string.

  • #string To : The To State string.

Return value

#boolean: Return false to cancel Transition.

FSM_CONTROLLABLE:OnEnterStopped(Controllable, From, Event, To)

OnEnter Transition Handler for State Stopped.

Parameters

  • Wrapper.Controllable#CONTROLLABLE Controllable : The Controllable Object managed by the FSM.

  • #string From : The From State string.

  • #string Event : The Event string.

  • #string To : The To State string.

FSM_CONTROLLABLE:OnLeaveStopped(Controllable, From, Event, To)

OnLeave Transition Handler for State Stopped.

Parameters

  • Wrapper.Controllable#CONTROLLABLE Controllable : The Controllable Object managed by the FSM.

  • #string From : The From State string.

  • #string Event : The Event string.

  • #string To : The To State string.

Return value

#boolean: Return false to cancel Transition.

FSM_CONTROLLABLE:SetControllable(FSMControllable)

Sets the CONTROLLABLE object that the FSM_CONTROLLABLE governs.

Parameter

Return value

#FSM_CONTROLLABLE:

FSM_CONTROLLABLE:Stop()

Synchronous Event Trigger for Event Stop.

FSM_CONTROLLABLE:__Stop(Delay)

Asynchronous Event Trigger for Event Stop.

Parameter

  • #number Delay : The delay in seconds.

FSM_CONTROLLABLE:_call_handler(step, trigger, params, EventName)

Parameters

  • step :

  • trigger :

  • params :

  • EventName :

Type FSM_PROCESS

Field(s)

FSM_PROCESS:Assign(Task, ProcessUnit)

Assign the process to a Unit and activate the process.

Parameters

Return value

#FSM_PROCESS: self

FSM_PROCESS:Copy(Controllable, Task)

Creates a new FSMPROCESS object based on this FSMPROCESS.

Parameters

  • Controllable :

  • Task :

Return value

#FSM_PROCESS:

FSM_PROCESS:GetCommandCenter()

Gets the mission of the process.

Return value

Tasking.CommandCenter#COMMANDCENTER:

FSM_PROCESS:GetMission()

Gets the mission of the process.

Return value

Tasking.Mission#MISSION:

FSM_PROCESS:GetTask()

Gets the task of the process.

Return value

Tasking.Task#TASK:

FSM_PROCESS:Init(FsmProcess)

Parameter

  • FsmProcess :

FSM_PROCESS:Message(Message)

Send a message of the Task to the Group of the Unit.

Parameter

  • Message :

FSM_PROCESS:New(Controllable, Task)

Creates a new FSM_PROCESS object.

Parameters

  • Controllable :

  • Task :

Return value

#FSM_PROCESS:

FSM_PROCESS:Remove()

Removes an FSM_PROCESS object.

Return value

#FSM_PROCESS:

FSM_PROCESS:SetTask(Task)

Sets the task of the process.

Parameter

Return value

#FSM_PROCESS:

Tasking.Task#TASK FSM_PROCESS.Task
FSM_PROCESS:_call_handler(step, trigger, params, EventName)

Parameters

  • step :

  • trigger :

  • params :

  • EventName :

FSM_PROCESS:onenterFailed(ProcessUnit, Task, From, Event, To)

Parameters

  • ProcessUnit :

  • Task :

  • From :

  • Event :

  • To :

FSM_PROCESS:onstatechange(ProcessUnit, Event, From, To, Task)

StateMachine callback function for a FSM_PROCESS

Parameters

Type FSM_SET

FSM_SET class

Field(s)

FSM_SET:Get()

Gets the SETBASE object that the FSMSET governs.

Return value

Core.Set#SET_BASE:

FSM_SET:New(FSMT, Set_SET_BASE, FSMSet)

Creates a new FSM_SET object.

Parameters

  • #table FSMT : Finite State Machine Table

  • SetSETBASE : FSMSet (optional) The Set object that the FSM_SET governs.

  • FSMSet :

Return value

#FSM_SET:

Core.Set#SET_BASE FSM_SET.Set
FSM_SET:_call_handler(step, trigger, params, EventName)

Parameters

  • step :

  • trigger :

  • params :

  • EventName :

Type FSM_TASK

FSM_TASK class

Field(s)

FSM_TASK:New(TaskName)

Creates a new FSM_TASK object.

Parameter

  • #string TaskName : The name of the task.

Return value

#FSM_TASK:

Tasking.Task#TASK FSM_TASK.Task
FSM_TASK:_call_handler(step, trigger, params, EventName)

Parameters

  • step :

  • trigger :

  • params :

  • EventName :