diff --git a/Moose Development/Moose/Tasking/CommandCenter.lua b/Moose Development/Moose/Tasking/CommandCenter.lua index e8f9204e4..4b3e8a17c 100644 --- a/Moose Development/Moose/Tasking/CommandCenter.lua +++ b/Moose Development/Moose/Tasking/CommandCenter.lua @@ -30,19 +30,93 @@ --- Governs multiple missions, the tasking and the reporting. -- --- The commandcenter communicates important messages between the various groups of human players executing tasks in missions. +-- Command centers govern missions, communicates the task assignments between human players of the coalition, and manages the menu flow. +-- It can assign a random task to a player when requested. +-- The commandcenter provides the facilitites to communicate between human players online, executing a task. -- --- ## COMMANDCENTER constructor +-- ## 1. Create a command center object. -- -- * @{#COMMANDCENTER.New}(): Creates a new COMMANDCENTER object. -- --- ## Mission Management +-- ## 2. Command center mission management. +-- +-- Command centers manage missions. These can be added, removed and provides means to retrieve missions. +-- These methods are heavily used by the task dispatcher classes. -- -- * @{#COMMANDCENTER.AddMission}(): Adds a mission to the commandcenter control. -- * @{#COMMANDCENTER.RemoveMission}(): Removes a mission to the commandcenter control. -- * @{#COMMANDCENTER.GetMissions}(): Retrieves the missions table controlled by the commandcenter. -- --- ## Reference Zones +-- ## 3. Communication management between players. +-- +-- Command center provide means of communication between players. +-- Because a command center is a central object governing multiple missions, +-- there are several levels at which communication needs to be done. +-- Within MOOSE, communication is facilitated using the message system within the DCS simulator. +-- +-- Messages can be sent between players at various levels: +-- +-- - On a global level, to all players. +-- - On a coalition level, only to the players belonging to the same coalition. +-- - On a group level, to the players belonging to the same group. +-- +-- Messages can be sent to **all players** by the command center using the method @{Tasking.CommandCenter#COMMANDCENTER.MessageToAll}(). +-- +-- To send messages to **the coalition of the command center**, there are two methods available: +-- +-- - Use the method @{Tasking.CommandCenter#COMMANDCENTER.MessageToCoalition}() to send a specific message to the coalition, with a given message display duration. +-- - You can send a specific type of message using the method @{Tasking.CommandCenter#COMMANDCENTER.MessageTypeToCoalition}(). +-- This will send a message of a specific type to the coalition, and as a result its display duration will be flexible according the message display time selection by the human player. +-- +-- To send messages **to the group** of human players, there are also two methods available: +-- +-- - Use the method @{Tasking.CommandCenter#COMMANDCENTER.MessageToGroup}() to send a specific message to a group, with a given message display duration. +-- - You can send a specific type of message using the method @{Tasking.CommandCenter#COMMANDCENTER.MessageTypeToGroup}(). +-- This will send a message of a specific type to the group, and as a result its display duration will be flexible according the message display time selection by the human player . +-- +-- Messages are considered to be sometimes disturbing for human players, therefore, the settings menu provides the means to activate or deactivate messages. +-- For more information on the message types and display timings that can be selected and configured using the menu, refer to the @{Core.Settings} menu description. +-- +-- ## 4. Command center detailed methods. +-- +-- Various methods are added to manage command centers. +-- +-- ### 4.1. Naming and description. +-- +-- There are 3 methods that can be used to retrieve the description of a command center: +-- +-- - Use the method @{Tasking.CommandCenter#COMMANDCENTER.GetName}() to retrieve the name of the command center. +-- This is the name given as part of the @{Tasking.CommandCenter#COMMANDCENTER.New}() constructor. +-- The returned name using this method, is not to be used for message communication. +-- +-- A textual description can be retrieved that provides the command center name to be used within message communication: +-- +-- - @{Tasking.CommandCenter#COMMANDCENTER.GetShortText}() returns the command center name as `CC [CommandCenterName]`. +-- - @{Tasking.CommandCenter#COMMANDCENTER.GetText}() returns the command center name as `Command Center [CommandCenterName]`. +-- +-- ### 4.2. The coalition of the command center. +-- +-- The method @{Tasking.CommandCenter#COMMANDCENTER.GetCoalition}() returns the coalition of the command center. +-- The return value is an enumeration of the type @{DCS#coalition.side}, which contains the RED, BLUE and NEUTRAL coalition. +-- +-- ### 4.3. The command center is a real object. +-- +-- The command center must be represented by a live object within the DCS simulator. As a result, the command center +-- can be a @{Wrapper.Unit}, a @{Wrapper.Group}, an @{Wrapper.Airbase} or a @{Wrapper.Static} object. +-- +-- Using the method @{Tasking.CommandCenter#COMMANDCENTER.GetPositionable}() you retrieve the polymorphic positionable object representing +-- the command center, but just be aware that you should be able to use the representable object derivation methods. +-- +-- ### 5. Command center reports. +-- +-- Because a command center giverns multiple missions, there are several reports available that are generated by command centers. +-- These reports are generated using the following methods: +-- +-- - @{Tasking.CommandCenter#COMMANDCENTER.ReportSummary}(): Creates a summary report of all missions governed by the command center. +-- - @{Tasking.CommandCenter#COMMANDCENTER.ReportDetails}(): Creates a detailed report of all missions governed by the command center. +-- - @{Tasking.CommandCenter#COMMANDCENTER.ReportMissionPlayers}(): Creates a report listing the players active at the missions governed by the command center. +-- +-- ## 6. Reference Zones. -- -- Command Centers may be aware of certain Reference Zones within the battleground. These Reference Zones can refer to -- known areas, recognizable buildings or sites, or any other point of interest. diff --git a/Moose Development/Moose/Tasking/Mission.lua b/Moose Development/Moose/Tasking/Mission.lua index c2f9f2de1..6bbca053e 100644 --- a/Moose Development/Moose/Tasking/Mission.lua +++ b/Moose Development/Moose/Tasking/Mission.lua @@ -19,12 +19,106 @@ -- @module Tasking.Mission -- @image Task_Mission.JPG ---- The MISSION class --- @type MISSION +--- @type MISSION -- @field #MISSION.Clients _Clients -- @field Core.Menu#MENU_COALITION MissionMenu -- @field #string MissionBriefing -- @extends Core.Fsm#FSM + +--- Models goals to be achieved and can contain multiple tasks to be executed to achieve the goals. +-- +-- A mission contains multiple tasks and can be of different task types. +-- These tasks need to be assigned to human players to be executed. +-- +-- A mission can have multiple states, which will evolve as the mission progresses during the DCS simulation. +-- +-- - **IDLE**: The mission is defined, but not started yet. No task has yet been joined by a human player as part of the mission. +-- - **ENGAGED**: The mission is ongoing, players have joined tasks to be executed. +-- - **COMPLETED**: The goals of the mission has been successfully reached, and the mission is flagged as completed. +-- - **FAILED**: For a certain reason, the goals of the mission has not been reached, and the mission is flagged as failed. +-- - **HOLD**: The mission was enaged, but for some reason it has been put on hold. +-- +-- Note that a mission goals need to be checked by a goal check trigger: @{#MISSION.OnBeforeMissionGoals}(), which may return false if the goal has not been reached. +-- This goal is checked automatically by the mission object every x seconds. +-- +-- - @{#MISSION.Start}() or @{#MISSION.__Start}() will start the mission, and will bring it from **IDLE** state to **ENGAGED** state. +-- - @{#MISSION.Stop}() or @{#MISSION.__Stop}() will stop the mission, and will bring it from **ENGAGED** state to **IDLE** state. +-- - @{#MISSION.Complete}() or @{#MISSION.__Complete}() will complete the mission, and will bring the mission state to **COMPLETED**. +-- Note that the mission must be in state **ENGAGED** to be able to complete the mission. +-- - @{#MISSION.Fail}() or @{#MISSION.__Fail}() will fail the mission, and will bring the mission state to **FAILED**. +-- Note that the mission must be in state **ENGAGED** to be able to fail the mission. +-- - @{#MISSION.Hold}() or @{#MISSION.__Hold}() will hold the mission, and will bring the mission state to **HOLD**. +-- Note that the mission must be in state **ENGAGED** to be able to hold the mission. +-- Re-engage the mission using the engage trigger. +-- +-- The following sections provide an overview of the most important methods that can be used as part of a mission object. +-- Note that the @{Tasking.CommandCenter} system is using most of these methods to manage the missions in its system. +-- +-- ## 1. Create a mission object. +-- +-- - @{#MISSION.New}(): Creates a new MISSION object. +-- +-- ## 2. Mission task management. +-- +-- Missions maintain tasks, which can be added or removed, or enquired. +-- +-- - @{#MISSION.AddTask}(): Adds a task to the mission. +-- - @{#MISSION.RemoveTask}(): Removes a task from the mission. +-- +-- ## 3. Mission detailed methods. +-- +-- Various methods are added to manage missions. +-- +-- ### 3.1. Naming and description. +-- +-- There are several methods that can be used to retrieve the properties of a mission: +-- +-- - Use the method @{#MISSION.GetName}() to retrieve the name of the mission. +-- This is the name given as part of the @{#MISSION.New}() constructor. +-- +-- A textual description can be retrieved that provides the mission name to be used within message communication: +-- +-- - @{#MISSION.GetShortText}() returns the mission name as `Mission "MissionName"`. +-- - @{#MISSION.GetText}() returns the mission name as `Mission "MissionName (MissionPriority)"`. A longer version including the priority text of the mission. +-- +-- ### 3.2. Get task information. +-- +-- - @{#MISSION.GetTasks}(): Retrieves a list of the tasks controlled by the mission. +-- - @{#MISSION.GetTask}(): Retrieves a specific task controlled by the mission. +-- - @{#MISSION.GetTasksRemaining}(): Retrieve a list of the tasks that aren't finished or failed, and are governed by the mission. +-- - @{#MISSION.GetGroupTasks}(): Retrieve a list of the tasks that can be asigned to a @{Wrapper.Group}. +-- - @{#MISSION.GetTaskTypes}(): Retrieve a list of the different task types governed by the mission. +-- +-- ### 3.3. Get the command center. +-- +-- - @{#MISSION.GetCommandCenter}(): Retrieves the @{Tasking.CommandCenter} governing the mission. +-- +-- ### 3.4. Get the groups active in the mission as a @{Core.Set}. +-- +-- - @{#MISSION.GetGroups}(): Retrieves a @{Core.Set#SET_GROUP} of all the groups active in the mission (as part of the tasks). +-- +-- ### 3.5. Get the names of the players. +-- +-- - @{#MISSION.GetPlayerNames}(): Retrieves the list of the players that were active within th mission.. +-- +-- ## 4. Menu management. +-- +-- A mission object is able to manage its own menu structure. Use the @{#MISSION.GetMenu}() and @{#MISSION.SetMenu}() to manage the underlying submenu +-- structure managing the tasks of the mission. +-- +-- ## 5. Reporting management. +-- +-- Several reports can be generated for a mission, and will return a text string that can be used to display using the @{Core.Message} system. +-- +-- - @{#MISSION.ReportBriefing}(): Generates the briefing for the mission. +-- - @{#MISSION.ReportOverview}(): Generates an overview of the tasks and status of the mission. +-- - @{#MISSION.ReportDetails}(): Generates a detailed report of the tasks of the mission. +-- - @{#MISSION.ReportSummary}(): Generates a summary report of the tasks of the mission. +-- - @{#MISSION.ReportPlayersPerTask}(): Generates a report showing the active players per task. +-- - @{#MISSION.ReportPlayersProgress}(): Generates a report showing the task progress per player. +-- +-- +-- @field #MISSION MISSION = { ClassName = "MISSION", Name = "", diff --git a/Moose Development/Moose/Tasking/Task.lua b/Moose Development/Moose/Tasking/Task.lua index f76cbf7fe..3835621a3 100644 --- a/Moose Development/Moose/Tasking/Task.lua +++ b/Moose Development/Moose/Tasking/Task.lua @@ -1,4 +1,13 @@ ---- **Tasking** -- This module contains the TASK class, the main engine to run human taskings. +--- **Tasking** -- A task object governs the main engine to administer human taskings. +-- +-- **Features:** +-- +-- * Manage the overall task execution, following-up the progression made by the pilots and actors. +-- * Provide a mechanism to set a task status, depending on the progress made within the task. +-- * Manage a task briefing. +-- * Manage the players executing the task. +-- * Manage the task menu system. +-- * Manage the task goal and scoring. -- -- === -- @@ -21,43 +30,127 @@ -- @field Tasking.TaskInfo#TASKINFO TaskInfo -- @extends Core.Fsm#FSM_TASK ---- --- # TASK class, extends @{Core.Base#BASE} +--- Governs the main engine to administer human taskings. -- --- ## The TASK class implements the methods for task orchestration within MOOSE. +-- A task is governed by a @{Tasking.Mission} object. Tasks are of different types. +-- The @{#TASK} object is used or derived by more detailed tasking classes that will implement the task execution mechanisms +-- and goals. The following TASK_ classes are derived from @{#TASK}. -- --- The class provides a couple of methods to: -- --- * @{#TASK.AssignToGroup}():Assign a task to a group (of players). --- * @{#TASK.AddProcess}():Add a @{Process} to a task. --- * @{#TASK.RemoveProcesses}():Remove a running @{Process} from a running task. --- * @{#TASK.SetStateMachine}():Set a @{Core.Fsm} to a task. --- * @{#TASK.RemoveStateMachine}():Remove @{Core.Fsm} from a task. --- * @{#TASK.HasStateMachine}():Enquire if the task has a @{Core.Fsm} --- * @{#TASK.AssignToUnit}(): Assign a task to a unit. (Needs to be implemented in the derived classes from @{#TASK}. --- * @{#TASK.UnAssignFromUnit}(): Unassign the task from a unit. --- * @{#TASK.SetTimeOut}(): Set timer in seconds before task gets cancelled if not assigned. +-- TASK +-- TASK_A2A +-- TASK_A2A_ENGAGE +-- TASK_A2A_INTERCEPT +-- TASK_A2A_SWEEP +-- TASK_A2G +-- TASK_A2G_SEAD +-- TASK_A2G_CAS +-- TASK_A2G_BAI +-- TASK_CARGO +-- TASK_CARGO_TRANSPORT +-- TASK_CARGO_CSAR +-- +-- +-- +-- #### A2A Tasks +-- +-- - @{Tasking.Task_A2A#TASK_A2A_ENGAGE} - Models an A2A engage task of a target group of airborne intruders mid-air. +-- - @{Tasking.Task_A2A#TASK_A2A_INTERCEPT} - Models an A2A ground intercept task of a target group of airborne intruders mid-air. +-- - @{Tasking.Task_A2A#TASK_A2A_SWEEP} - Models an A2A sweep task to clean an area of previously detected intruders mid-air. +-- +-- #### A2G Tasks +-- +-- - @{Tasking.Task_A2G#TASK_A2G_SEAD} - Models an A2G Suppression or Extermination of Air Defenses task to clean an area of air to ground defense threats. +-- - @{Tasking.Task_A2G#TASK_A2G_CAS} - Models an A2G Close Air Support task to provide air support to nearby friendlies near the front-line. +-- - @{Tasking.Task_A2G#TASK_A2G_BAI} - Models an A2G Battlefield Air Interdiction task to provide air support to nearby friendlies near the front-line. +-- +-- #### Cargo Tasks +-- +-- - @{Tasking.Task_Cargo#TASK_CARGO_TRANSPORT} - Models the transportation of cargo to deployment zones. +-- - @{Tasking.Task_Cargo#TASK_CARGO_CSAR} - Models the rescue of downed friendly pilots from behind enemy lines. +-- +-- The above task objects take care of the **progress** and **completion** of the task **goal(s)**. +-- Tasks are executed by **human pilots** and actors within a DCS simulation. +-- Pilots can use a **menu system** to engage or abort a task, and provides means to +-- understand the **task briefing** and goals, and the relevant **task locations** on the map and +-- obtain **various reports** related to the task. +-- +-- As the task progresses, the **task status** will change over time, from Planned state to Completed state. +-- **Multiple pilots** can execute the same task, as such, the tasking system provides a **co-operative model** for joint task execution. +-- Depending on the task progress, a **scoring** can be allocated to award pilots of the achievements made. +-- The scoring is fully flexible, and different levels of awarding can be provided depending on the task type and complexity. +-- +-- ## 1. Task Statuses +-- +-- ### 1.1. Task status overview. +-- +-- A task has a state, reflecting the progress and completion of the task: +-- +-- - **Planned**: Expresses that the task is created, but not yet in execution and is not assigned yet to a pilot. +-- - **Assigned**: Expresses that the task is assigned to a group of pilots, and that the task is in execution mode. +-- - **Success**: Expresses the successful execution and finalization of the task. +-- - **Failed**: Expresses the failure of a task. +-- - **Abort**: Expresses that the task is aborted by by the player using the abort menu. +-- - **Cancelled**: Expresses that the task is cancelled by HQ or through a logical situation where a cancellation of the task is required. +-- +-- A normal flow of task status would evolve from the **Planned** state, to the **Assigned** state ending either in a **Success** or a **Failed** state. +-- The state completion is by default set to **Success**, if the goals of the task have been reached, but can be overruled by a goal method. +-- +-- Depending on the tactical situation, a task can be **Rejected** or **Cancelled** by the mission governer. +-- It is actually the mission designer who has the flexibility to decide at which conditions a task would be set to **Success**, **Failed** or **Cancelled**. +-- It all depends on the task goals, and the phase/evolution of the task conditions that would accomplish the goals. +-- For example, if the task goal is to merely destroy a target, and the target is mid-mission destroyed by another event than the pilot destroying the target, +-- the task goal could be set to **Failed**, or .. **Cancelled** ... +-- However, it could very well be also acceptable that the task would be flagged as **Success**. +-- +-- The tasking mechanism governs beside the progress also a scoring mechanism, and in case of goal completion without any active pilot involved +-- in the execution of the task, could result in a **Success** task completion status, but no score would be awared, as there were no players involved. +-- +-- ### 1.2. Task status events. +-- +-- The task statuses can be set by using the following methods: +-- +-- - @{#TASK.Success}() - Set the task to **Success** state. +-- - @{#TASK.Fail}() - Set the task to **Failed** state. +-- - @{#TASK.Hold}() - Set the task to **Hold** state. +-- - @{#TASK.Abort}() - Set the task to **Aborted** state, aborting the task. The task may be replanned. +-- - @{#TASK.Cancel}() - Set the task to **Cancelled** state, cancelling the task. +-- +-- The mentioned derived TASK_ classes are implementing the task status transitions out of the box. +-- So no extra logic needs to be written. -- --- ## 1.2) Set and enquire task status (beyond the task state machine processing). +-- ## 2. Goal conditions for a task. -- --- A task needs to implement as a minimum the following task states: +-- Every 30 seconds, a @{#Task.Goal} trigger method is fired. +-- You as a mission designer, can capture the **Goal** event trigger to check your own task goal conditions and take action! -- --- * **Success**: Expresses the successful execution and finalization of the task. --- * **Failed**: Expresses the failure of a task. --- * **Planned**: Expresses that the task is created, but not yet in execution and is not assigned yet. --- * **Assigned**: Expresses that the task is assigned to a Group of players, and that the task is in execution mode. +-- ### 2.1. Goal event handler `OnAfterGoal()`. -- --- A task may also implement the following task states: --- --- * **Rejected**: Expresses that the task is rejected by a player, who was requested to accept the task. --- * **Cancelled**: Expresses that the task is cancelled by HQ or through a logical situation where a cancellation of the task is required. --- --- A task can implement more statusses than the ones outlined above. Please consult the documentation of the specific tasks to understand the different status modelled. --- --- The status of tasks can be set by the methods **State** followed by the task status. An example is `StateAssigned()`. --- The status of tasks can be enquired by the methods **IsState** followed by the task status name. An example is `if IsStateAssigned() then`. +-- And this is a really great feature! Imagine a task which has **several conditions to check** before the task can move into **Success** state. +-- You can do this with the OnAfterGoal method. -- --- ## 1.3) Add scoring when reaching a certain task status: +-- The following code provides an example of such a goal condition check implementation. +-- +-- function Task:OnAfterGoal() +-- if condition == true then +-- self:Success() -- This will flag the task to Succcess when the condition is true. +-- else +-- if condition2 == true and condition3 == true then +-- self:Fail() -- This will flag the task to Failed, when condition2 and condition3 would be true. +-- end +-- end +-- end +-- +-- So the @{#TASK.OnAfterGoal}() event handler would be called every 30 seconds automatically, and within this method, you can now check the conditions and take respective action. +-- +-- ### 2.2. Goal event trigger `Goal()`. +-- +-- If you would need to check a goal at your own defined event timing, then just call the @{#TASK.Goal}() method within your logic. +-- The @{#TASK.OnAfterGoal}() event handler would then directly be called and would execute the logic. +-- Note that you can also delay the goal check by using the delayed event trigger syntax `:__Goal( Dalay )`. +-- +-- +-- ## 3) Add scoring when reaching a certain task status: -- -- Upon reaching a certain task status in a task, additional scoring can be given. If the Mission has a scoring system attached, the scores will be added to the mission scoring. -- Use the method @{#TASK.AddScore}() to add scores when a status is reached. diff --git a/Moose Development/Moose/Tasking/Task_A2A.lua b/Moose Development/Moose/Tasking/Task_A2A.lua index 5fb22050b..bd12b7e43 100644 --- a/Moose Development/Moose/Tasking/Task_A2A.lua +++ b/Moose Development/Moose/Tasking/Task_A2A.lua @@ -8,7 +8,7 @@ -- -- === -- --- @module Tasking.Tasking.Task_A2A +-- @module Tasking.Task_A2A -- @image MOOSE.JPG do -- TASK_A2A diff --git a/Moose Development/Moose/Tasking/Task_A2G.lua b/Moose Development/Moose/Tasking/Task_A2G.lua index 51294075d..637f1fdc4 100644 --- a/Moose Development/Moose/Tasking/Task_A2G.lua +++ b/Moose Development/Moose/Tasking/Task_A2G.lua @@ -457,7 +457,7 @@ do -- TASK_A2G_BAI -- @field Core.Set#SET_UNIT TargetSetUnit -- @extends Tasking.Task#TASK - -- Defines an Battlefield Air Interdiction task for a human player to be executed. + --- Defines a Battlefield Air Interdiction task for a human player to be executed. -- These tasks are more strategic in nature and are most of the time further away from friendly forces. -- BAI tasks can also be used to express the abscence of friendly forces near the vicinity. -- @@ -551,7 +551,7 @@ do -- TASK_A2G_CAS -- @field Core.Set#SET_UNIT TargetSetUnit -- @extends Tasking.Task#TASK - -- Defines an Close Air Support task for a human player to be executed. + --- Defines an Close Air Support task for a human player to be executed. -- Friendly forces will be in the vicinity within 6km from the enemy. -- -- The TASK_A2G_CAS is used by the @{Tasking.Task_A2G_Dispatcher#TASK_A2G_DISPATCHER} to automatically create CAS tasks diff --git a/Moose Development/Moose/Tasking/Task_CARGO.lua b/Moose Development/Moose/Tasking/Task_CARGO.lua index cdcaca1f7..b10e9e1ab 100644 --- a/Moose Development/Moose/Tasking/Task_CARGO.lua +++ b/Moose Development/Moose/Tasking/Task_CARGO.lua @@ -44,10 +44,10 @@ do -- TASK_CARGO -- ## 2. Task execution experience from the player perspective -- -- A human player can join the battle field in a client airborne slot or a ground vehicle within the CA module (ALT-J). - -- The player needs to accept the task from the task overview list within the mission, using the radio menus. + -- The player needs to accept the task from the task overview list within the mission, using the menus. -- -- Once the TASK_CARGO is assigned to the player and accepted by the player, the player will obtain - -- an extra **Cargo Handling Radio Menu** that contains the CARGO objects that need to be transported. + -- an extra **Cargo (Radio) Menu** that contains the CARGO objects that need to be transported. -- -- Each CARGO object has a certain state: -- @@ -56,9 +56,9 @@ do -- TASK_CARGO -- * **Boarding**: The CARGO is running or moving towards your Carrier for loading. -- * **UnBoarding**: The CARGO is driving or jumping out of your Carrier and moves to a location in the Deployment Zone. -- - -- Cargo must be transported towards different **Deployment @{Zone}s**. + -- Cargo must be transported towards different Deployment @{Zone}s. -- - -- The Cargo Handling Radio Menu system allows to execute **various actions** to handle the cargo. + -- The Cargo Menu system allows to execute **various actions** to transport the cargo. -- In the menu, you'll find for each CARGO, that is part of the scope of the task, various actions that can be completed. -- Depending on the location of your Carrier unit, the menu options will vary. -- @@ -86,7 +86,7 @@ do -- TASK_CARGO -- -- ### 2.2. Task Action Menu. -- - -- When a player has joined a task, for that player only, it's carrier radio menu will show an additional menu option. + -- When a player has joined a task, for that player only, it's carrier Menu will show an additional menu option. -- It has the name of the task you currently joined and @ player name. -- -- ![Task_Types](../Tasking/Task_Briefing.JPG). @@ -116,7 +116,7 @@ do -- TASK_CARGO -- -- - **Loading**: Stationary cargo (like crates), which are heavy, can only be loaded or sling loaded, meaning, -- your carrier must be close enough to the cargo to be able to load the cargo within the carrier bays. - -- Moose provides you with an additional menu system to load stationary cargo into your carrier bays using the radio menu. + -- Moose provides you with an additional menu system to load stationary cargo into your carrier bays using the menu. -- These menu options will become available, when the carrier is within loading range. -- The Moose cargo will report to the carrier when the range is close enough. The load range is set by the mission designer. -- @@ -147,7 +147,7 @@ do -- TASK_CARGO -- -- The routing messages are formulated in the coordinate format that is currently active as configured in your settings profile. -- ![Task_Types](../Tasking/Task_Cargo_Settings.JPG) - -- Use the Settings Menu to select the coordinate format that you would like to use for location determination. + -- Use the **Settings Menu** to select the coordinate format that you would like to use for location determination. -- -- -- #### 2.3.1. Pickup Cargo. @@ -210,11 +210,11 @@ do -- TASK_CARGO -- - **Unboarding**: Moveable cargo (like infantry or vehicles), can be unboarded, that means, -- the cargo will step out of the carrier and will run to a group location. -- Moose provides you with an additional menu system to unload stationary cargo from the carrier bays, - -- using the radio menu. These menu options will become available, when the carrier is within the deploy zone. + -- using the menu. These menu options will become available, when the carrier is within the deploy zone. -- -- - **Unloading**: Stationary cargo (like crates), which are heavy, can only be unloaded or sling loaded. -- Moose provides you with an additional menu system to unload stationary cargo from the carrier bays, - -- using the radio menu. These menu options will become available, when the carrier is within the deploy zone. + -- using the menu. These menu options will become available, when the carrier is within the deploy zone. -- -- - **Sling Deploying**: Stationary cargo (like crates), which are heavy, can also be sling deployed. -- Once the cargo is within the deploy zone, the cargo can be deployed from the sling onto the ground. @@ -235,12 +235,12 @@ do -- TASK_CARGO -- -- The routing messages are formulated in the coordinate format that is currently active as configured in your settings profile. -- ![Task_Types](../Tasking/Task_Cargo_Settings.JPG) - -- Use the Settings Menu to select the coordinate format that you would like to use for location determination. + -- Use the **Settings Menu** to select the coordinate format that you would like to use for location determination. -- -- ### 2.4. Deploy Cargo. -- -- Various Deployment Zones can be foreseen in the scope of the Cargo transportation. Each deployment zone can be of varying @{Zone} type. - -- The Cargo Handling Radio Menu provides with menu options to execute an action to steer your Carrier to a specific Zone. + -- The Cargo menu provides with menu options to execute an action to steer your Carrier to a specific Zone. -- -- In order to deploy cargo, use the task action menu to select a cargo to route to. -- When selected, the HQ will send you routing messages indicating the location of the deploy zone. @@ -285,7 +285,7 @@ do -- TASK_CARGO -- -- ### Specific TASK_CARGO Events -- - -- Specific Cargo Handling event can be captured, that allow to trigger specific actions! + -- Specific Cargo event can be captured, that allow to trigger specific actions! -- -- * **Boarded**: Triggered when the Cargo has been Boarded into your Carrier. -- * **UnBoarded**: Triggered when the cargo has been Unboarded from your Carrier and has arrived at the Deployment Zone.