mirror of
https://github.com/FlightControl-Master/MOOSE.git
synced 2025-10-29 16:58:06 +00:00
Documentation improvements
This commit is contained in:
Van De Velde
parent
16b279c5db
commit
ea89c6255b
@ -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.
|
||||
|
||||
@ -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 = "",
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
--
|
||||
-- ===
|
||||
--
|
||||
-- @module Tasking.Tasking.Task_A2A
|
||||
-- @module Tasking.Task_A2A
|
||||
-- @image MOOSE.JPG
|
||||
|
||||
do -- TASK_A2A
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
--
|
||||
-- .
|
||||
@ -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.
|
||||
-- 
|
||||
-- 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.
|
||||
-- 
|
||||
-- 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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user