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.