diff --git a/Moose Development/Moose/Core/Event.lua b/Moose Development/Moose/Core/Event.lua index cd5a3a24c..5a390985e 100644 --- a/Moose Development/Moose/Core/Event.lua +++ b/Moose Development/Moose/Core/Event.lua @@ -1,27 +1,155 @@ ---- This module contains the **EVENT** class, which models the dispatching of DCS Events to subscribed MOOSE classes, +--- This core module models the dispatching of DCS Events to subscribed MOOSE classes, -- following a given priority. -- --- ## --- --- ![Banner Image](..\Presentations\FSM\Dia1.JPG) +-- ![Banner Image](..\Presentations\EVENT\Dia1.JPG) -- -- === -- ---- This module contains the EVENT class. +-- # 1) Event Handling Overview +-- +-- ![Objects](..\Presentations\EVENT\Dia2.JPG) +-- +-- Within a running mission, various DCS events occur. Units are dynamically created, crash, die, shoot stuff, get hit etc. +-- This module provides a mechanism to dispatch those events occuring within your running mission, to the different objects orchestrating your mission. +-- +-- ![Objects](..\Presentations\EVENT\Dia3.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia4.JPG) +-- +-- The _EVENTDISPATCHER object is automatically created within MOOSE, +-- and handles the dispatching of DCS Events occurring +-- in the simulator to the subscribed objects +-- in the correct processing order. +-- +-- ![Objects](..\Presentations\EVENT\Dia5.JPG) +-- +-- There are 5 levels of kind 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. +-- * 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. +-- +-- ![Objects](..\Presentations\EVENT\Dia6.JPG) +-- +-- For most DCS events, the above order of updating will be followed.1 +-- +-- ![Objects](..\Presentations\EVENT\Dia7.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia8.JPG) +-- +-- The actual event subscribing and handling is not facilitated through the _EVENTDISPATCHER, but it is done through the @{BASE} class, @{UNIT} class and @{GROUP} class. +-- The _EVENTDISPATCHER is a component that is quietly working in the background of MOOSE. +-- +-- ![Objects](..\Presentations\EVENT\Dia9.JPG) +-- +-- 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 +-- +-- 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. +-- There are two functions which you use to subscribe to or unsubscribe from an event. +-- +-- * @{Base#BASE.HandleEvent}(): Subscribe to a DCS Event. +-- * @{Base#BASE.UnHandleEvent}(): Unsubscribe from a DCS Event. +-- +-- ### 1.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 @{Event#EVENTDATA} structure, which contains a lot of information +-- about the event that occurred. +-- +-- Find below an example of the prototype how to write an event handling function for two units: +-- +-- local Tank1 = UNIT:FindByName( "Tank A" ) +-- local Tank2 = UNIT:FindByName( "Tank B" ) +-- +-- -- Here we subscribe to the Dead events. So, if one of these tanks dies, the Tank1 or Tank2 objects will be notified. +-- Tank1:HandleEvent( EVENTS.Dead ) +-- Tank2:HandleEvent( EVENTS.Dead ) +-- +-- --- This function is an Event Handling function that will be called when Tank1 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank1:OnEventDead( EventData ) +-- +-- self:SmokeGreen() +-- end +-- +-- --- This function is an Event Handling function that will be called when Tank2 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank2:OnEventDead( EventData ) +-- +-- self:SmokeBlue() +-- end +-- +-- ### 1.3.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 +-- +-- The EVENTS structure contains names for all the different DCS events that objects can subscribe to using the +-- @{Base#BASE.HandleEvent}() method. +-- +-- # 3) EVENTDATA type +-- +-- The EVENTDATA contains all the fields that are populated with event information before +-- an Event Handler method is being called by the event dispatcher. +-- The Event Handler received the EVENTDATA object as a parameter, and can be used to investigate further the different events. +-- There are basically 4 main categories of information stored in the EVENTDATA structure: +-- +-- * Initiator Unit data: Several fields documenting the initiator unit related to the event. +-- * Target Unit data: Several fields documenting the target unit related to the event. +-- * Weapon data: Certain events populate weapon information. +-- * Place data: Certain events populate place information. +-- +-- Find below an overview which events populate which information categories: +-- +-- ![Objects](..\Presentations\EVENT\Dia14.JPG) +-- +-- ==== +-- +-- # **API CHANGE HISTORY** +-- +-- The underlying change log documents the API changes. Please read this carefully. The following notation is used: +-- +-- * **Added** parts are expressed in bold type face. +-- * _Removed_ parts are expressed in italic type face. +-- +-- YYYY-MM-DD: CLASS:**NewFunction**( Params ) replaces CLASS:_OldFunction_( Params ) +-- YYYY-MM-DD: CLASS:**NewFunction( Params )** added +-- +-- Hereby the change log: +-- +-- * 2016-02-07: Did a complete revision of the Event Handing API and underlying mechanisms. -- -- === -- --- Takes care of EVENT dispatching between DCS events and event handling functions defined in MOOSE classes. +-- # **AUTHORS and CONTRIBUTIONS** -- --- === +-- ### Contributions: -- --- The above menus classes **are derived** from 2 main **abstract** classes defined within the MOOSE framework (so don't use these): --- --- === --- --- ### Contributions: - --- ### Authors: FlightControl : Design & Programming +-- ### Authors: -- +-- * [**FlightControl**](https://forums.eagle.ru/member.php?u=89536): Design & Programming & documentation. +-- -- @module Event --- The EVENT structure @@ -33,6 +161,9 @@ EVENT = { ClassID = 0, } +--- The different types of events supported by MOOSE. +-- Use this structure to subscribe to events using the @{Base#BASE.HandleEvent}() method. +-- @type EVENTS EVENTS = { Shot = world.event.S_EVENT_SHOT, Hit = world.event.S_EVENT_HIT, @@ -59,6 +190,28 @@ EVENTS = { ShootingEnd = world.event.S_EVENT_SHOOTING_END, } +--- The Event structure +-- @type EVENTDATA +-- @field id +-- @field initiator +-- @field target +-- @field weapon +-- @field IniDCSUnit +-- @field IniDCSUnitName +-- @field Wrapper.Unit#UNIT IniUnit +-- @field #string IniUnitName +-- @field IniDCSGroup +-- @field IniDCSGroupName +-- @field TgtDCSUnit +-- @field TgtDCSUnitName +-- @field Wrapper.Unit#UNIT TgtUnit +-- @field #string TgtUnitName +-- @field TgtDCSGroup +-- @field TgtDCSGroupName +-- @field Weapon +-- @field WeaponName +-- @field WeaponTgtDCSUnit + local _EVENTMETA = { [world.event.S_EVENT_SHOT] = { @@ -178,27 +331,6 @@ local _EVENTMETA = { }, } ---- The Event structure --- @type EVENTDATA --- @field id --- @field initiator --- @field target --- @field weapon --- @field IniDCSUnit --- @field IniDCSUnitName --- @field Wrapper.Unit#UNIT IniUnit --- @field #string IniUnitName --- @field IniDCSGroup --- @field IniDCSGroupName --- @field TgtDCSUnit --- @field TgtDCSUnitName --- @field Wrapper.Unit#UNIT TgtUnit --- @field #string TgtUnitName --- @field TgtDCSGroup --- @field TgtDCSGroupName --- @field Weapon --- @field WeaponName --- @field WeaponTgtDCSUnit --- The Events structure -- @type EVENT.Events diff --git a/Moose Development/Moose/Functional/AirbasePolice.lua b/Moose Development/Moose/Functional/AirbasePolice.lua index e0b14d61b..1afb020ac 100644 --- a/Moose Development/Moose/Functional/AirbasePolice.lua +++ b/Moose Development/Moose/Functional/AirbasePolice.lua @@ -183,6 +183,7 @@ function AIRBASEPOLICE_BASE:_AirbaseMonitor() else MESSAGE:New( "Player " .. Client:GetPlayerName() .. " has been removed from the airbase, due to a speeding violation ...", 10, "Airbase Police" ):ToAll() Client:Destroy() + trigger.action.setUserFlag( "AIRCRAFT_"..Client:GetID(), 100) Client:SetState( self, "Speeding", false ) Client:SetState( self, "Warnings", 0 ) end diff --git a/Moose Mission Setup/Moose Mission Update/l10n/DEFAULT/Moose.lua b/Moose Mission Setup/Moose Mission Update/l10n/DEFAULT/Moose.lua index 748b52623..b815a4a93 100644 --- a/Moose Mission Setup/Moose Mission Update/l10n/DEFAULT/Moose.lua +++ b/Moose Mission Setup/Moose Mission Update/l10n/DEFAULT/Moose.lua @@ -1,5 +1,5 @@ env.info( '*** MOOSE STATIC INCLUDE START *** ' ) -env.info( 'Moose Generation Timestamp: 20170207_1336' ) +env.info( 'Moose Generation Timestamp: 20170207_1733' ) local base = _G Include = {} @@ -4019,22 +4019,114 @@ end ---- This module contains the **EVENT** class, which models the dispatching of DCS Events to subscribed MOOSE classes, +--- This core module models the dispatching of DCS Events to subscribed MOOSE classes, -- following a given priority. -- --- ## --- --- ![Banner Image](..\Presentations\FSM\Dia1.JPG) +-- ![Banner Image](..\Presentations\EVENT\Dia1.JPG) -- -- === -- ---- This module contains the EVENT class. +-- # 1) Event Handling Overview -- --- === +-- ![Objects](..\Presentations\EVENT\Dia2.JPG) -- --- Takes care of EVENT dispatching between DCS events and event handling functions defined in MOOSE classes. +-- Within a running mission, various DCS events occur. Units are dynamically created, crash, die, shoot stuff, get hit etc. +-- This module provides a mechanism to dispatch those events occuring within your running mission, to the different objects orchestrating your mission. -- --- === +-- ![Objects](..\Presentations\EVENT\Dia3.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia4.JPG) +-- +-- The _EVENTDISPATCHER object is automatically created within MOOSE, +-- and handles the dispatching of DCS Events occurring +-- in the simulator to the subscribed objects +-- in the correct processing order. +-- +-- ![Objects](..\Presentations\EVENT\Dia5.JPG) +-- +-- There are 5 levels of kind 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. +-- * 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. +-- +-- ![Objects](..\Presentations\EVENT\Dia6.JPG) +-- +-- For most DCS events, the above order of updating will be followed.1 +-- +-- ![Objects](..\Presentations\EVENT\Dia7.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia8.JPG) +-- +-- The actual event subscribing and handling is not facilitated through the _EVENTDISPATCHER, but it is done through the @{BASE} class, @{UNIT} class and @{GROUP} class. +-- The _EVENTDISPATCHER is a component that is quietly working in the background of MOOSE. +-- +-- ![Objects](..\Presentations\EVENT\Dia9.JPG) +-- +-- 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 +-- +-- 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. +-- There are two functions which you use to subscribe to or unsubscribe from an event. +-- +-- * @{Base#BASE.HandleEvent}(): Subscribe to a DCS Event. +-- * @{Base#BASE.UnHandleEvent}(): Unsubscribe from a DCS Event. +-- +-- ### 1.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 @{Event#EVENTDATA} structure, which contains a lot of information +-- about the event that occurred. +-- +-- Find below an example of the prototype how to write an event handling function for two units: +-- +-- local Tank1 = UNIT:FindByName( "Tank A" ) +-- local Tank2 = UNIT:FindByName( "Tank B" ) +-- +-- -- Here we subscribe to the Dead events. So, if one of these tanks dies, the Tank1 or Tank2 objects will be notified. +-- Tank1:HandleEvent( EVENTS.Dead ) +-- Tank2:HandleEvent( EVENTS.Dead ) +-- +-- --- This function is an Event Handling function that will be called when Tank1 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank1:OnEventDead( EventData ) +-- +-- self:SmokeGreen() +-- end +-- +-- --- This function is an Event Handling function that will be called when Tank2 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank2:OnEventDead( EventData ) +-- +-- self:SmokeBlue() +-- end +-- +-- ### 1.3.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: +-- +-- First Header | Second Header +-- ------------ | ------------- +-- Content from cell 1 | Content from cell 2 +-- Content in the first column | Content in the second column -- -- The above menus classes **are derived** from 2 main **abstract** classes defined within the MOOSE framework (so don't use these): -- @@ -22526,6 +22618,7 @@ function AIRBASEPOLICE_BASE:_AirbaseMonitor() else MESSAGE:New( "Player " .. Client:GetPlayerName() .. " has been removed from the airbase, due to a speeding violation ...", 10, "Airbase Police" ):ToAll() Client:Destroy() + trigger.action.setUserFlag( "AIRCRAFT_"..Client:GetID(), 100) Client:SetState( self, "Speeding", false ) Client:SetState( self, "Warnings", 0 ) end diff --git a/Moose Mission Setup/Moose.lua b/Moose Mission Setup/Moose.lua index 748b52623..b815a4a93 100644 --- a/Moose Mission Setup/Moose.lua +++ b/Moose Mission Setup/Moose.lua @@ -1,5 +1,5 @@ env.info( '*** MOOSE STATIC INCLUDE START *** ' ) -env.info( 'Moose Generation Timestamp: 20170207_1336' ) +env.info( 'Moose Generation Timestamp: 20170207_1733' ) local base = _G Include = {} @@ -4019,22 +4019,114 @@ end ---- This module contains the **EVENT** class, which models the dispatching of DCS Events to subscribed MOOSE classes, +--- This core module models the dispatching of DCS Events to subscribed MOOSE classes, -- following a given priority. -- --- ## --- --- ![Banner Image](..\Presentations\FSM\Dia1.JPG) +-- ![Banner Image](..\Presentations\EVENT\Dia1.JPG) -- -- === -- ---- This module contains the EVENT class. +-- # 1) Event Handling Overview -- --- === +-- ![Objects](..\Presentations\EVENT\Dia2.JPG) -- --- Takes care of EVENT dispatching between DCS events and event handling functions defined in MOOSE classes. +-- Within a running mission, various DCS events occur. Units are dynamically created, crash, die, shoot stuff, get hit etc. +-- This module provides a mechanism to dispatch those events occuring within your running mission, to the different objects orchestrating your mission. -- --- === +-- ![Objects](..\Presentations\EVENT\Dia3.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia4.JPG) +-- +-- The _EVENTDISPATCHER object is automatically created within MOOSE, +-- and handles the dispatching of DCS Events occurring +-- in the simulator to the subscribed objects +-- in the correct processing order. +-- +-- ![Objects](..\Presentations\EVENT\Dia5.JPG) +-- +-- There are 5 levels of kind 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. +-- * 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. +-- +-- ![Objects](..\Presentations\EVENT\Dia6.JPG) +-- +-- For most DCS events, the above order of updating will be followed.1 +-- +-- ![Objects](..\Presentations\EVENT\Dia7.JPG) +-- +-- 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 +-- +-- ![Objects](..\Presentations\EVENT\Dia8.JPG) +-- +-- The actual event subscribing and handling is not facilitated through the _EVENTDISPATCHER, but it is done through the @{BASE} class, @{UNIT} class and @{GROUP} class. +-- The _EVENTDISPATCHER is a component that is quietly working in the background of MOOSE. +-- +-- ![Objects](..\Presentations\EVENT\Dia9.JPG) +-- +-- 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 +-- +-- 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. +-- There are two functions which you use to subscribe to or unsubscribe from an event. +-- +-- * @{Base#BASE.HandleEvent}(): Subscribe to a DCS Event. +-- * @{Base#BASE.UnHandleEvent}(): Unsubscribe from a DCS Event. +-- +-- ### 1.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 @{Event#EVENTDATA} structure, which contains a lot of information +-- about the event that occurred. +-- +-- Find below an example of the prototype how to write an event handling function for two units: +-- +-- local Tank1 = UNIT:FindByName( "Tank A" ) +-- local Tank2 = UNIT:FindByName( "Tank B" ) +-- +-- -- Here we subscribe to the Dead events. So, if one of these tanks dies, the Tank1 or Tank2 objects will be notified. +-- Tank1:HandleEvent( EVENTS.Dead ) +-- Tank2:HandleEvent( EVENTS.Dead ) +-- +-- --- This function is an Event Handling function that will be called when Tank1 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank1:OnEventDead( EventData ) +-- +-- self:SmokeGreen() +-- end +-- +-- --- This function is an Event Handling function that will be called when Tank2 is Dead. +-- -- @param Wrapper.Unit#UNIT self +-- -- @param Core.Event#EVENTDATA EventData +-- function Tank2:OnEventDead( EventData ) +-- +-- self:SmokeBlue() +-- end +-- +-- ### 1.3.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: +-- +-- First Header | Second Header +-- ------------ | ------------- +-- Content from cell 1 | Content from cell 2 +-- Content in the first column | Content in the second column -- -- The above menus classes **are derived** from 2 main **abstract** classes defined within the MOOSE framework (so don't use these): -- @@ -22526,6 +22618,7 @@ function AIRBASEPOLICE_BASE:_AirbaseMonitor() else MESSAGE:New( "Player " .. Client:GetPlayerName() .. " has been removed from the airbase, due to a speeding violation ...", 10, "Airbase Police" ):ToAll() Client:Destroy() + trigger.action.setUserFlag( "AIRCRAFT_"..Client:GetID(), 100) Client:SetState( self, "Speeding", false ) Client:SetState( self, "Warnings", 0 ) end diff --git a/Moose Test Missions/ABP - Airbase Police/APL-001 - Caucasus/APL-001 - Caucasus.miz b/Moose Test Missions/ABP - Airbase Police/APL-001 - Caucasus/APL-001 - Caucasus.miz index 4cd1a6d4b..1784d8f8b 100644 Binary files a/Moose Test Missions/ABP - Airbase Police/APL-001 - Caucasus/APL-001 - Caucasus.miz and b/Moose Test Missions/ABP - Airbase Police/APL-001 - Caucasus/APL-001 - Caucasus.miz differ diff --git a/Moose Test Missions/ABP - Airbase Police/APL-002 - Nevada/APL-002 - Nevada.miz b/Moose Test Missions/ABP - Airbase Police/APL-002 - Nevada/APL-002 - Nevada.miz index 4a1f6140f..0d8a7f3c3 100644 Binary files a/Moose Test Missions/ABP - Airbase Police/APL-002 - Nevada/APL-002 - Nevada.miz and b/Moose Test Missions/ABP - Airbase Police/APL-002 - Nevada/APL-002 - Nevada.miz differ diff --git a/docs/Documentation/AI_Patrol.html b/docs/Documentation/AI_Patrol.html index c2d613229..cfd08e72f 100644 --- a/docs/Documentation/AI_Patrol.html +++ b/docs/Documentation/AI_Patrol.html @@ -880,6 +880,9 @@ Use the method AIPATROLZONE.M + +

