Extended eventhandlers

[Spooner 0]

Regarding running or precompiling sqf files, always, always use preprocessFileLineNumbers!

loadFile -> No preprocessing of macros or comments; vague error information.

preprocessFile -> Macro preprocessing; vague error information.

preprocessFileLineNumbers -> Macro preprocessing; full error information.

(full error information means you are told the file and line number of the error, just like you get with execVM!.

---

A problem I'm having with XEH at the moment is that if men are inside vehicles, then their init is not run until after the mission starts (time > 0). This is because you spawn these inits, rather than calling them (I know you have to because of the sleep you have in there, but I'm not sure why you need to sleep; it isn't as though those men's inits wouldn't all be run at time == 0 if they were on foot). It is important that SPON Core is run at time == 0 and I'm currently starting it using the camanbase init. If you can't avoid that spawn, I'll just have to add init to vehicles as well, since it isn't guaranteed that a mission will have men on foot at the start.

To save this messing about, I have an alternative suggestion: Would it not be possible to have a single pre_init handler that was run once before all object inits (by running it on the first object that is created, before that object's init was run)? This would save all the addons, such as mine, that just want to start a single script up at the start of the mission, from having code run in every object's init. This would have the added benefit of allowing us to precompile functions and actually use them inside object inits, saving a lot of unnecessary use of execVM.

[i0n0s 0]

To save this messing about, I have an alternative suggestion: ...

/me likes to have that pre_init handler too!

That drops most

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (isNil "Bla") then {Bla = "Bla"; ...}

and will be a performance win.

[killswitch 19]

A problem I'm having with XEH at the moment is that if men are inside vehicles, then their init is not run until after the mission starts (time > 0). This is because you spawn these inits, rather than calling them (I know you have to because of the sleep you have in there, but I'm not sure why you need to sleep; it isn't as though those men's inits wouldn't all be run at time == 0 if they were on foot). It is important that SPON Core is run at time == 0 and I'm currently starting it using the camanbase init. If you can't avoid that spawn, I'll just have to add init to vehicles as well, since it isn't guaranteed that a mission will have men on foot at the start.

There's an oddity (?) with ArmA in that the crew of a vehicle "isn't present" at the time the vehicle's init event handler runs. Phrased differently: the expression crew (_this select 0) returns an empty array if used in the init EH even on manned vehicles. However, it seems as if the sleep isn't actually needed and the crew inits could be called earlier (ie at time=0 as soon as the spawned "thread" is started instead of at time=0.1+). I'll do more lab testing on this, so stay tuned...

Quote[/b] ]To save this messing about, I have an alternative suggestion: Would it not be possible to have a single pre_init handler that was run once before all object inits (by running it on the first object that is created, before that object's init was run)? This would save all the addons, such as mine, that just want to start a single script up at the start of the mission, from having code run in every object's init. This would have the added benefit of allowing us to precompile functions and actually use them inside object inits, saving a lot of unnecessary use of execVM.

Hmm, that could be useful...I'll see what I can cook up.

[kroky 1]

Thanks for the mirroring!

Regarding ECS - I can confirm that ECS fails to load properly with the new version of Extended Eventhandlers. I had a look at their(?) bridge addon, "Themis.pbo" and the XEH support is done in a slightly "unsupported" way.

The proper way to do it would be to have a config like looks like this: config.cpp.

EDIT: I've reported the problem in the ECS forums aswell. Here's hoping they'll issue a fixed "Themis.pbo"...  

Do I understand correctly that this themis component has the same function as the slx_ecs_xeh.pbo made by Solus?

Or do I need both?

Here is the config.cpp made by Solus:

// Extended Eventhandler ECS

#define ReadAndWrite 0

#define ReadAndCreate 1

#define ReadOnly 2

#define ReadOnlyVerified 3

#define true 1

#define false 0

#define private 0

#define protected 1

#define public 2

#define VSoft 0

#define VArmor 1

#define VAir 2

#define LockNo 0

#define LockCadet 1

#define LockYes 2

#define TEast 0

#define TWest 1

#define TGuerrila 2

#define TCivilian 3

#define TSideUnknown 4

#define TEnemy 5

#define TFriendly 6

#define TLogic 7

class CfgPatches

{

class SLX_ECS_XEH

{

units[]={};

requiredVersion = 0.1;

requiredAddons[] = {"Extended_EventHandlers"};

};

};

class Extended_Init_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_Init="if (isnil (""ECS_path"")) then {ECS_path = ""\ECS_Core\data\scripts\""}; _this call compile loadfile format[""%1init.sqf"",ECS_path];_this exec format[""%1init.sqs"",ECS_path];";

};

};

class Extended_Hit_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[1,_this] call (ECS_functions select 111);";

};

};

class Extended_Killed_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[2,_this] call (ECS_functions select 111);";

};

};

class Extended_Dammaged_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[3,_this] call (ECS_functions select 111);";

};

};

class Extended_Fired_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[4,_this] call (ECS_functions select 111);";

};

};

