General fixes (#1673)

* General minor

Code formatting and minor typo/document fixes.

* Update Marker.lua

Code formatting and minor typo/document fixes. Note specifically the correction of "self.tocoaliton" to "self.tocoalition".

Moose Development/Moose/Core/Database.lua

@@ -903,7 +903,7 @@ function DATABASE:_RegisterPlayers()
   return self
 end
 
---- Private method that registers all Groups and Units within in the mission.
+--- Private method that registers all Groups and Units within the mission.
 -- @param #DATABASE self
 -- @return #DATABASE self
 function DATABASE:_RegisterGroupsAndUnits()
@@ -944,7 +944,7 @@ function DATABASE:_RegisterGroupsAndUnits()
   return self
 end
 
---- Private method that registers all Units of skill Client or Player within in the mission.
+--- Private method that registers all Units of skill Client or Player within the mission.
 -- @param #DATABASE self
 -- @return #DATABASE self
 function DATABASE:_RegisterClients()
@@ -957,7 +957,8 @@ function DATABASE:_RegisterClients()
   return self
 end
 
---- @param #DATABASE self
+--- Private method that registers all Statics within the mission.
+-- @param #DATABASE self
 function DATABASE:_RegisterStatics()
 
   local CoalitionsData = { GroupsRed = coalition.getStaticObjects( coalition.side.RED ), GroupsBlue = coalition.getStaticObjects( coalition.side.BLUE ), GroupsNeutral = coalition.getStaticObjects( coalition.side.NEUTRAL ) }

Moose Development/Moose/Core/Event.lua

@@ -32,11 +32,11 @@
 --
 -- ![Objects](..\Presentations\EVENT\Dia5.JPG)
 --
--- There are 5 levels of kind of objects that the _EVENTDISPATCHER services:
+-- There are 5 types/levels of objects that the _EVENTDISPATCHER services:
 --
 --  * _DATABASE object: The core of the MOOSE objects. Any object that is created, deleted or updated, is done in this database.
---  * SET_ derived classes: Subsets of the _DATABASE object. These subsets are updated by the _EVENTDISPATCHER as the second priority.
---  * UNIT objects: UNIT objects can subscribe to DCS events. Each DCS event will be directly published to teh subscribed UNIT object.
+--  * SET_ derived classes: These are subsets of the _DATABASE object. These subsets are updated by the _EVENTDISPATCHER as the second priority.
+--  * UNIT objects: UNIT objects can subscribe to DCS events. Each DCS event will be directly published to the subscribed UNIT object.
 --  * GROUP objects: GROUP objects can subscribe to DCS events. Each DCS event will be directly published to the subscribed GROUP object.
 --  * Any other object: Various other objects can subscribe to DCS events. Each DCS event triggered will be published to each subscribed object.
 --
@@ -131,6 +131,8 @@
 --    * Weapon data: Certain events populate weapon information.
 --    * Place data: Certain events populate place information.
 --
+-- Example code snippet:
+--
 --      --- This function is an Event Handling function that will be called when Tank1 is Dead.
 --      -- EventData is an EVENTDATA structure.
 --      -- We use the EventData.IniUnit to smoke the tank Green.
@@ -150,6 +152,7 @@
 -- In case a STATIC object is involved, the documentation indicates which fields will and won't not be populated.
 -- The fields **IniObjectCategory** and **TgtObjectCategory** contain the indicator which **kind of object is involved** in the event.
 -- You can use the enumerator **Object.Category.UNIT** and **Object.Category.STATIC** to check on IniObjectCategory and TgtObjectCategory.
+--
 -- Example code snippet:
 --
 --      if Event.IniObjectCategory == Object.Category.UNIT then

Moose Development/Moose/Core/Fsm.lua

@@ -18,11 +18,11 @@
 --
 -- A Finite State Machine (FSM) models a process flow that transitions between various **States** through triggered **Events**.
 --
--- A FSM can only be in one of a finite number of states. 
+-- A FSM can only be in one of a finite number of states.
 -- The machine is in only one state at a time; the state it is in at any given time is called the **current state**.
 -- It can change from one state to another when initiated by an **__internal__ or __external__ triggering event**, which is called a **transition**.
--- An **FSM implementation** is defined by **a list of its states**, **its initial state**, and **the triggering events** for **each possible transition**.
--- An FSM implementation is composed out of **two parts**, a set of **state transition rules**, and an implementation set of **state transition handlers**, implementing those transitions.
+-- A **FSM implementation** is defined by **a list of its states**, **its initial state**, and **the triggering events** for **each possible transition**.
+-- A FSM implementation is composed out of **two parts**, a set of **state transition rules**, and an implementation set of **state transition handlers**, implementing those transitions.
 --
 -- The FSM class supports a **hierarchical implementation of a Finite State Machine**,
 -- that is, it allows to **embed existing FSM implementations in a master FSM**.
@@ -34,21 +34,21 @@
 -- orders him to destroy x targets and account the results.
 -- Other examples of ready made FSM could be:
 --
---   * route a plane to a zone flown by a human
---   * detect targets by an AI and report to humans
---   * account for destroyed targets by human players
---   * handle AI infantry to deploy from or embark to a helicopter or airplane or vehicle 
---   * let an AI patrol a zone
+--   * Route a plane to a zone flown by a human.
+--   * Detect targets by an AI and report to humans.
+--   * Account for destroyed targets by human players.
+--   * Handle AI infantry to deploy from or embark to a helicopter or airplane or vehicle.
+--   * Let an AI patrol a zone.
 --
--- The **MOOSE framework** uses extensively the FSM class and derived FSM\_ classes,
+-- The **MOOSE framework** extensively uses the FSM class and derived FSM\_ classes,
 -- because **the goal of MOOSE is to simplify mission design complexity for mission building**.
 -- By efficiently utilizing the FSM class and derived classes, MOOSE allows mission designers to quickly build processes.
 -- **Ready made FSM-based implementations classes** exist within the MOOSE framework that **can easily be re-used,
 -- and tailored** by mission designers through **the implementation of Transition Handlers**.
 -- Each of these FSM implementation classes start either with:
 --
---   * an acronym **AI\_**, which indicates an FSM implementation directing **AI controlled** @{GROUP} and/or @{UNIT}. These AI\_ classes derive the @{#FSM_CONTROLLABLE} class.
---   * an acronym **TASK\_**, which indicates an FSM implementation executing a @{TASK} executed by Groups of players. These TASK\_ classes derive the @{#FSM_TASK} class.
+--   * an acronym **AI\_**, which indicates a FSM implementation directing **AI controlled** @{GROUP} and/or @{UNIT}. These AI\_ classes derive the @{#FSM_CONTROLLABLE} class.
+--   * an acronym **TASK\_**, which indicates a FSM implementation executing a @{TASK} executed by Groups of players. These TASK\_ classes derive the @{#FSM_TASK} class.
 --   * an acronym **ACT\_**, which indicates an Sub-FSM implementation, directing **Humans actions** that need to be done in a @{TASK}, seated in a @{CLIENT} (slot) or a @{UNIT} (CA join). These ACT\_ classes derive the @{#FSM_PROCESS} class.
 --
 -- Detailed explanations and API specifics are further below clarified and FSM derived class specifics are described in those class documentation sections.
@@ -59,7 +59,7 @@
 -- I've reworked this development (taken the concept), and created a **hierarchical state machine** out of it, embedded within the DCS simulator.
 -- Additionally, I've added extendability and created an API that allows seamless FSM implementation.
 --
--- The following derived classes are available in the MOOSE framework, that implement a specialised form of a FSM:
+-- The following derived classes are available in the MOOSE framework, that implement a specialized form of a FSM:
 --
 --   * @{#FSM_TASK}: Models Finite State Machines for @{Task}s.
 --   * @{#FSM_PROCESS}: Models Finite State Machines for @{Task} actions, which control @{Client}s.

Moose Development/Moose/Core/Menu.lua

@@ -778,7 +778,7 @@ end
 
 do
   -- This local variable is used to cache the menus registered under groups.
-  -- Menus don't dissapear when groups for players are destroyed and restarted.
+  -- Menus don't disappear when groups for players are destroyed and restarted.
   -- So every menu for a client created must be tracked so that program logic accidentally does not create.
   -- the same menus twice during initialization logic.
   -- These menu classes are handling this logic with this variable.

Moose Development/Moose/Core/Spawn.lua

@@ -1373,7 +1373,7 @@ function SPAWN:SpawnWithIndex( SpawnIndex, NoBirth )
           SpawnTemplate.modulation = self.SpawnInitModu
         end
 
-        -- Set country, coaliton and categroy.
+        -- Set country, coalition and category.
         SpawnTemplate.CategoryID = self.SpawnInitCategory or SpawnTemplate.CategoryID
         SpawnTemplate.CountryID = self.SpawnInitCountry or SpawnTemplate.CountryID
         SpawnTemplate.CoalitionID = self.SpawnInitCoalition or SpawnTemplate.CoalitionID
@@ -2360,7 +2360,7 @@ end
 -- The known AIRBASE objects are automatically imported at mission start by MOOSE.
 -- Therefore, there isn't any New() constructor defined for AIRBASE objects.
 --
--- Ships and Farps are added within the mission, and are therefore not known.
+-- Ships and FARPs are added within the mission, and are therefore not known.
 -- For these AIRBASE objects, there isn't an @{Wrapper.Airbase#AIRBASE} enumeration defined.
 -- You need to provide the **exact name** of the airbase as the parameter to the @{Wrapper.Airbase#AIRBASE.FindByName}() method!
 --