Extended eventhandlers

[sickboy 13]

sickboy is your experimental EH in 6thS different or all what's there is now in 1.1 XEH ?

The importance being? Besides this is the XEH thread.

Anyway, the version in 6thSenseMod is not much different from KS's implemented changes. KS official version will be integrated soon.

[Solus 1]

I fixed a bug in XEH that made the extended dammaged eventhandler not work, and I included the fixed SightAdjustment_Autoinit.pbo:

XEH 1.2:

http://files.filefront.com/Extende....fo.html

[UNN 0]

Quote[/b] ]UNN: I haven't heard of that one, is there any info on it? I can't find any.

Well not exactly sure myself, it was something I read on the ACES forum. But it sounds like the same problems we have with the OnMapSingleClick command. As in, one persons scripts or addon, can overwrite what’s been assigned to either the display event handler, or the map click event, of another script or addon.

I know it means more work on you're part, but it seamed like the init event handler has already set a precedent in this area, so it's kind of a natural extension?

Perhaps a little different, in that it really needs a set of scripts for addon free missions as well.

[.kju 3242]

http://community.bistudio.com/wiki/Talk:displaySetEventHandler

Quote[/b] ]And that means we can have the only EH per display. Not good if we want several scripts with keys hooking.

Quote[/b] ]

bad news

example 1:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_display = findDisplay 46;

_display displaySetEventHandler ["KeyDown","if (_this select 1 == 37) then{hint""K""}"];

_display displaySetEventHandler ["KeyUp","if (_this select 1 == 18) then{hint""E""}"];

these two are the ONLY 2 EHs that actually work TOGETHER (KeyDown, KeyUp)

example 2:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_display = findDisplay 46;

_display displaySetEventHandler ["KeyDown","if (_this select 1 == 37) then{hint""K""}"];

_display displaySetEventHandler ["KeyDown","if (_this select 1 == 18) then{hint""E""}"];

this will NOT work, the EHs wont fire, assuming they overwrite themselves

useless to use the display EHs when missions, scripts, other 3rd party addons use already displayEHs

[Solus 1]

Thanks for the info! It seems possible but I don't have time to fully test and implement it but here are some very basic ideas of how it would be done, please excuse the mess:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// \Extended_Display_EventHandlers\config.cpp

// class Extended_Init_EventHandlers

// {

// class All

// {

// SLX_Extended_Display_EventHandlers_All="call compile preprocessfile ""\Extended_Display_EventHandlers\InitExtendedDisplayEventHandlers.sqf"";";

// };

// };

// \Extended_Display_EventHandlers\InitExtendedDisplayEventHandlers.sqf

_display = findDisplay 46;

// The event handlers call global variables. The global variables are strings that missions can add code to. There might be a better way to do it though, since compiling for every key press might be a bit much.

_display displaySetEventHandler ["KeyDown","_this call compile SLX_ExtendedDisplayEHKeyDown"];

_display displaySetEventHandler ["KeyUp","_this call compile SLX_ExtendedDisplayEHKeyUp"];

// Make sure the global variable is initialized if it doesn't exist yet.

if(isNil "SLX_ExtendedDisplayEHKeyDown")then{SLX_ExtendedDisplayEHKeyDown=""};

if(isNil "SLX_ExtendedDisplayEHKeyUp")then{SLX_ExtendedDisplayEHKeyUp=""};

//// get a list of code as string from a config or somewhere and put them into the global variable

// _i=0;

// _t=count (configFile/"Extended_Display_EH_Class");

// while {_i<_t} do

// {

// SLX_ExtendedDisplayEHKeyDown=SLX_ExtendedDisplayEHKeyDown+(getText ((configFile/"Extended_Display_EH_Class") select _i))+";";

// _i=_i+1;

// };

// test strings

_handlers=["player sidechat format[""Down test 1 %1"",_this]","player sidechat format[""Down test 2 %1"",_this]"];

// combine the code and put them into a global variable as a string

{SLX_ExtendedDisplayEHKeyDown=SLX_ExtendedDisplayEHKeyDown+_x+";"} forEach _handlers;

