Event Handler priority

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