HandleDamage Shortcomings

[Big Dawg KS 6]

So I recently came across the new handleDamage eventhandler. It looked like it could prove to be really useful, so I started playing around with it. I thought it could be useful for simulating a more realistic armor penetration/damage model for tanks. For the most part it works well, however after a bit of testing I discovered quite a fundamental flaw with the eventhandler.

What it's supposed to do, as documented, is allow you to determine how to handle damage when a unit is hit. To do this, you can put any code in the eventhandler that evaluates to either true (kills the unit), false (no damage), nil (seems to also do no damage), or a number representing how much damage to apply. However there is a problem that I came across when I tried to apply different amounts of damage depending on which part of the unit (in this case a tank) was hit.

Like the "damage" EH, handleDamage passes information such as damage and hit location (which part of the unit was hit). Also like the damage EH, it can fire multiple times from a single hit (if multiple parts are damaged). This is however where the problem arises...

Let's use an example from my script. Basically, the script would determine how much damage to apply based on where the tank was hit. Because a single hit could trigger multiple instances of the script, each on a different part, depending on the part the tank could recieve different amounts of damage for each instance. The problem I discovered however is that the damage applied by all instances of the eventhandler are not accumulative, but rather whatever the damage was for the last executed instance was would be the only damage applied. So for example, if one part recieved 0.6 damage (60%) and the rest took 0, unless the 60% damaged part was the last part to be "hit", the tank would recieve 0 damage.

Ok, so that means the returned damage is the absolute damage of the unit (basically same thing as using setDammage). So I figured I'd try using getDammage and addition to make the damage accumulative. This however did not work, because getDammage (also tried damage, same function as getDammage) would always return the damage of the tank before any of damage from the handleDamage EH was applied, usually 0, meaning that even with getDammage the last instance to execute would still return the damage of the tank prior to being hit (usually 0) + calculated damage for this instance (also usually 0), thus making it impossible to effectively apply the proper amount of damage.

Hopefully I've explained this well enough as to make it easy to understand exactly what the problem is (as I see it). My hopes in posting this is to get the attention of BIS and hopefully convince them to alter the behaviour of this EH (in a future patch) so that it will allow for the kind of thing I'm trying to do.

[Defunkt 431]

Bummer, it would be great to get a better penetration system. I'm new, is there anywhere else (i.e. another property of the vehicle) you could store the accumulated damage so the correct value is available to you in each handleDamage call?

[Big Dawg KS 6]

But then the problem becomes how do you know which instance will be the last to execute. It still relies too much on oder of execution, and that's not going to be consistant/reliable.

We can still use it to set a minimum damage value, for example to stop small arms from eventually destroying tanks, but I was hoping to make a part specific system.

[Defunkt 431]