// SLX_ExtendedDisplayEHKeyUp

// test strings

_handlers=["player sidechat format[""Up test 1 %1"",_this]","player sidechat format[""Up test 2 %1"",_this]"];

// combine the handlers and put them into a global variable

{SLX_ExtendedDisplayEHKeyUp=SLX_ExtendedDisplayEHKeyUp+_x+";"} forEach _handlers;

//// loop for all event handlers

// _events=["KeyDown","KeyUp","etc"];

// {

// Other code above with:

//

// {_handler=_handler+_x+";"} forEach _handlers;

// format["SLX_ExtendedDisplayEH%1",_x]=format["%1",_handler];

//

// Or something like that.

//

// } foreach _events;

// missions can also add their own code to the global variables

SLX_ExtendedDisplayEHKeyUp=SLX_ExtendedDisplayEHKeyUp+"player sidechat format[""keyup added mission code 1 %1"",_this]"+";";

Maybe someone else can take this and put it together. It would work similarly to InitOther.sqf in Extended_EventHandlers.

[Twisted1 0]

Thanks Solus

Works great now. Most happy after a (Forced) week away from Arma I can now use all my mods again

[sickboy 13]

@Solus, please don't knit strings together especially not by adding ";" etc to it. Just add compiled strings to _ar array, then { call _x } forEach _ar;

like in XEH v1.1 and newer:)

I also have another suggestion to add:

Maybe it should be possible to do a "typeOf" check, for inits that should only run on the specific class, and not on any of it's subclasses. Not by default, but possibly by an override.

This override could come in the form of a simple extra entry in the unit class inside the Extended_****_EventHandlers classes, of type number (this way you can differ between strings = eh code, number = override.

e.g: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Extended_Init_EventHandlers

{

    class M1Abrams

    {

         SIX_AbramsInit = "player sideChat str(_this)";

         SIX_AbramsInit_Override = 1;

    };

};You can make sure the Override field is not used as an init by checking with isString, while you can still check for initName+"_Override" if it's a number and if it's 1.

[Dwarden 1125]

so after painful hour of trial tests i finally pinpointed addon pack which caused huge XEH troubles

HWM pack 2.0 ... most of XEH addons cease to work at all or just work randomly ...

so ... bash You lovely mod makers to develop only XEH compliant mods or "get lost"

nothing in ungood just be compatible

[killswitch 19]

e.g: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Extended_Init_EventHandlers

{

class M1Abrams

{

SIX_AbramsInit = "player sideChat str(_this)";

SIX_AbramsInit_Override = 1;

};

};

You can make sure the Override field is not used as an init by checking with isString, while you can still check for initName+"_Override" if it's a number and if it's 1.

How about

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

...

#define private 0

...

class Extended_Init_EventHandlers

{

class M1Abrams

{

SIX_AbramsInit_scope = private;

SIX_AbramsInit = "player sideChat str(_this)";

};

};

[sickboy 13]

How about

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Sexy Solution

Spot on mate, sounds just great  

Just thinking, another solution which would not require extra entries, is:

Either use a string if it should be used on the vehicle and all subVehicles

or use an array (with string inside), if it should only run on the vehicle itself, or maybe even add extra parameters through array entries, the scope could be one.

[killswitch 19]

Resulting from the discussion above, here  you go: Extended Eventhandlers 1.3

You can now limit specific extended EH:s to specific classes. As an example, to have an init EH run only on units of the class SoldierWB you'd do as follows:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

#define private 0

...

class Extended_Init_EventHandlers

{

   class SoldierWB

   {

       // Here, we put an inner class with an init event handler that

       // should *only* run on units of the type "SoldierWB".

       // Descendants of that class won't run them because scope=0

       class SLX_SoldierWB_Init

       {

           scope = private; // scope = 0; is the same thing

           init = "_this execVM ""\myaddon\Init_SoldierWB.sqf"";";

       };

   };

};

...

Changelog

Quote[/b] ]

XEH Change log

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

1.3

