weyne/MOOSE_DOCS
1
0
Fork 0
mirror of https://github.com/FlightControl-Master/MOOSE_DOCS.git synced 2026-08-20 07:42:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

Auto commit by GitHub Actions Workflow

Browse Source
This commit is contained in:
MooseBotter
2026-03-24 09:16:17 +00:00
parent 9358c16d91
commit 61e9a3c834
29 changed files with 1742 additions and 912 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/Core.Fsm.html
+2 -18
View File
@@ -1502,15 +1502,7 @@ because <strong>the goal of MOOSE is to simplify mission design complexity for m
By efficiently utilizing the FSM class and derived classes, MOOSE allows mission designers to quickly build processes.
<strong>Ready made FSM-based implementations classes</strong> exist within the MOOSE framework that <strong>can easily be re-used,
and tailored</strong> by mission designers through <strong>the implementation of Transition Handlers</strong>.
Each of these FSM implementation classes start either with:</p>
<ul>
<li>an acronym <strong>AI_</strong>, which indicates a FSM implementation directing <strong>AI controlled</strong> <a href="Wrapper.Group.html##(GROUP)">Wrapper.Group#GROUP</a> and/or <a href="Wrapper.Unit.html##(UNIT)">Wrapper.Unit#UNIT</a>. These AI_ classes derive the <a href="##(FSM_CONTROLLABLE)">#FSM_CONTROLLABLE</a> class.</li>
<li>an acronym <strong>TASK_</strong>, which indicates a FSM implementation executing a <a href="Tasking.Task.html##(TASK)">Tasking.Task#TASK</a> executed by Groups of players. These TASK_ classes derive the <a href="##(FSM_TASK)">#FSM_TASK</a> class.</li>
<li>an acronym <strong>ACT_</strong>, which indicates an Sub-FSM implementation, directing <strong>Humans actions</strong> that need to be done in a <a href="Tasking.Task.html##(TASK)">Tasking.Task#TASK</a>, seated in a <a href="Wrapper.Client.html##(CLIENT)">Wrapper.Client#CLIENT</a> (slot) or a <a href="Wrapper.Unit.html##(UNIT)">Wrapper.Unit#UNIT</a> (CA join). These ACT_ classes derive the <a href="##(FSM_PROCESS)">#FSM_PROCESS</a> class.</li>
</ul>
<p>Detailed explanations and API specifics are further below clarified and FSM derived class specifics are described in those class documentation sections.</p>
Detailed explanations and API specifics are further below clarified and FSM derived class specifics are described in those class documentation sections.</p>
<h2><strong>Disclaimer:</strong></h2>
<p>The FSM class development is based on a finite state machine implementation made by Conroy Kyle.
@@ -1521,7 +1513,6 @@ Additionally, I've added extendability and created an API that allows seamless F
<p>The following derived classes are available in the MOOSE framework, that implement a specialized form of a FSM:</p>
<ul>
<li><a href="##(FSM_TASK)">#FSM_TASK</a>: Models Finite State Machines for <a href="Tasking.Task.html">Tasking.Task</a>s.</li>
<li><a href="##(FSM_PROCESS)">#FSM_PROCESS</a>: Models Finite State Machines for <a href="Tasking.Task.html">Tasking.Task</a> actions, which control <a href="Wrapper.Client.html">Wrapper.Client</a>s.</li>
<li><a href="##(FSM_CONTROLLABLE)">#FSM_CONTROLLABLE</a>: Models Finite State Machines for <a href="Wrapper.Controllable.html">Wrapper.Controllable</a>s, which are <a href="Wrapper.Group.html">Wrapper.Group</a>s, <a href="Wrapper.Unit.html">Wrapper.Unit</a>s, <a href="Wrapper.Client.html">Wrapper.Client</a>s.</li>
<li><a href="##(FSM_SET)">#FSM_SET</a>: Models Finite State Machines for <a href="Core.Set.html">Core.Set</a>s. Note that these FSMs control multiple objects!!! So State concerns here
@@ -1586,14 +1577,7 @@ Other examples of ready made FSM could be:</p>
because <strong>the goal of MOOSE is to simplify mission design complexity for mission building</strong>.
By efficiently utilizing the FSM class and derived classes, MOOSE allows mission designers to quickly build processes.
<strong>Ready made FSM-based implementations classes</strong> exist within the MOOSE framework that <strong>can easily be re-used,
and tailored</strong> by mission designers through <strong>the implementation of Transition Handlers</strong>.
Each of these FSM implementation classes start either with:</p>
<ul>
<li>an acronym <strong>AI_</strong>, which indicates an FSM implementation directing <strong>AI controlled</strong> <a href="Wrapper.Group.html##(GROUP)">Wrapper.Group#GROUP</a> and/or <a href="Wrapper.Unit.html##(UNIT)">Wrapper.Unit#UNIT</a>. These AI_ classes derive the <a href="##(FSM_CONTROLLABLE)">#FSM_CONTROLLABLE</a> class.</li>
<li>an acronym <strong>TASK_</strong>, which indicates an FSM implementation executing a <a href="Tasking.Task.html##(TASK)">Tasking.Task#TASK</a> executed by Groups of players. These TASK_ classes derive the <a href="##(FSM_TASK)">#FSM_TASK</a> class.</li>
<li>an acronym <strong>ACT_</strong>, which indicates an Sub-FSM implementation, directing <strong>Humans actions</strong> that need to be done in a <a href="Tasking.Task.html##(TASK)">Tasking.Task#TASK</a>, seated in a <a href="Wrapper.Client.html##(CLIENT)">Wrapper.Client#CLIENT</a> (slot) or a <a href="Wrapper.Unit.html##(UNIT)">Wrapper.Unit#UNIT</a> (CA join). These ACT_ classes derive the <a href="##(FSM_PROCESS)">#FSM_PROCESS</a> class.</li>
</ul>
and tailored</strong> by mission designers through <strong>the implementation of Transition Handlers</strong>.</p>
<p><img src="..\Presentations\FSM\Dia3.JPG" alt="Transition Rules and Transition Handlers and Event Triggers"/></p>