Extended Init Event Handler

[moosenoodles 0]

Bloody confusing if u ask me lol..

All i need to know is, sixth sense misc pbo now defunct ? do i need it for running tracers and other effect mods like armaeffects? its all very confusing.

One day someone will make a sticky thread that relates to -

1) Common addons used

2) How they do, or can work with eachother so we dont have to keep searching threads for possible comination update possibilities.

Just a thought :P

3)

[Maddmatt 1]

Bloody confusing if u ask me lol..

All i need to know is, sixth sense misc pbo now defunct ? do i need it for running tracers and other effect mods like armaeffects? its all very confusing.

One day someone will make a sticky thread that relates to -

1) Common addons used

2) How they do, or can work with eachother so we dont have to keep searching threads for possible comination update possibilities.

Just a thought :P

3)

If a mod needs this it will say so in the readme and may even include it. My mod needs it for the tank muzzleflash effect.

The 6thsense tracers still need to be updated to use this addon.

[cross 1]

solus can you pls edit the first post and provide a link there with an update remark. might get overlooked in the posts area..

[sickboy 13]

6thSense.eu "Pack1" from now on also full ExtendedInitEventhandlers compatible!

[sickboy 13]

Solus, im eagerly wanting to use the Extended Fired EventHandlers etc, and hope aswell that you are considering to create these Extended Eventhandler addons for all of the EventHandlers, is this the case?

Another thing... beforehand I was using a simple trigger that got checked every few seconds to see if there were new units on the map, if that was the case, my eventhandlers got added to those units. Now the problem with your setup is of course the addons which do not 'support' the extendedInitEventhandler system, as in case they overwrite Fired or Init eventhandlers, my stuff will not work anymore.

May I suggest a large promotion campaign to addon makers to use this Eventhandler System?

I'm planning already on contacting a lot of ppl to suggest to use these, but maybe we can reach out to some of the news sites aswell so they can do a call to unite )

Also, as you call the getVariable, why do you believe it takes 1 more cycle to process? You are not using spawn, but call, and according to Suma, Object getVariable "..." has no extra delay whatsoever compared to using a global Variable, as both are taken from the variable database in the same manner.

[quiet_man 8]

this is a MUST for every mod!

QuietMan

[Solus 1]

Maddmatt: Cool, looking forward to what you can do with it!

Malick, quiet_man: Thanks, I hope it catches on!

moosenoodles: Hopefully the extended event handlers addons will make most compatability problems a thing of the past.

crawler75: Sure, first post updated, also with updated readme.

sickboy:

Quote[/b] ]6thSense.eu "Pack1" from now on also full ExtendedInitEventhandlers compatible!

Cool!

Quote[/b] ]Solus, im eagerly wanting to use the Extended Fired EventHandlers etc, and hope aswell that you are considering to create these Extended Eventhandler addons for all of the EventHandlers, is this the case?

I wasn't planning to make any more extended EH addons, but the extended fired EH could easily be used as a base for other extended eventhandler addons. Actually it's probably so easy I might just do it anyway.

I think most of the other EH's should work fine by being added with addEventHandler from the extended init, but maybe someone will find a greater need for more extended EH's or some drawbacks from the addEventHandler method.

Quote[/b] ]

Another thing... beforehand I was using a simple trigger that got checked every few seconds to see if there were new units on the map, if that was the case, my eventhandlers got added to those units. Now the problem with your setup is of course the addons which do not 'support' the extendedInitEventhandler system, as in case they overwrite Fired or Init eventhandlers, my stuff will not work anymore.

May I suggest a large promotion campaign to addon makers to use this Eventhandler System?

I'm planning already on contacting a lot of ppl to suggest to use these, but maybe we can reach out to some of the news sites aswell so they can do a call to unite )

I don't plan to advertise more but it would be great if you and others want to help promote it as a standard! :]

Quote[/b] ]

Also, as you call the getVariable, why do you believe it takes 1 more cycle to process? You are not using spawn, but call, and according to Suma, Object getVariable "..." has no extra delay whatsoever compared to using a global Variable, as both are taken from the variable database in the same manner.