This table contains the targets detected during patrol.

+
diff --git a/docs/Documentation/Event.html b/docs/Documentation/Event.html index c37b270e2..2990127f4 100644 --- a/docs/Documentation/Event.html +++ b/docs/Documentation/Event.html @@ -71,33 +71,172 @@

Module Event

-

This module contains the EVENT class, which models the dispatching of DCS Events to subscribed MOOSE classes, +

This core module models the dispatching of DCS Events to subscribed MOOSE classes, following a given priority.

-

- -

Banner Image

+

Banner Image

+

1) Event Handling Overview

+ +

Objects

+ +

Within a running mission, various DCS events occur. Units are dynamically created, crash, die, shoot stuff, get hit etc. +This module provides a mechanism to dispatch those events occuring within your running mission, to the different objects orchestrating your mission.

+ +

Objects

+ +

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

+ +

Objects

+ +

The _EVENTDISPATCHER object is automatically created within MOOSE, +and handles the dispatching of DCS Events occurring +in the simulator to the subscribed objects +in the correct processing order.

+ +

Objects

+ +

There are 5 levels of kind of objects that the _EVENTDISPATCHER services:

+
    -
  • This module contains the EVENT class.
    • +
  • _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.
    • +
  • 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.
    • +
+ +

Objects

+ +

