I'm not able to reproduce this. I created mission which contains one blufor unit (player) and one opfor unit. In file "init.sqf" is code which you can see bellow. After start of the mission opfor unit shoots the blufor unit and everything works as intended. Variable BIS_handleTest is changed to true and player is immortal after first hit. Could you please provide more specific repro? Thank you.

----------------------------------------------------------------------

BIS_handleTest = false;
player addEventHandler ["HandleDamage",{BIS_handleTest = true; player allowDamage false}];

while {true} do {
hint str BIS_handleTest;
sleep 0.1;
};

The problem is not that the event is not triggered. The problem is that the return values are not correct if you use more than one HD-EVH at the same time. It is simply the wrong way to put an EVH on a player object to handle some internal engine processes. (or whatever BIS_hitArray do)

Our eventhandler is the simple way how to solve some things and I still don't see the problem. I have five HandleDamage eventhandlers in my mission and everything works fine. Return value of each addEventHandler command is index number which is correct. Information in variable _this in each eventhnadler is correct as well.

We can try to fix this problem but we must be able to reproduce it. Could you please provide more specific info or prepare repro mission? Thank you.

DarkDruid, I'm shocked that a BIS developer does not know that adding more than one handleDamage eventhandler to an object results in unknown behaviour as it is unknown which result from which handleDamage EH the engine uses (especially if one tries to modify the _this select 2 values for his needs).

Attached is a simple test mission (HDEHTest). Shoot the unit in front of you in the head.
The following handleDamage eventhandlers are added via init line to the unit:

this addEventHandler ["handleDamage", {diag_log ["First HD EH returning _this select 2, _this:",_this];_this select 2}];
this addEventHandler ["handleDamage", {diag_log ["Second HD EH returns 0 instead of _this select 2 (which should make the unit immortal), _this:",_this];0}];
this addEventHandler ["handleDamage", {diag_log ["Third HD EH returning _this select 2, _this:",_this];_this select 2}];

The second handleDamage EH should make the unit immortal (it just returns 0) but the unit dies.

There is one simple rule when it comes to eventhandlers like handleDamage (probably explosion EH too): Never add more than one of them to an object.

Furthermore, you do not remove the handleDamage EH before respawn which means that it is still triggered for the dead unit (if it receives damage) and thus changing the variables even though the current player unit does not receive any damage.

Thank you Xeno. ;-)

Definitely a problem, the BIS handler seems to always get first "dibs" when it comes to returning the damage value, making it impossible for any addon or mission maker to actually "handle damage".

"Furthermore, you do not remove the handleDamage EH before respawn which means that it is still triggered for the dead unit (if it receives damage) and thus changing the variables even though the current player unit does not receive any damage."
I will look at it. Thanks for info.

Anyway, behaviour of multiple EH for one object is not unknown. Add sleep before adding your EH (for example "sleep 0.1"). Your EH will be processed as the last one and it's damage will be used correctly.

Feedback? So, is this a question if the workaround works/is sufficient for us, or will you still be looking into this?

The 'solution' that DarkDruid has given, is rather confusing.

What does he mean by 'Add sleep before adding your EH (for example "sleep 0.1").' ?? At what point? Is this to put it on the EH list at a specific index? What if the player is initialised, and then later given the EH, or, what?

A full example is needed.

If I understand DarkDruid correctly, the point is to ensure your EH is added <i>last</i>.

Deadfast is right. Damage returned by last added EH is used.

Unfortunately, we don't change it in this stage of the game. So question is if the workaround works.

*facepalm*

This isn't a solution - Have a look at the real problem that was reported here. It's enough to read the topic header again.
I think it's senseless to discuss with you Dark Druid.

^ this.

What good does this EH do exactly? From what I can tell, it just records useless stuff.

At least save the index to a variable, so people can get it and remove the damned thing, or know if it's defined, so they can waituntil {!isnil BIS_var_HDEHIndex} and define their own afterwards. Eliminating guess work.

So, you won't fix this during the ALPHA stage of the game? So what is alpha for exactly? An early showcase of mistakes and problems that won't be fixed?

Sleep is NOT an elegant solution to make sure your event handler is the last one applied. I find it completely unacceptable that BIS is unwilling to fix this during alpha.

So let me state the problems again..

1. BI to use addEH at all - optimization / conflicts.
2. BI to use HD event - conflicts.
3. To add HD onRespawn - EHs are sticky. http://community.bistudio.com/wiki/addEventHandler
4. To not remove HD onDeath. See Xeno's comment.
5. Potential locality problems in MP.
6. No index saved. See Radioman's comment.
7. Multiple HD on one object cause undefined behavior.

While processing Damage works fairly fine by adding a sleep.
I'm getting some rather strange selectionName readings.
If i shoot my dummy person in the Arms or Hit it returns "Hands" while Hits to the legs and Upper Body always returns "legs".

EDIT: Thank you Deadfast.

<b>@mantls</b>: Please see #8047.

It seems the issue here is with HandleDamage expecting return damage value to feed to the engine.

@DarkDruid you guys do some amazing stuff with adding new commands almost every day, why don't you create a new kind of event handler that is a copy of HandleDamage only it does not require to feed damage back to the engine? Call it HandleDamage2 or whatever, it looks like you can use it for what you are using original HandleDamage currently just fine.

In fact I'd use one myself, if all I want is detailed damage from a hit. Then people can stack this EH until they pop :)

This is still a problem in 0.77.109586.

While the EH no longer keeps re-adding itself on respawn, the automatic re-add does not guarantee the order is retained which brings us back to the original problem.

For now, the following can be used to work around this...

waitUntil {!isNil {player getVariable "BIS_fnc_feedback_hitArrayHandler"}};
player removeAllEventHandlers "handleDamage";
player addEventHandler [

"handleDamage",
{
   BIS_hitArray = _this; BIS_wasHit = true; // For BIS stuff to work
   // Your own handling here...
}

];

Does the EH need to be deleted?

waitUntil {!isNil {player getVariable "BIS_fnc_feedback_hitArrayHandler"}};
player addEventHandler [

"handleDamage",
{
   // Your own handling here...
}

];

Wouldn't this also work since it will be the last EH added so the engine will use only this handler return damage?

As I said, I experienced issues with the order not being maintained upon respawn.

Now that the handleDamage eventhandler was changed

http://forums.bistudio.com/showthread.php?160330-Development-Branch-Scripting-Discussion&p=2550677&viewfull=1#post2550677

it would be cool if the handleDamage eventhandler beeing used in fn_feedbackInit in the feedback system would also be changed (it still returns _this select 2).

(Edit: how about the explosion eventhandler?)

Na endlich!
Now let's take a look if it do what it should be to do.

Claimed fixed...

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2551502&viewfull=1#post2551502

I suggest you chaps re-test and confirm so this ticket can be closed :)

Should be fixed in current version of dev branch. Could you please confirm it? Thanks

The hole Bi-Team had needed round about 7 month to do anything at this thing. So let me please some days to found the timespace byside my normal work for switching to dev-build and test it detailed. :-)

Marking resolved.

Tested: the work around works. We can handle multiple hdeh's now. solved.
thx, for solve this ticket.

but, new issue opened: http://feedback.arma3.com/view.php?id=15948

Mass closing resolved issues not updated since November.