Event Handler priority

[Unnamed]

The Bas Delta Rangers include the following in there config for JAM weapons:

Code: [Select]

fired = "if ( (_this select 1 in [{Throw},{JAM_AT4Launcher},{JAM_RPG7Launcher},{JAM_M72LAWLauncher}]) or (_this select 4 in [{JAM_MarkerGrenadeammo}]) ) then {_this exec {\JAM_Magazines\FX\firedEH.sqs}}";
So firedEH.sqs is only ever called when one of the JAM weapons specified in the above code fire. You probably dont need to worry about adding multiple events, just dig deeper into each addons code, to see what conditions are needed for each to activate.

If its a BIS/Laser/ORC/HYK unit, I call both scripts.

That sounds like the one your interested in? Just need to check it's conditions. Using single or multiple events, your probably going to have to add your own code to get it working the way you want.

[Kammak]

I'm not sure I understand that post.

If "fired" above is a function variable, then its just showing an EH that calls the JAM2 scripts.  It is still an EH, and its checking the event param "_this" to get the weapon and ammo type.

Similar to what I manually add for non-JAM2 soldiers.

You can actually remove the weapon/ammo condition check, as it is repeated again in the actual JAM2 code.

[KTottE]

I don't understand why you're making it harder on yourself. Using if() then {}-statements you can make your single EventHandler do exactly what you want based on what unit it's added to. Something like:

Code: [Select]