Sorry, that stuff about it taking another cycle is from an older test version of the extended fired EH when I wrote the readme, before I realized that getVariable could be called in the same cycle and call it's own functions. I hadn't taken the time to update the readme to completely reflect the current process, but it should be somewhat more explained in the note in my earlier post. Also the first post now has an updated readme that should explain the current version more correctly.

[UNN 0]

Quote[/b] ]I don't plan to advertise more but it would be great if you and others want to help promote it as a standard!

I'm certainly interested in taking a look at it. But are there any mirrors? I can't download anything from FileFront.

[Solus 1]

Sorry, here are some more mirrors:

Extended Init EventHandlers 1.1 @ ArmedAssault.Info

Extended Init EventHandlers 1.1 @ Armaholic.com

Extended Init EventHandlers 1.1 @ ArmedAssault.kiev.ua

http://files-upload.com/files/528902/Extended_Init_EH_1.1.rar

Thanks to ArmedAssault.Info, Armaholic.com, and Armed Assault Ukraine for hosting!

[Maddmatt 1]

I've finally taken some time to look at the new fired eventhandlers. Is there any reason to use them instead of adding them through the init eventhandler?

It could be useful if you passed the projectile itself to whatever gets called by the fired eventhandler, that way not every running mod has to use the nearestobject command. So for example your addon can call the nearestobject command on a bullet and then pass that to the scripts/functions in my mod and the 6thsense tracers, as well as any other mods that use it.

So when a unit fires, instead of the nearestobject command running 2 or 3 times, it only runs once.

Was that the idea you were trying with the shotinfo function?

[UNN 0]

Thanks for posting the links to the mirrors. Managed to check it out know, so I have a couple of questions:

Any reason why you used ExecVM to launch the init events, rather than Call?

Another thing that worried me, was inheritance. If a unit using the extended init event handlers, inherits from another unit using a different extended init event. Will the extended init events assigned to the parent, be executed twice, when really they shouldn’t?

[Solus 1]

Maddmatt:

The reason to use the fired event handler is because it has the nearestObject command built in, and the shot object is passed to the functions/scripts that are called, just like you described. Take a look at the examples to see the stuff that's passed along. The ShotInfo function was just used to collect and pass more data along, like the shot's position, speed, direction, vector, velocity, type, etc. but the called scripts can also do that stuff so it was taken out.

Hmm, speaking of the info that's passed along, maybe the shot should just be added to the end of the array so that other scripts/functions that were written for the regular event handler don't have to change the order/style of any of the _this select things they get from the array(I think it's in a sub-array, like ((_this select 0) select whatever) ), they would just need to take out the nearestobject command and replace it with the _this select from the end of the passed array.

UNN:

If you mean the execVM's used in the example addons, it was what I found to work to start functions and I thought the more experienced scripters/function users might prefer having .sqf function examples rather than regular .sqs scripts. You don't need to use execVM in the extended inits, you can do whatever you want, it should all get run the same way as having it in the regular EventHandler init line, so you could use exec on a script or do calculations, if-then, or whatever.

I also used execVM on the extended init functions that read the extended init config lines and compile and call them because it seems to work and do what I need it to do. Would it be better to use call loadFile or something else to start those functions? I think I've seen functions get defined in a global variable and then called from there, but I don't like to do that when it's not necessary because I don't like filling up the global variables with unnecessary stuff, since the number of global variables are limited in 1.08, and having too many results in the save game bug, making save games unloadable. Even if execVM is slower I don't think it's used too often to have any effect on performance and I don't see a need for it to take up space in a global variable, but maybe there's something I haven't considered?

The inheritance can be a little tricky, that's why I included the example addons to help demonstrate it. Basically every unit executes every extended init for every inherited class that matches a listing in the base class Extended_Init_EventHandlers. For example:

Class SoldierWB inherits from class CAManBase which inherits from class Man which inherits from class Land which inherits from class AllVehicles which inherits from class All.

The extended init function will check every one of those classes for a matching class name in Extended_Init_EventHandlers and will add the init lines of each matching class to a string, then compile and call the string. So SoldierWB will call the extended init lines for CAManBase, Man, Land, AllVehicles, and All.

So in your example you mean if there are two units, one inheriting from the other, and the parent has a matching class name in class Extended_Init_EventHandlers? The child class will run the Extended Init Function, which will add the parent class'(and any other inherited classes) matching class names from Extended_Init_EventHandlers together and then compile and call them.

The only way to have the inits run twice is to have the Extended_Init_EventHandlers class inherit from another Extended_Init_EventHandlers class, which will mean that the child class will have all of the inherited classes, which will be added to the init string, then the parent class' init lines will be added to the init string, which will mean that there are copies of the init lines. The solution: Don't use inheritance in the base class Extended_Init_EventHandlers. And if you do, make sure that no unit will ever have two matching inheritance classes that match inheriting classes in Extended_Init_EventHandlers. For example, if in cfgVehicles Unit1 is the parent of Unit2, just make it like this:

<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 My_Unit1

{

My_Unit1_class_init="(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";";

};

class My_Unit2

{

My_Unit2_class_init="(_this select 0) exec ""\My_Addon\Unit2_Script.sqs"";";

};

};

