weyne/MOOSE
1
0
Fork 0
mirror of https://github.com/FlightControl-Master/MOOSE.git synced 2026-08-12 16:57:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'Apple/Develop' into master-ng

Browse Source
This commit is contained in:
Thomas
2026-03-24 10:13:28 +01:00
committed by GitHub
parent 6bccd64ade 5e2e8d1fae
commit 75d4b70623
11 changed files with 406 additions and 82 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Moose Development/Moose/Core/Fsm.lua
-12
View File
@@ -45,12 +45,6 @@
-- 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 a 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 a 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.
--
-- Detailed explanations and API specifics are further below clarified and FSM derived class specifics are described in those class documentation sections.
--
-- ##__Disclaimer:__
@@ -61,7 +55,6 @@
--
-- The following derived classes are available in the MOOSE framework, that implement a specialized form of a FSM:
--
-- * @{#FSM_TASK}: Models Finite State Machines for @{Tasking.Task}s.
-- * @{#FSM_PROCESS}: Models Finite State Machines for @{Tasking.Task} actions, which control @{Wrapper.Client}s.
-- * @{#FSM_CONTROLLABLE}: Models Finite State Machines for @{Wrapper.Controllable}s, which are @{Wrapper.Group}s, @{Wrapper.Unit}s, @{Wrapper.Client}s.
-- * @{#FSM_SET}: Models Finite State Machines for @{Core.Set}s. Note that these FSMs control multiple objects!!! So State concerns here
@@ -118,11 +111,6 @@ do -- FSM
-- 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.
--
-- ![Transition Rules and Transition Handlers and Event Triggers](..\Presentations\FSM\Dia3.JPG)
--
Moose Development/Moose/Core/Set.lua
+2 -47
View File
@@ -1149,30 +1149,6 @@ do
-- --self:F({ GroupObject = GroupObject:GetName() })
-- end
--
-- While this is a good example, there is a catch.
-- Imagine you want to execute the code above, the the self would need to be from the object declared outside (above) the OnAfterDead method.
-- So, the self would need to contain another object. Fortunately, this can be done, but you must use then the **`.`** notation for the method.
-- See the modified example:
--
-- -- Now we have a constructor of the class AI_CARGO_DISPATCHER, that receives the SetHelicopter as a parameter.
-- -- Within that constructor, we want to set an enclosed event handler OnAfterDead for SetHelicopter.
-- -- But within the OnAfterDead method, we want to refer to the self variable of the AI_CARGO_DISPATCHER.
--
-- function AI_CARGO_DISPATCHER:New(SetCarrier, SetCargo, SetDeployZones)
--
-- local self = BASE:Inherit(self, FSM:New()) -- #AI_CARGO_DISPATCHER
--
-- -- Put a Dead event handler on SetCarrier, to ensure that when a carrier is destroyed, that all internal parameters are reset.
-- -- Note the "." notation, and the explicit declaration of SetHelicopter, which would be using the ":" notation the implicit self variable declaration.
--
-- function SetHelicopter.OnAfterDead(SetHelicopter, From, Event, To, GroupObject)
-- SetHelicopter:F({ GroupObject = GroupObject:GetName() })
-- self.PickupCargo[GroupObject] = nil -- So here I clear the PickupCargo table entry of the self object AI_CARGO_DISPATCHER.
-- self.CarrierHome[GroupObject] = nil
-- end
--
-- end
--
-- ===
-- @field #SET_GROUP SET_GROUP
SET_GROUP = {
@@ -2308,28 +2284,6 @@ do -- SET_UNIT
-- --self:F({ UnitObject = UnitObject:GetName() })
-- end
--
-- While this is a good example, there is a catch.
-- Imagine you want to execute the code above, the the self would need to be from the object declared outside (above) the OnAfterDead method.
-- So, the self would need to contain another object. Fortunately, this can be done, but you must use then the **`.`** notation for the method.
-- See the modified example:
--
-- -- Now we have a constructor of the class AI_CARGO_DISPATCHER, that receives the SetHelicopter as a parameter.
-- -- Within that constructor, we want to set an enclosed event handler OnAfterDead for SetHelicopter.
-- -- But within the OnAfterDead method, we want to refer to the self variable of the AI_CARGO_DISPATCHER.
--
-- function ACLASS:New(SetCarrier, SetCargo, SetDeployZones)
--
-- local self = BASE:Inherit(self, FSM:New()) -- #AI_CARGO_DISPATCHER
--
-- -- Put a Dead event handler on SetCarrier, to ensure that when a carrier is destroyed, that all internal parameters are reset.
-- -- Note the "." notation, and the explicit declaration of SetHelicopter, which would be using the ":" notation the implicit self variable declaration.
--
-- function SetHelicopter.OnAfterDead(SetHelicopter, From, Event, To, UnitObject)
-- SetHelicopter:F({ UnitObject = UnitObject:GetName() })
-- self.array[UnitObject] = nil -- So here I clear the array table entry of the self object ACLASS.
-- end
--
-- end
-- ===
-- @field #SET_UNIT SET_UNIT
SET_UNIT = {
@@ -5814,6 +5768,7 @@ do -- SET_AIRBASE
end
do -- SET_ZONE
---
@@ -7905,7 +7860,7 @@ do -- SET_SCENERY
local AddSceneryNamesArray = (type(AddSceneryNames) == "table") and AddSceneryNames or { AddSceneryNames }
--self:T((AddSceneryNamesArray)
--UTILS.PrintTableToLog(AddSceneryNamesArray)
for AddSceneryID, AddSceneryName in pairs(AddSceneryNamesArray) do
self:Add(AddSceneryName, SCENERY:FindByZoneName(AddSceneryName))
end