if ((typeOf _this select 0) == "Classname")) then { [_this] exec {myCodeForClassname.sqs}

Where classname is the classname of the unit you want to check for. You could also nest IF-statements to get even more control.

Reading the official command reference, it doesn't state that you can add multiple eventHandlers for the same event, only that you can add multiple eventHandlers at the same time, I.E one hit, one fired and one init eventHandler.
I've never tried using more than one eventHandler for the same type in OFP, as this isn't logical.

If you're using eventhandlers in a real programming language, you wouldn't set up two eventHandlers to trap the exact same event.

Pseudocode:

Code: [Select]

class eventHandler(event fired)
{
     // perform the code here
};

class eventHandler(event fired)
{
     // more code here
};

This is what you are doing in OFP if you're doing two addEventHandler-statements for the same eventHandler type. It's not efficient and it's not smart.

[Kammak]

Here's an example of "proper" functioning of two eventhandlers (for the same event) in OFP.

New mission.
Place an init trigger (condition=true) with the following in the On Activation field:

TACTshotgunTypes=TACTshotgunTypes+["JAM_AT4ammo"]

Place a BIS soldier, with the following in his init field:

[[this],"m16","m16"] exec "TACTEvents\onPlayerInit.sqs";removeallweapons this;this addmagazine "m16";this addmagazine "jam_at4rocket";this addweapon "m16";this addweapon "jam_at4launcher";this addEventhandler["fired",{_this call TACTfuncFiredEH}];this addEventHandler["fired",{_this exec "\JAM_Magazines\FX\firedEH.sqs"}]

Now, when he fires the M16 you get TACTEvents smoke - good.
When he fires the AT4, you get **both** TACTEvents shotgun sparks AND the JAM2 rocket fire smoke - very good.

Both handlers process the fired event correctly.  I added the AT4 to the shotgun array as the shotgun effects are more noticable, so its easier to see the EH is working.

That should put the issue of whether it *can* work to rest...OFP handles it nicely and correctly.

What I'm still interested in learning is how one EH can disable subsequent handlers from working properly *for that specific event*.  And second, whether the mission-added EH's take precedence over config-added EHs for sure.

I may just have to make a quick addon tonight to settle the second question, but I was hoping someone else had already gone through this process before!  

[Kammak]

Reading the official command reference, it doesn't state that you can add multiple eventHandlers for the same event, only that you can add multiple eventHandlers at the same time, I.E one hit, one fired and one init eventHandler.
I've never tried using more than one eventHandler for the same type in OFP, as this isn't logical.

If you're using eventhandlers in a real programming language, you wouldn't set up two eventHandlers to trap the exact same event.

This is what you are doing in OFP if you're doing two addEventHandler-statements for the same eventHandler type. It's not efficient and it's not smart.

??

Very incorrect.  Its often extremely desirable to have multiple handlers fire for a single event, as you then contain specific code within seperate modules...thats kinda the point of event driven systems and publish/subscribe - one is to get rid of app polling, the second is to allow seperate code components to react to a change in a logical, sequenced fashion.  Which is also why event-driven systems include the ability to shutdown subsequent handlers within one EH - because it is expected that multiple handlers are waiting to process the event.

RE: In OFP - again incorrect.  When you remove an EH you specify the index and the event of the handler you are removing...because more than one handler can be plugged into the event for that unit.

RE: Not effecient and not smart:     Again incorrect.  It is good coding practice.  And its very efficient, as you don't have to put extra logic into *EACH UNIT*, but instead keep it tucked away in the EH itself.

But regarding my initial question, and the reason for this topic, your proposed solution doesn't address (nor fix) the problem.  You simply move some of the logic into every unit, but the sequence and the param issue remains.

[Kammak]

I don't understand why you're making it harder on yourself.

Actually I'm making things easier on myself, but thanks for the concern.  I originally started this by adding JAM2 smoke grenade effects to Marine Assault Pack units.  MAP units already have TACTEvents events defined in the config.  So by simply reading the JAM2 readme and the TACTEvents readme, it is obvious that you can add multiple "fired" handlers to a single unit, as they show you how....

But this situation was obviously thought of by BIS, as they expected some units would have config-defined events, but mission makers would still want to add other events too...again, its just the proper way you work with event driven systems.

So your proposed solution doesn't work for most cases, because I can't override config-defined logic, nor can I removed config-defined events (that I know of) at the mission-creation level.

I have a script that loads and initializes TACTEvents on non MAP units.  I have a second script that loads JAM2 events on non-JAM units.  I then exec those scripts depending on what kind of unit I'm working with in a mission.

Much easier (and simpler and efficient) than trying to iterate through 68(+) distinct unit types returned from typeOf to then figure out what to add.

I prefer:

{_x exec "AddJamEH.sqs"} foreach units group this

or

{_x exec "AddTACTEH.sqs";_x exec "AddJamEH.sqs"} foreach units group this

Simpler, no?

[KTottE]

Add the checks in the eventHandler. OFP doesn't have proper eventHandlers. Realize this and use them in the most efficient manner.

And that is by performing checks in the eventHandler before you execute the scripts. It works, it's efficient, and it's actually more readable and logical than two separate eventHandlers and performing checks inside the scripts.

Each time you start a script you have to initialize it and the variables, adding more and more to what OFP has to process. Be smart, consolidate.

[General Barron]

Haven't read this whole topic, but I have been noticing people saying you can't add multiple EH of the same type. I know I've added two "fired" EH's before, and they both worked (in fact, I used one to remove the other one). So I don't understand the problem.... but I guess I'll have to read the whole thread first, so I'll just shut up :X

[Kammak]

@ Kotte (not General Barron):

?

Are you actually reading these posts?  What are you talking about?

OFP does have proper EHs...which I just demonstrated how you can prove to yourself a few posts up.  Please read the posts before making more comments.

What you are calling "consolidating" is called "overworking the plumbing" in dev circles.

And again, what you keep suggesting has NOTHING to do with the original questions in this post.  Addons configure units with event handlers.  So do mission makers.  Its a reality.

RE: "More readable and more logicial" - ?? Part of the statement is pure opinion (readable), the second part is just plain incorrect.

You can't include all EHs in one script statement because some of the EH are defined in the unit config.  Logically, each separate item that needs to react to an event should define a distinct Handler.  You can uncouple that code as needed by simply removing the handler...in mission if necessary, rather than going back to code to rewrite statements.

Second,  isolating each code segment into distinct scripts, called by unique handlers, is the most efficient way to reuse code and lower debugging time.   Far better in *every* way than writing several logic statements into EACH unit to determine what code to fire for an event.  Especially considering the wide variety of units OFP mission makers can use in missions, with their varying config EHs.

OFP does have proper EHs for the most part.  Use it as intended...saves time in the long run.

[Kammak]

Haven't read this whole topic, but I have been noticing people saying you can't add multiple EH of the same type. I know I've added two "fired" EH's before, and they both worked (in fact, I used one to remove the other one). So I don't understand the problem.... but I guess I'll have to read the whole thread first, so I'll just shut up :X

You're entirely right.  Instead of getting help with my two questions, I've had to write an ad-hoc EH tute for those that are ignorant of their use in OFP, and programming in general.  Not what I intended.

My original query was:  does anyone know how OFP prioritizes handlers, specifically config added ones vs. mission added ones.  And second, what change can one EH make to the params that would affect and break subsequent handlers working that same event.

In same cases, two handlers won't work in succession, and I believe its because of a change one makes to the passed params.  But I'm not sure.  I had hoped someone knew more about the topic...so far, no luck.

[KTottE]

You're not understanding me. I'm talking about eventHandlers added by the command addEventHandler (the kind you are using). I haven't tried it but I would bet it's not possible to add more than one eventHandler of any given type in the config.cpp of an addon. Like I said, haven't tried it so don't quote me on that.

Disregard addon-eventHandlers completely.

Okay, now, what you are doing is this:
1. Add an eventHandler of type X. Make it execute code Y.
2. Add a new eventHandler of type X. Make this one execute code Z.

Code Y and Z in this case are both starting scripts (well, functions but it amounts to the same thing in OFP), which consume memory and resources.
The eventHandler is of type fired as well, which is probably the EH that gets triggered the most.

What you are doing also (I assume, don't know the exact code in the scripts you're firing, and I don't care to look either) is that you're firing the scripts regardless, and if the script applies the script applies.

What you should be doing is this:

Code: [Select]

addEventHandler["fired","if (check to see if TACT events apply) then {fire tactScript here}; if (check to see if JAM scripts apply) then {fire JAM scripts here}"]

This way, the scripts will fire if they apply, thus only using resources when they are actually needed and used. Instead of being instantiated each time someone fires, and probably 80% of the time it's not even necessary.

I'm arguing against your use of double eventHandlers because it is not smart. I don't care what your previous experience is, this is not something you would do in a real development environment. If you think this, then you are misunderstanding how you are using the eventHandlers in OFP.

edit
If you want to find out, you can probably test it yourself. Make an addon with an eventHandler and make a contradicting eventHandler in the mission (addEventHandler), see which one has effect in your mission.

Make multiple EHs, and hint format[""] the arguments in each EH in turn, see if something changes.

[Kammak]

This is starting to get funny.

Here's the situation, you are wrong on just about every count.  Even funnier is that you are still not addressing the only two questions in this thread.

First you were arguing two event handlers couldn't work.  I've proven they do.  General Barron has used them, many other folks have used more than one.

Second, you keep arguing as if you are an authority on event systems, yet you don't know enough to realize your statements are completely wrong.

Now, you are arguing about resource use on BOOLEAN comparisons!!  Just curious...are you a developer?  Before you telling people they are not smart, or they "should be doing this", you should really find out who you are talking to.  It prevents you from making an ass of yourself.

RE: The boolean checks, here's the problem:  First, you are just duplicating the checks that are already done by the EH code itself, which is unreachable from a mission-making standpoint.  It makes no sense to rewrite an addon for personal use, just to remove a few bool checks.  So I'm actually saving "resources" by NOT running the check twice.  It is stupid to make the engine run a comparison twice.

Second, "disregard addon EHs" - um, NO.  I'm using addons, I have to live with the addon EHs.  Simple.

Third, drop the "not smart" line.  Its bad form.  And its incorrect in most cases, but that's secondary.

If you choose to not use multiple handlers, great.  I couldn't care less.  But you need to hush about making others not use multiple handlers.  It works.  That is how event systems are designed to work.  OFP supports it.  Not using them is not "smart", it is just YOUR preference.

And after all that, we still have no answer to the original questions...please stay on topic from this point forward...I'm really just looking for input from someone that *knows more* about the event system in OFP than I do.

[KTottE]

If you re-read my statement regarding multiple eventHandlers you will see that I used the nifty phrase "as far as I know", which means that as far as I know (well, knew, since it's an old post now) it didn't work. I was wrong, apparently, but by using that very phrase I am automatically exempt from any statements including "you said".

Now, I am a developer, which is really beside the point. What I am is someone who has used eventHandlers in operation flashpoint and has learned how to use them efficiently. You need to drop all your notions that you're a developer now that you're entering the scene of OFP scripting.

I'll use some C# pseudo-code to illustrate what you are doing, hopefully it's clear enough for you to understand even if you're not experienced with C#.

Code: [Select]

static void firedEvent(object firingUnit, string weapon, string muzzle, string mode, string ammo)
{
     TACTFuncFired(); // which we pretend is a defined function here
}

static void firedEvent(object firingUnit, string weapon, string muzzle, string mode, string ammo)
{
     JAMFuncFired(); // which we pretend is a defined function here
}

I don't know what programming language, API or framework you have been using, but that's not good coding practice in any way, shape or form.

And, before you try and argue the use of resources in OFP, maybe you should learn how OFP uses resources first?
It's far more costly to instantiate a script than to make a fairly simple boolean evaluation, instantiate two scripts and the cost of resources is even greater.

Instantiate two scripts every time someone fires their weapon, and you're hogging resources like you wouldn't believe. Especially since you do not need to instantiate the scripts. Doubling up on the boolean evaluations is still just a fraction of the resource cost of instantiating a script.

And, as far as trying to tell me to shut the hell up, although not in those words, this is a discussion forum. If you don't wish people to reply to your threads, don't start threads. As long as posts do not violate the forum rules, you can't decide who gets to post in your thread and who doesn't, and you can certainly not decide what they get to post.

With regards to my choice of words, if you're offended by what I have said in this thread, then I apologize. But I uphold my opinion that it is not smart to duplicate an eventHandler in the way that you are doing.

And when I said "disregard addon EHs", I meant that I wasn't talking about an addon EH and a mission EH when I said "multiple EHs". I meant an addon and an addon or a mission and a mission EH, of the same type that is.

I am not arguing whether or not it can be done, I'm arguing whether or not it should be done, and by the examples you are giving, I'm saying it shouldn't be done.

[Kammak]

Too funny.

I think its the reverse re:entering the OFP world.  I created, own, and am the president of "Kammak Incorporated", which is a medical software company.

You may a limited dev experience, and for that, I am sorry.  As you broaden your developing skills, you will no doubt encounter event systems programming and publish/subscribe systems, which is what we are dealing with in OFP.

RE: The pseudo code - completely wrong example.

Use the dll model instead - the scripts are self-contained DLLs that can be re-used over and over.  One script handles one "concept", another script deals with a different concept.  By using distinct handlers, as is proper in an event system, the code can be plugged and unplugged as necessary from the system without affecting other handlers.

i.e. - Design the mission using TACTEvents.  If the player can't support it because of system constraints, either provide a UI option to disable it (remove that handler) or do it automatically by benchmark checks.

Another example: hide bodies on killed and squad kill count on killed.  Two seperate handlers that perform entirely different functions.  Absolutely stupid to call them from one ever-increasly complicated logic check on EVERY unit, which then provides no ability to unplug them at will in mission.  Again- some players may want to see dead bodies, some may require they disapper to free up resources...THAT has nothing to do with the kills score keeper which also fires on "killed".

You may have worked with EH in OFP, but you apparently never get too far into them, nor did you correctly interpret the documentation about them...so further statements about what you "feel" is appropriate coding procedure is highly suspect.

That, and your repeated claims that multiple handlers "should not" fire for one event, shows your inexperience with, and ignorance of, event driven systems.

We are not writing code that runs inline with the engine.  OFP is publishing events which scripts then subscribe to.  As many scripts as desired.  That is why BIS gives you an index when you attach a handler, and why BIS requires an index when you remove a handler.

At this point, you come across as nothing but a spammer - someone that is harping on a point completely immaterial to the topic of the thread.  In addition, you are incorrect about most of what you've written, and attempt to pass off personal preference as "coding rules", when they are mostly concepts that were outdated 5 years ago, let alone today.

[Noon416]

Now now, play nice people.

You would both benefit more by listening to each other's experience instead of beating each other up with it.