From 05d69457f25008a73e9bb017f872e188092ae92c Mon Sep 17 00:00:00 2001 From: FlightControl Date: Wed, 14 Jun 2017 15:08:49 +0200 Subject: [PATCH] Documentation --- .../Moose/AI/AI_A2A_Dispatcher.lua | 10 +- docs/Documentation/AI_Patrol.html | 3 - docs/Documentation/Cargo.html | 2 + docs/Documentation/Designate.html | 1 - docs/Documentation/Detection.html | 1 - docs/Documentation/Fsm.html | 3 +- docs/Documentation/Movement.html | 4 + docs/Documentation/Spawn.html | 5 +- docs/Documentation/Task_Cargo.html | 3 +- docs/README.md | 123 +++++++++--------- 10 files changed, 73 insertions(+), 82 deletions(-) diff --git a/Moose Development/Moose/AI/AI_A2A_Dispatcher.lua b/Moose Development/Moose/AI/AI_A2A_Dispatcher.lua index 0525d0d72..6865a0e03 100644 --- a/Moose Development/Moose/AI/AI_A2A_Dispatcher.lua +++ b/Moose Development/Moose/AI/AI_A2A_Dispatcher.lua @@ -915,11 +915,11 @@ do -- AI_A2A_DISPATCHER DefenderSquadron.Spawn = {} if type( SpawnTemplates ) == "string" then local SpawnTemplate = SpawnTemplates - self.DefenderSpawns[SpawnTemplate] = self.DefenderSpawns[SpawnTemplate] or SPAWN:New( SpawnTemplate ):InitCleanUp( 30 ) + self.DefenderSpawns[SpawnTemplate] = self.DefenderSpawns[SpawnTemplate] or SPAWN:New( SpawnTemplate ) -- :InitCleanUp( 180 ) DefenderSquadron.Spawn[1] = self.DefenderSpawns[SpawnTemplate] else for TemplateID, SpawnTemplate in pairs( SpawnTemplates ) do - self.DefenderSpawns[SpawnTemplate] = self.DefenderSpawns[SpawnTemplate] or SPAWN:New( SpawnTemplate ):InitCleanUp( 30 ) + self.DefenderSpawns[SpawnTemplate] = self.DefenderSpawns[SpawnTemplate] or SPAWN:New( SpawnTemplate ) -- :InitCleanUp( 180 ) DefenderSquadron.Spawn[#DefenderSquadron.Spawn+1] = self.DefenderSpawns[SpawnTemplate] end end @@ -1882,11 +1882,11 @@ do -- AI_A2A_DISPATCHER if self.TacticalDisplay then -- Show tactical situation - Report:Add( string.format( "\n - Target %s ( %s ): %s" , DetectedItem.ItemID, DetectedItem.Index, DetectedItem.Set:GetObjectNames() ) ) + Report:Add( string.format( "\n - Target %s ( %s ): ( #%d ) %s" , DetectedItem.ItemID, DetectedItem.Index, DetectedItem.Set:Count(), DetectedItem.Set:GetObjectNames() ) ) for Defender, DefenderTask in pairs( self:GetDefenderTasks() ) do local Defender = Defender -- Wrapper.Group#GROUP if DefenderTask.Target and DefenderTask.Target.Index == DetectedItem.Index then - Report:Add( string.format( " - %s ( %s - %s ) %s", Defender:GetName(), DefenderTask.Type, DefenderTask.Fsm:GetState(), Defender:HasTask() == true and "Executing" or "Idle" ) ) + Report:Add( string.format( " - %s ( %s - %s ): ( #%d ) %s", Defender:GetName(), DefenderTask.Type, DefenderTask.Fsm:GetState(), Defender:GetSize(), Defender:HasTask() == true and "Executing" or "Idle" ) ) end end end @@ -1900,7 +1900,7 @@ do -- AI_A2A_DISPATCHER local Defender = Defender -- Wrapper.Group#GROUP if not DefenderTask.Target then local DefenderHasTask = Defender:HasTask() - Report:Add( string.format( " - %s ( %s - %s ) %s", Defender:GetName(), DefenderTask.Type, DefenderTask.Fsm:GetState(), Defender:HasTask() == true and "Executing" or "Idle" ) ) + Report:Add( string.format( " - %s ( %s - %s ): ( #%d ) %s", Defender:GetName(), DefenderTask.Type, DefenderTask.Fsm:GetState(), Defender:GetSize(), Defender:HasTask() == true and "Executing" or "Idle" ) ) end end Report:Add( string.format( "\n - %d Tasks", TaskCount ) ) diff --git a/docs/Documentation/AI_Patrol.html b/docs/Documentation/AI_Patrol.html index 43392b308..93a9f8ce6 100644 --- a/docs/Documentation/AI_Patrol.html +++ b/docs/Documentation/AI_Patrol.html @@ -926,9 +926,6 @@ Use the method AIPATROLZONE.M - -

This table contains the targets detected during patrol.

-
diff --git a/docs/Documentation/Cargo.html b/docs/Documentation/Cargo.html index 262969991..e3fae231c 100644 --- a/docs/Documentation/Cargo.html +++ b/docs/Documentation/Cargo.html @@ -2934,6 +2934,7 @@ The range till cargo will board.

+ CARGO_UNIT.CargoCarrier @@ -3059,6 +3060,7 @@ The range till cargo will board.

+ #number CARGO_UNIT.RunCount diff --git a/docs/Documentation/Designate.html b/docs/Documentation/Designate.html index 70e3562df..c0c7ee573 100644 --- a/docs/Documentation/Designate.html +++ b/docs/Documentation/Designate.html @@ -900,7 +900,6 @@ function below will use the range 1-7 just in case

- DESIGNATE.LaserCodes diff --git a/docs/Documentation/Detection.html b/docs/Documentation/Detection.html index 6e5b46606..4893802ee 100644 --- a/docs/Documentation/Detection.html +++ b/docs/Documentation/Detection.html @@ -2400,7 +2400,6 @@ The index of the DetectedItem.

- #number DETECTION_BASE.DetectedItemMax diff --git a/docs/Documentation/Fsm.html b/docs/Documentation/Fsm.html index 401b60084..5267af595 100644 --- a/docs/Documentation/Fsm.html +++ b/docs/Documentation/Fsm.html @@ -1604,7 +1604,7 @@ A string defining the start state.

- + #string FSM._StartState @@ -1903,7 +1903,6 @@ A string defining the start state.

- FSM.current diff --git a/docs/Documentation/Movement.html b/docs/Documentation/Movement.html index 4307c3aaa..be5ce073c 100644 --- a/docs/Documentation/Movement.html +++ b/docs/Documentation/Movement.html @@ -227,6 +227,7 @@ on defined intervals (currently every minute).

+ #number MOVEMENT.AliveUnits @@ -235,6 +236,9 @@ on defined intervals (currently every minute).

+ +

Contains the counter how many units are currently alive

+
diff --git a/docs/Documentation/Spawn.html b/docs/Documentation/Spawn.html index 0f27003d1..a9e356026 100644 --- a/docs/Documentation/Spawn.html +++ b/docs/Documentation/Spawn.html @@ -2194,9 +2194,6 @@ The group that was spawned. You can use this group for further actions.

- -

Don't repeat the group from Take-Off till Landing and back Take-Off by ReSpawning.

-
@@ -3129,7 +3126,7 @@ Spawn_BE_KA50 = SPAWN:New( 'BE KA-50@RAMP-Ground Defense' ):Schedule( 600, 0.5 )
- #boolean + SPAWN.SpawnUnControlled diff --git a/docs/Documentation/Task_Cargo.html b/docs/Documentation/Task_Cargo.html index 1c2148207..a49a3383f 100644 --- a/docs/Documentation/Task_Cargo.html +++ b/docs/Documentation/Task_Cargo.html @@ -510,7 +510,7 @@ based on the tasking capabilities defined in Task#TA
- + Core.Cargo#CARGO_GROUP FSM_PROCESS.Cargo @@ -524,7 +524,6 @@ based on the tasking capabilities defined in Task#TA
- FSM_PROCESS.DeployZone diff --git a/docs/README.md b/docs/README.md index fa0266ad6..4637ebd8f 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,4 +1,4 @@ -# 1) MOOSE framework +# 1. MOOSE framework MOOSE is a **M**ission **O**bject **O**riented **S**cripting **E**nvironment, and is meant for mission designers and mission hosters. It allows to quickly setup complex missions using pre-scripted scenarios using the available classes within the MOOSE Framework. @@ -17,55 +17,7 @@ Within the community, key users will start supporting, documenting, explaining a It is the ambition to grow this framework as a de-facto standard for mission designers to use. - - -# 2) MOOSE usage - -The delivery of MOOSE follows a structured release process. Over time, new features are added that can be used in your mission. - -### The latest release of MOOSE can be downloaded **[here](https://github.com/FlightControl-Master/MOOSE/releases)**. - -There are 3 different ways how you can use MOOSE, each with a different engagement and complexity level: - - - -## 2.1) Use MOOSE as a Mission Designer - -Refer to the detailed **[Usage Guide](Usage_Guide.html)** for more information. - - - -## 2.2) Beta test MOOSE - -Beta testers of MOOSE are requested to install additional software. - -As a return or as a reward, testers get: - - * Newly developed features planned for the next MOOSE release can be tested and incorporated in your missions early. - * You can evaluate and contribute to the stability of the next release. - * Your mission creation workflow becomes very flexible. New features are dynamically added to you missions. - -Please read the detailed **[Beta Test Guide](Beta_Test_Guide.html)** for more information. - - - -## 2.3) Contribute on the MOOSE development - -Those people who have experience in lua development or are excited to contribute to the MOOSE project are welcome. - -Please consult the **[Contribution Guide](Contribution_Guide.html)** for more information. - - - -# 3) MOOSE Support Channels - -MOOSE is broadcasted, documented and supported through various social media channels. - -Click here for the **[communities guide](Communities.html)** of the MOOSE framework. - - - -# 4) MOOSE Framework +# 2. MOOSE Framework The following classes are currently embedded within MOOSE framework and can be included within your mission scripts: @@ -92,7 +44,7 @@ You'll need to browse to the right MOOSE Class within the inheritance tree struc -## 4.1) MOOSE Demonstration Missions +## 2.1. MOOSE Demonstration Missions The framework comes with demonstration missions which can be downloaded [here](https://github.com/FlightControl-Master/MOOSE_MISSIONS/releases), that you can try out and helps you to code. These missions provide examples of defined use cases how the MOOSE framework can be utilized. Each test mission is located in a separate directory, which contains at least one .lua file and .miz file. @@ -105,7 +57,7 @@ Some of these exact test missions are also demonstrated in a video format on the -## 4.2) MOOSE Core Classes +## 2.2. MOOSE Core Classes These classes define the base building blocks of the MOOSE framework. These classes are heavily used within the MOOSE framework. @@ -141,7 +93,7 @@ The POINT_VEC3 class manages the 3D simulation space, while the POINT_VEC2 class * [RADIO](Documentation/Radio.html): Create radio communication. -## 4.3) MOOSE Wrapper Classes +## 2.3. MOOSE Wrapper Classes MOOSE Wrapper Classes provide an object oriented hierarchical mechanism to manage the DCS objects within the simulator. Wrapper classes provide another easier mechanism to control Groups, Units, Statics, Airbases and other objects. @@ -166,7 +118,7 @@ Wrapper classes provide another easier mechanism to control Groups, Units, Stati -## 4.4) MOOSE Functional Classes +## 2.4. MOOSE Functional Classes MOOSE Functional Classes provide various functions that are useful in mission design. @@ -188,11 +140,13 @@ MOOSE Functional Classes provide various functions that are useful in mission de * [CLEANUP](Documentation/Cleanup.html): Keeps the airbases clean from clutter. (Only partly functional due to a bug in DCS, destroyed objects cannot be removed). -## 4.5) MOOSE AI Controlling Classes +## 2.5. MOOSE AI Controlling Classes MOOSE AI Controlling Classes provide mechanisms to control AI over long lasting processes. These AI Controlling Classes are based on FSM (Finite State Machine) Classes, and provided an encapsulated way to make AI behave or execute an activity. +* [AI_BALANCER](Documentation/AI_A2A_Dispatcher.html): Create an automatic and dynamic A2A defense system, executed by AI units, as a result of detected A2A airborne targets executing CAP and GCI. This script replaces the GCICAP script. + * [AI_BALANCER](Documentation/AI_Balancer.html): Compensate in a multi player mission the abscence of players with dynamically spawned AI air units. When players join CLIENTS, the AI will either be destroyed, or will fly back to the home or nearest friendly airbase. * [AI_PATROL_ZONE](Documentation/AI_Patrol_Zone.html): Make an alive AI Group patrol a zone derived from the ZONE_BASE class. Manage out-of-fuel events and set altitude and speed ranges for the patrol. @@ -204,8 +158,7 @@ These AI Controlling Classes are based on FSM (Finite State Machine) Classes, an * [AI_BAI](Documentation/AI_Bai.html): Make an alive AI Group perform Battlefield Air Interdiction as a dynamic process. - -## 4.6) MOOSE Human Tasking Classes +## 2.6. MOOSE Human Tasking Classes MOOSE Tasking Classes provide a comprehensive Mission Orchestration System. Through COMMANDCENTERs, multiple logical MISSIONs can be orchestrated for coalitions. @@ -216,17 +169,18 @@ Each TASK has a TASK ACTION flow, which is the flow that a player (hosted by a U * [MISSION](Documentation/Mission.html): Each MISSION has various TASKs to be executed and accomplished by players. +* [TASK](Documentation/Task_A2A_Dispatcher.html): Automatically and dynamically dispatch A2A tasks to be executed by human players, as a result of the detection of airborne targets within a Mission scope. + +* [TASK](Documentation/Task_A2G_Dispatcher.html): Automatically and dynamically dispatch A2G tasks to be executed by human players, as a result of the detection of ground targets within a Mission scope. + * [TASK](Documentation/Task.html): Each TASK has a status, and has a TASK ACTION flow for each Player acting and executing the TASK. -* [TASK_SEAD](Documentation/Task_SEAD.html): Models a SEAD Task, where a Player is routed towards an attack zone, and various SEADing targets need to be eliminated. +* [TASK_CAS](Documentation/Task_A2G.html): Models a A2G tasks (SEAD, CAS and BAI) tasks, where a Player is routed towards an attack zone with enemies nearby, and various ground targets need to be eliminated. -* [TASK_BAI](Documentation/Task_A2G.html): Models a CAP Task, where a Player is routed towards an attack zone without enemies nearby, and various ground targets need to be eliminated. - -* [TASK_CAS](Documentation/Task_A2G.html): Models a CAS Task, where a Player is routed towards an attack zone with enemies nearby, and various ground targets need to be eliminated. +* [TASK_BAI](Documentation/Task_A2A.html): Models a A2A tasks (CAP, INTERCEPT, SWEEP) tasks, where a Player is routed towards an attack zone without enemies nearby, and various ground targets need to be eliminated. - -## 4.7) MOOSE Action Classes +## 2.7. MOOSE Action Classes MOOSE Action Classes are task action sub-flows, that can be used and combined, to quickly define a comprehensive end-to-end task action flow. For example, for the SEAD Task, the task action flow combines the actions ASSIGN, ROUTE, ACCOUNT and ASSIST task action sub-flows. @@ -241,9 +195,50 @@ For example, for the SEAD Task, the task action flow combines the actions ASSIGN +# 3. MOOSE usage + +The delivery of MOOSE follows a structured release process. Over time, new features are added that can be used in your mission. + +### The latest release of MOOSE can be downloaded **[here](https://github.com/FlightControl-Master/MOOSE/releases)**. + +There are 3 different ways how you can use MOOSE, each with a different engagement and complexity level: -# 5) Credits +## 3.1. Use MOOSE as a Mission Designer + +Refer to the detailed **[Usage Guide](Usage_Guide.html)** for more information. + + +## 3.2. Beta test MOOSE + +Beta testers of MOOSE are requested to install additional software. + +As a return or as a reward, testers get: + + * Newly developed features planned for the next MOOSE release can be tested and incorporated in your missions early. + * You can evaluate and contribute to the stability of the next release. + * Your mission creation workflow becomes very flexible. New features are dynamically added to you missions. + +Please read the detailed **[Beta Test Guide](Beta_Test_Guide.html)** for more information. + + +## 3.3. Contribute on the MOOSE development + +Those people who have experience in lua development or are excited to contribute to the MOOSE project are welcome. + +Please consult the **[Contribution Guide](Contribution_Guide.html)** for more information. + + + +# 4. MOOSE Support Channels + +MOOSE is broadcasted, documented and supported through various social media channels. + +Click here for the **[communities guide](Communities.html)** of the MOOSE framework. + + + +# 5. Credits Note that most of the framework is based on code i've written myself, but some code of it is also based on code that i've seen as great scripting code and ideas,