For most DCS events, the above order of updating will be followed.1

+ +

Objects

+ +

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

+ +

Objects

+ +

The actual event subscribing and handling is not facilitated through the _EVENTDISPATCHER, but it is done through the BASE class, UNIT class and GROUP class. +The _EVENTDISPATCHER is a component that is quietly working in the background of MOOSE.

+ +

Objects

+ +

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

+ +

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. +There are two functions which you use to subscribe to or unsubscribe from an event.

+ + + +

1.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 Event#EVENTDATA structure, which contains a lot of information +about the event that occurred.

+ +

Find below an example of the prototype how to write an event handling function for two units:

+ +
 local Tank1 = UNIT:FindByName( "Tank A" )
+ local Tank2 = UNIT:FindByName( "Tank B" )
+
+ -- Here we subscribe to the Dead events. So, if one of these tanks dies, the Tank1 or Tank2 objects will be notified.
+ Tank1:HandleEvent( EVENTS.Dead )
+ Tank2:HandleEvent( EVENTS.Dead )
+
+ --- This function is an Event Handling function that will be called when Tank1 is Dead.
+ -- @param Wrapper.Unit#UNIT self 
+ -- @param Core.Event#EVENTDATA EventData
+ function Tank1:OnEventDead( EventData )
+
+   self:SmokeGreen()
+ end
+
+ --- This function is an Event Handling function that will be called when Tank2 is Dead.
+ -- @param Wrapper.Unit#UNIT self 
+ -- @param Core.Event#EVENTDATA EventData
+ function Tank2:OnEventDead( EventData )
+
+   self:SmokeBlue()
+ end
+
+ +

