Revision of core classes documentation.

Moose Development/Moose/Core/Base.lua

@@ -1,4 +1,22 @@
---- **Core** -- BASE forms **the basis of the MOOSE framework**. Each class within the MOOSE framework derives from BASE.
+--- **Core** - The base class within the framework.
+-- 
+-- ===
+-- 
+-- ## 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.
+-- 
+-- ===
+-- 
+-- All classes within the MOOSE framework are derived from the BASE class.
+-- Note: The BASE class is an abstract class and is not meant to be used directly.
+-- 
+-- ===
 -- 
 -- ### Author: **FlightControl**
 -- ### Contributions: 
@@ -23,24 +41,14 @@ local _ClassID = 0
 -- @field ClassID The ID number of the class.
 -- @field ClassNameAndID The name of the class concatenated with the ID number of the class.
 
---- All classes within the MOOSE framework are derived from the BASE class. 
+--- BASE class
 --
--- BASE provides facilities for :
--- 
---   * 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.
--- 
--- Note: The BASE class is an abstract class and is not meant to be used directly.
--- 
--- ## 1.1) BASE constructor
+-- # 1. BASE constructor.
 -- 
 -- Any class derived from BASE, will use the @{Core.Base#BASE.New} constructor embedded in the @{Core.Base#BASE.Inherit} method. 
 -- See an example at the @{Core.Base#BASE.New} method how this is done.
 -- 
--- ## 1.2) Trace information for debugging
+-- # 2. Trace information for debugging.
 -- 
 -- The BASE class contains trace methods to trace progress within a mission execution of a certain object.
 -- These trace methods are inherited by each MOOSE class interiting BASE, soeach object created from derived class from BASE can use the tracing methods to trace its execution.
@@ -71,7 +79,7 @@ local _ClassID = 0
 -- 
 -- Below a more detailed explanation of the different method types for tracing.
 -- 
--- ### 1.2.1) Tracing methods categories
+-- ## 2.1. Tracing methods categories.
 --
 -- There are basically 3 types of tracing methods available:
 -- 
@@ -79,7 +87,7 @@ local _ClassID = 0
 --   * @{#BASE.T}: Used to trace further logic within a function giving optional variables or parameters. A T is indicated at column 44 in the DCS.log file.
 --   * @{#BASE.E}: Used to always trace information giving optional variables or parameters. An E is indicated at column 44 in the DCS.log file.
 -- 
--- ### 1.2.2) Tracing levels
+-- ## 2.2 Tracing levels.
 --
 -- There are 3 tracing levels within MOOSE.    
 -- These tracing levels were defined to avoid bulks of tracing to be generated by lots of objects.
@@ -91,7 +99,7 @@ local _ClassID = 0
 --   * @{#BASE.T2}: Trace further logic within a function giving optional variables or parameters with tracing level 2.
 --   * @{#BASE.T3}: Trace further logic within a function giving optional variables or parameters with tracing level 3.
 -- 
--- ### 1.2.3) Trace activation.
+-- ## 2.3. Trace activation.
 -- 
 -- Tracing can be activated in several ways:
 -- 
@@ -101,16 +109,17 @@ local _ClassID = 0
 --   * Activate only the tracing of a certain method of a certain class through the @{#BASE.TraceClassMethod}() method.
 --   * Activate only the tracing of a certain level through the @{#BASE.TraceLevel}() method.
 -- 
--- ### 1.2.4) Check if tracing is on.
+-- ## 2.4. Check if tracing is on.
 -- 
 -- The method @{#BASE.IsTrace}() will validate if tracing is activated or not.
 -- 
--- ## 1.3 DCS simulator Event Handling
+-- 
+-- # 3. DCS simulator Event Handling.
 -- 
 -- The BASE class provides methods to catch DCS Events. These are events that are triggered from within the DCS simulator, 
 -- and handled through lua scripting. MOOSE provides an encapsulation to handle these events more efficiently.
 -- 
--- ### 1.3.1 Subscribe / Unsubscribe to DCS Events
+-- ## 3.1. Subscribe / Unsubscribe to DCS Events.
 -- 
 -- At first, the mission designer will need to **Subscribe** to a specific DCS event for the class.
 -- So, when the DCS event occurs, the class will be notified of that event.
@@ -119,7 +128,7 @@ local _ClassID = 0
 --   * @{#BASE.HandleEvent}(): Subscribe to a DCS Event.
 --   * @{#BASE.UnHandleEvent}(): Unsubscribe from a DCS Event.
 -- 
--- ### 1.3.2 Event Handling of DCS Events
+-- ## 3.2. Event Handling of DCS Events.
 -- 
 -- Once the class is subscribed to the event, an **Event Handling** method on the object or class needs to be written that will be called
 -- when the DCS event occurs. The Event Handling method receives an @{Core.Event#EVENTDATA} structure, which contains a lot of information
@@ -154,7 +163,7 @@ local _ClassID = 0
 -- 
 -- See the @{Event} module for more information about event handling.
 -- 
--- ## 1.4) Class identification methods
+-- # 4. Class identification methods.
 -- 
 -- BASE provides methods to get more information of each object:
 -- 
@@ -162,7 +171,7 @@ local _ClassID = 0
 --   * @{#BASE.GetClassName}(): Gets the name of the object, which is the name of the class the object was instantiated from.
 --   * @{#BASE.GetClassNameAndID}(): Gets the name and ID of the object.
 -- 
--- ## 1.5) All objects derived from BASE can have "States"
+-- # 5. All objects derived from BASE can have "States".
 -- 
 -- A mechanism is in place in MOOSE, that allows to let the objects administer **states**.  
 -- States are essentially properties of objects, which are identified by a **Key** and a **Value**.  
@@ -177,7 +186,7 @@ local _ClassID = 0
 -- Thus, if the state is to be set for the same object as the object for which the method is used, then provide the same
 -- object name to the method.
 -- 
--- ## 1.10) Inheritance
+-- # 6. Inheritance.
 -- 
 -- The following methods are available to implement inheritance
 -- 
@@ -186,8 +195,7 @@ local _ClassID = 0
 -- 
 -- ===
 -- 
--- @field #BASE BASE
--- 
+-- @field #BASE
 BASE = {
   ClassName = "BASE",
   ClassID = 0,

Moose Development/Moose/Core/Database.lua

@@ -1,4 +1,25 @@
---- **Core** -- DATABASE manages the database of mission objects. 
+--- **Core** - 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#GROUP} objects alive in the mission.
+--   * Manage database of @{Wrapper.Unit#UNIT} objects alive in the mission.
+--   * Manage database of @{Wrapper.Static#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#ZONE_BASE} objects.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Event.lua

@@ -1,8 +1,15 @@
---- **Core** -- EVENT models DCS **event dispatching** using a **publish-subscribe** model.
+--- **Core** - Models DCS event dispatching using a publish-subscribe model.
 -- 
 -- ===
 -- 
--- # 1) Event Handling Overview
+-- ## Features:
+-- 
+--   * Capture DCS events and dispatch them to the subscribed objects.
+--   * Generate DCS events to the subscribed objects from within the code.
+-- 
+-- ===
+-- 
+-- # Event Handling Overview
 -- 
 -- ![Objects](..\Presentations\EVENT\Dia2.JPG)
 -- 
@@ -14,7 +21,7 @@
 -- Objects can subscribe to different events. The Event dispatcher will publish the received DCS events to the subscribed MOOSE objects, in a specified order.
 -- In this way, the subscribed MOOSE objects are kept in sync with your evolving running mission.
 -- 
--- ## 1.1) Event Dispatching
+-- ## 1. Event Dispatching
 -- 
 -- ![Objects](..\Presentations\EVENT\Dia4.JPG)
 -- 
@@ -41,7 +48,7 @@
 -- 
 -- But for some DCS events, the publishing order is reversed. This is due to the fact that objects need to be **erased** instead of added.
 -- 
--- ## 1.2) Event Handling
+-- # 2. Event Handling
 -- 
 -- ![Objects](..\Presentations\EVENT\Dia8.JPG)
 -- 
@@ -53,7 +60,7 @@
 -- The BASE class provides methods to catch DCS Events. These are events that are triggered from within the DCS simulator, 
 -- and handled through lua scripting. MOOSE provides an encapsulation to handle these events more efficiently.
 -- 
--- ### 1.2.1 Subscribe / Unsubscribe to DCS Events
+-- ## 2.1. Subscribe to / Unsubscribe from DCS Events.
 -- 
 -- At first, the mission designer will need to **Subscribe** to a specific DCS event for the class.
 -- So, when the DCS event occurs, the class will be notified of that event.
@@ -69,7 +76,7 @@
 -- So if a UNIT within the mission has the subscribed event for that object, 
 -- then the object event handler will receive the event for that UNIT!
 -- 
--- ### 1.3.2 Event Handling of DCS Events
+-- ## 2.2 Event Handling of DCS Events
 -- 
 -- Once the class is subscribed to the event, an **Event Handling** method on the object or class needs to be written that will be called
 -- when the DCS event occurs. The Event Handling method receives an @{Core.Event#EVENTDATA} structure, which contains a lot of information
@@ -100,19 +107,19 @@
 --        self:SmokeBlue()
 --      end
 -- 
--- ### 1.3.3 Event Handling methods that are automatically called upon subscribed DCS events
+-- ## 2.3 Event Handling methods that are automatically called upon subscribed DCS events.
 -- 
 -- ![Objects](..\Presentations\EVENT\Dia10.JPG)
 -- 
 -- The following list outlines which EVENTS item in the structure corresponds to which Event Handling method.
 -- Always ensure that your event handling methods align with the events being subscribed to, or nothing will be executed.
 -- 
--- # 2) EVENTS type
+-- # 3. EVENTS type
 -- 
 -- The EVENTS structure contains names for all the different DCS events that objects can subscribe to using the 
 -- @{Core.Base#BASE.HandleEvent}() method.
 -- 
--- # 3) EVENTDATA type
+-- # 4. EVENTDATA type
 -- 
 -- The @{Core.Event#EVENTDATA} structure contains all the fields that are populated with event information before 
 -- an Event Handler method is being called by the event dispatcher.
@@ -166,11 +173,12 @@
 -- @image Core_Event.JPG
 
 
---- The EVENT structure
--- 
--- @type EVENT
+--- @type EVENT
 -- @field #EVENT.Events Events
 -- @extends Core.Base#BASE
+
+--- The EVENT class
+-- @field #EVENT
 EVENT = {
   ClassName = "EVENT",
   ClassID = 0,

Moose Development/Moose/Core/Fsm.lua

@@ -1,5 +1,18 @@
---- **Core** -- The **FSM** (**F**inite **S**tate **M**achine) class and derived **FSM\_** classes 
--- are design patterns allowing efficient (long-lasting) processes and workflows.
+--- **Core** - 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.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Goal.lua

@@ -1,8 +1,16 @@
---- **Core (WIP)** -- Base class to allow the modeling of processes to achieve Goals.
+--- **Core** - Models the process to achieve goal(s).
 --
 -- ===
 -- 
--- GOAL models processes that have an objective with a defined achievement. Derived classes implement the ways how the achievements can be realized.
+-- ## Features:
+-- 
+--   * Define the goal.
+--   * Monitor the goal achievement.
+--   * Manage goal contribution by players.
+-- 
+-- ===
+-- 
+-- Classes that implement a goal achievement, will derive from GOAL to implement the ways how the achievements can be realized.
 -- 
 -- ===
 -- 
@@ -13,6 +21,7 @@
 -- @module Core.Goal
 -- @image Core_Goal.JPG
 
+
 do -- Goal
 
   --- @type GOAL
@@ -21,21 +30,43 @@ do -- Goal
 
   --- Models processes that have an objective with a defined achievement. Derived classes implement the ways how the achievements can be realized.
   -- 
-  -- ## 1. GOAL constructor
+  -- # 1. GOAL constructor
   --   
   --   * @{#GOAL.New}(): Creates a new GOAL object.
   -- 
-  -- ## 2. GOAL is a finite state machine (FSM).
+  -- # 2. GOAL is a finite state machine (FSM).
   -- 
-  -- ### 2.1 GOAL States
+  -- ## 2.1. GOAL States
   -- 
   --   * **Pending**: The goal object is in progress.
   --   * **Achieved**: The goal objective is Achieved.
   -- 
-  -- ### 2.2 GOAL Events
+  -- ## 2.2. GOAL Events
   -- 
   --   * **Achieved**: Set the goal objective to Achieved.
   -- 
+  -- # 3. Player contributions.
+  -- 
+  -- Goals are most of the time achieved by players. These player achievements can be registered as part of the goal achievement.
+  -- Use @{#GOAL.AddPlayerContribution}() to add a player contribution to the goal.
+  -- The player contributions are based on a points system, an internal counter per player.
+  -- So once the goal has been achieved, the player contributions can be queried using @{#GOAL.GetPlayerContributions}(), 
+  -- that retrieves all contributions done by the players. For one player, the contribution can be queried using @{#GOAL.GetPlayerContribution}().
+  -- The total amount of player contributions can be queried using @{#GOAL.GetTotalContributions}().
+  -- 
+  -- # 4. Goal achievement.
+  -- 
+  -- Once the goal is achieved, the mission designer will need to trigger the goal achievement using the **Achieved** event.
+  -- The underlying 2 examples will achieve the goals for the `Goal` object:
+  -- 
+  --       Goal:Achieved() -- Achieve the goal immediately.
+  --       Goal:__Achieved( 30 ) -- Achieve the goal within 30 seconds.
+  -- 
+  -- # 5. Check goal achievement.
+  -- 
+  -- The method @{#GOAL.IsAchieved}() will return true if the goal is achieved (the trigger **Achieved** was executed).
+  -- You can use this method to check asynchronously if a goal has been achieved, for example using a scheduler.
+  -- 
   -- @field #GOAL
   GOAL = {
     ClassName = "GOAL",

Moose Development/Moose/Core/Menu.lua

@@ -1,7 +1,27 @@
---- **Core** -- MENU_ classes model the definition of **hierarchical menu structures** and **commands for players** within a mission.
+--- **Core** - Manage hierarchical menu structures and commands for players within a mission.
 -- 
 -- ===
 -- 
+-- ### 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.
+-- 
 -- DCS Menus can be managed using the MENU classes. 
 -- 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

Moose Development/Moose/Core/Message.lua

@@ -1,4 +1,15 @@
---- **Core** -- MESSAGE class takes are of the **real-time notifications** and **messages to players** during a simulation.
+--- **Core** - 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.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Point.lua

@@ -1,6 +1,6 @@
---- **Core** -- Defines an **extensive API** to **manage 3D points** in the DCS World 3D simulation space.
+--- **Core** - Defines an extensive API to manage 3D points in the DCS World 3D simulation space.
 --
--- **Features:**
+-- ## 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.

Moose Development/Moose/Core/Radio.lua

@@ -1,7 +1,12 @@
---- **Core** -- The RADIO Module is responsible for everything that is related to radio transmission and you can hear in DCS, be it TACAN beacons, Radio transmissions...
+--- **Core** - 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.
+--
 -- The Radio contains 2 classes : RADIO and BEACON
 --  
 -- What are radio communications in DCS ?

Moose Development/Moose/Core/Report.lua

@@ -1,20 +1,26 @@
---- **Core** -- **REPORT** class provides a handy means to create messages and reports.
+--- **Core** - Provides a handy means to create messages and reports.
 --
 -- ===
 -- 
--- ### Authors:
+-- ## Features:
 -- 
---   * FlightControl : Design & Programming
+--   * Create text blocks that are formatted.
+--   * Create automatic indents.
+--   * Variate the delimiters between reporting lines.
 -- 
--- ### Contributions:
+-- ===
+--
+-- ### Authors: FlightControl : Design & Programming
 --
 -- @module Core.Report
 -- @image Core_Report.JPG
 
 
---- The REPORT class
--- @type REPORT
+--- @type REPORT
 -- @extends Core.Base#BASE
+
+--- Provides a handy means to create messages and reports.
+-- @field #REPORT
 REPORT = {
   ClassName = "REPORT",
   Title = "",

Moose Development/Moose/Core/Scheduler.lua

@@ -1,9 +1,10 @@
---- **Core** -- SCHEDULER prepares and handles the **execution of functions over scheduled time (intervals)**.
+--- **Core** - Prepares and handles the execution of functions over scheduled time (intervals).
 --
 -- ===
 -- 
--- SCHEDULER manages the **scheduling of functions**:
+-- ## 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, 

Moose Development/Moose/Core/Set.lua

@@ -1,22 +1,35 @@
---- **Core** -- SET_ classes define **collections** of objects to perform **bulk actions** and logically **group** objects.
+--- **Core** - Define collections of objects to perform bulk actions and logically group objects.
 -- 
 -- ===
 -- 
--- SET_ classes group objects of the same type into a collection, which is either:
+-- ## Features:
 -- 
---   * Manually managed using the **:Add...()** or **:Remove...()** methods. The initial SET can be filtered with the **@{#SET_BASE.FilterOnce}()** method
+--   * 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.
+--   
+-- ===
+-- 
+-- Group objects or data of the same type into a collection, which is either:
+-- 
+--   * Manually managed using the **:Add...()** or **:Remove...()** methods. The initial SET can be filtered with the **@{#SET_BASE.FilterOnce}()** method.
 --   * Dynamically updated when new objects are created or objects are destroyed using the **@{#SET_BASE.FilterStart}()** method.
 --   
 -- Various types of SET_ classes are available:
 -- 
---   * @{#SET_UNIT}: Defines a colleciton of @{Wrapper.Unit}s filtered by filter criteria.
 --   * @{#SET_GROUP}: Defines a collection of @{Wrapper.Group}s filtered by filter criteria.
+--   * @{#SET_UNIT}: Defines a colleciton of @{Wrapper.Unit}s filtered by filter criteria.
+--   * @{#SET_STATIC}: Defines a collection of @{Wrapper.Static}s filtered by filter criteria.
 --   * @{#SET_CLIENT}: Defines a collection of @{Client}s filterd by filter criteria.
 --   * @{#SET_AIRBASE}: Defines a collection of @{Wrapper.Airbase}s filtered by filter criteria.
+--   * @{#SET_CARGO}: Defines a collection of @{Cargo.Cargo}s filtered by filter criteria.
+--   * @{#SET_ZONE}: Defines a collection of @{Core.Zone}s filtered by filter criteria.
 -- 
--- These classes are derived from @{#SET_BASE}, which contains the main methods to manage SETs.
+-- These classes are derived from @{#SET_BASE}, which contains the main methods to manage the collections.
 -- 
--- A multitude of other methods are available in SET_ classes that allow to:
+-- A multitude of other methods are available in the individual set classes that allow to:
 -- 
 --   * Validate the presence of objects in the SET.
 --   * Trigger events when objects in the SET change a zone presence.

Moose Development/Moose/Core/Settings.lua

@@ -1,4 +1,16 @@
---- **Core** -- Manages various settings for MOOSE classes.
+--- **Core** - 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.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Spawn.lua

@@ -1,8 +1,32 @@
---- **Core** --Spawn dynamically new GROUPs of UNITs in your missions.
+--- **Core** - Spawn dynamically new groups of units in running missions.
 --  
 -- ===
 -- 
--- The documentation of the SPAWN class can be found further in this document.
+-- ## 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.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/SpawnStatic.lua

@@ -1,8 +1,14 @@
---- **Core** -- Spawn dynamically new STATICs in your missions.
+--- **Core** - Spawn new statics in your running missions.
 --  
 -- ===
 -- 
--- SPAWNSTATIC spawns static structures in your missions dynamically. See below the SPAWNSTATIC class documentation.
+-- ## 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.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Spot.lua

@@ -1,4 +1,4 @@
---- **Core** -- Management of SPOT logistics, that can be transported from and to transportation carriers.
+--- **Core** - Management of spotting logistics, that can be activated and deactivated upon command.
 --
 -- ===
 -- 

Moose Development/Moose/Core/UserFlag.lua

@@ -1,8 +1,10 @@
---- **Core (WIP)** -- Manage user flags.
+--- **Core** - Manage user flags to interact with the mission editor trigger system and server side scripts.
 --
 -- ===
 -- 
--- Management of DCS User Flags.
+-- ## Features:
+-- 
+--   * Set or get DCS user flags within running missions.
 -- 
 -- ===
 -- 
@@ -22,7 +24,7 @@ do -- UserFlag
 
   --- Management of DCS User Flags.
   -- 
-  -- ## USERFLAG constructor
+  -- # 1. USERFLAG constructor
   --   
   --   * @{#USERFLAG.New}(): Creates a new USERFLAG object.
   -- 

Moose Development/Moose/Core/UserSound.lua

@@ -1,4 +1,10 @@
---- **Core (WIP)** -- Manage user sound.
+--- **Core** - Manage user sound.
+--
+-- ===
+-- 
+-- ## Features:
+-- 
+--   * Play sounds wihtin running missions.
 -- 
 -- ===
 -- 

Moose Development/Moose/Core/Velocity.lua

@@ -1,4 +1,12 @@
---- **Core** -- VELOCITY models a speed, which can be expressed in various formats according the Settings.
+--- **Core** - 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.
 --   
 -- ===
 -- 

Moose Development/Moose/Core/Zone.lua

@@ -1,7 +1,24 @@
---- **Core** -- ZONE classes define **zones** within your mission of **various forms**, with **various capabilities**.
+--- **Core** - 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.
+--   
+-- 
 -- There are essentially two core functions that zones accomodate:
 -- 
 --   * Test if an object is within the zone boundaries.