Event Handler priority

[Kammak]

Anyone know how OFP prioritizes EHs?  Specifically, if a unit has a "hit" EH defined by the unit config, and then a mission editor adds a second "hit" EH in a mission, it **seems** that the mission-assigned EH runs prior to the config-assigned EH...is this correct?

Second, is there ANY mechanism that stops further processing of EHs for the same event, as in programming languages?


The situation I seem to be encountering is this:

MAP units have a "hit" EH assigned by the config that fires a TACTEvents function.

In every mission I add a "hit" EH as well.  Everthing works fine.

If I now take a BAS DeRa unit, and first assign the TACTEvents "hit" EH, then assign my standard mission "hit" EH, the second EH doesn't seem to be firing.  It seems that when manually added (instead of through the config), the TACTEvents handler is running first, and somehow disabling subsequent event handlers from firing.  In addition to the "hit" EH, this has also happened with TACTEvents "fired" EH and JAM2 "fired" EHs.

Obviously there could be something else happening too, but I'm curious if anyone has more knowledge on how OFP handles event firing.

[h-]

it **seems** that the mission-assigned EH runs prior to the config-assigned EH...is this correct?

I would say just the opposite...
As the config is read when OFP is loaded technically it should have a reserved place in the RAM (simplifiedly put) way before the init field placed EH which is read when the mission is loaded...
Or have you got some 'data' that says otherwise??

Second, is there ANY mechanism that stops further processing of EHs for the same event, as in programming languages?

removeEventHandler or removeAllEventHandlers??
(check the comref about those...)

I'm curious if anyone has more knowledge on how OFP handles event firing.

Badly as you can see
I think there's 'conflicts' when mixing config and non-config EHs...
At least it seems to be the case...

[Kammak]

RE: RemoveEH...what I was going after is some type of flag *within* an EH which stops the cascade....either nulling out the passed params or flipping a bool or something.

Most programming languages will let you determine if subsequent handlers should fire or not, from within an event handler itself.  Just wondered if that mechanism is in OFP too.

RE: Priority, yet I do believe the mission added EHs have priority, which would make sense...the mission added EH are specific, whereas the config defined ones are generalized.  It would make sense (from a programmatic standpoint) to give the specific EH first run before the more general default EHs...make sense?

Edit: I agree on the load sequence you described, but I'm guessing the devs applied a priority to mission-defined EHs as a design decision.  Just guessing however.

My "data" is only observational...specifically the situation in the first post.  When a mission-added EH and a config-added EH run together, its fine.  But when the config-added EH is manually added to a different unit, and runs first, it disables the second mission-added EH.  Which leads me to believe it is normally running second, after the mission-added EH, in the first scenario.

[Unnamed]

If I remember correctly, events in configs overwrite each other when you inherit from addons, just assumed it would be the same with script events?