1.3.3 Event Handling methods that are automatically called upon subscribed DCS events

+ +

Objects

+ +

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

+ +

The EVENTS structure contains names for all the different DCS events that objects can subscribe to using the +Base#BASE.HandleEvent() method.

+ +

3) EVENTDATA type

+ +

The EVENTDATA contains all the fields that are populated with event information before +an Event Handler method is being called by the event dispatcher. +The Event Handler received the EVENTDATA object as a parameter, and can be used to investigate further the different events. +There are basically 4 main categories of information stored in the EVENTDATA structure:

+ + + +

Find below an overview which events populate which information categories:

+ +

Objects

+ +
+ +

API CHANGE HISTORY

+ +

The underlying change log documents the API changes. Please read this carefully. The following notation is used:

+ + + +

YYYY-MM-DD: CLASS:NewFunction( Params ) replaces CLASS:OldFunction( Params ) +YYYY-MM-DD: CLASS:NewFunction( Params ) added

+ +

Hereby the change log:

+ +
-

Takes care of EVENT dispatching between DCS events and event handling functions defined in MOOSE classes.

+

AUTHORS and CONTRIBUTIONS

-
+

Contributions:

-

The above menus classes are derived from 2 main abstract classes defined within the MOOSE framework (so don't use these):

+

Authors:

-
- -

Contributions: -

-

Authors: FlightControl : Design & Programming

+

Global(s)

@@ -543,6 +682,148 @@ following a given priority.

EVENTDATA.weapon + + + + +

Type EVENTS

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EVENTS.BaseCaptured + +
EVENTS.Birth + +
EVENTS.Crash + +
EVENTS.Dead + +
EVENTS.Ejection + +
EVENTS.EngineShutdown + +
EVENTS.EngineStartup + +
EVENTS.Hit + +
EVENTS.HumanFailure + +
EVENTS.Land + +
EVENTS.MissionEnd + +
EVENTS.MissionStart + +
EVENTS.PilotDead + +
EVENTS.PlayerComment + +
EVENTS.PlayerEnterUnit + +
EVENTS.PlayerLeaveUnit + +
EVENTS.Refueling + +
EVENTS.RefuelingStop + +
EVENTS.ShootingEnd + +
EVENTS.ShootingStart + +
EVENTS.Shot + +
EVENTS.Takeoff + +
EVENTS.TookControl +
@@ -565,7 +846,7 @@ following a given priority.

- + #EVENTS EVENTS @@ -2381,6 +2662,337 @@ The self instance of the class for which the event is.

+ +
+ +

Type EVENTS

+ +

The different types of events supported by MOOSE.

+ + +

Use this structure to subscribe to events using the Base#BASE.HandleEvent() method.

+ +

Field(s)

+
+
+ + + +EVENTS.BaseCaptured + +
+
+ + + +
+
+
+
+ + + +EVENTS.Birth + +
+
+ + + +
+
+
+
+ + + +EVENTS.Crash + +
+
+ + + +
+
+
+
+ + + +EVENTS.Dead + +
+
+ + + +
+
+
+
+ + + +EVENTS.Ejection + +
+
+ + + +
+
+
+
+ + + +EVENTS.EngineShutdown + +
+
+ + + +
+
+
+
+ + + +EVENTS.EngineStartup + +
+
+ + + +
+
+
+
+ + + +EVENTS.Hit + +
+
+ + + +
+
+
+
+ + + +EVENTS.HumanFailure + +
+
+ + + +
+
+
+
+ + + +EVENTS.Land + +
+
+ + + +
+
+
+
+ + + +EVENTS.MissionEnd + +
+
+ + + +
+
+
+
+ + + +EVENTS.MissionStart + +
+
+ + + +
+
+
+
+ + + +EVENTS.PilotDead + +
+
+ + + +
+
+
+
+ + + +EVENTS.PlayerComment + +
+
+ + + +
+
+
+
+ + + +EVENTS.PlayerEnterUnit + +
+
+ + + +
+
+
+
+ + + +EVENTS.PlayerLeaveUnit + +
+
+ + + +
+
+
+
+ + + +EVENTS.Refueling + +
+
+ + + +
+
+
+
+ + + +EVENTS.RefuelingStop + +
+
+ + + +
+
+
+
+ + + +EVENTS.ShootingEnd + +
+
+ + + +
+
+
+
+ + + +EVENTS.ShootingStart + +
+
+ + + +
+
+
+
+ + + +EVENTS.Shot + +
+
+ + + +
+
+
+
+ + + +EVENTS.Takeoff + +
+
+ + + +
+
+
+
+ + + +EVENTS.TookControl + +
+
+ + +
diff --git a/docs/Documentation/index.html b/docs/Documentation/index.html index b9f027a75..f618bb44d 100644 --- a/docs/Documentation/index.html +++ b/docs/Documentation/index.html @@ -231,7 +231,7 @@ and automatically engage any airborne enemies that are within a certain range or Event -

This module contains the EVENT class, which models the dispatching of DCS Events to subscribed MOOSE classes, +

This core module models the dispatching of DCS Events to subscribed MOOSE classes, following a given priority.

diff --git a/docs/Presentations/EVENT.pptx b/docs/Presentations/EVENT.pptx new file mode 100644 index 000000000..5ae8628cb Binary files /dev/null and b/docs/Presentations/EVENT.pptx differ diff --git a/docs/Presentations/EVENT/Dia1.JPG b/docs/Presentations/EVENT/Dia1.JPG new file mode 100644 index 000000000..2621f5880 Binary files /dev/null and b/docs/Presentations/EVENT/Dia1.JPG differ diff --git a/docs/Presentations/EVENT/Dia10.JPG b/docs/Presentations/EVENT/Dia10.JPG new file mode 100644 index 000000000..1bba3324c Binary files /dev/null and b/docs/Presentations/EVENT/Dia10.JPG differ diff --git a/docs/Presentations/EVENT/Dia11.JPG b/docs/Presentations/EVENT/Dia11.JPG new file mode 100644 index 000000000..9a54dbe58 Binary files /dev/null and b/docs/Presentations/EVENT/Dia11.JPG differ diff --git a/docs/Presentations/EVENT/Dia12.JPG b/docs/Presentations/EVENT/Dia12.JPG new file mode 100644 index 000000000..c5d44cb5a Binary files /dev/null and b/docs/Presentations/EVENT/Dia12.JPG differ diff --git a/docs/Presentations/EVENT/Dia13.JPG b/docs/Presentations/EVENT/Dia13.JPG new file mode 100644 index 000000000..a9527b996 Binary files /dev/null and b/docs/Presentations/EVENT/Dia13.JPG differ diff --git a/docs/Presentations/EVENT/Dia14.JPG b/docs/Presentations/EVENT/Dia14.JPG new file mode 100644 index 000000000..46773eef0 Binary files /dev/null and b/docs/Presentations/EVENT/Dia14.JPG differ diff --git a/docs/Presentations/EVENT/Dia15.JPG b/docs/Presentations/EVENT/Dia15.JPG new file mode 100644 index 000000000..430bf4cd8 Binary files /dev/null and b/docs/Presentations/EVENT/Dia15.JPG differ diff --git a/docs/Presentations/EVENT/Dia16.JPG b/docs/Presentations/EVENT/Dia16.JPG new file mode 100644 index 000000000..8290075f6 Binary files /dev/null and b/docs/Presentations/EVENT/Dia16.JPG differ diff --git a/docs/Presentations/EVENT/Dia17.JPG b/docs/Presentations/EVENT/Dia17.JPG new file mode 100644 index 000000000..340e62c88 Binary files /dev/null and b/docs/Presentations/EVENT/Dia17.JPG differ diff --git a/docs/Presentations/EVENT/Dia18.JPG b/docs/Presentations/EVENT/Dia18.JPG new file mode 100644 index 000000000..3e2df6692 Binary files /dev/null and b/docs/Presentations/EVENT/Dia18.JPG differ diff --git a/docs/Presentations/EVENT/Dia2.JPG b/docs/Presentations/EVENT/Dia2.JPG new file mode 100644 index 000000000..55116b7a4 Binary files /dev/null and b/docs/Presentations/EVENT/Dia2.JPG differ diff --git a/docs/Presentations/EVENT/Dia3.JPG b/docs/Presentations/EVENT/Dia3.JPG new file mode 100644 index 000000000..4cb2ee9a3 Binary files /dev/null and b/docs/Presentations/EVENT/Dia3.JPG differ diff --git a/docs/Presentations/EVENT/Dia4.JPG b/docs/Presentations/EVENT/Dia4.JPG new file mode 100644 index 000000000..23ff25bba Binary files /dev/null and b/docs/Presentations/EVENT/Dia4.JPG differ diff --git a/docs/Presentations/EVENT/Dia5.JPG b/docs/Presentations/EVENT/Dia5.JPG new file mode 100644 index 000000000..f81a00aa2 Binary files /dev/null and b/docs/Presentations/EVENT/Dia5.JPG differ diff --git a/docs/Presentations/EVENT/Dia6.JPG b/docs/Presentations/EVENT/Dia6.JPG new file mode 100644 index 000000000..77cb3930d Binary files /dev/null and b/docs/Presentations/EVENT/Dia6.JPG differ diff --git a/docs/Presentations/EVENT/Dia7.JPG b/docs/Presentations/EVENT/Dia7.JPG new file mode 100644 index 000000000..d55b937c9 Binary files /dev/null and b/docs/Presentations/EVENT/Dia7.JPG differ diff --git a/docs/Presentations/EVENT/Dia8.JPG b/docs/Presentations/EVENT/Dia8.JPG new file mode 100644 index 000000000..16b16bec1 Binary files /dev/null and b/docs/Presentations/EVENT/Dia8.JPG differ diff --git a/docs/Presentations/EVENT/Dia9.JPG b/docs/Presentations/EVENT/Dia9.JPG new file mode 100644 index 000000000..2ac82a4b6 Binary files /dev/null and b/docs/Presentations/EVENT/Dia9.JPG differ