And never have it like this:

<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 My_Unit1

{

My_Unit1_class_init="(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";";

};

class My_Unit2:My_Unit1

{

My_Unit2_class_init="(_this select 0) exec ""\My_Addon\Unit2_Script.sqs"";";

};

};

Because then the My_Unit2 class will run the class My_Unit1 init line twice. Basically when you inherit from something it looks like this to the game:

<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 My_Unit1

{

My_Unit1_class_init="(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";";

};

class My_Unit2:My_Unit1

{

My_Unit1_class_init="(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";";

My_Unit2_class_init="(_this select 0) exec ""\My_Addon\Unit2_Script.sqs"";";

};

};

And "(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";" would be run twice because the child's matching class inherits the line, and the parent class also has the same line. Sorry if my explanations are kind of confusing.

Hmm, since the names of all the init lines are different(like My_Unit2_class_init in the above examples), maybe there could be some way to use those, maybe to put them in an array so that matching child classes can maybe overwrite the lines that might otherwise be inherited, so that the running of certain lines could be disabled for specific units.

[UNN 0]

Quote[/b] ]Would it be better to use call loadFile or something else to start those functions?

Call loadfile or a pre-compiled function that’s freed up after execution, would be better if you can get away with it? For JIP there are at least 10 opportunities to execute functions and commands, before ExecVM executes from a configs init event. These include the mission editor init fields. A dedicated server has four and an MP client has 2. So it does cut out some useful functionality if you only use ExecVM. Where as the Call command will cover all of these events.

Quote[/b] ]The only way to have the inits run twice is to have the Extended_Init_EventHandlers class inherit from another Extended_Init_EventHandlers class

*Edit:

Actually I just realised, it only presents a problem if both addons are calling the same script. Which reduces the likely hood of this happening, even more. So it probably isn't anything to worry about after all. So the following isn't relevant in most cases.

That’s what worries me, we may not always have control over this. If addons from different authors are combined into a mission. The scenario I was thinking about, might be when you have two different addons:

Addon A:

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

       {

       ....

       ....

       class Extended_Init_EventHandlers

               {

               class My_Unit1

                       {

                       My_Unit1_class_init="(_this select 0) exec ""\My_Addon\Unit1_Script.sqs"";";

                       };

               };

       };

Addon B:

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

cfgVehicles My_Unit2 : My_Unit1

       {

       ....

       ....

       class Extended_Init_EventHandlers

               {

               class My_Unit2

                       {

                       My_Unit2_class_init="(_this select 0) exec ""\My_Addon\Unit2_Script.sqs"";";

                       };

               };

       };

Won't the inheritsFrom command execute Unit1's init event a second time, from within Unit2's addon? Not that such a scenario is going to happen all that often. But it's best people are at least aware of it, if it does.

[Maddmatt 1]

Maddmatt:

The reason to use the fired event handler is because it has the nearestObject command built in, and the shot object is passed to the functions/scripts that are called, just like you described. Take a look at the examples to see the stuff that's passed along. The ShotInfo function was just used to collect and pass more data along, like the shot's position, speed, direction, vector, velocity, type, etc. but the called scripts can also do that stuff so it was taken out.