But if it calls a function, then there is at least one solution. You can override that function (it's just a global variable after all) and add your own code along with the original function code.

If you do find out more, let us know. Cant remember seeing any info about this.

Cheers

Edit:

When a mission-added EH and a config-added EH run together, its fine.  But when the config-added EH is manually added to a different unit, and runs first, it disables the second mission-added EH.  Which leads me to believe it is normally running second, after the mission-added EH, in the first scenario.

Same goes for your two scripted EH, you can update your function to include both code sections....Hmm I did understand correctly. You want to add two different code segments for the same Event, at different points in your mission?

[Kammak]

What I want is for multiple EHs for the same event to work.  What I seem to be experiencing is that some EHs, sometimes, manage to disable subsequent handlers from firing for that specific event.

Example:  JAM2 and TactEvents.  By default, they both have a "fired" EH that will process different ammo types.  They work together fine.  However, if I try to make JAM2 handle an ammo type that TACTEvents also handles, it won't work.  In this case, TACTEvents gets it first, applies its magic, then when the JAM2 event fires, for some reason it doesn't work.  If I remove the ammo type from the  TACTEvent arrays, then TACTEvents still goes first, but immediately exits, then JAM2 fires, and processes it OK.

Ideally, both EH would work and apply their effects to the event.

In the case of "hit" EHs, I want BOTH the TACTEvents hit effects to work, and I want my "hit" EH to also work.   But again it seems that only the first one that fires actually handles the event properly (if it processes it and doesn't just exit).

When TACTEvents is defined by the config, it seems to run after my mission-added EH, so my EH works.  When the TACTEvents EH is added through the mission editor, then my EH added also, my EH doesn't seem to work anymore.  Note that I believe ALL the handlers are firing, but in some cases they are not able to function properly due to changes the first handler has made to the event params.

[Unnamed]

When the TACTEvents EH is added through the mission editor, then my EH added also, my EH doesn't seem to work anymore.  Note that I believe ALL the handlers are firing, but in some cases they are not able to function properly due to changes the first handler has made to the event params.

Why dont you remove the addevent TACTEvents from your mission, but include the TACTEvents code in your own event? So you have one event that calls both chuncks of code.

[Kammak]

Well, 2 reasons.  First, I want to understand what the problem is before I start looking for workarounds.  I'm curious exactly how OFP is dealing with EH priorities and cascades.

Second, I don't want to include 27 scripts and functions in every mission just for weapon effects, when TACTEvents already has them nicely bundled in an addon.  

Right now I'm in the "figuring out" phase...trying to get the "why" down.  I can always figure out a workaround, but I want to understand the overarching issue here first.

[Unnamed]

Well, 2 reasons.  First, I want to understand what the problem is before I start looking for workarounds.  I'm curious exactly how OFP is dealing with EH priorities and cascades.

From the sounds of it, ofp does not support multiple events of the same type being added in one mission. But then why should it, you only need one fired event handler per unit.  

Second, I don't want to include 27 scripts and functions in every mission just for weapon effects, when TACTEvents already has them nicely bundled in an addon.

You can call an addons scripts and functions from within a mission, or another addon e.g

Code: [Select]

[_This] Exec "\MyAddon\Scripts\MyScript.sqs"

[Kammak]

Well thats not entirely accurate.  The events do fire, and there are many reasons why you would want multiple handlers firing per each event.  Any event-driven system *should* support multiple handlers plugging into a single event.

The problem seems to be changes that *some* handlers make to the passed parameters, which screws up subsequent handlers that work with those same params.

For example:  If you add three "fired" EHs, and put a sideChat command in each one, you will see each sidechat when the mission runs and the event happens.   So OFP is firing all the events as it should.


RE: Calling functions from an addon - yes, that is how I added the JAM2 smoke effects for a LAW rocket...skipping the JAM2 EH routine and calling the script the EH calls.  But again, I'm not looking for help on a workaround, just trying to find out if anyone has more knowledge about the event system.

[Unnamed]

Well thats not entirely accurate.  The events do fire, and there are many reasons why you would want multiple handlers firing per each event.  Any event-driven system *should* support multiple handlers plugging into a single event.

When you have multiple turrets e.t.c I could see the rational. Same for handling events from addons and mssions. I just cant see why you would want to add an event twice in a mission, if you can, and only. Need to do it once?

The problem seems to be changes that *some* handlers make to the passed parameters, which screws up subsequent handlers that work with those same params.

Ahh I see, sorry I did not pick up on this before. The parameters change, for the same event type when called multiple times?

I guess it depends on the parameter? If it's the killed event, that passes the killer. Unless all the events are processed in an instant (which I would have thought it does) the killer may die while waiting for all events to complete. But are you sure it's not the code being called that changes the parameters, and not the event it's self?

Could you post details of the two events your trying to add?

P.S Good to know about addons and script events working together, I did wonder when including my own in some addons. But does it work the same for addons that inherit from other addons with events? I could not help feeling inherited events are lost in addons, if you try to add another version of the same event. Well at least for the init event, not tried the others.

[Lt.Shitkilla]

is there an eventhandler for the reloading of a weapon? i am having a little something happen when the weapon is reloaded. or some way to do the same with when the ammo in the current mag = 0, then call my script, but plz, any help would be appreciated.

-Lt. Shitkilla

[Kammak]

No reload or out of ammo EHs, at least that are documented.  There are **many** events I would love to see raised...hopefully in OFP2.

RE: Your specific example, only thing that comes to mind is spawning a monitor script (fast loop) as below:

Code: [Select]

#init
_startAmmo=player ammo (primaryWeapon player)

#loop
~.5
? player ammo (primaryWeapon player)==0:goto "empty"
? player ammo (primaryWeapon player)>_startAmmo:goto "reloaded"
goto "loop"

#empty
;Put your out of ammo code here
goto "init"

#reloaded
;Put your reloaded code here
goto "init"

There is no way I know of to tell when a player has reloaded, other than monitoring the ammo count and looking for an increase.

Hope that helps you!  

[Lt.Shitkilla]

 ;D Thank you so much, that's working perfectly. you shall be recognised when the time comes for release.

[KTottE]

How are you doing the multiple eventhandlers?

Code: [Select]

this addEventHandler["hit",""]; this addEventHandler["hit",""]

Like that?

Why aren't you doing:

Code: [Select]

this addEventHandler["hit","TACTEventHandler goes here; your other EH goes here"]

As far as I know it's not possible to add double eventHandlers at the same point in the hierarchy. I.E you can't config two hit-EHs on the same vehicle, and you can't addEventHandler two hit-EHs on the same vehicle.

You can combine the execution-code of two EHs into a single EH. You could even do evaluations in the EH to decide whether or not you should fire it, it's very common with addons.

Code: [Select]

if (a == b) then {[_this] exec "myScript.sqs"}; if ((a > b) or (a < b)) then {[_this] exec "myOtherScript.sqs"}

For example.

[Kammak]

Adding two event  handlers for the same event DOES WORK.  

The issue is that some EH seem to make changes to the passed params that screw up following handlers for that same event.

For example:  Take a standard BIS soldier, then add a "fired" EH which calls the JAM2 EH, and also add a second "fired" EH which calls TACTEvents fired EH.

The unit will show TactEvents effects when it fires a BIS weapon, and will show JAM2 effects when it fires a JAM AT4 or JAM RPG7.

Again, I'm not sure who exactly I'm talking to, but it is SOP for an event driven system to support multiple handlers per event.  OFP states it supports it, as to remove an EH, you have to specify the EH index...meaning there can be more than one EH per event type.

The reason why I'm doing it is simple - keeps the code components seperated (habits are hard to break).  I have one script that adds JAM2 smoke effects to a unit.  I have a second script that adds TACTEvents hit & smoke effects to a unit.  If the unit is a JAM2 unit, I only call the second script.  If its a MAP unit, I only call the first script.  If its a BIS/Laser/ORC/HYK unit, I call both scripts.

Call it a RAD mission design system...I don't like mixing code elements unless absolutely necessary.

[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.

[Kammak]

Its like trying to carry on a conversation about long division, but a little kid keeps interrupting to tell you 2+2=5.

It gets frustrating after a while.

[Unnamed]

From what I read I thought the issue was not pros and cons of multiple over single events but:

The problem seems to be changes that *some* handlers make to the passed parameters, which screws up subsequent handlers that work with those same params.

I took a look at both events, It turns out I had them without realising it:

One of the functions launched by the TACT event:

Code: [Select]

private ["_soldier","_ammo","_shot","_vel"];
_soldier = _this select 0;
_ammo = _this select 4;
_shot = nearestObject [_soldier,_ammo];
_vel = velocity _shot;
if (TACTbuckInUse) then {} else
{
drop
[
   "HandGrenade",
   "",
   "SpaceObject",
   1,
   1,
   getPos _shot,
   [
      (_vel select 0) * 0.06,
      (_vel select 1) * 0.06,
      (_vel select 2) * 0.06
   ],
   0,
   5,
   1,
   0.01,
   [0.2],
   [
      [0,0,0,1]
   ],
   [0],
   0.1,
   1,
   "",
   "",
   ""
]
}
And the Jam2 script:

Code: [Select]

_unit = _this select 0
_weapon = _this select 1
_muzzle = _this select 2
_mode = _this select 3
_ammo = _this select 4

?(_weapon in ["JAM_AT4Launcher","JAM_RPG7Launcher","JAM_M72LAWLauncher"]): _this exec "\JAM_Magazines\fx\launchSmoke.sqs"

?!(local _unit): exit

?(_ammo in ["SmokeShell","SmokeShellRed","SmokeShellGreen"]): _this exec "\JAM_Magazines\fx\man_popSmoke.sqs"
?(_ammo == "JAM_MarkerGrenadeammo"): _this exec "\JAM_Magazines\fx\smokeRocket.sqs"

exit
Assuming multiple events work without any problem (I dont know btw), it must be down to the order your adding them. The TACT events require priority as there using the Nearestobject command on the ammo. Any delay in calling this may result in the round being lost and _shot being set to ObjNull, in fact they have two of these functions for both the sparks and the wad making calls to nearestobject for the same ammo type, all being called from a third function. Probably more reliable using the one function, but probably better programing practice and more flexibile (From the TACT guys point of view) to use multiple functions.

So you could try this:

Code: [Select]

{_x exec "AddJamEH.sqs" ; _x exec "AddTACTEH.sqs"} foreach units group this
Perhaps it's a case of last one in, first one out?

As for multiple events over single events, depends on what your trying to do. In this case I'd say it was better to have a single high priority event that does all it needs to as quickly as possible? Depends on how consistent the effects are during heavy game play.

Should not loose sight of the fact that OFP is a game with a programing language, and not the other way around.

[KTottE]

That is exactly my point Unnamed. I thought I was going to be nice and offer a solution to the problem (multiple EHs not working correctly, with regards to the arguments being changed or lost) as well as a more efficient way of doing it in Operation Flashpoint.

Now I'm going to leave the thread, since Kammak doesn't appriciate my efforts, and apparently is agitated by my very being here.

Kammak, if you do solve the problem using your method, I congratulate you and hope that you will share the solution here.

[General Barron]

Oh yeah, I just remembered something. From my experience working with multiple fired EHs, they would only work once when running them from the editor. Let me explain: they would work fine when you hit "preview", but if you then hit "retry", they would not work. This problem didn't occur in exported missions. Could this be the problem?

[Kammak]

@ Unnamed:

So you think the occasional failure is just a timing problem, where the handler can't grab the correct "nearest object" to apply effects to?  That would make sense, as it would vary with mission activity.

The thing to remember is by default, TACTEvents and JAM2 never work the same weapon/ammo.  I merely made that example to demonstrate that (1) multiple events fire fine in OFP, and that (2) *sometimes* subsequent handlers don't work properly, though they do fire correctly.

I really don't use shotgun effects on AT4s in a mission.  

As for multiple handlers, again, they DO work.  I've got dozens of examples of them working fine in missions, both in editor and .pbo format.  Its a non-issue.  BIS intended multiple handlers to be attached, otherwise they wouldn't provide all the code to handle and remove multiple handlers (of the same event) from a unit.  Whether you choose to use multiple handlers is personal preference, (or obstinence as the case my be).  But its supported by the game.  It works.

[Kammak]

Oh yeah, I just remembered something. From my experience working with multiple fired EHs, they would only work once when running them from the editor. Let me explain: they would work fine when you hit "preview", but if you then hit "retry", they would not work. This problem didn't occur in exported missions. Could this be the problem?

I've not run into that.  I use one "killed" EH to hide dead bodies sometimes, and a second "killed" EH that increments a squad kill score...they work fine with multiple previews in the editor.

The JAM2 and TACTEvents also work repeatedly in the editor, at least for me they do.

[Unnamed]

BTW Multiple events do execute at the same time, well at least as far as OFP's clock goes, and the first one you add is the first to be executed.

So you think the occasional failure is just a timing problem, where the handler can't grab the correct "nearest object" to apply effects to?  That would make sense, as it would vary with mission activity.

I was just suprised the shotgun made two calls for the same ammo object, but if it works....I think making the call to nearestobject, straight from the event is more reliable?

Code: [Select]

player addEventHandler ["fired",{[_this,(NearestObject [_This select 0,_This Select 4])] Call MYEvents}]

[Kammak]

Config-defined Event Handlers definitely fire LAST, after all mission-defined handlers fire.  At least definitely for "fired" events.

I created a simple addon with a unit.  The config EH does nothing but have the player sidechat "EHFired just fired".

I then created a mission with that unit, added two more "fired" EH in the unit init field, both of which also have the player sidechat which script has fired.

The first mission added EH goes first, then the second mission added EH, then the config defined EH.

So it appears to be a design decision by BIS to have the mission added handlers go first, rather than a simpler first in last out system.  Proof being the mission-added EHs fired in the order they are added (FIFO) in mission, not FILO.