class Extended_IncomingMissile_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[5,_this] call (ECS_functions select 111);";

};

};

class Extended_GetIn_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[6,_this] call (ECS_functions select 111);";

};

};

class Extended_GetOut_EventHandlers

{

class AllVehicles

{

SLX_ECS_XEH_AllVehicles="[7,_this] call (ECS_functions select 111);";

};

};

[killswitch 19]

Do I understand correctly that this themis component has the same function as the slx_ecs_xeh.pbo made by Solus?

Yes, that does the same thing except that "slx_ecs_xeh.pbo" is missing a few of the event handlers that Themis.pbo covers - the engine, fuel, gear, landedTouchDown, landedStopped, animChanged and animDone are missing. Here's how that config looks if they were to be added: (EDIT: pastebin link removed since the config it pointed to 1) had a syntax error 2) an update to ECS' bridge addon has been released)

Quote[/b] ]Or do I need both?

No, they are intended to to the same job - to "bridge" together ECS and XEH, each in their own way. Unfortunately, as they are today, neither will make ECS fully interoperable with addons using XEH if XEH 1.8 is installed, Themis.pbo due to it being written in a certain way that XEH 1.8 breaks and slx_ecs_xeh.pbo due to it needing additions to cover all ECS event handlers.

[kroky 1]

I tested shortly three scenarios in the mission delivery boy:

1. only with slx_ecs_xeh