Hmm, speaking of the info that's passed along, maybe the shot should just be added to the end of the array so that other scripts/functions that were written for the regular event handler don't have to change the order/style of any of the _this select things they get from the array(I think it's in a sub-array, like ((_this select 0) select whatever) ), they would just need to take out the nearestobject command and replace it with the _this select from the end of the passed array.

Thanks. Guess I should have taken a better look at it.

As for adding the shot to the end of the array, that seems like a good idea for me.

[Solus 1]

Quote[/b] ]Where as the Call command will cover all of these events.

Ok, sounds like a good reason to use call, I'll put that in the next update, thanks!

Quote[/b] ]Won't the inheritsFrom command execute Unit1's init event a second time, from within Unit2's addon?

No, based on your example I think you've gotten an incorrect idea of where the classes are and what they do, since the names are kind of confusing, sorry. I'll try and explain it a little more.

Class Extended_EventHanders is what I call a "base class" as in cfgVehicles, CfgAmmo, CfgWhatever. It contains the event handlers themselves, that the cfgVehicles classes inherit into their class EventHandlers, like this:

Quote[/b] ]// not inside any brackets, a "base class," just like cfgVehicles

class Extended_EventHandlers

{

init="_this call loadFile ""\Extended_Init_EventHandlers\init.sqf"";"; // the utility function

// the fired event handler and other extended EHs are also added here by other addons

};

// not inside any brackets, a "base class"

class cfgVehicles

{

class Tank;

class My_Unit : Tank

{

...

...

// class EventHandlers is inside all cfgVehicles classes, it can hold the event handlers themselves, or inherit them from somewhere else like this

class EventHandlers : Extended_EventHandlers {}; // the EventHandlers class inherits the event handlers from Extended_EventHandlers

};

// you can also have no event handlers for a unit, like some BIS vehicles have

class My_Unit2:My_Unit

{

...

...

class EventHandlers {}; // don't have anything and don't inherit from anything

};

// or maybe you're thinking of something that has an eventhandlers class and also inherits another vehicle that has an eventhandlers class as well?

class My_Unit3:My_Unit

{

...

...

class EventHandlers : Extended_EventHandlers {}; // the EventHandler class completely overwrites/replaces the previous one, they don't overlap at all. It inherits from a clean slate. It's the same as removing this line, since the vehicle inherits the same thing from it's parent class. The only reason to do this is to make 100% sure that this class has the EventHandlers class that inherits the extended ones in case you're worried that it might not be inheriting from the parent for some reason, or if you want to add some kind of specialized eventhandler like in the next example, or if the unit is inheriting from a unit with a special event handler that you don't want to run on the unit that's inheriting like in the example after that, Unit5.

};

// you can have a custom extended init eventhandler for an addon unit

class My_Unit4:My_Unit

{

...

...

class EventHandlers : Extended_EventHandlers

{

init="_this exec ""\My_Unit\Special_Script.sqs"";_this call loadFile ""\Extended_Init_EventHandlers\init.sqf"";"; // this replaces the original init line, so you need to add the extended init utility function here or else it won't be run for this unit. This special script could be done with the extended init event handlers, but the only reason to do it this way is if you don't want inheriting units to have this init, since all vehicle that inherit from the extended init vehicle will have that extended init also. The reason that this one inherits from Extended_EventHandlers rather than just having the event handlers defined here is so that the other event handlers that are defined in Extended_EventHandlers by other addons are included here.

};

};

// inherit from a unit that has a special event handler, but you want this one to have the regular extended event handlers

class My_Unit5:My_Unit4

{

...

...

class EventHandlers : Extended_EventHandlers {}; // this one inherits from Unit4 which has a specially defined event handler, but you don't want this one to inherit that special event handler, so you reinherit from the Extended_EventHandlers class again to get back the basic ones.

};

};

The event handlers themselves no longer contain anything other than the utility functions that get the actual code that does stuff from somewhere else.

Here's where it gets confusing, there are other "base classes" that have very similar names:

Quote[/b] ]// "base class"

class Extended_EventHandlers

{

...

};

// a new "base class"

class Extended_Init_EventHandlers

