eventHandler "Dammaged" not working well?

[laggy]

Hi all.

In a "dammaged" eventhandler I want the unit to stay on initial damage level (which is 0,8) unless it's the head "hlava" that is dammaged. I can't make it work. Does anyone have any ideas?

Unit Init: this addEventHandler ["dammaged",{_this exec "headshot.sqs"}]


#START_SQS#

_unit = _this select 0
_bodypart = _this select 1

? _bodypart == "hlava" : exit

_unit setdamage 0.8

exit

#END_SQS#


It seems that in ArmA (unlike OFP) you can not revert the "dying process". Is that so? I also tried "killed" eventhandler to setdamage 0 on the unit, didn't work either.

Laggy

[Mr.Peanut]

http://www.ofpec.com/forum/index.php?topic=29789.0

[laggy]

Thanks.

Cheers

Laggy

[Mr.Peanut]

Check my edited post above!

[Wolfrug]

Having worked with these for my "bodyarmor" script, these are my findings:

1) Unlike OFP, it's impossible to revert the deadstate of a living unit: once they're dead, they're dead.
2) Native "dammaged" and "hit" eventhandlers are both slightly too slow when used in the traditional "unit setdamage 0" (or "unit setdamage 0.8") way : quite often the unit will be killed by two consecutive shots, or a single lethal one from close range. And, as mentioned, once they're dead they're dead. SOMETIMES it's possible to get a "living" guy who's lying dead on the ground and who'll tell you to hold fire when you shoot at him, but he'll be immobile forever (no way to get out of a "deadstate" playmove either)
3) To fix this it is possible using either the "dammaged" or the "hit" eventhandlers to give the unit negative health: unit addeventhandler ["hit", {_this select 0 setdamage -5}]; However using the "dammaged" eventhandler here is very much not suggested: the "dammaged" eventhandler FIRST calculates damage and where the hit took place, and then runs its attached script: this means the unit might very well have been killed before it was healed again. The hit eventhandler registers a hit and runs the script. And no: if you have a "hit" eventhandler that resets health to -5 all the time, and a "dammaged" eventhandler to boot, the "dammaged" will never run since the damage never has time to register before the "hit" resets it.

So in short: it is impossible (AFAIK) to leave a unit at 0.8 health until someone shoots them in the head - I'm guessing this is for some kind of zombie script, correct? Or, correction: if the unit would have an armor value bordering that of a tank, it would be possible, except for the fact the "dammaged" (or "hit") eventhandlers are rarely run when the damage is that tiny..... In other words, it's not really doable without an addon. Hence: go look for zombie-addons for all your zombie-bashing needs! There're a couple

(I might be wrong of course!)

Wolfrug out.

[laggy]

Damn you got me Wolfrug.

Zombies of course... thougt I could keep it hidden, as I wanted to scare the hell out of ignorant players in a "change genre" mission (like Volcano in OFP).

Guess the negative damage thing (tried it and it is useless in plural) could maybe work in SP, if the eventhandler is only run on nearestObject [player, "civilian"].

Cheers

Laggy

[Mr.Peanut]

This is me thinking out loud. Take ideas below with a grain of salt.

0) zombie setVariable ["headShot",objNull]
1) Add a script to each zombie that checks for the nearest projectile. If it detects a projectile, have it record the position and velocity.
2) Check if a vector(line) extended from the bullet position following the bullet velocity intersects the zombie's head LOD. If it does then zombie setVariable ["headShot", _bullet]. In the Beta board thread for Mandoble's detect prone/crouching there are a couple examples of testing LOD intersection.
3) Add a hit eventhandler to each zombie. When the event handler fires a script first sets negative damage, and then checks not isNull zombie getVariable "headShot". If TRUE then execute zombie exploding head script.

Hopefully, someone wiser than I (wake up Mand!) can verify whether this idea might work. I can think of two possible problems: weapons with high fire rates, and non-standard names for head LODs.