PMC Editing Wiki

User Tools

Site Tools

Trace:
arma:config:xeh

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
arma:config:xeh [2010/07/12 08:51] – changed new bis forum link. snakemanarma:config:xeh [2024/08/01 07:49] (current) – links added. snakeman
Line 1: Line 1:
-====== Extended Event Handlers (XEH) ======+====== ArmA 1 Extended Event Handlers (XEH) ====== 
 + 
 +[[https://www.pmctactical.org/forum/viewforum.php?f=42|ArmA 1 Forum]], [[:arma|ArmA 1 Home]], [[arma:config|ArmA 1 Config]], [[arma:tools|ArmA 1 Tools]], [[arma:file_formats|ArmA 1 File Formats]], [[arma:missions|ArmA 1 Missions]], [[arma:modeling|ArmA 1 3D Modeling]], [[arma:terrain|ArmA 1 Terrain]], [[arma:texturing|ArmA 1 Texturing]], [[arma:scripting|ArmA 1 Scripting]] 
 + 
 +**ArmA 1** aka Armed Assault (ArmA)
  
 **Extended Event Handlers (XEH)** by Solus and Killswitch **Extended Event Handlers (XEH)** by Solus and Killswitch
Line 5: Line 9:
 ====== Introduction ====== ====== Introduction ======
  
-This addon allows a virtually infinite amount of event handlers to be used +This addon allows a virtually infinite amount of event handlers to be used together from different addons. The event handlers are executed for the matching class and all inheriting classes. The event handler init line also contains the extended event handler class to look for, so you can have a custom inheritance for custom units.
-together from different addons. The event handlers are executed for the matching +
-class and all inheriting classes. The event handler init line also contains the +
-extended event handler class to look for, so you can have a custom inheritance +
-for custom units.+
  
-Normally event handlers can only be added in configs, and trying to add a new +Normally event handlers can only be added in configs, and trying to add a new event handler caused all previous event handlers to be overwritten. This addon allows that limitation to be overcome. This is mostly useful for having addons that can add different functionality, for example in OFP addons that had their own event handlers wouldn't inherit default event handlers, such as a custom unit with EHs being used with ECP or FFUR wouldn't have the ECP or FFUR effects.
-event handler caused all previous event handlers to be overwritten. This addon +
-allows that limitation to be overcome. This is mostly useful for having addons +
-that can add different functionality, for example in OFP addons that had their +
-own event handlers wouldn't inherit default event handlers, such as a custom +
-unit with EHs being used with ECP or FFUR wouldn't have the ECP or FFUR effects.+
  
  
-====== "Other" extended event handlers by Killswitch ======+====== "Other" Extended Event Handlers By Killswitch ======
  
 This adds support for using extended event handlers for all Arma event types This adds support for using extended event handlers for all Arma event types
  
  
-====== Extended fired event handler ======+====== Extended Fired Event Handler ======
  
-This allows a virtually infinite amount of fired event handlers to be used +This allows a virtually infinite amount of fired event handlers to be used together from different addons.
-together from different addons.+
  
 The extended fired event handler has several different parts: The extended fired event handler has several different parts:
  
-  *  First the extended init EH is run for all units to add together and compile all of the inherited fired event handlers and use setVariable to attach those to the unit. +  * First the extended init EH is run for all units to add together and compile all of the inherited fired event handlers and use setVariable to attach those to the unit.
   * The extended fired event handler is added to the base class called Extended_EventHandlers so that all the CfgVehicles' class EventHandlers inherit it. When a unit fires and sets off the event handler the shot is immediately captured in the same game state cycle. Then the compiled extended fired events are called by using getVariable to retrieve them from the unit.   * The extended fired event handler is added to the base class called Extended_EventHandlers so that all the CfgVehicles' class EventHandlers inherit it. When a unit fires and sets off the event handler the shot is immediately captured in the same game state cycle. Then the compiled extended fired events are called by using getVariable to retrieve them from the unit.
  
-The fired event handler init line contains the extended event handler class to +The fired event handler init line contains the extended event handler class to look for, so you can have a custom inheritance for custom units. The event handlers are executed for the matching class and all inheriting classes.
-look for, so you can have a custom inheritance for custom units. The event +
-handlers are executed for the matching class and all inheriting classes.+
  
-It allows more fired events to be used together, for example a script that makes +It allows more fired events to be used together, for example a script that makes shots affected by wind and a tracer script could be used together.
-shots affected by wind and a tracer script could be used together.+
  
  
 ====== Examples ====== ====== Examples ======
  
-There are two example Extended Init addons included to demonstrate how to assign +There are two example Extended Init addons included to demonstrate how to assign new event handlers and the event handler inheritance. The example pbos should not be installed except for testing.
-new event handlers and the event handler inheritance. The example pbos should +
-not be installed except for testing.+
  
-There is an example addon included to demonstrate how to assign new fired event +There is an example addon included to demonstrate how to assign new fired event handlers and the event handler inheritance. The example also has a quickly called function that is able to capture information on the shot in the same game state cycle before the shot is updated and moves away from it's starting position and changes it's status. The example pbo should not be installed except for testing.
-handlers and the event handler inheritance. The example also has a quickly +
-called function that is able to capture information on the shot in the same game +
-state cycle before the shot is updated and moves away from it's starting +
-position and changes it's status. The example pbo should not be installed except +
-for testing.+
  
-The addon "SightAdjustment_AutoInit.pbo" is an addon that makes gmJamez' +The addon "SightAdjustment_AutoInit.pbo" is an addon that makes gmJamez' "GMJ_SightAdjustment" addon compatible with XEH.
-"GMJ_SightAdjustment" addon compatible with XEH.+
  
-Note to addon makers: Before XEH 1.1, you had to make sure to add a ";" at the +Note to addon makers: Before XEH 1.1, you had to make sure to add a ";" at the end of your extended init line to separate it from other extended inits. This is no longer necessary - the Extended Init EH will separate them automatically, so ending without one won't cause a problem
-end of your extended init line to separate it from other extended inits. This +
-is no longer necessary - the Extended Init EH will separate them automatically, +
-so ending without one won't cause a problem+
  
  
-====== New in: ======+====== New In: ======
  
 1.3: Limiting certain event handler to a specific vehicle class 1.3: Limiting certain event handler to a specific vehicle class
  
-The example addon "SLX_Advanced_Init_Example" shows how to create +The example addon "SLX_Advanced_Init_Example" shows how to create an XEH init EH that will only be used on units that are of the class SoldierWB, ie the West "Rifleman". Units that inherit from "SoldierWB", eg the Grenadier, won't run the init EH.
-an XEH init EH that will only be used on units that are of the class SoldierWB, +
-ie the West "Rifleman". Units that inherit from "SoldierWB", eg the Grenadier, +
-won't run the init EH.+
  
-One can do the same thing for the other XEH event types. For example, to add a +One can do the same thing for the other XEH event types. For example, to add a "GetIn" event handler that works only on the the vehicle XYZ_BRDM2, but not on the XYZ_BRDM2_ATGM variant you would do something like this:
-"GetIn" event handler that works only on the the vehicle XYZ_BRDM2, but not on +
-the XYZ_BRDM2_ATGM variant you would do something like this:+
 <code cpp> <code cpp>
 ... ...
Line 106: Line 80:
 </code> </code>
  
-Note that within that innermost XEH class, you have to put a string value with +Note that within that innermost XEH class, you have to put a string value with the same name as the desired event handler. In the above example it was "getin". For the "fired" event handler, you would use
-the same name as the desired event handler. In the above example it was "getin". +
-For the "fired" event handler, you would use+
 <code cpp> <code cpp>
 ... ...
Line 119: Line 91:
             scope=0;             scope=0;
             // We wish to make a SoldierEB-specific *Fired* EH, so the             // We wish to make a SoldierEB-specific *Fired* EH, so the
-            // property name should be "fired" +            // property name should be "fired"
             //             //
             fired = "_this call XYZ_SoldierEB_fired";             fired = "_this call XYZ_SoldierEB_fired";
Line 129: Line 101:
  
  
-====== 1.5: Excluding certain descendant vehicle types ======+====== 1.5: Excluding Certain Descendant Vehicle Types ======
  
-With XEH 1.5, you can exclude one or more subtypes of a vehicle from +With XEH 1.5, you can exclude one or more subtypes of a vehicle from getting a certain XEH event handler. To do this, you add a directive, exclude, in an inner, "composite" XEH class (introduced in 1.3)
-getting a certain XEH event handler. To do this, you add a directive, +
-exclude, in an inner, "composite" XEH class (introduced in 1.3)+
  
-Here's an example of how to exclude the west pilot class from running +Here's an example of how to exclude the west pilot class from running the basic Man class XEH init event handler. Instead, there's a special init for the pilot ("SoldierWPilot"). Note that all subclasses of "SoldierWPilot" will be excluded from using the basic class Man XEH init too.
-the basic Man class XEH init event handler. Instead, there's a special +
-init for the pilot ("SoldierWPilot"). Note that all subclasses of +
-"SoldierWPilot" will be excluded from using the basic class Man XEH +
-init too.+
 <code cpp> <code cpp>
 /* /*
Line 175: Line 141:
 </code> </code>
  
-In the second example, we'll exclude both the standard west and east +In the second example, we'll exclude both the standard west and east pilots and add unique init EH:S to them and the BIS Camel pilot. To do so, use the exclude[] directive in array form:
-pilots and add unique init EH:S to them and the BIS Camel pilot. To do +
-so, use the exclude[] directive in array form:+
 <code cpp> <code cpp>
 /* /*
Line 231: Line 195:
  
  
-====== 1.8: making XEH init event handlers run when a unit respawns ======+====== 1.8: Making XEH Init Event Handlers Run When A Unit Respawns ======
  
-Normally, when a player respawns into a new unit (object), the init event +Normally, when a player respawns into a new unit (object), the init event handler is not executed again. However, with XEH 1.8, you can make an XEH init event handler be rerun when the new unit spawns. To do so, declare your init EH as a "composite EH class" (described above). Then, add a property to it called "onRespawn" and set it to true (the number 1).
-handler is not executed again. However, with XEH 1.8, you can make an XEH init +
-event handler be rerun when the new unit spawns. To do so, declare your init EH +
-as a "composite EH class" (described above). Then, add a property to it called +
-"onRespawn" and set it to true (the number 1).+
  
 Here's an example that shows how to do it: Here's an example that shows how to do it:
Line 256: Line 216:
 }; };
 </code> </code>
-The example above will cause all classes that are descendants of class "Man" +The example above will cause all classes that are descendants of class "Man" to have the function "My_Respawn_InitEH" called both when the unit is created and after a player has respawned into a new unit.
-to have the function "My_Respawn_InitEH" called both when the unit is created +
-and after a player has respawned into a new unit.+
  
-Note that unless you have "onRespawn=true" like above, XEH will use the default +Note that unless you have "onRespawn=true" like above, XEH will use the default ArmA behavior which is to NOT run the init EH when a unit respawns.
-ArmA behavior which is to NOT run the init EH when a unit respawns.+
  
-IMPORTANT: This feature will only work on the player's unit - AI units that +IMPORTANT: This feature will only work on the player's unit - AI units that respawn won't have their XEH init EH:s re-executed. (If someone can figure out a trick to identify playable units in a MP mission, this limitation could be removed)
-respawn won't have their XEH init EH:s re-executed. (If someone can figure +
-out a trick to identify playable units in a MP mission, this limitation could +
-be removed)+
  
  
-====== 1.9: version stringtable and "pre-init EH" code ======+====== 1.9: Version Stringtable And "Pre-Init EH" Code ======
  
-You can get a string with the version of Extended_Eventhandlers using the +You can get a string with the version of Extended_Eventhandlers using the "localize" command. Here's an example function which will return the version as a decimal number or "0" if XEH isn't installed;
-"localize" command. Here's an example function which will return the +
-version as a decimal number or "0" if XEH isn't installed;+
 <code cpp> <code cpp>
 /* /*
Line 296: Line 248:
 }; };
 </code> </code>
-Another addition is a way to put code that you want to run only once in +Another addition is a way to put code that you want to run only once in a new class, Extended_PreInit_EventHandlers. Anything in that class will be called early and before any of the normal extended init event handlers have run.
-a new class, Extended_PreInit_EventHandlers. Anything in that class will +
-be called early and before any of the normal extended init event handlers +
-have run.+
  
 Here's an example: let's say there's an addon with the following XEH init: Here's an example: let's say there's an addon with the following XEH init:
Line 329: Line 278:
 }; };
 </code> </code>
-Warning: if you write your addon using this new "pre-init" system, keep in mind +Warning: if you write your addon using this new "pre-init" system, keep in mind that it won't work with XEH versions older than 1.9.
-that it won't work with XEH versions older than 1.9.+
  
  
 ====== 1.91: PostInit and InitPost ====== ====== 1.91: PostInit and InitPost ======
  
-Two new event handler types can be used to execute things at a later stage, +Two new event handler types can be used to execute things at a later stage, when all XEH init EH:s have run and all mission.sqm init lines have been processed by ArmA. It happens just before the mission's "init.sqf" is executed.
-when all XEH init EH:s have run and all mission.sqm init lines have been +
-processed by ArmA. It happens just before the mission's "init.sqf" is executed.+
  
-The PostInit handler mirrors the pre-init event handler introduced in 1.9 and +The PostInit handler mirrors the pre-init event handler introduced in 1.9 and will make a code snippet run once per mission. Example:
-will make a code snippet run once per mission. Example:+
 <code cpp> <code cpp>
 class Extended_PostInit_EventHandlers class Extended_PostInit_EventHandlers
Line 349: Line 294:
 }; };
 </code> </code>
-The other event handler, InitPost type mimics the mission editor init lines in +The other event handler, InitPost type mimics the mission editor init lines in that it will be run once on every unit and vehicle in the mission. You write the InitPost EH just like you would the normal XEH init, fired etc handlers. That means you have to wrap the handler in the desired vehicle/unit class for which you want the InitPost EH applied. As an example, you could use this to set a per-unit variable that's needed for your addon. It needs to be done for all units that are derived from the CAManBase class. Here's how it would look:
-that it will be run once on every unit and vehicle in the mission. You write +
-the InitPost EH just like you would the normal XEH init, fired etc handlers. +
-That means you have to wrap the handler in the desired vehicle/unit class for +
-which you want the InitPost EH applied. As an example, you could use this to +
-set a per-unit variable that's needed for your addon. It needs to be done for +
-all units that are derived from the CAManBase class. Here's how it would look:+
 <code cpp> <code cpp>
 class Extended_InitPost_EventHandlers class Extended_InitPost_EventHandlers
Line 368: Line 307:
  
  
-====== Change log ======+====== Change Log ======
  
 ===== XEH ===== ===== XEH =====
Line 475: Line 414:
 ====== Notes ====== ====== Notes ======
  
-Forum topic in [[http://tactical.nekromantix.com/forum/viewtopic.php?f=29&t=21877|PMC Tactical]] and gmJamez Sight adjustment addon thread [[http://forums.bistudio.com/showthread.php?t=60462|here]].+[[https://www.pmctactical.org/forum/viewtopic.php?f=29&t=21877|PMC Tactical Forum]] topic. 
arma/config/xeh.1278924703.txt.gz · Last modified: 2010/07/12 08:51 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

All PMC web site download services are temporarily suspended until web site yearly fees have been recovered, want to download addons/mods? Then Support PMC.

If you are grateful for all the work PMC has done in the past 25 years, use Support PMC page.