{

// matches the name of the cfgVehicles class, which the utility function checks

class My_Unit

{

My_Unit_Init="if(alive (_this select 0))then{_this exec ""whatever.sqs"";};"; // the code that does stuff

};

};

// "base class"

class cfgVehicles

{

...

};

Extended_Init_EventHandlers is a new "base class" that I created for the extended event handler init.sqf function to read from, it's where the actual code that does stuff comes from now.

Maddmatt:

Actually it looks like I already made it do that.

[Maddmatt 1]

Maddmatt:

Actually it looks like I already made it do that.

Well you should have said so in your readme

I still need to change some stuff in my mod to use your fired event handler. Right now it just adds them all through the init.

Anyway your addon has really made things easier. My mod and the 6thsense.eu stuff works perfectly together with this

[UNN 0]

Quote[/b] ]Ok, sounds like a good reason to use call, I'll put that in the next update, thanks!

Nice one, cheers. I like the reassurance and functionality, of function timing over script timing, when it can be used.

Quote[/b] ]No, based on your example I think you've gotten an incorrect idea of where the classes are and what they do

Possible, I just did a cut and paste from one of your previous examples. It wasn't so much, event inheritance that concerned me.

As per my edit, I was just kind of over complicating things. I took another look at the scripts and saw the flaw in my thinking

[Maddmatt 1]

Solus, one more think I need to bug you about

Are you going to sign your addon? I want to sign ArmA Effects, but your addon also needs to be signed for that to be any use.

[VictorFarbau 0]

Solus, one question. Have you tested this on a dedicated server? I have used the init event handler in my VFAI extension which runs fine on a local server and also local dedicated server (running the client on the same machine).

But as soon as I run it from a remote dedi server (addon is present) the inits don't seem to be run anymore. Have you heard similar feedback?

Thanks,

VictorFarbau

[Kirq 0]

Sorry for a noob question. But how exactly do i implement this addon ? Copy to addons folder ? or create @folder in arma and editing shortcut ? I had 6-7 addons runing perfectly until i aded NWD Tank Fire control. I lost any sights in tank guner, the screen was clear, i can zoom in and out but i dont have any aiming device, then i noticed that this addon needs Extended Init Event Handler. I tried to add EIEH but i didnt managed to make tank fire control work , insted i lost 6sence tracers :/

[Maddmatt 1]

Sorry for a noob question. But how exactly do i implement this addon ? Copy to addons folder ? or create @folder in arma and editing shortcut ? I had 6-7 addons runing perfectly until i aded NWD Tank Fire control. I lost any sights in tank guner, the screen was clear, i can zoom in and out but i dont have any aiming device, then i noticed that this addon needs Extended Init Event Handler. I tried to add EIEH but i didnt managet to make tank fire control work , insted i lost 6sence tracers :/

You are using addons that conflict with this. Get rid of them and/or get updated versions. The new 6thsense stuff supports the extended eventhandlers addon.

[stun 5]

how many copies of the event handler do you need? at the moment I have one in my 6th sense modfolder and one in my armaeffects folder. The copies of the event handler in the folders are the ones that came packaged with the various addons. Do i need one with each addon, or can I just use one copy in my main addons folder?

[Maddmatt 1]

how many copies of the event handler do you need? at the moment I have one in my 6th sense modfolder and one in my armaeffects folder. The copies of the event handler in the folders are the ones that came packaged with the various addons. Do i need one with each addon, or can I just use one copy in my main addons folder?

You only need one. Having more than one copy of an addon doesn't do anything.

[dmarkwick 261]

how many copies of the event handler do you need? at the moment I have one in my 6th sense modfolder and one in my armaeffects folder. The copies of the event handler in the folders are the ones that came packaged with the various addons. Do i need one with each addon, or can I just use one copy in my main addons folder?

Yeah as MM said just one set is needed. It's quite an important addon (and will become even more so) so it justifies a place in your default Addons folder, where you will always know where it is and can update it if & when it becomes necessary.

[Kirq 0]

Do i have to put Extended_Init_EventHandlers.pbo, Extended_Fired_EventHandlers.pbo and Examples folder i arma/addons folder ? just like that ?