weyne/MOOSE
1
0
Fork 0
mirror of https://github.com/FlightControl-Master/MOOSE.git synced 2025-08-15 10:47:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/master' into develop

Browse Source
This commit is contained in:
Applevangelist 2023-11-08 17:02:53 +01:00
commit 57ca4f37a3
126 changed files with 2976 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/gh-pages.yml vendored
View File

@ -75,4 +75,4 @@ jobs:
- name: Setup Node
uses: actions/setup-node@v3
- run: npm install linkinator
- run: npx linkinator https://flightcontrol-master.github.io/MOOSE/ --recurse
- run: npx linkinator https://flightcontrol-master.github.io/MOOSE/ --verbosity error --timeout 5000 --recurse

9
docs/_config.yml
View File

@ -34,3 +34,12 @@ callouts_opacity: 0.4
aux_links:
GitHub: https://github.com/FlightControl-Master/MOOSE
Discord: https://discord.gg/aQtjcR94Qf
kramdown:
syntax_highlighter_opts:
block:
line_numbers: true
compress_html:
ignore:
envs: all

181
docs/archive/classes-ai.md Normal file
View File

@ -0,0 +1,181 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 1
---
# AI classes guide
## 1. A2A Dispatching
### 1.1. [AI A2A Dispatcher]
![AI A2A Dispatcher](../images/classes/ai/a2a-dispatcher.jpg)
Create an **A2A defense system** executed by AI to perform CAP or GCI to defend your airspace.
There are two classes that are important to learn:
* [AI_A2A_GCICAP]
* [AI_A2A_DISPATCHER]
The [AI_A2A_GCICAP] is a class for **novice mission designers**,
so I recommend novice users to start with using this class.
You can quickly configure a working GCICAP process.
But it will provide less flexibility and options.
If you want more options, use the [AI_A2A_DISPATCHER].
**Features:**
* Setup quickly an A2A defense system for a coalition.
* Setup (CAP) Control Air Patrols at defined zones to enhance your A2A defenses.
* Setup (GCI) Ground Control Intercept at defined airbases to enhance your A2A defenses.
* Define and use an EWR (Early Warning Radar) network.
* Define squadrons at airbases.
* Enable airbases for A2A defenses.
* Add different plane types to different squadrons.
* Add multiple squadrons to different airbases.
* Define different ranges to engage upon intruders.
* Establish an automatic in air refuel process for CAP using refuel tankers.
* Setup default settings for all squadrons and A2A defenses.
* Setup specific settings for specific squadrons.
* Quickly setup an A2A defense system using AI_A2A_GCICAP.
* Setup a more advanced defense system using AI_A2A_DISPATCHER.
## 2. AI Cargo Dispatching
Cargo dispatching will make the AI to transport cargo to deploy zones.
Cargo can be transported by APC or trucks, or by helicopters.
**Overall Features:**
* Quickly transport cargo to various deploy zones using different carrier types.
* Various cargo types can be transported. These are infantry groups and crates.
* Define a list of deploy zones of various types to transport the cargo to.
* Multiple carrier groups can be enabled as one collaborating transportation process.
* Different options can be setup to tweak the cargo transporation behaviour.
* Home location that will be used for carrier parking, when all cargo has been transported.
* Automatic activation of carriers when new cargo is to be picked-up (of cargo is spawned for example).
### 2.1. [AI Cargo Dispatching for APC]
![AI_Cargo_Dispatcher_APC](../images/classes/ai/cargo-dispatcher-apc.jpg)
Models the intelligent transportation of infantry and other cargo using **APCs or trucks**.
**Specific Features:**
* The vehicles follow the roads to ensure the fastest possible cargo transportation over the ground.
* Multiple vehicles can transport multiple cargo as one vehicle group.
* Infantry loaded as cargo, will unboard in case enemies are nearby and will help defending the vehicles.
* Different ranges can be setup for enemy defenses.
### 2.2. [AI Cargo Dispatching for Helicopters]
![AI_Cargo_Dispatcher_Helicopter](../images/classes/ai/cargo-dispatcher-helicopters.jpg)
Models the intelligent transportation of infantry and other cargo using **Helicopters**.
**Specific Features:**
* The helicopters will fly towards the pickup locations to pickup the cargo.
* The helicopters will fly towards the deploy zones to deploy the cargo.
* Precision deployment as well as randomized deployment within the deploy zones are possible.
* Helicopters will orbit the deploy zones when there is no space for landing until the deploy zone is free.
## 3. [AI Balancing]
![AI_Balancer](../images/classes/ai/balancer.jpg)
Balance player slots with AI to create an engaging simulation environment, independent of the amount of players.
**Features:**
* Automatically spawn AI as a replacement of free player slots for a coalition.
* Make the AI to perform tasks.
* Define a maximum amount of AI to be active at the same time.
* Configure the behaviour of AI when a human joins a slot for which an AI is active.
## 4. [AI Large Formations]
![AI_Formation](../images/classes/ai/formation.jpg)
Build large airborne formations of aircraft.
**Features:**
* Build in-air formations consisting of more than 40 aircraft as one group.
* Build different formation types.
* Assign a group leader that will guide the large formation path.
## 5. AI engagement
### 5.1. [AI Patrolling]
![AI_Patrol](../images/classes/ai/patrol.jpg)
Peform Air Patrolling for airplanes within a patrol zone.
**Features:**
* Patrol AI airplanes within a given zone.
* Trigger detected events when enemy airplanes are detected.
* Manage a fuel treshold to RTB on time.
### 5.2. [AI Combat Air Patrolling]
![AI_Patrol](../images/classes/ai/cap.jpg)
Peform Combat Air Patrolling (CAP) for airplanes within a patrol zone.
**Features:**
* Patrol AI airplanes within a given zone.
* Trigger detected events when enemy airplanes are detected.
* Manage a fuel treshold to RTB on time.
* Engage the enemy when detected.
### 5.3. [AI Close Air Support]
![AI_Patrol](../images/classes/ai/a2g-cas.jpg)
Peform Close Air Support (CAS) near friendlies within an engagement zone.
**Features:**
* Hold and standby within a patrol zone.
* Engage upon command the enemies within an engagement zone.
* Loop the zone until all enemies are eliminated.
* Trigger different events upon the results achieved.
* After combat, return to the patrol zone and hold.
* RTB when commanded or after out of fuel.
### 5.4. [AI Battlefield Air Interdiction]
![AI_Patrol](../images/classes/ai/bai.jpg)
Peform Battlefield Air Interdiction (BAI) within an engagement zone.
**Features:**
* Hold and standby within a patrol zone.
* Engage upon command the assigned targets within an engagement zone.
* Loop the zone until all targets are eliminated.
* Trigger different events upon the results achieved.
* After combat, return to the patrol zone and hold.
* RTB when commanded or after out of fuel.
[AI A2A Dispatcher]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_A2A_Dispatcher.html
[AI_A2A_GCICAP]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_A2A_Dispatcher.html#AI_A2A_GCICAP
[AI_A2A_DISPATCHER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_A2A_Dispatcher.html#AI_A2A_DISPATCHER
[AI Cargo Dispatching for APC]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_APC.html
[AI Cargo Dispatching for Helicopters]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_Helicopter.html
[AI Balancing]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Balancer.html
[AI Large Formations]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Formation.html
[AI Patrolling]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Patrol.html
[AI Combat Air Patrolling]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_CAP.html
[AI Close Air Support]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_CAS.html
[AI Battlefield Air Interdiction]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_BAI.html
[AI Patrolling]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Patrol.html

263
docs/archive/classes-cargo.md Normal file
View File

@ -0,0 +1,263 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 3
---
# Cargo classes guide
![MOOSE CARGO](../images/classes/category-cargo.jpg)
MOOSE implements a whole enhanced mechanism to **create virtual cargo** within your missions.
Within this system, virtual cargo can be represented by:
* Moveable cargo, represented by **groups of units**. It can be **boarded** into **carriers**, which can be
**APCs or vehicles**, **helicopters**, **planes** or **ships**.
* Stationary cargo, reprented by **static objects** or **static cargo objects**. It can be loaded into **carriers**,
which can also be **APCs** or **vehicles**, **helicopters**, **planes** or **ships**.
* Sling loadable cargo, reprented by **static cargo objects**. It can be sling loaded by **helicopter carriers**.
In order to use the MOOSE cargo management system, you'll need to declare cargo objects as part of your mission
script and setup either an **AI or a human cargo (task) dispatcher** to transport this virtual cargo around the
battlefield. For this, several MOOSE classes have been created for cargo dispatchment, which are listed below.
Click on each individual MOOSE class for detailed features and usage explanations, which are part of the detailed MOOSE
class documentation.
## 1. [WAREHOUSE]
![WAREHOUSE](../images/classes/functional/warehouse.jpg)
The MOOSE warehouse concept simulates the organization and implementation of complex operations regarding the flow of
assets between the point of origin and the point of consumption in order to meet requirements of a potential conflict.
In particular, this class is concerned with maintaining army supply lines while disrupting those of the enemy, since an
armed force without resources and transportation is defenseless.
**Features:**
* Holds (virtual) assests in stock and spawns them upon request.
* Manages requests of assets from other warehouses.
* Queueing system with optional priorization of requests.
* Realistic transportation of assets between warehouses.
* Different means of automatic transportation (planes, helicopters, APCs, self propelled).
* Strategic components such as capturing, defending and destroying warehouses and their associated infrastructure.
* Intelligent spawning of aircraft on airports (only if enough parking spots are available).
* Possibility to hook into events and customize actions.
* Can be easily interfaced to other MOOSE classes.
Please note that his class is work in progress and in an **alpha** stage.
**Video:**
[![Warehouse](https://img.youtube.com/vi/e98jzLi5fGk/0.jpg)](https://youtu.be/e98jzLi5fGk "Warehouse")
## 2. [AI_CARGO_DISPATCHER]
![AI_CARGO_DISPATCHER](../images/classes/ai/cargo-dispatcher.jpg)
This section details the classes that you can use to setup an automatic cargo dispatching system that will make
AI carriers transport cargo (automatically) through the battlefield. Depending on the type of AI unit types, various
classes are implemented.
However, this class is the **BASE class** and contains the main functionality for the underlying more detailed
implementation classes. So, please read the documentation of the AI_CARGO_DISPATCHER class first (by clicking on it!)
### 2.1. [AI_CARGO_DISPATCHER_APC]
![AI_Cargo_Dispatcher_APC](../images/classes/ai/cargo-dispatcher-apc.jpg)
Models the intelligent transportation of **infantry** and other **small or lightweight cargo** using **APCs or trucks**.
This class models cargo to be transported between **zones**!
**Features:**
* The vehicles follow the roads to ensure the fastest possible cargo transportation over the ground.
* Multiple vehicles can transport multiple cargo as one vehicle group.
* Infantry loaded as cargo, will unboard in case enemies are nearby and will help defending the vehicles.
* Different ranges can be setup for enemy defenses.
### 2.2. [AI_CARGO_DISPATCHER_HELICOPTER]
![AI_Cargo_Dispatcher_Helicopter](../images/classes/ai/cargo-dispatcher-helicopters.jpg)
Models the intelligent transportation of **infantry** and other **small cargo** using **Helicopters**.
This class models cargo to be transported between **zones**!
**Features:**
* The helicopters will fly towards the pickup locations to pickup the cargo.
* The helicopters will fly towards the deploy zones to deploy the cargo.
* Precision deployment as well as randomized deployment within the deploy zones are possible.
* Helicopters will orbit the deploy zones when there is no space for landing until the deploy zone is free.
### 2.3. [AI_CARGO_DISPATCHER_AIRPLANE]
![AI_Cargo_Dispatcher_Airplane](../images/classes/ai/cargo-dispatcher-airplanes.jpg)
Models the intelligent transportation of **infantry, vehicles** and other **heavy cargo** using **Airplanes**.
This class models cargo to be transported between **airbases**!
**Features:**
* The airplanes will fly towards the pickup airbases to pickup the cargo.
* The airplanes will fly towards the deploy airbases to deploy the cargo.
---
## 3. Human cargo transportation dispatching.
Also **humans can achieve tasks** by to **transporting cargo** as part of a task or mission **goal**.
### 3.1. [TASK_CARGO_DISPATCHER]
![TASK_CARGO_DISPATCHER](../images/classes/tasking/cargo-dispatcher.jpg)
The [TASK_CARGO_DISPATCHER] allows you to setup various tasks for let human players transport cargo as part of a task.
The cargo dispatcher will implement for you mechanisms to create cargo transportation tasks:
* As setup by the mission designer.
* Dynamically create CSAR missions (when a pilot is downed as part of a downed plane).
* Dynamically spawn new cargo and create cargo taskings!
**Features:**
* Creates a task to transport @{Cargo.Cargo} to and between deployment zones.
* Derived from the TASK_CARGO class, which is derived from the TASK class.
* Orchestrate the task flow, so go from Planned to Assigned to Success, Failed or Cancelled.
* Co-operation tasking, so a player joins a group of players executing the same task.
**A complete task menu system to allow players to:**
* Join the task, abort the task.
* Mark the task location on the map.
* Provide details of the target.
* Route to the cargo.
* Route to the deploy zones.
* Load/Unload cargo.
* Board/Unboard cargo.
* Slingload cargo.
* Display the task briefing.
**A complete mission menu system to allow players to:**
* Join a task, abort the task.
* Display task reports.
* Display mission statistics.
* Mark the task locations on the map.
* Provide details of the targets.
* Display the mission briefing.
* Provide status updates as retrieved from the command center.
* Automatically assign a random task as part of a mission.
* Manually assign a specific task as part of a mission.
**A settings system, using the settings menu:**
* Tweak the duration of the display of messages.
* Switch between metric and imperial measurement system.
* Switch between coordinate formats used in messages: BR, BRA, LL DMS, LL DDM, MGRS.
* Different settings modes for A2G and A2A operations.
* Various other options.
---
## 4. The cargo system explained.
The following section provides a detailed explanation on the cargo system, how to use etc.
<https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.Cargo.html>
---
## 5. Cargo management classes.
MOOSE has implemented **a separate system for cargo handling**.
It combines the capabilities of DCS world to combine infantry groups, cargo static objects and static objects
as "cargo" objects. Cargo classes provides a new and enhanced way to handle cargo management and transportation.
In order to use these MOOSE cargo facilities, you'll have to declare those groups and static objects
in a special way within your scripts and/or within the mission editor.
The main [Cargo.Cargo] class is the base class for all the cargo management.
It contains the required functionality to load / board / unload / unboard cargo, and manage the state of each cargo
object. From this CARGO class are other CARGO_ classes derived, which inherit the properties and functions from CARGO,
but implement a specific process to handle specific cargo objects!
It is not the purpose to use directly the CARGO class within your missions.
However, consult the CARGO documention as it provides a comprehensive description on how to manage cargo within your
missions.
### 5.1. [CARGO_GROUP]
![CARGO_GROUP](../images/classes/cargo/cargogroup.jpg)
Management of **moveable** and **grouped** cargo logistics, which are based on a
[Wrapper.Group] object. Typical cargo of this type can be infantry or (small) vehicles.
**Features:**
* Board cargo into a carrier.
* Unboard cargo from a carrier.
* Automatic detection of destroyed cargo.
* Respawn cargo.
* Maintain cargo status.
* Communication of cargo through messages.
* Automatic declaration of group objects to be treated as MOOSE cargo in the mission editor!
### 5.2. [CARGO_CRATE]
![CARGO_CRATE](../images/classes/cargo/cargocrate.jpg)
Management of single cargo crates, which are based on a [Wrapper.Static] object. Typical cargo of this type can be
crates, oil barrels, wooden crates etc. The cargo can be ANY static type! So potentially also other types of static
objects can be treated as cargo! Like flags, tires etc.
**Features:**
* Loading / Unloading of cargo.
* Automatic detection of destroyed cargo.
* Respawn cargo.
* Maintain cargo status.
* Communication of cargo through messages.
* Automatic declaration of group objects to be treated as MOOSE cargo in the mission editor!
### 5.3. [CARGO_SLINGLOAD]
![CARGO_SLINGLOAD](../images/classes/cargo/cargoslingload.jpg)
Management of **sling loadable** cargo crates, which are based on a [Wrapper.Static] object. This cargo can only be
slingloaded.
**Features:**
* Slingload cargo.
* Automatic detection of destroyed cargo.
* Respawn cargo.
* Maintain cargo status.
* Communication of cargo through messages.
* Automatic declaration of group objects to be treated as MOOSE cargo in the mission editor!
### 5.4. [CARGO_UNIT]
Management of **moveable** units, which are based on a [Wrapper.Unit] object.
Note that this is an **Internal** class and is only mentioned here for reference!
[WAREHOUSE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Warehouse.html
[AI_CARGO_DISPATCHER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher.html
[AI_CARGO_DISPATCHER_APC]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_APC.html
[AI_CARGO_DISPATCHER_HELICOPTER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_Helicopter.html
[AI_CARGO_DISPATCHER_HELICOPTER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_Helicopter.html
[AI_CARGO_DISPATCHER_AIRPLANE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/AI.AI_Cargo_Dispatcher_Airplane.html
[TASK_CARGO_DISPATCHER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Tasking.Task_Cargo_Dispatcher.html
[CARGO_GROUP]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.CargoGroup.html
[CARGO_CRATE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.CargoCrate.html
[CARGO_SLINGLOAD]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.CargoSlingload.html
[CARGO_UNIT]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.CargoUnit.html
[Cargo.Cargo]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Cargo.Cargo.html
[Wrapper.Group]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Group.html
[Wrapper.Static]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Static.html
[Wrapper.Unit]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Unit.html

401
docs/archive/classes-core.md Normal file
View File

@ -0,0 +1,401 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 5
---
# Core classes guide
![MOOSE CORE](../images/classes/category-core.jpg)
This chapter lists the core classes, which enhance existing DCS capabilities, and are used throughout the framework.
Mission designers can use these core classes to enhance their scripting.
## 1. [BASE](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Base.html)
![BASE](../images/classes/core/base.jpg)
Wraps the DCS _Group_ objects.
**Features:**
* The construction and inheritance of MOOSE classes.
* The class naming and numbering system.
* The class hierarchy search system.
* The tracing of information or objects during mission execution for debuggin purposes.
* The subscription to DCS events for event handling in MOOSE objects.
* Object inspection.
**Remember, everything in moose derives from the BASe class.**
## 2. [DATABASE](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Database.html)
![DATABASE](../images/classes/core/database.jpg)
Manages several databases containing templates, mission objects, and mission information.
**Features:**
* During mission startup, scan the mission environment, and create / instantiate intelligently the different objects as defined within the mission.
* Manage database of DCS Group templates (as modelled using the mission editor).
- Group templates.
- Unit templates.
- Statics templates.
* Manage database of [Wrapper.Group] objects alive in the mission.
* Manage database of [Wrapper.Unit] objects alive in the mission.
* Manage database of [Wrapper.Static] objects alive in the mission.
* Manage database of players.
* Manage database of client slots defined using the mission editor.
* Manage database of airbases on the map, and from FARPs and ships as defined using the mission editor.
* Manage database of countries.
* Manage database of zone names.
* Manage database of hits to units and statics.
* Manage database of destroys of units and statics.
* Manage database of [Core.Zone] objects.
**These database contain all objects, you can filter these objects using sets.**
## 3. [EVENT](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Event.html)
![EVENT](../images/classes/core/event.jpg)
Models DCS event dispatching using a publish-subscribe model.
**Features:**
* Capture DCS events and dispatch them to the subscribed objects.
* Generate DCS events to the subscribed objects from within the code.
**Learn the event handling system, it will make your life much more easier while designing missions.**
## 4. [FSM](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Fsm.html)
![FSM](../images/classes/core/fsm.jpg)
FSM (Finite State Machine) are objects that model and control long lasting business processes and workflow.
**Features:**
* Provide a base class to model your own state machines.
* Trigger events synchronously.
* Trigger events asynchronously.
* Handle events before or after the event was triggered.
* Handle state transitions as a result of event before and after the state change.
* For internal moose purposes, further state machines have been designed:
- to handle controllables (groups and units).
- to handle tasks.
- to handle processes.
**Finite State Machines are a great asset within moose, it is used everywhere to create dynamic workflows!**
## 5. [GOAL](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Goal.html)
![GOAL](../images/classes/core/goal.jpg)
Models the process to achieve Goal(s). Derived classes implement the ways how the achievements can be realized.
**Features:**
* Define the goal.
* Monitor the goal achievement.
* Manage goal contribution by players.
**Define goals to provide your players with a challenge.**
## 6. [MENU](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Menu.html)
![MENU](../images/classes/core/menu.jpg)
Manage hierarchical menu structures and commands for players within a mission.
The advantage of using menu classes is that it hides the complexity of dealing with menu management in more advanced
scanerios where you need to set menus and later remove them, and later set them again. You'll find while using use
normal DCS scripting functions, that setting and removing menus is not a easy feat if you have complex menu hierarchies
defined. Using the moose menu classes, the removal and refreshing of menus are nicely being handled within these
classes, and becomes much more easy. On top, moose implements variable parameter passing for command menus, which can
be updated without having to touch the menus.
**Features:**
* Setup mission sub menus.
* Setup mission command menus.
* Setup coalition sub menus.
* Setup coalition command menus.
* Setup group sub menus.
* Setup group command menus.
* Manage menu creation intelligently, avoid double menu creation.
* Only create or delete menus when required, and keep existing menus persistent.
* Update menu structures.
* Refresh menu structures intelligently, based on a time stamp of updates.
- Delete obscolete menus.
- Create new one where required.
- Don't touch the existing ones.
* Provide a variable amount of parameters to menus.
* Update the parameters and the receiving methods, without updating the menu within DCS!
* Provide a great performance boost in menu management.
* Provide a great tool to manage menus in your code.
**Learn the menu system, it has some great hidden features.**
## 7. [MESSAGE](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Message.html)
![MESSAGE](../images/classes/core/message.jpg)
Informs the players using messages during a simulation.
**Features:**
* A more advanced messaging system using the DCS message system.
* Time messages.
* Send messages based on a message type, which has a pre-defined duration that can be tweaked in SETTINGS.
* Send message to all players.
* Send messages to a coalition.
* Send messages to a specific group.
**The message system really helps with the communication to your players.**
## 8. [POINT](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Point.html)
![POINT](../images/classes/core/point.jpg)
Defines an extensive API to manage 3D points in the DCS World 3D simulation space.
**Features:**
* Provides a COORDINATE class, which allows to manage points in 3D space and perform various operations on it.
* Provides a POINT_VEC2 class, which is derived from COORDINATE, and allows to manage points in 3D space, but from a
Lat/Lon and Altitude perspective.
* Provides a POINT_VEC3 class, which is derived from COORDINATE, and allows to manage points in 3D space, but from a
X, Z and Y vector perspective.
**The coordinate system classes are essential to understand. Learn this!**
## 9. [RADIO](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Sound.Radio.html)
![RADIO](../images/classes/sound/radio.jpg)
Is responsible for everything that is related to radio transmission and you can hear in DCS, be it TACAN beacons, Radio
transmissions.
**Features:**
* Provide radio functionality to broadcast radio transmissions.
* Provide beacon functionality to assist pilots.
**Radio and beacons really enhance game experience for hardened and experienced players and pilots!**
## 10. [REPORT](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Report.html)
![REPORT](../images/classes/core/report.jpg)
Provides a handy means to create messages and reports. This class is extensively used in the tasking mechanism.
**Features:**
* Create text blocks that are formatted.
* Create automatic indents.
* Variate the delimiters between reporting lines.
**Reports are used extensively in moose. Learn it and your messages get structure.**
## 11. [SCHEDULER](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Scheduler.html)
![SCHEDULER](../images/classes/core/scheduler.jpg)
Prepares and handles the execution of functions over scheduled time (intervals).
**Features:**
* Schedule functions over time,
* optionally in an optional specified time interval,
* optionally **repeating** with a specified time repeat interval,
* optionally **randomizing** with a specified time interval randomization factor,
* optionally **stop** the repeating after a specified time interval.
**Scheduler is key to control time and timed events.**
**When you lean how to schedule functions, you will be in control of your mission.**
## 12. [SET](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Set.html)
![SET](../images/classes/core/sets.jpg)
Define collections of objects to perform bulk actions and logically group objects.
**Features:**
* Dynamically maintain collections of objects.
* Manually modify the collection, by adding or removing objects.
* Collections of different types.
* Validate the presence of objects in the collection.
* Perform bulk actions on collection.
**Collections are essential to control the objects and data in your missions efficiently.**
## 13. [SETTINGS](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Settings.html)
![SETTINGS](../images/classes/core/settings.jpg)
Manages various settings for running missions, consumed by moose classes and provides a menu system for players to tweak
settings in running missions.
**Features:**
* Provide a settings menu system to the players.
* Provide a player settings menu and an overall mission settings menu.
* Mission settings provide default settings, while player settings override mission settings.
* Provide a menu to select between different coordinate formats for A2G coordinates.
* Provide a menu to select between different coordinate formats for A2A coordinates.
* Provide a menu to select between different message time duration options.
* Provide a menu to select between different metric systems.
**Settings can really enhance game play, especially for non-europeans :-)**
## 14. [SPAWN](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Spawn.html)
![SPAWN](../images/classes/core/spawn.jpg)
Spawn dynamically new groups of units in running missions.
**Features:**
* Spawn new groups in running missions.
* Schedule spawning of new groups.
* Put limits on the amount of groups that can be spawned, and the amount of units that can be alive at the same time.
* Randomize the spawning location between different zones.
* Randomize the intial positions within the zones.
* Spawn in array formation.
* Spawn uncontrolled (for planes or helos only).
* Clean up inactive helicopters that "crashed".
* Place a hook to capture a spawn event, and tailor with customer code.
* Spawn late activated.
* Spawn with or without an initial delay.
* Respawn after landing, on the runway or at the ramp after engine shutdown.
* Spawn with custom heading.
* Spawn with different skills.
* Spawn with different liveries.
* Spawn with an inner and outer radius to set the initial position.
* Spawn with a randomize route.
* Spawn with a randomized template.
* Spawn with a randomized start points on a route.
* Spawn with an alternative name.
* Spawn and keep the unit names.
* Spawn with a different coalition and country.
* Enquiry methods to check on spawn status.
**Spawning groups is a great way of making your missions dynamic!**
## 15. [SPAWNSTATIC](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.SpawnStatic.html)
![SPAWNSTATIC](../images/classes/core/spawnstatic.jpg)
Spawn new statics in your running missions.
**Features:**
* Spawn new statics from a static already defined using the mission editor.
* Spawn new statics from a given template.
* Spawn new statics from a given type.
* Spawn with a custom heading and location.
* Spawn within a zone.
**Spawning statics is a great way of decorating your missions with additional scenery objects!**
## 16. [SPOT](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Spot.html)
![SPOT](../images/classes/core/spot.jpg)
Management of spotting logistics, that can be activated and deactivated upon command.
**Features:**
* Spot for a defined duration.
* Updates of laer spot position every 0.2 seconds for moving targets.
* Wiggle the spot at the target.
* Provide a @{Wrapper.Unit} as a target, instead of a point.
* Implement a status machine, LaseOn, LaseOff.
**Spot is a rather technical class, and is used in designate and warehouse.**
## 17. [USERFLAG](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.UserFlag.html)
![USERFLAG](../images/classes/core/userflag.jpg)
Manage user flags to interact with the mission editor trigger system and server side scripts.
**Features:**
* Set or get DCS user flags within running missions.
**User flags are the method to set or retrieve the value of flags as set in the mission editor.**
## 18. [USERSOUND](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Sound.UserSound.html)
![USERSOUND](../images/classes/sound/usersound.jpg)
Manage user sound.
**Features:**
* Play sounds wihtin running missions.
**User sounds are a great way to enhance your missions with ambient music or sounds upon various events.**
## 19. [VELOCITY](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Velocity.html)
![VELOCITY](../images/classes/core/velocity.jpg)
Models a velocity or speed, which can be expressed in various formats according the settings.
**Features:**
* Convert velocity in various metric systems.
* Set the velocity.
* Create a text in a specific format of a velocity.
**Velocity is an internal class used within the moose framework.**
## 20. [ZONE](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Zone.html)
![ZONE](../images/classes/core/zones.jpg)
Define zones within your mission of various forms, with various capabilities.
**Features:**
* Create radius zones.
* Create trigger zones.
* Create polygon zones.
* Create moving zones around a unit.
* Create moving zones around a group.
* Provide the zone behaviour. Some zones are static, while others are moveable.
* Enquiry if a coordinate is within a zone.
* Smoke zones.
* Set a zone probability to control zone selection.
* Get zone coordinates.
* Get zone properties.
* Get zone bounding box.
* Set/get zone name.
**Zones are very important in mission design, this is definitely a skill to learn to make great missions!**
[Wrapper.Group]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Group.html
[Wrapper.Static]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Static.html
[Wrapper.Unit]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Unit.html
[Core.Zone]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Zone.html

284
docs/archive/classes-functional.md Normal file
View File

@ -0,0 +1,284 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 4
---
# Functional classes guide
![MOOSE FUNCTIONAL](../images/classes/category-functional.jpg)
This chapter explains functional classes within MOOSE that allows you to enrich or enhance the functionality of your mission scenarios.
## 1. [ATC_GROUND]
![ATC Ground](../images/classes/functional/atc-ground.jpg)
The ATC_GROUND classes monitor airbase traffic and regulate speed while taxiing.
**Features:**
* Monitor speed of the airplanes of players during taxi.
* Communicate ATC ground operations.
* Kick speeding players during taxi.
## 2. [ARTY]
![Arty](../images/classes/functional/artillery.jpg)
Easily assign and manage targets for artillery units using an advanced queueing system.
**Features:**
* Multiple targets can be assigned. No restriction on number of targets.
* Targets can be given a priority. Engagement of targets is executed a according to their priority.
* Engagements can be scheduled, i.e. will be executed at a certain time of the day.
* Multiple relocations of the group can be assigned and scheduled via queueing system.
* Special weapon types can be selected for each attack, e.g. cruise missiles for Naval units.
* Automatic rearming once the artillery is out of ammo (optional).
* Automatic relocation after each firing engagement to prevent counter strikes (optional).
* Automatic relocation movements to get the battery within firing range (optional).
* Simulation of tactical nuclear shells as well as illumination and smoke shells.
* New targets can be added during the mission, e.g. when they are detected by recon units.
* Targets and relocations can be assigned by placing markers on the F10 map.
* Finite state machine implementation. Mission designer can interact when certain events occur.
## 3. [CLEANUP]
![CleanUp](../images/classes/functional/cleanup.jpg)
Keep an airbase clean of crashing or colliding airplanes.
**Features:**
* Try to keep the airbase clean and operational.
* Prevent airplanes from crashing.
* Clean up obstructing airplanes from the runway that are standing still for a period of time.
* Prevent airplanes firing missiles within the airbase zone.
## 4. [DESIGNATE]
![Designate](../images/classes/functional/designation.jpg)
Orchestrate the designation of potential targets executed by a Recce group,
and communicates these to a dedicated attacking group of players,
so that following a dynamically generated menu system,
each detected set of potential targets can be lased or smoked...
**Features:**
* Faciliate the communication of detected targets to players.
* Designate targets using lasers, through a menu system.
* Designate targets using smoking, through a menu system.
* Designate targets using illumination, through a menu system.
* Auto lase targets.
* Refresh detection upon specified time intervals.
* Prioritization on threat levels.
* Reporting system of threats.
## 5. [DETECTION]
![Detection](../images/classes/functional/detection.jpg)
Facilitate the detection of enemy units within the battle zone executed by FACs (Forward Air Controllers) or Recces (Reconnassance Units).
Detection uses the in-built detection capabilities of DCS World, but adds new functionalities.
**Features:**
* Detection of targets by recce units.
* Group detected targets per unit, type or area (zone).
* Keep persistency of detected targets, if when detection is lost.
* Provide an indication of detected targets.
* Report detected targets.
* Refresh detection upon specified time intervals.
## 6. [ESCORT]
![Escort](../images/classes/functional/escorting.jpg)
Allows you to interact with escorting AI on your flight and take the lead.
Each escorting group can be commanded with a whole set of radio commands (radio menu in your flight, and then F10).
The radio commands will vary according the category of the group. The richest set of commands are with Helicopters and AirPlanes.
Ships and Ground troops will have a more limited set, but they can provide support through the bombing of targets designated by the other escorts.
**Features:**
* Escort navigation commands.
* Escort hold at position commands.
* Escorts reporting detected targets.
* Escorts scanning targets in advance.
* Escorts attacking specific targets.
* Request assistance from other groups for attack.
* Manage rule of engagement of escorts.
* Manage the allowed evasion techniques of escorts.
* Make escort to execute a defined mission or path.
* Escort tactical situation reporting.
## 7. [MISSILE_TRAINER]
![MissileTrainer](../images/classes/functional/missile-trainer.jpg)
be alerted of any missiles fired, and when a missile would hit your aircraft, the class will destroy the missile within a certain range,
to avoid damage to your aircraft. This is a training class for noob pilots, receiving training on missile evasion and detection techniques.
**Features:**
* Track the missiles fired at you and other players, providing bearing and range information of the missiles towards the airplanes.
* Provide alerts of missile launches, including detailed information of the units launching, including bearing, range
* Provide alerts when a missile would have killed your aircraft.
* Provide alerts when the missile self destructs.
* Enable / Disable and Configure the Missile Trainer using the various menu options.
## 8. [RANGE]
![Range](../images/classes/functional/range.jpg)
The RANGE class enables easy set up of bombing and strafing ranges within DCS World.
476th - Air Weapons Range Objects mod is highly recommended for this class.
**Features:**
* Impact points of bombs, rockets and missils are recorded and distance to closest range target is measured and reported to the player.
* Number of hits on strafing passes are counted and reported. Also the percentage of hits w.r.t fired shots is evaluated.
* Results of all bombing and strafing runs are stored and top 10 results can be displayed.
* Range targets can be marked by smoke.
* Range can be illuminated by illumination bombs for night practices.
* Bomb, rocket and missile impact points can be marked by smoke.
* Direct hits on targets can trigger flares.
* Smoke and flare colors can be adjusted for each player via radio menu.
* Range information and weather report at the range can be reported via radio menu.
## 9. [RAT]
![rat](../images/classes/functional/rat.jpg)
Fill the empty DCS world with randomized air traffic and bring more life to your airports.
In particular, it is designed to spawn AI air units at random airports. These units will be assigned a random flight path to another random airport on the map.
Even the mission designer will not know where aircraft will be spawned and which route they follow.
**Features:**
* Very simple interface. Just one unit and two lines of Lua code needed to fill your map.
* High degree of randomization. Aircraft will spawn at random airports, have random routes and random destinations.
* Specific departure and/or destination airports can be chosen.
* Departure and destination airports can be restricted by coalition.
* Planes and helicopters supported. Helicopters can also be send to FARPs and ships.
* Units can also be spawned in air within pre-defined zones of the map.
* Aircraft will be removed when they arrive at their destination (or get stuck on the ground).
* When a unit is removed a new unit with a different flight plan is respawned.
* Aircraft can report their status during the route.
* All of the above can be customized by the user if necessary.
* All current (Caucasus, Nevada, Normandy, Persian Gulf) and future maps are supported.
## 10. [SCORING]
![Scoring](../images/classes/functional/scoring.jpg)
Administers the scoring of player achievements, and creates a CSV file logging the scoring events and results for use at team or squadron websites.
Automatically calculates the threat level of the objects hit and destroyed by players, which can be Wrapper.Unit, Static objects.
Positive score points are granted when enemy or neutral targets are destroyed.
Negative score points or penalties are given when a friendly target is hit or destroyed.
This brings a lot of dynamism in the scoring, where players need to take care to inflict damage on the right target.
By default, penalties weight heavier in the scoring, to ensure that players don't commit fratricide.
The total score of the player is calculated by adding the scores minus the penalties.
**Features:**
* Set the scoring scales based on threat level.
* Positive scores and negative scores.
* A contribution model to score achievements.
* Score goals.
* Score specific achievements.
* Score the hits and destroys of units.
* Score the hits and destroys of statics.
* Score the hits and destroys of scenery.
* Log scores into a CSV file.
* Connect to a remote server using JSON and IP.
## 11. [SEAD]
![Sead](../images/classes/functional/sead.jpg)
Provides defensive behaviour to a set of SAM sites within a running Mission.
**Features:**
* When SAM sites are being fired upon, the SAMs will take evasive action will reposition themselves when possible.
* When SAM sites are being fired upon, the SAMs will take defensive action by shutting down their radars.
## 12. [SUPPRESSION]
![Supporession](../images/classes/functional/suppression.jpg)
When ground units get hit by (suppressive) enemy fire, they will not be able to shoot back for a certain amount of time.
The implementation is based on an idea and script by MBot. See the DCS forum threat for details.
In addition to suppressing the fire, conditions can be specified which let the group retreat to a defined zone, move away from the attacker or hide at a nearby scenery object.
**Features:**
* Hold fire of attacked units when being fired upon.
## 13. [WAREHOUSE]
![Warehouse](../images/classes/functional/warehouse.jpg)
The warehouse concept simulates the organization and implementation of complex operations regarding the flow of assets between the point of origin
and the point of consumption in order to meet requirements of a potential conflict.
In particular, this class is concerned with maintaining army supply lines while disrupting those of the enemy,
since an armed force without resources and transportation is defenseless.
**Features:**
* Holds (virtual) assests in stock and spawns them upon request.
* Manages requests of assets from other warehouses.
* Queueing system with optional priorization of requests.
* Realistic transportation of assets between warehouses.
* Different means of automatic transportation (planes, helicopters, APCs, self propelled).
* Strategic components such as capturing, defending and destroying warehouses and their associated infrastructure.
* Intelligent spawning of aircraft on airports (only if enough parking spots are available).
* Possibility to hook into events and customize actions.
* Can be easily interfaced to other MOOSE classes.
## 14. [ZONE_CAPTURE_COALITION]
![ZoneCaptureCoalition](../images/classes/functional/zonecapturecoalition.jpg)
A very powerful class to models the process to zone guarding, attacking and capturing.
**Features:**
* Models the possible state transitions between the Guarded, Attacked, Empty and Captured states.
* A zone has an owning coalition, that means that at a specific point in time, a zone can be owned by the red or blue coalition.
* Provide event handlers to tailor the actions when a zone changes coalition or state.
[ATC_GROUND]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.ATC_Ground.html
[ARTY]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Artillery.html
[CLEANUP]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.CleanUp.html
[DESIGNATE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Designate.html
[DETECTION]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Detection.html
[ESCORT]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Escort.html
[MISSILE_TRAINER]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.MissileTrainer.html
[RANGE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Range.html
[RAT]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.RAT.html
[SCORING]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Scoring.html
[SEAD]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Sead.html
[SUPPRESSION]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Suppression.html
[WAREHOUSE]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Warehouse.html
[ZONE_CAPTURE_COALITION]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.ZoneCaptureCoalition.html

103
docs/archive/classes-tasking.md Normal file
View File

@ -0,0 +1,103 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 2
---
# Tasking classes guide
![MOOSE TASKING](../images/classes/category-tasking.jpg)
This chapter explains the major principles behind the tasking concepts in MOOSE.
Tasking is achieved through the utilization of various classes that fall in the category Tasking.
MOOSE allows humans to achieve mission goals, through the execution of tasks.
In order to setup the Tasking, you'll have to define:
- At least one command center object for each coalition.
- A mission or multiple missions for each command center.
- A task dispatcher per mission.
**Features:**
* Each coalition must have a command center.
* Each command center can govern multiple missions.
* Each command center owns a player menu.
* Each mission can contain multiple tasks of different categories.
* Each mission has a goal to be achieved.
* Each mission has a state, that indicates the fase of the mission.
* Each task can be joined by multiple human players, thus, a task is done in co-op mode.
* Each task has a state, that indicates the fase of the task.
* Players have their own menu. When a player joins a task, only that player will have the menu of the task.
## 1. [Command Center]
![Tasking Command Center](../images/classes/tasking/commandcenter.jpg)
A command center governs multiple missions, and takes care of the reporting and communications.
**Features:**
* Govern multiple missions.
* Communicate to coalitions, groups.
* Assign tasks.
* Manage the menus.
* Manage reference zones.
## 2. [Mission]
![Tasking Command Center](../images/classes/tasking/mission.jpg)
A mission models a goal to be achieved through the execution and completion of tasks by human players.
**Features:**
* A mission has a goal to be achieved, through the execution and completion of tasks of different categories by human players.
* A mission manages these tasks.
* A mission has a state, that indicates the fase of the mission.
* A mission has a menu structure, that facilitates mission reports and tasking menus.
* A mission can assign a task to a player.
## 3. [A2A Task Dispatcher]
![Tasking A2A Dispatching](../images/classes/tasking/task-a2a-dispatcher.jpg)
Dynamically allocates A2A tasks to human players, based on detected airborne targets through an EWR network.
**Features:**
* Dynamically assign tasks to human players based on detected targets.
* Dynamically change the tasks as the tactical situation evolves during the mission.
* Dynamically assign (CAP) Control Air Patrols tasks for human players to perform CAP.
* Dynamically assign (GCI) Ground Control Intercept tasks for human players to perform GCI.
* Dynamically assign Engage tasks for human players to engage on close-by airborne bogeys.
* Define and use an EWR (Early Warning Radar) network.
* Define different ranges to engage upon intruders.
* Keep task achievements.
* Score task achievements.
## 3. [A2G Task Dispatcher]
![Tasking A2G Dispatching](../images/classes/tasking/task-a2g-dispatcher.jpg)
Dynamically allocates A2G tasks to human players, based on detected ground targets through reconnaissance.
**Features:**
* Dynamically assign tasks to human players based on detected targets.
* Dynamically change the tasks as the tactical situation evolves during the mission.
* Dynamically assign (CAS) Close Air Support tasks for human players.
* Dynamically assign (BAI) Battlefield Air Interdiction tasks for human players.
* Dynamically assign (SEAD) Supression of Enemy Air Defense tasks for human players to eliminate G2A missile threats.
* Define and use an EWR (Early Warning Radar) network.
* Define different ranges to engage upon intruders.
* Keep task achievements.
* Score task achievements.
[Command Center]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Tasking.CommandCenter.html
[Mission]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Tasking.Mission.html
[A2A Task Dispatcher]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Tasking.Task_A2A_Dispatcher.html
[A2G Task Dispatcher]: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Tasking.Task_A2G_Dispatcher.html

65
docs/archive/classes-wrapper.md Normal file
View File

@ -0,0 +1,65 @@
---
parent: Mission Designers Guide
grand_parent: Archive
nav_order: 5
---
# Wrapper classes guide
![MOOSE WRAPPER](../images/classes/category-wrapper.jpg)
This chapter lists the wrapper classes which enhances the functionality for mission designers on the mission objects.
## 1. [GROUP](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Group.html)
![Group](../images/classes/wrapper/group.jpg)
Wraps the DCS _Group_ objects.
**Features:**
* Support all DCS Group APIs.
* Enhance with Group specific APIs not in the DCS Group API set.
* Handle local Group Controller.
* Manage the "state" of the DCS Group.
## 2. [UNIT](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Unit.html)
![Unit](../images/classes/wrapper/unit.jpg)
Wraps the DCS _Unit_ objects.
**Features:**
* Support all DCS Unit APIs.
* Enhance with Unit specific APIs not in the DCS Unit API set.
* Handle local Unit Controller.
* Manage the "state" of the DCS Unit.
## 3. [STATIC](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Static.html)
![Static](../images/classes/wrapper/static.jpg)
Wraps the DCS _Static_ objects.
Note that Statics are almost the same as Units, but they don't have a controller.
**Features:**
* Wraps the DCS Static objects.
* Support all DCS Static APIs.
* Enhance with Static specific APIs not in the DCS API set.
## 4. [AIRBASE](https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Airbase.html)
![Airbase](../images/classes/wrapper/airbase.jpg)
Wraps the DCS _Airbase_ objects.
**Features:**
* Support all DCS Airbase APIs.
* Enhance with Airbase specific APIs not in the DCS Airbase API set.

173
docs/archive/guide-beta-tester.md Normal file
View File

@ -0,0 +1,173 @@
---
parent: Archive
nav_order: 3
---
# Beta Tester Guide
You are interrested in **testing the bleeding edge functionalities** and features added by contributors every day,
and you are **not afraid of bugs** that will inevitably crop up from time to time ? Then this page is for you !
You are going to learn:
1. **Installation:** How to set up your development environment
2. **Repository:** How is the Moose repository organized
3. **Loading:** How Moose is loaded in the missions and how this can make your workflow more efficient
4. How to use tools to process your .miz files efficiently
5. How Moose's release cycle work
6. How the Issue Tracker is managed
This might be a bit daunting at first, but the rewards in term of simplified workflow and direct access to new features
is well worth the effort! If you have any problem during the setup or at any other point, don't hesitate to ask the
[community](guide-communities.md) for help!
This guide assumes that **you already setup your development environment**, like a "normal" mission designer.
Which means Lua Development Tools (LDT) is installed on your computer, and you already know how to create a mission
using MOOSE. If it is not the case, please follow the instructions [here](guide-usage.md) before proceeding.
## Installation
Get your MOOSE repository installed on your PC and linked with GITHUB
### Install GitHub desktop
Install [GitHub](https://desktop.github.com) desktop.
Since the MOOSE code is evolving very rapidely between Releases, we store the MOOSE code on GitHub, and we use the
GitHub to sync it between the remote repository (the "origin") and your local MOOSE repository. That way, only one
click is needed to update to the latest version of GitHub.
### Link the MOOSE repository
Link the MOOSE repository on GITHUB to your freshly installed GITHUB desktop.
This is done by browing to the [MOOSE repository at GitHub](https://github.com/FlightControl-Master/MOOSE), and
selecting the green button **Clone or Download** -> **Open in Desktop**.
![](../images/archive/installation/GitHub_Clone.JPG)
Specify a local directory on your PC where you want to store the MOOSE repository contents.
Sync the MOOSE repository to a defined local MOOSE directory on your PC using GITHUB desktop (press the sync button).
You now have a copy of the code on computer, which you can update at any time by simply pressing the sync button.
### Install 7-Zip
Install [7-Zip](http://www.7-zip.org/) if you don't already have it. It is a free and open source file archiver program.
Since DCS .miz files are simply renamed .zip files, 7-Zip is very usefull to manimulate them. We are providing the MOOSE
testers and contributors with tools to batch process their .miz files, and they rely on 7-Zip. Keep the path to your
7-Zip installation handy, it will be use in the next step!
# Repository
The MOOSE repository has a couple of folders, but the most important one is the **Moose Development** folder.
This directory contains an other folder called **Moose**. This is the most important folder, as this contains all the
MOOSE source code!
The other directories contained within the repository are for administration and automation of the deployment process.
# Loading the repository within your missions.
## Static Loading
**Moose Static Loading** is what the "normal" mission designer uses.
Simply put, you would include all the code of MOOSE by including **just one Moose.lua file**.
So by executing a DO SCRIPT FILE within your mission, you would load the complete MOOSE code within your mission.
This process is very useful **when you are using a stable Release** of Moose which don't change often,
because it is really easy to set up for the mission designer.
It also allows him to **release missions** which are contained in their entirety in the .miz file.
But in a context in wich Moose changes often, static loading would require the generation of a new Moose.lua
**for every change within the MOOSE framework** and you would need to replace the old Moose.lua in the .miz file you are
using to test the changes. Add to this cumbersome process the fact that the Mission Editor doesn't like changes to the
.miz file while it is open, which means you would need to close and reopen the Mission Editor for every change,
and this process becomes unworkable for both the tester and the contributor.
## Dynamic Loading
So, beyond the Static Loading, there is the Dynamic Loading, which allows a much more smooth proces while testing your
missions.
Enter **Moose Dynamic loading**. In this process, the **Moose.lua** you insert in your .miz file looks for every .lua
which constitute Moose in `DCSWorld\Scripts`, **and asks DCS to load them** during the mission startup.
This way, the latest changes to the MOOSE .lua files in `DCSWorld\Scripts` are automatically taken into account when you
restart the mission, no need to fiddle around with the .miz file or to close the mission editor!
Now, there is still a problem left : you wouldn't want to have to copy the MOOSE .lua files from your local repository
to `DCSWorld\Scripts`, everytime you retrieve a new version of Moose. The solution to this problem is a dynamic link!
Simply put, it makes sure that the folder `DCSWorld\Scripts\Moose` is always in sync with your local MOOSE repository
on your disk. That way, **everytime you want to update to the next Moose, you simply sync your local repository** with
the remote with GitHub, **and restart your mission**!
Note that if you want to **release your missions to end users**, you will need to make it
**use the static loading process**. There is a tool to automate this task, read below.
# Tools to help you manage your .miz files
***TODO : Add a list of the .miz files tools a briefly explain their usages***
# The release cycle
To ensure that the next Release of Moose is as bug-free and feature rich as possible, every Moose contributor respects
a release cycle.
![](../images/archive/installation/MOOSE_Release_Cycle.JPG)
If you are not familiar with Git, this might be a bit criptic, but the idea behind it is simple :
* Most of the time, contributors write code, be it features or bug fixes, and the testers report bugs.
* When a good amount of features are added to the last release, FlightControl decides to enter in a "Feature Freeze"
period. **No new features are added** during this period (but they can still be worked on), and
**every bug must be eliminated**. That is the period during which bug reports are paramount!
* Now that this version of **Moose is stable**, we can release it for every mission designer and go back to the start
for the next cycle.
# The Issue Tracker
## How to report a bug?
If you **encounter** what seem to be a **bug**, which is bound to happen sooner or later since you are testing the brand
new untested features of Moose, you will want to **report it** so that it can be solved by the contributors. We use the
standard GitHub [Issue Tracker](https://github.com/FlightControl-Master/MOOSE/issues). Here is the process to create a
new issue:
* First, do a quick **search on the issue tracker** to see if someone hasn't already reported your issue. If it is the
case, comment on this issue that you are able to reproduce it, and add the informations listed below.
* **Create a new issue**.
* **Add the information** listed below
* Add the **lablel possible bug**
* Thank you for helping us make Moose better!
**_Informations we need to solve the issue_**
* **A descriptive title**, not too long if possible. For exemple, `CTD when calling SPAWN:New()` is a good title.
`I found a bug in MOOSE` is not.
* Explain **what you are trying to do**, as well as **how you expect Moose to be behave**.
* Which **version of Moose** and DCS World you are using. This can be found in `dcs.log`
* Did the code you are using worked in previous version of either DCS World or Moose? Which one?
* The **code** or portion of code **that triggered the problem**. Please put **_\`\`\`lua_** one line before your
code, and **_\`\`\`_** at the end, to make your code readable.
* The relevant part of **`dcs.log`**. Please put **_\`\`\`_** before and after your copy-pasted log to make it readable.
![Example of a great bug report](../images/archive/installation/GitHub_Issue_example.JPG)
## How to add a feature request?
* **A descriptive title**, not too long if possible.
* Explain in detail **what you want Moose to do** in which circonstance.
* If possible, add some pseudocode or a high level design implementation to better explain how your feature would work.
* Add the **lablel enhancment**
## The life and death of an issue
**_What is going to happen next to my issue?_**
* A contributor will set some labels and a milestone to your issue, in order to classify it.
* You might be asked to clarify some part of your issue, please answer as swiftly as possible.
* You might be asked to sync your local repository and try again, if we think we fixed your issue. If we can confirm it
to be fixed the issue is closed.
**_Wait, my issue was closed, and it never got fixed ! / Nobody is paying attention to it !_**
This can happen for multiple reasons:
* Your issue is a duplicate. (There is alredy a issue in our issue tracker for this)
* Nobody was able to reproduce your bug, so we think it's a problem on your end
* Your feature request asks for a feature that already exists
* We think your feature request is a really good idea, but it's a huge time commitment. We therefore postponed it to the
Realease after the next one, or to a later Release.
* We are working hard and simply don't have the time. We will get around to check your issue, please be patient!

45
docs/archive/guide-communities.md Normal file
View File

@ -0,0 +1,45 @@
---
parent: Archive
nav_order: 7
---
# Communities
MOOSE is broadcasted, documented and supported through various social media channels.
## 1. MOOSE on YouTube
MOOSE has a [broadcast channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg) on youtube.
These videos are grouped into playlists, which explain specific MOOSE capabilities,
and gradually build up the "understanding" and "what is possible" to do with the MOOSE framework.
I really, really encourage all to watch the explanation videos.
Some mandatory videos to watch are:
* [MOOSE Introduction](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl1JEtVcyf9sazUV5_fGICz4)
* [MOOSE Setup](https://www.youtube.com/watch?v=-Hxae3mTCE8&t=159s&index=1&list=PL7ZUrU4zZUl0riB9ULVh-bZvFlw1_Wym2)
* [MOOSE Spawning](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl1jirWIo4t4YxqN-HxjqRkL)
* [MOOSE Tasking](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl3CgxN2iAViiGLTPpQ-Ajdg)
* [MOOSE Task Dispatching](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl3I6ieFM-cjey-rncF1ktNI)
## 2. MOOSE on Eagle Dynamics forums
This is a default thread at the Eagle Dynamics forums where the MOOSE framework can be discussed and supported.
The thread is called [MOOSE - Mission Object Oriented Scripting Framework].
## 3. MOOSE development on GitHub
I encourage that you create also a user at [GitHub](https://github.com/FlightControl-Master/MOOSE).
On the GitHub site, you can register issues, feedback and comments in the issues section of the site.
This allows to track this feedback and issues, in order to provide a structured support and create a milestone plan.
In other words, treat this development as a project.
## 4. MOOSE community on Discord
Join our MOOSE community on [Discord](https://discord.gg/yBPfxC6).
A place where mission designers and developers come together to discuss the latest features.
We are now with about 5 people supporting Mission Designers on Discord.
There are currently more than 300 members on our discord MOOSE channel.
[MOOSE - Mission Object Oriented Scripting Framework]: https://forums.eagle.ru/showthread.php?t=138043

246
docs/archive/guide-contribution.md Normal file
View File

@ -0,0 +1,246 @@
---
parent: Archive
nav_order: 5
---
# Contribution
*** UNDER CONSTRUCTION ***
So, you are already familiarized with Lua and you think the best way to get the new feature you want fast is to program
it yourself ? Or you feel like reporting bugs isn't enough, you want to fix them yourself ? Either way, you need some
more information to contribute to Moose.
This guide assumes that **you are already familiar with Moose** and that **you already set up your development**
**environment**. If it is not the case, please go through the [Beta Tester Guide](guide-beta-tester.md) before
proceeding.
In this document, we will review:
1. GitHub/Git organisation
2. Contribution guidelines
3. Coding standards
4. The Luadoc
5. Moose release cycle
6. The Issue Tracker: labels and milestones
# 1) GitHub/Git organisation
You are assumed to be familar with at least the basics of GitHub (branches, commits, pull requests...). If it is not the
case, please at least read [this tutorial](https://guides.github.com/introduction/flow/). If something isn't clear
still, ask us, we'll be glad to explain!
## 1.1) The Repositories
Moose is in fact located on **three repositories** :
* [**MOOSE**](https://github.com/FlightControl-Master/MOOSE) contains the Moose's **code**, the **documentation** and
the file necessary to the **setup**
* [**MOOSE_MISSIONS**](https://github.com/FlightControl-Master/MOOSE_MISSIONS) contains the **demo missions**
* [**MOOSE_PRESENTATIONS**](https://github.com/FlightControl-Master/MOOSE_PRESENTATIONS) contains bits and bob related
to Moose, like Moose's logos and PowerPoint files to present a specific feature of Moose.
## 1.2) Branches
On the [MOOSE](https://github.com/FlightControl-Master/MOOSE) repository, three branches are protected, which means that
you cannot merge or commit directly to them, you need to create a pull request;
* [master](https://github.com/FlightControl-Master/MOOSE/tree/master) stores Moose's current latest semi-stable code.
* master-release stores Mosse's last release code. There is no reason you would want to modify this branch.
* [master-backup](https://github.com/FlightControl-Master/MOOSE/tree/master-backup). We sometime backup the master into
master-backup, in case the worst happen. There is no reason you would want to modify this branch.
You are encourgaed to **create your own branch, named after you pseudonyme**, to test stuff and do some small-scale
bugfixes. When you want to work on bigger features, you should **create a new branch named after the feature** you are
working on. Don't forget to delete it when the feature is merged with master!
## 1.3) Commits
The usual [Git commit](https://chris.beams.io/posts/git-commit/) guidelines apply. Don't overthink it though, time is
better spent coding or managing the Issue Tracker than writing long-form commit descriptions.
## 1.4) Merge/Pull Requests
When the code you are working on is finished, you will want to **resolve the merge conflicts** between your branch and
master, and then **create a pull request**. Explain clearly what your code does (with a link to the relevant issue).
If it meets the requirements below, it will be approved ASAP by FlightControl.
# 2) Contribution guidelines
We try to **follow a contribution process**, to make sure we work efficiently together. It isn't set in stone, but it
gives an idea of what should be done. We wouldn't want two contributors both working on the same issue at the same time,
would we ? This process is more geared towards the implementation of new features, the process for bug fixes is more
flexible and several steps can be overlooked.
1. Think about **what you are trying to achieve.** Writing some pseudocode is a great way to undersatnd the challenges
you are going to face.
2. **Discuss your idea** with the community **on Slack**. Maybe there is a way to do it you didn't even think about, or
maybe you could team up with someone who is already working on it!
3. Create a **high level design document**. It doesn't need to be thorough, but you need to have an idea of which class
do you want to write, which class they should inherit from, which methods are needed in each class...
4. Write an **issue on GitHub** with your high level design document, apply the label "enhancement" to it, and assign it
to yourself.
5. Create a **new branch** named after the feature **on MOOSE's repository** to work on (you will be given contributor
access).
6. **Write your code** in this branch, following the Coding Standards. **Sync** fairly regularly
**this branch with master**, so that you don't have tons of merge conflicts at the end.
7. When done, **write a/some test mission(s)** to showcase how to use your feature to the community.
8. **Generate the Luadoc**.
9. **Relsove merge conflicts** with master and **create a new pull request**.
10. **Delete your branch** if you are not going to use it again.
# 3) Coding Standards
To ensure a good degree of **consistency** in Moose's code, we follow the following standards:
* The code need to be **intellisense/Luadoc compatible**. See below for more information
* The code needs to be **commented**. Remember:
_“Programs must be written for people to read, and only incidentally for machines to execute.”_ - Hal Abelson.
Keep in mind that you code will be red by non-programmers and beginners.
* **Indentation** should be 2 spaces (default in LDT)
* **Class names** should be in **capital letters** (e.g. `SPAWN`)
* **Class should all inherit from `Core.Base#BASE`**
* **Methods** should start by a **capital letter** (e.g. `GetName()`)
* If your **method** is intended for **private use** only, its name should **start with an underscore**
(e.g. `_GetLastIndex()`)
* **Variables** should start with a **capital leter** (e.g. `IndexString`)
* Provide a **trace** for the mission designer at the start of every method, and when it is appropriate.
Trace functions are inherited from `BASE` :
* `F()`, `F2()` and `F3()` for function calls,
* `T()`, `T2()` and `T3()` for function logic,
* `E()` for errors.
# 4) The Luadoc
The **Luadoc system** is not only **useful for the contributor** to understand the code, but
**also the mission designer**, as it used to automatically generate the
[HTML documentation](http://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/index.html).
It thus needs to follow some strict standards.
Keep in mind the following informations:
* Every Luadoc block needs to start with **three minus signs** (`---`).
* The generated html file will use **Markdown**. If you are not familar with it, use this
[reference](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
* You can create **hyperlinks** by writing
* `@{Module#CLASS.Method}` for a method
* `@{Module#CLASS}` for a class
* `Module` can be ommited if the hyperlink points to the same module (e.g. `@{#CLASS}` is valid if CLASS is in the
Module the link is in)
* Luadoc **types the variables**. the following types are available
* `Folder.Module#CLASS` (a Moose class)
* `Dcs.DCSTypes#Class` (a DCS class)
* `#string`
* `#number` (integer or floating point)
* `#boolean`
* `#nil`
## 4.1) Modules
Every new file should contain at least one module, which is documented by a comment block. You can copy paste the
following model and fill in the blanks:
```lua
--- **Name of the Module** - Short Description
--
-- ===
--
-- Long description. Explain the use cases.
-- Remember that this section will be red by non programmers !
--
-- ===
--
-- ### Authors : Your name/pseudnyme
--
-- @module Module
```
## 4.2) Classes
Every class should be documented by a comment block. You can copy paste the following model and fill in the blanks :
```lua
--- **Name of the CLASS** class, extends @{Module#CLASS}
--
-- Long description. Explain the use cases.
-- Remember that this section will be red by non programmers !
--
-- @type CLASSNAME
-- @field #type AttributeName (add a @field for each attribute)
-- @extends Folder.Module#CLASS
```
## 4.3) Methods
Every method should be documented by a comment block. You can copy paste the following model and fill in the blanks :
```lua
--- Description of the method
-- @param #type (add a @param for each parameters, self included, even if it's implied)
-- @return #type (add other @return fields if the method can return different variables)
-- @usage (can be omitted if the usage is obvious)
-- -- Explain how to use this method
-- -- on multiple lines if you need it !
```
# 5) Moose release cycle
To ensure that the next Release of Moose is as bug-free and feature rich as possible, every Moose contributor
**respects a release cycle**.
![](../images/archive/installation/MOOSE_Release_Cycle.JPG)
The key takeways are:
* During "normal" time, **write your features** and correct bugs **as you please**.
* During "Feature Freeze", you can still work on your features, but you are
**strongly encouraged to prioritize bug fixes**, especially if it involves your code.
**No pull request for new features will be accepted during feature freeze !**
* After the Release, it's back to the start for a new cycle.
# 6) The Issue Tracker : labels and milestones
## 6.1) Milestones
You can see Milestone as the GitHub way to say Release. Moose repository has
**three active [Milestone](https://github.com/FlightControl-Master/MOOSE/milestones) at any time**:
* The next milestone (e.g. Moose-2.0)
* The milestone after the next one (e.g. Moose-2.1)
* The "future" milestone (Moose-Future)
Every **bug is assigned to the next milestone**, and should be fixed before the release.
**Features are assigned to any milestone depending on the importance** of it and how hard it is to implement.
Typically, a feature that is currently worked on is assigned to the next milestone, an very long-term feature is
assigned to Moose-Future, and any other feature is assigned to the milestone after the next one, the goal being to have
a nice todo list for the contributor to pick and choose from at the end of feature freeze. If you come accross a issue
that isn't assigned to a milestone, feel free to add it to the correct one!
## 6.2) Labels
We heavily use **GitHub's label system** on the Issue Tracker to categorize each issue.
Each **issue is assigned the relevant label(s) at birth** by a contributor, and they are then updated to reflect the
current state of the issue. If you come accross an untagged issue, feel free label it ! You can consult the
[full list of labels available](https://github.com/FlightControl-Master/MOOSE/labels),
but **please asks the community before adding or removing a label** to the list.
* Bugs
* question : not even a bug report
* possible bug : might be a bug, but hasn't been reproduced yet
* bug : the bug has been confirmed / reproduced
* fixed : We think the bug is fixed. but there is a good reson why we are not closing the issue just yet.
Usually used in conjunction with ready for testing
* Feature requests
* enhancement : this issue is a feature request
* implemented : we implemented this enhancement, but there is a good reson why we are not closing the issue just yet.
Usually used in conjunction with ready for testing
* Documentation work
* documentation
* Urgency
* urgent (fix in a few days) : This is used primarly for bugs found in the latest Release.
* not urgent (can wait)
* Work load (this is merely to help contributer choose issues conpatible with the free time they have)
* hard work
* trivial
* Will not fix
* wontfix
* duplicate : this issue already exists somewhere else
* invalid

343
docs/archive/guide-debug.md Normal file
View File

@ -0,0 +1,343 @@
---
parent: Archive
nav_order: 6
---
# Interactive Debugging
The Lua Development Tools in the Eclipse suite has a possibility to "attach a lua debugger" to your LDT environment.
Read this section to setup a debugger in our DCS World environment.
The people who have used debuggers before, will recognize a lot in this explanation!
How it works:
* Setup a **debug listener** within LDT. When running, it will listen over IP on the local host (127.0.0.1) on a port.
* Attach a **debug client** to your DCS World configuration. This **debug client** will attach itself to the
**debug listener** over IP.
* Modify your mission, so that your source files are loaded **dynamically**. This is very important because DCS World
**renames** unfortunately the name of the source files when it runs a mission!
* Set breakpoints where needed. The debugger will stop at the breakpoints set.
* Run the **debug listener** on LDT.
* Run the DCS World mission, which uses the **debug client** to connect to the **debug listener** over IP.
* The logic will stop at the set breakpoints. Using LDT, you can walk through the logic (statements), while inspecting
variable contents and evaluate expressions.
* You can set breakpoints during the process where you want, you can add / delete variables in the views where you
want.
**This capability will give you a new experience in DCS World mission design!**
**Note:** The assets that are used in this description, were modified to accomodate the debugging, so the LDT
off-the-shelf assets aren't working. So use the assets as listed here, or your debugger won't work!
## 1. Explanation of the LDT debugging environment.
![](../images/archive/debugging/DEBUG_Intro.JPG)
The following pictures outline some of the interesting places in LDT to debug your lua code... A quick manual.
![](../images/archive/debugging/DEBUG_Bug.JPG)
This picture shows a debug view of the LDT environment. You can activate the debug view through the debug icon that is
located in the upper right corner of the LDT.
![](../images/archive/debugging/DEBUG_Tracking.JPG)
Various windows exist to track the content of:
* Variables: local and global variables will appear automatically in the Variables window where used.
* Breakpoints: Breakpoints that are set at lines of various sources, are listed here.
* Expressions: Various expressions can be entered to evaluate a more complex statement.
* Interactive Console: Here you can type in commands that will be executed. Here you can SPAWN for example new groups.
![](../images/archive/debugging/DEBUG_Source.JPG)
This window lists the sources active in Eclipse.
During a debug sessions, the sources where the process is at the moment of debugging, should be loaded automatically.
If not, something is wrong.
All the other sources that are currently open in the LDT are also listed.
![](../images/archive/debugging/DEBUG_Engine.JPG)
This window shows the status of the "attach debug engine".
If this process is running, it will listen to the IP 127.0.0.1 or localhost if setup on your PC.
## 2. Setup your **debug listener** in LDT.
To use the debug enviornment in LDT, you'll need to setup within LDT a " Lua Attach to Application" **debug listener**.
![](../images/archive/debugging/DEBUG_Engine.JPG)
You can access this screen through the LDT editor menu **Run->Debug Configurations...**.
This is the meaning of each field:
* Project: The name of the project that you are debugging within your workspace. You need to have a project registered
here!
* IDE key: this string is used connect the **debug client** to the **debug listener**.
* Timeout: the amount of miliseconds you want DCS World to wait for the **debug listener** to be connecting.
* Source mapping: Select the option "Local Resolution". All the sources are loaded locally from your PC automatically
when debugging.
For the IDE key, this key will be the "link" to the debug connection on the client side!
As will be explained a bit further, `initconnection( "127.0.0.1", 10000, "dcsserver", nil, "win", "" )` will make a
connection on the **debug client**.
Ensure that the IDE key specified matches up in the **debug listener** and the **debug client**.
So in this example, `"dcsserver"` is the IDE key and should match in the debug Configuration panel and the
`initconnection` parameters!
## 3. Setup your **debug client** and attach it to DCS World mission runtime.
This process is essential.
Within the MOOSE repository, there are two important files that you need to consider.
These files are located in the MOOSE repository
[here](https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Development/Debugger).
Download the MOOSE repository or the files on your disk, and read further ...
You should have at least on your disk:
* debugger.lua
* READ.ME
* MissionScripting.lua
### 3.1. debugger.lua.
This is the **debug client**. The source is part of the LDT debug suite, but has been modified to work together with the
DCS World scripting engine. You need to copy this file to the root directory of your DCS World installation in
Program Files.
![](../images/archive/debugging/DEBUG_Debugger.JPG)
By example, the location of debugger.lua is here on my DCS World installation PC.
### 3.2. Modify the MissionScripting.lua file.
The READ.ME file is a file that contains an explanation of how to modify the MissionScripting.lua.
But for clarity reasons, I've also attached my version of the MissionScripting.lua.
![](../images/archive/debugging/DEBUG_MissionScripting.JPG)
Take the MissionScripting.lua from the folder, and copy / paste (overwrite) the version in your DCS World installation
directory under the Scripts folder.
If you want, you can first rename the existing MissionScripting.lua file to MissionScripting_old.lua
Don't mistake yourself, a lot of mods/tools modify this file during installation.
Tools like **slmod** etc also change the MissionScripting.lua file (during installation).
So beware that when copying over the file there may be unwanted changes.
If you are using a mod, it is better to do the change manually according the direction in the READ.ME file!
And a validation needs to be done. Once you've modified/overwritten the MissionScripting.lua file, check if the contents
are indeed changed!
Sometimes it seems that the file is saved, but the contents aren't updated due to lack of administration rights and
extra security done by windows.
MissionScripting.lua should contain (at least) the following:
```lua
--Initialization script for the Mission lua Environment (SSE)
dofile('Scripts/ScriptingSystem.lua')
-- Add LuaSocket to the LUAPATH, so that it can be found.
package.path = package.path..";.\\LuaSocket\\?.lua;"
-- Connect to the debugger, first require it.
local initconnection = require("debugger")
-- Now make the connection..
-- "127.0.0.1" is the localhost.
-- 1000 is the timeout in ms on IP level.
-- "dcsserver" is the name of the server. Ensure the same name is used at the
-- Debug Configuration panel! nil (is for transport protocol, but not using this)
-- "win" don't touch. But is important to indicate that we are in a windows
-- environment to the debugger script.
initconnection( "127.0.0.1", 10000, "dcsserver", nil, "win", "" )
-- Sanitize Mission Scripting environment
-- This makes unavailable some unsecure functions.
-- Mission downloaded from server to client may contain potentialy harmful lua
-- code that may use these functions.
-- You can remove the code below and make availble these functions at your own risk.
local function sanitizeModule(name)
_G[name] = nil
package.loaded[name] = nil
end
do
sanitizeModule('os')
--sanitizeModule('io')
sanitizeModule('lfs')
require = nil
loadlib = nil
end
```
Please read through the comment lines for a detailed description what it does.
The io module has been de-sanitized because the debugger.lua needs to use the io module while debugging.
## 4. Setup your .miz file.
When you run a mission in single player in DCS World, a couple of things are happening.
1. The .miz (mission) file that was selected to run, is unzipped in a temp folder on your drive.
2. Each lua file that is included in a DO SCRIPT FILE, is **RENAMED** to a file structure like ~mis__nnnnn__.lua.
This is very bad. Because this prevents you from settings breakpoints at the source file and ensure that the
debugger recognizes the source during run and the location of the breakpoint!
So we need to do something special. The trick is **dynamic loading**.
And believe me, it is the only way to be able to debug your sources.
So this is a little task that you need to learn how to do, but once you understand it, it will become very easy to do.
Instead of executing a DO SCRIPT FILE, you need to add a couple of things in your .miz file.
### 4.1 Conditionalize the DO SCRIPT FILE execution.
Keep the DO SCRIPT FILE line in your mission. Why? Because if you would remove it, and you woudn't debug your code, your
mission file would be deleted. Instead, we are going to put a flag before this part of the execution. A debug flag.
For example, in my mission I put a debug flag 999. When 999 is ON, I would NOT execute the mission file...
Follow this process how to do that... As my recommendation...
![](../images/archive/debugging/DEBUG_Flag.JPG)
Setup a debug flag... If you wanna debug, set flag 999 to ON.
![](../images/archive/debugging/DEBUG_Static.JPG)
Conditionalize the DO SCRIPT FILE execution by evaluating if the 999 is OFF.
### 4.2 Add a dynamic loader to debug your mission script.
Now we are adding a little line.
We are now going to ADD a **dynamic loader** of your mission source.
![](../images/archive/debugging/DEBUG_Dynamic.JPG)
This loads the file dynamically. Instead of a DO SCRIPT FILE, we execute here a DO SCRIPT.
The DO SCRIPT contains a little piece of code that loads your source file from a location on your disk.
![](../images/archive/debugging/DEBUG_Loader.JPG)
This is how my piece of code looks like. I am using a stub of the MOOSE framework to load the file.
`MOOSE.Include( full_path_name, file_name )`
* The `full_path_name` needs to be between quotes, **follows unix folder notation** and **needs to end with a /**
* The `file name` is the full file name, **including the .lua extension**!
If you don't wanna use __Moose.Include, no worries, there is another method.
`_G.loadfile( full_path_name .. file_name )`
The MOOSE.Include loader uses _G.loadfile to load the sources. But it does a bit more checking and logs in dcs.log which
files were dynamically loaded, and from which location!
### 5. Run the **debug listener** on LDT.
Now we are all setup! You've got your **debug listener** setup in LDT, you got your **debug client** setup and connected
to your DCS World environment, and you got your mission file ready for debug!
Now we are going to run a debug. To have a successful debug run, you need to start the listener in LDT.
### 5.1. Setup your debug favorite.
First we setup the Debug as your "favorite", so that it is easy for your to repeat the run easily.
![](../images/archive/debugging/DEBUG_Favorites.JPG)
Click on the "Bug" icon that you'll find in the task bar. The "Bug" icon is the place where you will start your
**debug listener**. However, first, click on Organize Favorites. You need to do this one time only.
![](../images/archive/debugging/DEBUG_Add_Favorites.JPG)
Just click on the Debug Name that you entered (for me DCS 1.5) in the Debug Configuration window and it will be added to
your favorites. I did already that, so it was already added as an example in the previous picture.
### 5.2. Run the **debug listener**.
Now you can easily activate the **debug listener**.
![](../images/archive/debugging/DEBUG_Run_Listener.JPG)
Just click the "Bug" again, and select the **debug listener** that you configured.
![](../images/archive/debugging/DEBUG_Listener.JPG)
When done, you'll see that the **debug listener** is running!
It will be listening quietly to IP 127.0.0.1 on port 100000.
### 6. Set breakpoints.
Open your source file **from the exact location** from where you have specified it to be loaded as part of the
**dynamic loading**. Once it is loaded, you can attach breakpoints within the editor.
![](../images/archive/debugging/DEBUG_Breakpoint.JPG)
How? Right click on the source line number or the grey area before the line, and a pop-up window will appear. Select
"Toggle Breakpoint".
![](../images/archive/debugging/DEBUG_Breakpoint_List.JPG)
As a result, the breakpoint will be listed in the "Breakpoints" list at the debug view, and it will show also the line
number where the breakpoint is set. When your mission runs, the logic will stop at this line!!!
### 7. Run your DCS World mission.
Now it is time to start your DCS World mission. Just run it as you would like have it.
1. The **debug client** (debugger.lua) is loaded as part of the MissionScripting.lua file.
2. The **debug client** connects to the **debug listener** on ldt using 127.0.0.1 using port 10000.
3. Your **mission source** will be **loaded dynamically**.
4. Your mission will start running.
5. Debugger is active and will monitor if a breakpoint has been set at the source currently active during runtime of
your mission.
6. Once it matches a valid breakpoint at a valid source and a specified line, it will stop the logic!
![](../images/archive/debugging/DEBUG_Session.JPG)
### 8. Next steps.
There is a lot to say about debugging and the techniques that you can use how to track the code.
For this, videos will be made in the MOOSE For Dummies video series.
Please consult the youtube channel for more info on debugging.
### 9. Sequel.
When I started to use DCS World (discovered it by accident), I was sold.
After a while I started to discover the SSE capabilities of DCS World and started to code lua.
But a very important piece was missing while developing the MOOSE framework.
**A debugger**.
I've been searching for about 4 years to get this working. There was a huge learning curve.
I had to "hack" myself into the LDT environment and modify the LDT assets to make this work.
There were moments of "clarity" that made me understand how it all fits together.
And now it is there. Wanted to share this for all users of DCS World.
It does require a bit of effort to use this in the DCS World environment, but the little effort
is a small trade against the huge advantages here!
I also encourage you to use the MOOSE Framework, as it brings you a lot of great capabilities
you will never have in any editor. Being able to debug your code, will solve a lot of your questions now!
I hope you will all have fun with the new debug capability and that it may result in greater missions.

84
docs/archive/guide-designers.md Normal file
View File

@ -0,0 +1,84 @@
---
parent: Archive
nav_order: 2
has_children: true
---
# Mission Designers Guide
MOOSE contains a lot of classes that can be used to enhance your missions.
![MOOSE framework](../images/classes/overview.jpg)
Each section has an overview explanation on the different classes that mission designers can use to design compelling simulation scenarios.
It provides a short explanation of the concepts and its features, as well as important information to know in order to understand how to use the classes.
For more detailed information on the class, you will be guided to more detailed documentation on each individual class.
Click on one of the next section links below to open the guides for each of the major areas that are covered by MOOSE.
## 1. [AI Classes]
AI classes take control over the AI and makes the AI perform various processes.
Some very complicated and enhanced classes are implemented to take control of AI.
It uses the AI to create for you an enhanced simulation experience for your players.
**Apply the AI classes to create a truly dynamic defense and attack system driven by AI.**
## 2. [Tasking Classes]
Tasking classes provide a comprehensive Mission Orchestration System for human players.
Command Centers govern multiple missions to achieve a mission goal.
Within each mission, various tasks are defined, which can be assigned to human players.
Upon completion of each task, a mission goal can be achieved, which will result in score points.
**Join the forces and apply the tasking classes to create a truly dynamic co-operative combat scenario.**
## 3. [Cargo Classes]
Cargo classes provide enhanced means to handle cargo transportation.
Cargo requires a bit more explanation. MOOSE has implemented **a separate system for cargo handling**.
It combines the capabilities of DCS world to combine infantry groups, cargo static objects and static objects
as "cargo" objects.
It also provides you with **AI cargo transportation** classes,
and **Tasking classes for human players**, to transport cargo as part of a mission goal.
In order to use these MOOSE cargo facilities, you'll have to declare those groups and static objects
in a special way within your scripts and/or within the mission editor.
It is not a rocket science, but requires a bit of reading to trying to learn this new method.
Once you've learned this, a new world will open :-)
**Add the cargo capabilities, so that your mission scenarios are dynamically managing the combat resources.**
## 4. [Functional Classes]
MOOSE functional classes provide various functions that are useful in mission design.
These classes vary and enhance the functionality of your simulation scenario.
**Apply various functional classes, to enhance the functionality in your mission scenarios.**
## 5. [Wrapper Classes]
MOOSE wrapper classes provide an object oriented hierarchical mechanism to manage the DCS objects within the simulator.
Wrapper classes provide a greatly enhanced functionality to control groups, units, statics, scenery, airbases etc.
**Make life easy and use the wrapper classes to take control of individual DCS world objects.**
## 6. [Core Classes]
MOOSE core classes define the base building blocks of the MOOSE framework.
The core classes utilize the DCS world core capability and greatly enhance its functionality.
It also provides new mechanisms that provide you with new tools to create your simulation scenarios.
Some of these methods are schedulers, event handlers, menu refreshing, enhanced messaging, sound, flags etc.
**Learn and understand the different core classes, if you want to develop or enhance your mission scenarios.**
[AI Classes]: classes-ai.md
[Tasking Classes]: classes-tasking.md
[Cargo Classes]: classes-cargo.md
[Functional Classes]: classes-functional.md
[Wrapper Classes]: classes-wrapper.md
[Core Classes]: classes-core.md

76
docs/archive/guide-developers.md Normal file
View File

@ -0,0 +1,76 @@
---
parent: Archive
nav_order: 8
---
# Developers Guide
MOOSE contains a lot of classes that can be used to enhance your missions.
![MOOSE framework](../images/classes/overview.jpg)
Each section has an overview explanation on the different classes that mission designers can use to design compelling simulation scenarios.
It provides a short explanation of the concepts and its features, as well as important information to know in order to understand how to use the classes.
For more detailed information on the class, you will be guided to more detailed documentation on each individual class.
Click on one of the next section links below to open the guides for each of the major areas that are covered by MOOSE.
## 1. [MOOSE AI Classes](classes-ai.md)
AI classes take control over the AI and makes the AI perform various processes.
Some very complicated and enhanced classes are implemented to take control of AI.
It uses the AI to create for you an enhanced simulation experience for your players.
**Apply the AI classes to create a truly dynamic defense and attack system driven by AI.**
## 2. [MOOSE Tasking Classes](classes-tasking.md)
Tasking classes provide a comprehensive Mission Orchestration System for human players.
Command Centers govern multiple missions to achieve a mission goal.
Within each mission, various tasks are defined, which can be assigned to human players.
Upon completion of each task, a mission goal can be achieved, which will result in score points.
**Join the forces and apply the tasking classes to create a truly dynamic co-operative combat scenario.**
## 3. [MOOSE Cargo Classes](classes-cargo.md)
Cargo classes provide enhanced means to handle cargo transportation.
Cargo requires a bit more explanation. MOOSE has implemented **a separate system for cargo handling**.
It combines the capabilities of DCS world to combine infantry groups, cargo static objects and static objects
as "cargo" objects.
It also provides you with **AI cargo transportation** classes,
and **Tasking classes for human players**, to transport cargo as part of a mission goal.
In order to use these MOOSE cargo facilities, you'll have to declare those groups and static objects
in a special way within your scripts and/or within the mission editor.
It is not a rocket science, but requires a bit of reading to trying to learn this new method.
Once you've learned this, a new world will open :-)
**Add the cargo capabilities, so that your mission scenarios are dynamically managing the combat resources.**
## 4. [MOOSE Functional Classes](classes-functional.md)
MOOSE functional classes provide various functions that are useful in mission design.
These classes vary and enhance the functionality of your simulation scenario.
**Apply various functional classes, to enhance the functionality in your mission scenarios.**
## 5. [MOOSE Wrapper Classes](classes-wrapper.md)
MOOSE wrapper classes provide an object oriented hierarchical mechanism to manage the DCS objects within the simulator.
Wrapper classes provide a greatly enhanced functionality to control groups, units, statics, scenery, airbases etc.
**Make life easy and use the wrapper classes to take control of individual DCS world objects.**
## 6. [MOOSE Core Classes](classes-core.md)
MOOSE core classes define the base building blocks of the MOOSE framework.
The core classes utilize the DCS world core capability and greatly enhance its functionality.
It also provides new mechanisms that provide you with new tools to create your simulation scenarios.
Some of these methods are schedulers, event handlers, menu refreshing, enhanced messaging, sound, flags etc.
**Learn and understand the different core classes, if you want to develop or enhance your mission scenarios.**

339
docs/archive/guide-setup-ldt.md Normal file
View File

@ -0,0 +1,339 @@
---
parent: Archive
nav_order: 3
---
# LDT Setup Guide
Using the MOOSE framework is very easy, and this document provides you with a detailed explanation how to install
and use MOOSE within your missions.
## 1.1) MOOSE Framework on GITHUB
For reference, you can find the source code of [MOOSE framework on GitHub].
It is free for download and usage, since it is released under the GNU 3.0 open source license policy.
You don't need to use the source code as an end-user, but it may help to sneak into the code and understand how certain
things are working.
## 1.2) Write your scripts using MOOSE in a normal text editor
You can use the MOOSE framework with a normal text editor. This is perfectly okay.
But you won't have IntelliSense enabled, which is an interactive documentation system that helps you to code correctly!
Therefore, it is highly recommended you use the Eclipse LDT editor, which is explained below.
## 1.2) Eclipse LDT
The LDT environment or "Eclipse Lua Development Tools" is a fully integrated development environment for LUA developers.
It is recommended to use the LDT as your mission design editor using MOOSE.
The MOOSE framework is documented using the lua documentation standard within the MOOSE code.
As a result, every class, method and variable is documented within the source code
and mission designers can write mission script lua code that is **intellisense**(-ed).
What that means is that while you are coding your mission, your object and variables (derived from MOOSE classes)
will list interactively the methods and properties of that class interactively while coding.
![Intellisense](../images/archive/installation/intellisense.jpg)
This highly increases the quality and the speed of your scripting.
## 1.3) LUA training
In order to efficiently use the MOOSE framework, it is highly recommended that you learn a couple of basic principles of
lua. I recommend you learn the basic lua principles following this [lua tutorial](https://www.tutorialspoint.com/lua).
We're not asking you to become an expert in lua, but you'll need to have some basic lua coding knowledge to "understand"
the code, and also, to understand the syntax.
**Therefore, I suggest you walk through this [lua quick guide](https://www.tutorialspoint.com/lua/lua_quick_guide.htm)**.
Ignore the lua environment setup. DCS comes with a pre-defined lua environment.
# 2) Download the latest release of MOOSE
The delivery of MOOSE follows a structured release process.
Over time, new features are added that can be used in your mission.
MOOSE can be downloaded on the main release gage on [GitHub](https://github.com/FlightControl-Master/MOOSE/releases).
**Unzip the files into a directory of your choice, but keep the folder structure intact**.
Also, you'll notice that there are two files included:
- Moose.lua
- Moose_.lua
These are include files that you need to include within your mission.
These files contain ALL the MOOSE code in one file.
See a more detailed explanation below.
# 3) Download the software
## 3.1) Download and install the Eclipse Lua Development Tools **(LDT)**, which is an advanced lua editor.
1. If you don't have JAVA yet, you may have to install [java](https://www.java.com/en/download) first.
2. Download and Install [Eclipse LDT](https://eclipse.org/ldt) on your Windows 64 bit system.
Now you should have a working LDT on your system.
Don't skip this step, LDT is a game-changer.
# 4) Setup the **Moose_Framework project** in LDT.
You need to configure your Eclipse LDT environment and link it with the Moose code.
This will enable you to **start developing mission scripts** in lua, which will be **fully intellisense enabled**!
Please follow the steps outlined!
## 4.1) Create a new **Workspace** in LDT.
The LDT editor has a concept of **Workspaces**, which contains all your settings of your editing environment,
like views, menu options etc and your code. Nothing to pay attention to really, but you need to set it up!
When you open EclipseLDT for the first time, it will ask you where to put your *workspace area*.
1. Open Eclipse LDT.
2. Select the default workspace that LDT suggests.
## 4.2) Setup a **new project** in LDT and name it **Moose_Framework**.
### 4.2.1) Select from the Menu: **File** -> **New** -> **Lua Project**.
![LDT_New_Project](../images/archive/installation/LDT_New_Project.JPG)
Here, we will create a **New Project** called **Moose_Framework** in your LDT environment.
### Important! Name your project **Moose_Framework**
The project details are already defined within the MOOSE framework repository,
which is unzipped in your **local Moose folder** on your PC.
We will link into that directory and **automatically load the Project properties**.
### 4.2.2) Type the Project Name: **Moose_Framework**.
![LDT_Project](../images/archive/installation/LDT_Project.JPG)
### 4.2.3) In the sub-box "Project Contents", select the option **Create Project at existing location** (from existing source).
![LDT_Project](../images/archive/installation/LDT_Project_Existing_Location.JPG)
### 4.2.4) **Browse** to the local MOOSE directory (press on the Browse button) and select the **local Moose folder on your PC, which you unzipped**. Press OK.
### 4.2.5) You're back at the "New Project" dialog box. Press the **Next** button below the dialog box.
__(All the other settings are by default ok)__.
### 4.2.6) You should see now a dialog box with the following properties.
The Moose Development/Moose directory should be flagged as the **Source Directory*. (It is listed totally on top.)
This is important because it will search in the files in this directory and sub directories for lua documentator enabled lua files.
This will enable the intellisense of the MOOSE repository!
![LDT Finish](../images/archive/installation/LDT_Moose_Framework_Finish.JPG)
### 4.2.7) Press the **Finish** button.
As a result, when you browse to the Script Explorer, you'll see the following:
![LDT_Script_Explorer](../images/archive/installation/LDT_Script_Explorer.JPG)
### 4.2.8) **Congratulations! You have now setup your Moose_Framework project LDT environment!**
# 5) Setup a new project **Moose_Missions** in LDT, containing the the Moose demonstration missions.
The framework comes with demonstration missions which can be downloaded
[here](https://github.com/FlightControl-Master/MOOSE_MISSIONS), 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.
The .lua file contains the mission script file that shows how the use case was implemented.
You can copy/paste the code snippets from this .lua file into your missions
This will accellerate your mission developments. You will see, learn and understand how the different MOOSE classes
needs to be applied and how you can create more complex mission scenarios by combining these MOOSE classes into a
complex but powerful mission engine.
Some of these exact test missions are also demonstrated in a video format on the
[YouTube channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg).
- Download the [Moose demonstration missions](https://github.com/FlightControl-Master/MOOSE_MISSIONS/) latest release package.
- Unzip the package into a local folder on your PC.
- In LDT, select from the menu **New lua project**, and name it Moose_Missions.
- Select the local folder on your PC, where you saved the demonstration missions contents.
- Press Finish
# 6) Setup Your first mission
## 6.1) Setup a new project in LDT and name it **My_Missions**
In order to design your own missions, it is recommended you create a separate directory on your PC
which contains your mission files. Your mission will be designed consisting possibly
out of a couple of components, which are:
* (Mandatory) An include of the **Moose.lua** file (see chapter 2 above).
* (Mandatory) An include of your lua mission script file(s) (also with a .lua extension).
* (Optionally) Sound files (.ogg) and pictures (.jpg) which are added into your mission.
Using the menu system of the DCS World Mission Editor, you need to include files in your mission (.miz) file.
However, once included, maintaining these files is a tedious task,
having to replace each time manually these files when they change
(due to a new release or a change in your mission script).
Therefore, **the recommendation is that your create for each mission a separate folder**.
The MOOSE test mission folder structure is a good example how this could be organized.
The LDT has been customized and provides a tool to **automatically** maintain your existing .miz files.
### 6.1.1. Select from the Menu: **File** -> **New** -> **Lua Project**.
![LDT_New_Project](../images/archive/installation/LDT_New_Project.JPG)
### 6.1.2. A **New Project** dialog box is shown.
![LDT_Project](../images/archive/installation/LDT_Project.JPG)
### 6.1.3. Type your Project Name: (In my example it is **DCS_Caucasus_Missions**.
Note the indicated options in yellow:
* Note that you can select the option **No execution environment**.
* Deselect the option **Create default project template ready to run**.
![LDT_Project](../images/archive/installation/LDT_Project_My_Missions.JPG)
### 6.1.4. Press **Next >**
### 6.1.5. Click the **Projects** tab at the top of the window.
![LDT_Project](../images/archive/installation/LDT_New_Project_Projects.JPG)
### 6.1.6. Press the **Add...** button.
### 6.1.7. A new windows will be displayed: **Required Project Selection**.
This is an important step. This will _link_ your project to the Moose_Framework project and will activate **intellisense**.
![LDT_Project](../images/archive/installation/LDT_Select_Moose_Framework.JPG)
### 6.1.8. After the selection, press the **OK** button.
### 6.1.9. Watch your newly created project in the Script Explorer of LDT.
You can delete the possibly created SRC directory. You won't need it at all.
![LDT_Project](../images/archive/installation/LDT_Delete_Src.JPG)
### 6.1.10. Within your newly created Missions Project, right click and select **New -> Folder**.
As explained above, each of your missions will be stored in a separate folder. Please follow the explanation how to do that.
![LDT_Project](../images/archive/installation/LDT_Add_Folder.JPG)
### 6.1.11. Type the **Folder Name**.
This can be any descriptive text explaining the title of your mission.
![LDT_Project](../images/archive/installation/LDT_Mission_Folder_Name.JPG)
### 6.1.12. In your newly created **Mission Folder**, right click and select **New -> Lua File**.
This will create your **mission script file**,
the file that contains all the lua code using the Moose framework using your mission.
### 6.1.13. Type the **Lua Mission Script Name**.
![LDT_Project](../images/archive/installation/LDT_Mission_Lua_File_Name.JPG)
## 6.2) Create your first Mission file
In the root of the MOOSE package, a file named **Moose.lua** can be found.
In order to create or design a mission using the MOOSE framework,
you'll have to include this **Moose.lua** file into your missions:
1. Create a new mission in the DCS World Mission Editor.
2. In the mission editor, create a new trigger.
3. Name the trigger Moose Load and let it execute only at MISSION START.
4. Add an action DO SCRIPT FILE (without a condition, so the middle column must be empty).
5. In the action, browse to the **Moose.lua** file and include this file within your mission.
6. Make sure that the "Moose Load" trigger is completely at the top of your mission.
Voila, MOOSE is now included in your mission. During the execution of this mission, all MOOSE classes will be loaded
and all MOOSE initializations will be exectuted before any other mission action is executed.
Find below a detailed explanation of the actions to follow:
### 6.2.1. Open the Mission Editor in DCS, select an empty mission, and click the triggers button.
![LDT_Project](../images/archive/installation/DCS_Triggers_Empty.JPG)
### 6.2.2. Add a new trigger, that will load the Moose.lua file.
Check the cyan colored circles:
* This trigger is loaded at MISSION START.
* It is the first trigger in your mission.
* It contains a DO SCRIPT FILE action.
* No additional conditions!
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Moose_Add.JPG)
### 6.2.3. Select the Moose.lua loader from the **Moose Mission Setup** folder in the Moose_Framework pack.
Additional notes:
* If you've setup a folder link into Saved Games/DCS/Missions/Moose Mission Setup, then you can directly select this
folder from **My Missions**.
* See point ...
Press the **OK** button.
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Moose_Select_File.JPG)
### 6.2.4. Check that the Moose.lua file has been correctly added to your Mission.
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Moose_File_Added.JPG)
### 6.2.5. Add a new trigger, that will load your mission .lua file.
Check the cyan colored circles:
* This trigger is loaded at MISSION START.
* It is the second trigger in your mission.
* It contains a DO SCRIPT FILE action.
* No additional conditions!
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Mission_Add.JPG)
### 6.2.6. Select the mission .lua file from your **missions** folder you just created or already have.
Additional notes:
* If you've setup a folder link into Saved Games/DCS/Missions/Moose Mission Setup, then you can directly select this folder from **My Missions**.
* See point ...
Press the **OK** button.
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Mission_File_Select.JPG)
### 6.2.7. Check that your mission .lua script file has been correctly added to your mission.
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Mission_File_Added.JPG)
## 6.3) Maintain your .miz files
IMPORTANT NOTE: When a new version of MOOSE is released, you'll have to UPDATE the Moose.lua file in EACH OF YOUR MISSION.
This can be a tedious task, and for this purpose, a tool has been developed that will update the Moose.lua files automatically within your missions.
### 6.3.1. Select the **Update SELECTED Mission** from the External Tools in LDT.
This will activate a script that will automatically re-insert your mission .lua file into your mission.
![LDT_Project](../images/archive/installation/DCS_Triggers_Load_Mission_File_Added.JPG)
## 6.4) Create folder links into your "My Missions" folder in Saved Games/DCS/Missions.
***TODO : Detail how hard links work, explain how they help the wworkflow***
This trick will save you a lot of time. You need to install the tool ... to create easily new links.
Select from the following possible links that can be created to save you time while browing through the different folders to include script files:
### 6.4.1. Create a link to your **Moose Mission Setup** folder ...
### 6.4.2. Create a link to your **missions** folder ...
[MOOSE framework on GITHUB]: https://www.github.com/FlightControl-Master/MOOSE/

78
docs/archive/guide-starters.md Normal file
View File

@ -0,0 +1,78 @@
---
parent: Archive
nav_order: 1
---
# Starters Guide
## 1. MOOSE is an Object Oriented system.
MOOSE is an Object Oriented framework which provides different **classes** that take control of your simulation scenario.
### 1.1. Classes ...
* **AI** - Take control of the AI controlled groups and units to execute specific tasks and processes.
* **Tasking** - Assign tasks to human players, and let them achieve goals for logical missions setup in your simulation scenario.
* **Functional** - Apply additional functionalities on top of the standard DCS simulation capabilities.
* **Cargo** - Declare cargo objects, which are handled by moose in various ways.
* **Wrapper** - The default dcs classes are wrapped by moose wrapper classes, and provide additional funtionality and easier access.
* **Core** - The default dcs simulation capabilities are enhanced by moose, and provide additional functionality and easier access.
You as a mission designer are required to study each class features, and evaluate whether you want to apply
those features as part of your mission scenario.
### 1.2. Objects ...
If you want to apply a class, you need to **instantiate** the class by creating an **object** of that class.
Look at a **class** like the **definition of a process**, and the **object** **applies the process**.
Multiple objects can be created of the same class, and this is the power of an Object Oriented system.
These objects combine the combine **Methods** and **Variables**/**Properties** of the class as one encapsulated structure, that
hold state and work independently from each other!
Look at the following example:
Here we use the SPAWN class, which you can use to spawn new groups into your running simulation scenario.
The SPAWN class simplifies the process of spawning, and it has many methods to spawn new groups.
```lua
-- This creates a new SpawnObject from the SPAWN class,
-- using the constructor :New() to instantiate a new SPAWN object.
-- It will search for the GroupName as the late activated group defined within your Mission Editor.
-- If found, the object "SpawnObject" will now contain a "copy" of the SPAWN class to apply the spawning process.
local SpawnObject = SPAWN:New( "GroupName" )
-- Nothing is spawned yet..., so let's use now the SpawnObject to spawn a new GROUP.
-- We use the method :Spawn() to do that.
-- This method creates a new group from the GroupName template as defined within the Mission Editor.
local SpawnGroup = SpawnObject:Spawn()
```
### 1.3. Inheritance ...
MOOSE classes **derive or inherit** from each other, that means,
within MOOSE there is an **inheritance** structure.
The different moose classes are re-using properties and methods from its **parent classes**.
This powerful concept is used everywhere within the MOOSE framework.
The main (Parent) Class in the MOOSE framework is the BASE class.
Every MOOSE Class is derived from this top BASE Class.
So is also the SPAWN class derived from the BASE class.
The BASE class provides powerful methods for debugging,
event handling and implements the class handling logic.
As a normal MOOSE user, you won't implement any code using inheritance,
but just know that the inheritance structure is omni present in the intellisense and documentation.
You'll need to browse to the right MOOSE Class within the inheritance tree structure,
to identify which methods are properties are defined for which class.
## 2. MOOSE Demonstration Missions
The framework comes with demonstration missions which can be downloaded [here](https://github.com/FlightControl-Master/MOOSE_MISSIONS/), 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.
The .lua file contains the mission script file that shows how the use case was implemented.
You can copy/paste code the code snippets from this .lua file into your missions, as it will accellerate your mission developments.
You will learn, see, and understand how the different MOOSE classes need to be applied, and how you can create
more complex mission scenarios by combining these MOOSE classes into a complex but powerful mission engine.
Some of these exact test missions are also demonstrated in a video format on the [YouTube channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg).

159
docs/archive/guide-usage.md Normal file
View File

@ -0,0 +1,159 @@
---
parent: Archive
nav_order: 9
---
# Usage Guide
## 1. MOOSE is an Object Oriented system.
MOOSE is an Object Oriented framework which provides different **classes** that take control of your simulation scenario.
### 1.1. Classes ...
* **AI** - Take control of the AI controlled groups and units to execute specific tasks and processes.
* **Tasking** - Assign tasks to human players, and let them achieve goals for logical missions setup in your
simulation scenario.
* **Functional** - Apply additional functionalities on top of the standard DCS simulation capabilities.
* **Cargo** - Declare cargo objects, which are handled by moose in various ways.
* **Wrapper** - The default dcs classes are wrapped by moose wrapper classes, and provide additional funtionality and
easier access.
* **Core** - The default dcs simulation capabilities are enhanced by moose, and provide additional functionality and
easier access.
You as a mission designer are required to study each class features, and evaluate whether you want to apply
those features as part of your mission scenario.
### 1.2. Objects ...
If you want to apply a class, you need to **instantiate** the class by creating an **object** of that class.
Look at a **class** like the **definition of a process**, and the **object** **applies the process**.
Multiple objects can be created of the same class, and this is the power of an Object Oriented system.
These objects combine the combine **Methods** and **Variables**/**Properties** of the class as one encapsulated
structure, that hold state and work independently from each other!
Look at the following example:
Here we use the SPAWN class, which you can use to spawn new groups into your running simulation scenario.
The SPAWN class simplifies the process of spawning, and it has many methods to spawn new groups.
```lua
-- This creates a new SpawnObject from the SPAWN class,
-- using the constructor :New() to instantiate a new SPAWN object.
-- It will search for the GroupName as the late activated group defined within your Mission Editor.
-- If found, the object "SpawnObject" will now contain a "copy" of the SPAWN class to apply the spawning process.
local SpawnObject = SPAWN:New( "GroupName" )
-- Nothing is spawned yet..., so let's use now the SpawnObject to spawn a new GROUP.
-- We use the method :Spawn() to do that.
-- This method creates a new group from the GroupName template as defined within the Mission Editor.
local SpawnGroup = SpawnObject:Spawn()
```
### 1.3. Inheritance ...
MOOSE classes **derive or inherit** from each other, that means,
within MOOSE there is an **inheritance** structure.
The different moose classes are re-using properties and methods from its **parent classes**.
This powerful concept is used everywhere within the MOOSE framework.
The main (Parent) Class in the MOOSE framework is the BASE class.
Every MOOSE Class is derived from this top BASE Class.
So is also the SPAWN class derived from the BASE class.
The BASE class provides powerful methods for debugging,
event handling and implements the class handling logic.
As a normal MOOSE user, you won't implement any code using inheritance,
but just know that the inheritance structure is omni present in the intellisense and documentation.
You'll need to browse to the right MOOSE Class within the inheritance tree structure,
to identify which methods are properties are defined for which class.
## 2. MOOSE Framework Classes
MOOSE contains a lot of classes that can be used to enhance your missions.
![MOOSE framework](../images/classes/overview.jpg)
Each section has an overview explanation on the different classes that mission designers can use to design compelling
simulation scenarios. It provides a short explanation of the concepts and its features, as well as important information
to know in order to understand how to use the classes.
For more detailed information on the class, you will be guided to more detailed documentation on each individual class.
Click on one of the next section links below to open the guides for each of the major areas that are covered by MOOSE.
### 2.1. [MOOSE AI Classes](classes-ai.md)
AI classes take control over the AI and makes the AI perform various processes.
Some very complicated and enhanced classes are implemented to take control of AI.
It uses the AI to create for you an enhanced simulation experience for your players.
**Apply the AI classes to create a truly dynamic defense and attack system driven by AI.**
### 2.2. [MOOSE Tasking Classes](classes-tasking.md)
Tasking classes provide a comprehensive Mission Orchestration System for human players.
Command Centers govern multiple missions to achieve a mission goal.
Within each mission, various tasks are defined, which can be assigned to human players.
Upon completion of each task, a mission goal can be achieved, which will result in score points.
**Join the forces and apply the tasking classes to create a truly dynamic co-operative combat scenario.**
### 2.3. [MOOSE Cargo Classes](classes-cargo.md)
Cargo classes provide enhanced means to handle cargo transportation.
Cargo requires a bit more explanation. MOOSE has implemented **a separate system for cargo handling**.
It combines the capabilities of DCS world to combine infantry groups, cargo static objects and static objects
as "cargo" objects.
It also provides you with **AI cargo transportation** classes,
and **Tasking classes for human players**, to transport cargo as part of a mission goal.
In order to use these MOOSE cargo facilities, you'll have to declare those groups and static objects
in a special way within your scripts and/or within the mission editor.
It is not a rocket science, but requires a bit of reading to trying to learn this new method.
Once you've learned this, a new world will open :-)
**Add the cargo capabilities, so that your mission scenarios are dynamically managing the combat resources.**
### 2.4. [MOOSE Functional Classes](classes-functional.md)
MOOSE functional classes provide various functions that are useful in mission design.
These classes vary and enhance the functionality of your simulation scenario.
**Apply various functional classes, to enhance the functionality in your mission scenarios.**
### 2.5. [MOOSE Wrapper Classes](classes-wrapper.md)
MOOSE wrapper classes provide an object oriented hierarchical mechanism to manage the DCS objects within the simulator.
Wrapper classes provide a greatly enhanced functionality to control groups, units, statics, scenery, airbases etc.
**Make life easy and use the wrapper classes to take control of individual DCS world objects.**
### 2.6. [MOOSE Core Classes](classes-core.md)
MOOSE core classes define the base building blocks of the MOOSE framework.
The core classes utilize the DCS world core capability and greatly enhance its functionality.
It also provides new mechanisms that provide you with new tools to create your simulation scenarios.
Some of these methods are schedulers, event handlers, menu refreshing, enhanced messaging, sound, flags etc.
**Learn and understand the different core classes, if you want to develop or enhance your mission scenarios.**
## 3. 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.
The .lua file contains the mission script file that shows how the use case was implemented.
You can copy/paste code the code snippets from this .lua file into your missions, as it will accellerate your mission
developments.
You will learn, see, and understand how the different MOOSE classes need to be applied, and how you can create
more complex mission scenarios by combining these MOOSE classes into a complex but powerful mission engine.
Some of these exact test missions are also demonstrated in a video format on the
[YouTube channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg).

124
docs/archive/index.md Normal file
View File

@ -0,0 +1,124 @@
---
title: Archive
has_children: true
nav_order: 4
has_toc: false
---
# Archive
{: .important }
> This documentation is outdated! We are working on new a documentation.
Here you can find the guides written by FlightControl in the past.
Most of the informations are still valid. But we want to create a more up-to-date
documentation in the future.
The first step to do this, is to consolidate the differents versions of the
documentation from [MOOSE_DOCS] and [MOOSE_DOCS_DEVELOP] into this place.
After that we can create a new documentation step by step.
[MOOSE_DOCS]: https://github.com/FlightControl-Master/MOOSE_DOCS
[MOOSE_DOCS_DEVELOP]: https://github.com/FlightControl-Master/MOOSE_DOCS_DEVELOP
## Starters guide
You need to write lua code (scripts) to apply the MOOSE framework. But it is not really that hard, if you understand
a couple of principles.
## Mission Designers Guide
This section is meant for those who really want to start using MOOSE and write lua scripts for their missions.
The section provides a comprehensive overview of the different classes that form the complete MOOSE framework.
Here you find a high-level explanation and features, how to:
* Setup AI dispatchers to create complex and coordinated AI behaviour.
* Cargo handling
* Setup task dispatchers for Mission completion
* How to use MOOSE wrapper classes
* The different components of the core MOOSE engine
Each class will link you further down into the MOOSE Classes guide, for more detailed information on each MOOSE class.
## MOOSE Classes Guide
Here you can find detailed documentation for each MOOSE class.
Click on the hamburger menu on the left upper corner of each page to navigate to other MOOSE classes.
- `master` branch: <https://flightcontrol-master.github.io/MOOSE_DOCS/>
- `develop` branch: <https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/>
## MOOSE Setup
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:
### Setup for Mission Designers
This section shows how to setup a development environment for Mission Designers using the MOOSE framework.
- Download and install Java.
- Setup Lua Development Tools IDE (from the Eclipse suite).
- Setup a logging tool.
- Tweak your DCS environment.
Please read the detailed [LDT Setup Guide](guide-setup-ldt.md) for more information.
### Setup for Beta tester guide
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 tester guide](guide-beta-tester.md) for more information.
### 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](guide-contribution.md) for more information.
### Debug your code interactively using LDT
Have a look at the [Interactive Debugging](guide-debug.html) to setup your system so you can debug your mission code.
## MOOSE Support Channels
MOOSE is broadcasted, documented and supported through various social media channels.
Click here for the [communities guide](guide-communities.md) of the MOOSE framework.
## MOOSE framework goal
The goal of MOOSE is to allow mission designers to **enhance the mission designs** by using **mission orchestration objects**,
which can be _instantiated_ from defined classes within the framework.
This will allow to write exciting missions and multi player cooperative operation scenarios.
Of course, the richness of the framework will determine the richness of the misson scenarios.
The MOOSE is a service that is produced while being consumed ... ,
it will evolve further as more classes are developed for the framework, and as more users are using it.
MOOSE is NOT meant to be a one-man show, it is meant to evolve within a growing community around the framework.
Within the community, key users will support, document, explain and even create new classes for the framework.
It is the ambition to grow this framework as a de-facto standard for mission designers to use within the DCS World community.
## MOOSE community on Discord
Join our MOOSE community on Discord.
A place where mission designers and developers come together to discuss the latest features.
There are a lot of people supporting Mission Designers on [Discord](https://discord.gg/yBPfxC6).
Thank you!
The Moose Team

1
docs/docker-compose.yml
View File

@ -4,6 +4,7 @@ services:
jekyll:
build:
context: ./
image: moose/docs
ports:
- 4000:4000
volumes:

BIN
docs/images/archive/debugging/DEBUG_Add_Favorites.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
docs/images/archive/debugging/DEBUG_Breakpoint.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
docs/images/archive/debugging/DEBUG_Breakpoint_List.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
docs/images/archive/debugging/DEBUG_Bug.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

BIN
docs/images/archive/debugging/DEBUG_Debugger.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/images/archive/debugging/DEBUG_Dynamic.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/images/archive/debugging/DEBUG_Engine.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
docs/images/archive/debugging/DEBUG_Favorites.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/images/archive/debugging/DEBUG_Flag.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/images/archive/debugging/DEBUG_Intro.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

BIN
docs/images/archive/debugging/DEBUG_LDT_Setup.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 109 KiB

BIN
docs/images/archive/debugging/DEBUG_Listener.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
docs/images/archive/debugging/DEBUG_Loader.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
docs/images/archive/debugging/DEBUG_MissionScripting.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 58 KiB

BIN
docs/images/archive/debugging/DEBUG_Run_Listener.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
docs/images/archive/debugging/DEBUG_Session.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
docs/images/archive/debugging/DEBUG_Source.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs/images/archive/debugging/DEBUG_Static.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
docs/images/archive/debugging/DEBUG_Tracking.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Empty.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Mission_Add.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 115 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Mission_File_Added.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 111 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Mission_File_Select.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 120 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Moose_Add.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 114 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Moose_File_Added.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 108 KiB

BIN
docs/images/archive/installation/DCS_Triggers_Load_Moose_Select_File.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 132 KiB

BIN
docs/images/archive/installation/GitHub_Clone.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs/images/archive/installation/GitHub_Issue_example.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 151 KiB

BIN
docs/images/archive/installation/LDT_Add_Folder.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 100 KiB

BIN
docs/images/archive/installation/LDT_Delete_Src.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
docs/images/archive/installation/LDT_Mission_Folder_Name.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs/images/archive/installation/LDT_Mission_Lua_File_Name.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/images/archive/installation/LDT_Moose_Framework_Finish.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
docs/images/archive/installation/LDT_New_Project.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
docs/images/archive/installation/LDT_New_Project_Projects.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/images/archive/installation/LDT_Project.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
docs/images/archive/installation/LDT_Project_Existing_Location.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
docs/images/archive/installation/LDT_Project_My_Missions.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
docs/images/archive/installation/LDT_Script_Explorer.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/images/archive/installation/LDT_Select_Moose_Framework.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
docs/images/archive/installation/MOOSE_Release_Cycle.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 103 KiB

BIN
docs/images/archive/installation/intellisense.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

BIN
docs/images/classes/ai/a2a-dispatcher.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 308 KiB

BIN
docs/images/classes/ai/a2g-cas.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 172 KiB

BIN
docs/images/classes/ai/bai.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 206 KiB

BIN
docs/images/classes/ai/balancer.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 253 KiB

BIN
docs/images/classes/ai/cap.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 221 KiB

BIN
docs/images/classes/ai/cargo-dispatcher-airplanes.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 146 KiB

BIN
docs/images/classes/ai/cargo-dispatcher-apc.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 293 KiB

BIN
docs/images/classes/ai/cargo-dispatcher-helicopters.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 422 KiB

BIN
docs/images/classes/ai/cargo-dispatcher.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 248 KiB

BIN
docs/images/classes/ai/formation.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 205 KiB

BIN
docs/images/classes/ai/patrol.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 211 KiB

BIN
docs/images/classes/cargo/cargocrate.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 274 KiB

BIN
docs/images/classes/cargo/cargogroup.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 228 KiB

BIN
docs/images/classes/cargo/cargoslingload.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 217 KiB

BIN
docs/images/classes/category-cargo.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 305 KiB

BIN
docs/images/classes/category-core.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 304 KiB

BIN
docs/images/classes/category-functional.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 306 KiB

BIN
docs/images/classes/category-tasking.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 304 KiB

BIN
docs/images/classes/category-wrapper.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 308 KiB

BIN
docs/images/classes/core/base.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 272 KiB

BIN
docs/images/classes/core/database.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 203 KiB

BIN
docs/images/classes/core/event.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 351 KiB

BIN
docs/images/classes/core/fsm.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 228 KiB

BIN
docs/images/classes/core/goal.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 213 KiB

BIN
docs/images/classes/core/menu.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 215 KiB

BIN
docs/images/classes/core/message.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 256 KiB

BIN
docs/images/classes/core/point.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 222 KiB

BIN
docs/images/classes/core/report.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 195 KiB

BIN
docs/images/classes/core/scheduler.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 256 KiB

BIN
docs/images/classes/core/sets.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 254 KiB

BIN
docs/images/classes/core/settings.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 285 KiB

BIN
docs/images/classes/core/spawn.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 346 KiB

BIN
docs/images/classes/core/spawnstatic.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 218 KiB

BIN
docs/images/classes/core/spot.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 199 KiB

BIN
docs/images/classes/core/userflag.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 245 KiB

BIN
docs/images/classes/core/velocity.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 217 KiB

BIN
docs/images/classes/core/zones.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 442 KiB

BIN
docs/images/classes/functional/artillery.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 169 KiB

BIN
docs/images/classes/functional/atc-ground.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 215 KiB

Some files were not shown because too many files have changed in this diff Show More