Added: The ability to use "nested" XEH classes with a "scope" feature

          to limit certain event handlers to objects of specific classes.

1.2

Fixed: SightAdjustment_AutoInit.

Fixed: Extended Dammaged EventHandler.

1.1

Fixed: XEH can now handle extended event handlers that are missing a trailing

      semicolon.

Fixed: the example addons now require the Extended_Eventhandlers addon

      instead of the two older ones. Also, the debug sideChats are now guaranteed

      to be seen when previewing a mission with the example addons loaded.

Fixed: XEH init EH:s are now actually being called on units inside vehicles.

1.0 Initial Release

Combined Extended Init, Fired, and Other event handlers. Thanks to Killswitch for

combining them and adding the other extended event handlers!

Added signature and bikey.

To see how it's done, have a look at the example addon in Examples\SLX_Advanced_Init_Example.

[sickboy 13]

Hey Mate,

Total awesomeness,  

Here's your "favorite" DoorBell Ringer again, Ding Dong

Many people have reported to me that XEH enabled addons usually seize working after people respawn.

After a long hunt, and help by LoyalGuard, I figured out that Init EventHandlers do not rerun after respawn, while all other eh's get re-added, even ones that you add in scripts with addEventHandler.

I guess you get where I'm getting at already :-)

XEH Uses the Init EH to compile not only the list of inits for the unit, but also for all the other EH's, these are saved in variables on the unit object, which are not restored after respawn :-)

I have devised a temporary solution for the player, but I have no time atm to devise a more proper one

Here's my changes:

config.cpp: http://pastebin.com/f76d06f1a

temp.sqf: http://pastebin.com/f632fc134

temp2.sqf: http://pastebin.com/f342ea7a3

Maybe talk to you @ IRC.  

Update:

Updated temp.sqf to satisfy ViperMaul's worries

[Dwarden 1125]

thanks sickboy, here is updated file for these who don't know how pack it

http://www.mediafire.com/?qgazqnxnluv

[sickboy 13]

thanks sickboy, here is updated file for these who don't know how pack it

http://www.mediafire.com/?qgazqnxnluv

NP, I guess I should not forget to mention your part in getting me to finally look at this baby

[Deadeye 1]

Alright so this isn't an official update of the Extended Eventhandlers?

So newssites shouldn't mirror these file and wait for Solus or Killswitch to release an updated version, correct?

Anyway here's a direct downloadlink (I don't like mediafire :P)

http://www.deadeye.pytalhost.com/Addon/Extended_Eventhandlers.7z

(PM me when it should be removed)

[killswitch 19]

Hey Mate,

Total awesomeness,

Here's your "favorite" DoorBell Ringer again, Ding Dong

Argh...ze bells...ze bells

Thanks for the lab work! I'll review the findings you guys have made and see if we can cook up a properâ„¢ solution for the problem. Now, me being a working class nerd these days, I won't have time to dig into this until the next (upcoming) weekend.

[sickboy 13]

Argh...ze bells...ze bells  

Thanks for the lab work! I'll review the findings you guys have made and see if we can cook up a properâ„¢ solution for the problem. Now, me being a working class nerd these days, I won't have time to dig into this until the next (upcoming) weekend.

NP

Have fun @ your Script Molding Laboratories

Looking forward to what you will cook up.

[sickboy 13]

Ring Ring!

After some more extensive testing, and with the testing help of Dwarden, I came up with an alternate "Temporary" solution to the problem.

The problem is that for instance, Evolution, or some versions of it, and possibly other missions/scripts, use the removeAllEventHandlers function sometimes, incl removing the "Killed" one, added in my temp.sqf for reInitializing XEH after respawn.

With this solution, you would not need temp2.sqf, just temp.sqf:

http://pastebin.com/f722f17e5

This method howevers would work best when RespawnDelay would be set to 1 or more seconds. This does not guarantee to work when respawndelay = 0, to my knowledge that is.

Also, I've been thinking, as the Init EH firing again after respawn, is not default arma behaviour, this might be even better, directly re-attaching the other eh's instead:

http://pastebin.com/f7fe1c582