2. only with themis (I pbo'ed the config posted above above in this thread, made by Killswitch)

3. with both.

Result: all mods based on xeh work correctly,  ECS initializes correctly, SLX works correctly

Most astonishing: I had the best performance in FPS with both files...

So here no problem with the new 1.8 XEH.

Ok quick update:

I pboed your corrected slx_ecs_xeh config Killswitch and tested it: The error occurs:

Error in expression <if(isNil'ECS_path')then{ECS_path='\ECS_Core\data\scripts\'

Error position: <)then{ECS_path='\ECS_Core\data\scripts\'>

Error missing ;

He he where the smiley is should be a )

the forum has changed the character by itself

EDIT: I fixed it myself, it's easy. At the end of the line was only "; instead of ;"; and a ( was missing after isnil

The good news this config works great for SLX_ECS_XEH

[poweruser 10]

Save your efforts Kroky,

we (The ECS Team) reviewed Killswitch's request and integrated one of his suggestions into an Themis update v1.0.1

ECS Website - Downloads

[kroky 1]

Thank you very much for fixing this.

I must admit that with your themis addon some features, now work that didn't work slx_ecs_xeh. Great fix!!

[Joker-RS- 0]

Updated this morning.

ECS Themis compatibility component 10101

"Entry vehicle Air Fixed; 2008.09.16 2:00PM".

Look here for the link, thx you.

[killswitch 19]

First, a big thank you to the ECS team for the updated Themis ECS-XEH bridge addon!  

Next, the problem of the late crew member initialisation and request for a "pre-init" way of calling code - here's XEH 1.9: Extended_Eventhandlers19.zip

What's new in 1.9?

<ul>[*] Added: stringtable with STR_SLX_XEH_VERSION for use with the localize command.

[*] Fixed: crew and cargo of manned vehicles have their XEH init event handlers called earlier, just before the mission starts.

[*] Addon makers can create a Extended_PreInit_EventHandlers class with code that will run once, before any XEH init EH processing takes place.

The readme file in the ZIP archive has examples showing how to read out the version and make use of the "pre-init system".

[Guest]

New version frontpaged at the Armaholic.com homepage.

The Armaholic.com download page can be found here:

http://www.armaholic.com/page.php?id=2605

[oldbear 390]

New on front page at Armed Assault.info

Link to updated mirror :

http://www.armedassault.info/index....=306

[Spooner 0]

Thanks for making those improvements! I only suggested the pre-init system to avoid the issue with late-init on crews, but you did both (well, I think someone else suggested pre-init before, but it is definitely a nice feature)! Yay!

EDIT: SPON Core, and therefore the SPON components that run off it, now works properly with 1.9 due to the early execution of crew inits (it failed in missions where every human was in a vehicle - never considered that). I should have just changed it to be run on AllVehicles rather than Man, but now I don't have to *cough*. I'll be using the preinit in the future releases.

[rundll.exe 12]

The pre init is extremely usefull if it works like I think.. Thanx!

[Stavanger 0]

Mirror updated by ePrison.de

Extended Event Handlers (XEH) v1.9 by Solus&Killswitch

Regards,

Stavanger

[i0n0s 0]

Hi,

a stupid question:

If the fXEHversion should return the version number of the XEH, why does it return 1.6 instead of 1.9?

Stupid answer:

Replace all XEH-files, and not just those you know about...

[killswitch 19]

Hi,

a stupid question:

If the fXEHversion should return the version number of the XEH, why does it return 1.6 instead of 1.9?

By "the fXEHversion" I take it you mean the example function in the readme file? That function returns 1.6 if the Extended_Eventhandlers.pbo you're actually using is 1.6. Find all the older versions and replace them with the new one.

EDIT: OK, once I had finished this post you had already fixed the problem yourself. All is well that ends well.

I noticed there's a typo in the readme - an extraneous comma sign in the private array of that function in the readme file. Here's a corrected function:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">/*

   Return the version of Extended_Eventhandlers, or 0 if the addon

   isn't installed.

*/

_fXEHversion = {

   private ["_str", "_cfg", "_ver"];

   _cfg=(configFile/"CfgPatches"/"Extended_Eventhandlers"/"SLX_XEH2_Version");

   _ver=0;

   _str=localize "STR_SLX_XEH_VERSION";

   if !(_str == "") then {

       _ver=call compile _str;

   } else {

       // XEH version 1.8 and earlier lacks the stringtable version

       if (isNumber _cfg) then {

           _ver=getNumber _cfg;

       };

   };

   _ver

};

[Dwarden 1124]

KS fantastic work ... now the displayEH (i mean then displayXEH)

and it's even more steps close to 'perfection'

[i0n0s 0]

displayEH exists: http://www.ofpec.com/forum/index.php?topic=31384.0

But sadly not in XEH because of missing response to PM.

[mr burns 131]

Thx for the update!

Mirror @ armed-assault.de

PS: Been tired of not having a pic to include in news, so i made this:

If you like, feel free to use for whatever deems appropriate.

[Dwarden 1124]

displayEH exists: http://www.ofpec.com/forum/index.php?topic=31384.0

But sadly not in XEH because of missing response to PM.

which is exactly what i was talking about

[Doomguy 0]

Hi!

I have some XEH questions for the event handler experts here. Some missions, for instance Warfare, use event handlers to implement functionality like scoring and clean up. The event handlers are added by scripts that call addEventHandler. I'm concerned that this might conflict with the XEH system of keeping track of event handlers.

Now, the question. Does the use of addEventHandler in scripts conflict with event handlers added by addons using XEH (let's say, ACE). If, for instance, an addon would use XEH to add a "killed" event handler to all objects of type Man, and my mission script would do addEventHandler ["killed", command] to an object of type Man, would both event handlers remain, or would one override the other?

If event handlers override each other in the situation above I would like to know how to make sure both event handler run. Can you add event handlers to the XEH system in mission scripts?

Thanks!

Doomguy out.

[Wolfrug 0]

AFAIK normal eventhandlers added via script (like in your example) will NOT override config-based eventhandlers.

Which makes me curious...is a config-based eventhandler even considered when using removeEventhandler ID? (as in, CAN they be removed via script?). Hm hmm!

Regards,

Wolfrug

[Doomguy 0]

AFAIK normal eventhandlers added via script (like in your example) will NOT override config-based eventhandlers.

Which makes me curious...is a config-based eventhandler even considered when using removeEventhandler ID? (as in, CAN they be removed via script?). Hm hmm!

Regards,

Wolfrug

You're right Wolfrug! I just ran some tests and indeed, both event handlers run. Cool!

Also, removeAllEventHandlers seems to remove the ACE event handlers, indeed.

Doomguy

[killswitch 19]

Hot on the heels of the recent A.C.E mod 1.02 release comes a new Extended Eventhandlers addon - version 1.92

Extended_Eventhandlers192.zip

This is the same version as the one XEH in ACE 1.02 and introduces a few new advanced features that have been cooking in the cauldrons of the deep dungeons of A.C.E. for some time. Please see the enclosed "readme" file for details of the new twins - PostInit and InitPost (*).

Credit for these two new features should go to Sickboy and the ACE team. Neat stuff, guys!

Here's an excerpt from the readme and changelog:

Quote[/b] ]New in 1.91: PostInit and InitPost

==================================

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.

The PostInit handler mirrors the pre-init event handler introduced in 1.9 and

will make a code snippet run *once* per mission. Example:

class Extended_PostInit_EventHandlers

{

   // Run "late_init.sqf" just before the mission's init.sqf and after

   // all other init EH:s and mission editor init lines have been processed

   SLX_MyAddon_postinit="[] execVM 'SLX_MyAddon\late_init.sqf";

};

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:

class Extended_InitPost_EventHandlers

{

   class CAManBase

   {

       // Make sure everyone is happy when the mission starts

       SLX_MyAddon_init="_this setVariable ['slx_myaddon_ishappy', true]";

   };

};

XEH Change log

============

1.92 (Feb 09, 2009)

Changed: Some optimizations made (eg use pre-compiled XEH init functions).

       

1.91 (Dec 20, 2008) (Unofficial, for use with the ACE mod)

Added: New "post-init" feature that can be used to have a script run once

      at the end of mission initialisation, after all init EH:s and mission

      init lines have executed, but before the mission's init.{sqs,sqf}

      is processed.

Added: There's also a per-unit, "InitPost" XEH framework which lets you run

      scripts at the end of mission init. Unlike the PostInit event handlers

      described above, these snippets run once for every unit in the mission.

      (The name of this framework may change in the future to avoid confusion

      with "PostInit")

(*) Yes, I know... which one is which?