I've misunderstood then. I understood your return from handleDamage is always applied as the vehicle's new total damage in which case maintaining a separate running total (not susceptible to getDamage's vagaries) that is always returned by handleDamage would see the final damage correct regardless of the order called.

[Big Dawg KS 6]

Yea it seems like in theory it could work. However I did try doing something like this by storing it with set/getVariable. Maybe I did something wrong (it's hard to wrap your mind around this problem), but it didn't seem to have any effect. I guess I'll give it another shot some time.

Actually, the problem with that is that you still have to return a damage value for each instance. I suppose I could just return the current accumulated damage since the last one will overwrite it anyway. Heh, never thought of that... just goes to show how value another person's opinion is. Well I'll check it out when I get home.

[Big Dawg KS 6]

So that worked. However I don't expect to ever get the results I was hoping for simply because ArmA's simple damage model is getting in the way. As it is, regardless of where you hit a vehicle the damage is for the most part distributed to every part. So even with this EH there's no way to know which parts of the vehicle were actually hit, and which parts just took distributed damage.

[Defunkt 431]

Nevertheless, you can always return 0.0 damage for the 7.62mm vs T-72 scenario which is a huge improvement.

[Big Dawg KS 6]

Indeed. Still, I hope someday to see improvements here.

[[aps]gnat 28]

So even with this EH there's no way to know which parts of the vehicle were actually hit, and which parts just took distributed damage.

Huh? But you wrote that the EH returnes a location. Why isn't that useful?

[UNN 0]

What it's supposed to do, as documented

Where is it documented? The wiki just has an empty place holder.

The problem I discovered however is that the damage applied by all instances of the eventhandler are not accumulative, but rather whatever the damage was for the last executed instance was would be the only damage applied.

Well you can design the scripts to remember the damage passed and apply it once the handlers have finished. But I think the better way would be to use it in conjunction with the setHit command. That way all the damage should be applied properly:

Edit:

For future reference, you call the eventhandler like this:

_Object AddEventHandler ["handleDamage",{_this Call Compile PreProcessFile "UNN_SetHit.sqf"}]

UNN_SetHit.sqf:

private ["_vehicle","_selection","_damage"];

_Vehicle=_This Select 0;
_Selection=_This Select 1;
_Damage=_This Select 2;

[_Vehicle,_Selection,_Damage] Spawn {(_This Select 0) SetHit [_This Select 1,_This Select 2]};

False

Calling the script is imperative, as it provides better control over the timing of execution.

You have to apply the damage after the Called eventhandlers are finished, hence the spawn command.

Edited August 8, 2009 by UNN

[Big Dawg KS 6]

Gnat;1397542']Huh? But you wrote that the EH returnes a location. Why isn't that useful?

It does return the location. But every time the vehicle (in this case) takes a hit' date=' it fires multiple times for different locations (location being a vehicle component). So one hit will produce multiple locations.

Where is it documented? The wiki just has an empty place holder

Yea, the documentation I was refering to were just some notes on dev-heaven.

Also, UNN, I was able to use setVariable to accumulate the damage. Unfortunately it's still a bit buggy. For example, both damage and getDamage always return 0 even if the returned damage value was > 0, and the vehicle is visible damaged.

[nuxil 2]

i tested the handleDamage EH

seams like this doesnt work on planes.. can you guys confirme this ?

no part are returned.. I smell a bug in this EH. same goes for Dammaged EH

On heli Air classes it works fine.. just not planes

Edited August 10, 2009 by nuxil

[Defunkt 431]

I will be including it in some scripts I will hopefully be working on for the RHS/P85 guys.

Awww... why not a general purpose addon I wonder?

[UNN 0]

Also, UNN, I was able to use setVariable to accumulate the damage. Unfortunately it's still a bit buggy. For example, both damage and getDamage always return 0 even if the returned damage value was > 0, and the vehicle is visible damaged.

If all you want to do is apply the damage then setHit works fine. If you want to remember the damage then yeah, anything that allows you to store values will do.

I actually don't think it's bugged. Did the damage passed by the some of event handlers ever related to getDamage and setDamage? The way BI have it setup atm is more flexible IMHO. You can still apply damage with setDamage based on the values returned by the event, only you have to do it yourself. Which allows us to determine how it's used, rather than any fixed method.

seams like this doesnt work on planes.. can you guys confirme this ?

no part are returned.. I smell a bug in this EH. same goes for Dammaged EH

Are you sure it isn't just a case of, aircraft don't have any selections in the Fire geometry?

Edited August 22, 2009 by UNN

[Big Dawg KS 6]

Awww... why not a general purpose addon I wonder?

Maybe at some point. Right now I'm still working out the details of its implementation.

For example, should I add additional config values to all the ammo types or just use damage to determine penetration. Config values in the ammo classes would give more precision & versatility, but damage would be more universal.

Once I've settled on the implementation I'll worry about general purpose addon (since it will require modification to the vehicles' configs, another reason why it's easier to start with RHS/P85 tanks).

[Nice_Boat 10]

I did write something simple and it seems to work just fine:

_target = _this select 0

_selection = _this select 1

_damage = _this select 2

_attacker = _this select 3

_ammo = _this select 4

? _damage < 1 : exit

_target setHit [_selection, _damage]

The idea is simple: Armor value in the config file represents the top armor thickness of the vehicle, Hit value represents the penetration of a weapon. If the weapon hits multiple selections, the more fragile ones will get damaged to 1 (ie - destroyed), while others will be ok (for example a frontal hit will always destroy the lights, while a low hit has high odds for disabling the tracks without damaging any other parts of the vehicle - so I think it works just fine). That way actually aiming that RPG before engaging a tank will be the difference between mobility kill and no effect. Of course it would require a general overhaul of the .cpp files for weapons and armored vehicles to work realistically, as the default BIS values are "a little bit" arbitrary. Also, it could take into account the fact that HEAT rounds always penetrate more or less the same amount of RHA, while kinetic projectiles have less power over long distances (as simple as _target distance _attacker and then doing something with the value using some simple formula to modify the damage after checking if the impacting round is on the list of SABOT and perhaps HMG rounds). Of course some randomization could be easily added too: ? _damage + random 0.5 < 1 : exit would work just fine while still retaining the penetrated-destroyed, ricocheted-no effect approach. Another good thing about it is that it could simulate birdcage armor pretty well, perhaps even ERA too. Heck, I'd do it myself if not for my poor .cpp skills :mad:

Anyway, if such a system was implemented (or, even better - became a standard with the addon makers), ArmA2 would be a giant step closer to actually simulating warfare, especially if someone converted NWD's excellent Fire Control System... I mean, we already have FLIR, after these two issues are solved ArmA2 is going to feel more or less like Steel Beasts, dropping the unrealistic Battlefield 2 approach to vehicle combat .

[.kju 3245]

Thanks for sharing your ideas and progress Nice_Boat and Big Dawg KS. :)

How about joining the Skype group chat of project CASP - common armour systems project.

You can see the current member list here:

http://dev-heaven.net/projects/roadmap/casp

The overall is to bring the people and devs together interested in that area.

CASP is about everything related to vehicle combat. Examples are the tank FCS by

NWD now maintained and developed primarily by zGuba. HeinBloed and Ike kindly gave

us the permission to use and improve their scripts TOW, arena, smoke and other

systems.

The goal is to improve that area of the game, sharing the information and releasing

modular addons that work independent and automatically for any respective unit.

[nuxil 2]

Are you sure it isn't just a case of, aircraft don't have any selections in the Fire geometry?

i loaded the a10 bis example model in o2.im no o2 expert but there is alot of stuff in the fire geometry. also there is some stuff in hit point thingy. so im starting to think its a bug...

in hit-points i see motor and 3 other things.

did anyone test if they can return dammaged / hit parts on a plane.

because i cant get it to work.

[UNN 0]

i loaded the a10 bis example model in o2.im no o2 expert but there is alot of stuff in the fire geometry.

Neither am I, but selection names are a basic requirement. Not had chance to install the tools, but if there aren't any then it will fail, if there are then it might be deliberate or a bug.

[charon productions 10]

Sorry if this has been brought up elsewhere.

But for infantry units, this also does not seem to work as intended.

If you put this in the config (or add an EH) :

handleDamage = "hintsilent format [""part %1"",(_this select 1)]";

and shoot the unit,it ALWAYS returns "legs" no matter if you hit the head,hands etc.

So maybe the damage is also distributed over the whole body and thereby fires many handlers and the "legs" part is covered last ?!

[celery 8]

Regarding infantry applications, I made this body armor script a while back. You have to note that the EH activates separately for each body part so you have to store some of the damage information one way or another if you want to find out which part was actually hit and how hard. Feel free to play around with the script and make it better.

It might also give some ideas how to handle vehicle penetration stuff.

Edited October 18, 2009 by Celery

[.kju 3245]

@ Charon Productions

More likely all parts are damaged. Debug to rpt instead of hint.

[Q1184 0]

Re: HandlleDamage on soldiers

For each hit this EH triggers 5 times within a frame, always in this sequence of parts:

1. "" - info on overall damage

2. "head_hit"

3. "body"

4. "hands"

5. "legs"

Multiple hits within one frame are handled one by one, not causing mixups

(1-2-3-4-5 - 1-2-3-4-5 - etc)

Hint will naturally always return the last part (legs).

[Planck 1]

Suma today updated the Biki entry for this EH.

http://community.bistudio.com/wiki/ArmA:_Event_Handlers#HandleDamage

Planck