(fixed link, it was missing from pastebin )

[delta99 34]

Is it possible to add an event handler to a WeaponBoxWest or ReammoBox at all? I've tried all sorts of things to do this but nothing seems to work. I can easily attach an event handler to any of the Soldier types.

Am I doing something wrong or is this just not possible?

[delta99 34]

Is it possible to add an event handler to a WeaponBoxWest or ReammoBox at all? I've tried all sorts of things to do this but nothing seems to work. I can easily attach an event handler to any of the Soldier types.

Am I doing something wrong or is this just not possible?

It looks as though the WeaponBox classes are Static classes and as such, as far as I can tell by looking at the XEH code, aren't handled by XEH.

Can anyone confirm this for sure?

Is there any good reason for this? Can it simply be extended to Static classes without any issues?

[rubberkite 19]

Ring Ring!

After some more extensive testing, and with the testing help of Dwarden, I came up with an alternate "Temporary" solution to the problem.

The problem is that for instance, Evolution, or some versions of it, and possibly other missions/scripts, use the removeAllEventHandlers function sometimes, incl removing the "Killed" one, added in my temp.sqf for reInitializing XEH after respawn.

With this solution, you would not need temp2.sqf, just temp.sqf:

http://pastebin.com/f722f17e5

This method howevers would work best when RespawnDelay would be set to 1 or more seconds. This does not guarantee to work when respawndelay = 0, to my knowledge that is.

Also, I've been thinking, as the Init EH firing again after respawn, is not default arma behaviour, this might be even better, directly re-attaching the other eh's instead:

http://pastebin.com/d6fd314a2

Hi sikboy,

.. oh no again rubber... hehehe

I've noticed the problem in my evo-mod, with also revive script...

I'm happy to see here a solution, when I respawn, I don't see effect on my own weapon suck as your tracer and arma effects smoke, maybe also Q11 recoil and real rate of fire.

I found here your temporary solution to the problem, and your last post, have two link, last one show clear white post.

I don't understand what I must do to get the last solution, to test it.

the 7zip download posted by Dwarden,

with you last posted mod on the temp.sqf file ?

or just original xeh and your temp.sqf ?

please tell me how to, use your last solution, so I will test in in my "complex" mission environment.

[sickboy 13]

My solution is not meant to be supported mate. If you know what you're doing, go ahead with what I've posted. Otherwise just wait for everyone else until KS returns from Killswitch Scripting Laboratories, deep down in Castlevania.

[rubberkite 19]

With this solution, you would not need temp2.sqf, just temp.sqf:

http://pastebin.com/f722f17e5

I only ask if this is for standard xeh or if I need all the files you have uploaded, I whant to apply and try the solution for feedback, but I don't understand after your last post, if this is a stand alone code that works with original xeh file, or if I must use with all your modded files...

now I must come back to my laboratory in Yoshi Island

[sickboy 13]

I know that was your question Rubber. My answer is: Sorry, I only supplied the solution for those who know what to do with it, please wait until KS supplies a user-friendly version. Or maybe Dwarden is kind enough to supply another built-pbo.

(Well in the meantime I lost more time explaining, so here's the answer anyway; You need to take the dwarden posted version, delete temp2.sqf and overwrite the contents of temp.sqf with what I posted :-D)

Seems my PM-box is bombed with "How to XEH'ify Existing Configs with Normal Eventhandlers"

I _HATE_ pm's, so here's an answer for all of you

Before and After Picture

Original Config: http://pastebin.com/f71e60add

XEH'ed Config:

http://pastebin.com/f65a4d126

Difference Overview:

http://pastebin.com/pastebin.php?diff=f65a4d126

Another Example: http://www.flashpoint1985.com/cgi-bin....1225647

[william1 0]

Hi. Sickboy , thanks for the tip , i've followed your steps and i have working the init and fired eventhandlers, but the hit eventhandlers don't work , i've made them this way , is it correct ? no matter what i do it doesn't work and is the only one left to complete the config

class Extended_Hit_EventHandlers

{

class Man

{

my_hit_man = "my script;";

};

};