RUG_BodyArmor v.1.1 (ACCEPTED)

[Wolfrug]

Hey all!

Edit: Version 1.1 is out now, should be ready for review/upload. Check it out if you can find any bugs
I -might- yet in the future create a version which adds the possibility for proper anims upon death (currently a rather ugly switchmove) using Mando Unit Position to see if they're crouching or standing etc, and maybe incorporate some kind of POW-taking ability on enemies/yourself. But those can be done by mission makers as well, and might require external scripts.

This isn't really much : just a tiny self-sufficient script that simulates a -very- crude "body armor" which might increase the survivablity of at least your own soldiers. It is not suggested to use these on enemies - it's no fun scoring a straight headshot and getting nothing for your pain. Also, 1.09beta is recommended, since I'm using a whole bunch of globals and the like, hopefully making things a bit faster.

Script call: [UnitName, Mode, Init] execVM "RUG_BodyArmor.sqf" (can also be used with for instance foreach to give body armor to each member of your squad).

Unitname : name of the unit, quite simply. Can be this if called from init.

Mode : Currently supports four modes : 0, 1, 2 and 3. In 0, once the unit's body armor has been depleted and the unit has been knocked down, it will never return and the unit will be as defenceless as a standard ArmA dude. In 1, the body armor is fully regenerated between knock downs, which means there are only really two good ways to kill these people: high caliber weapons, or shoot 'em when they're down. 2 is the "Medevac" mode; the unit will regain full body armor once it has been fully healed, for instance by a medic or a medic tent. 3 is essential invulnerability: the unit is knocked unconscious, but can be revived, and is invulnerable during all these stages.
 
Init: this number should be less than 0, which tells the script it's initializing. The number also determines the total amount of body armor the unit should have in a relative way: the total body armor is directly derived from their config "armor" entry (for normal soldiers it's 3); this is then multiplied with the positive equivalent of the Init value. Make it -1 to give the units 3 body armor, -2 to give them 6, 0.5 to give them 1.5 and so on.

How the "body armor" works: It uses the little-known fact that you can set negative values to a unit's Damage using setDamage: however these negative values aren't persistent, and disappear with the first "hit". By having a "hit" eventhandler however which constantly resets the negative value, you can have invulnerable units. This has been used in various missions before, such as in Surdus Priest's. What my script does is stores the amount of damage done in each hit (which the "hit" eventhandler picks up), and once it surpasses the total body armor value, the unit is knocked "unconscious".

Being unconscious: Once the total body armor has been surpassed, you're unconscious (well, the units are switchmoved into a prone position and setCaptived, nothing else). This either lasts a random period (presently set to about 2 minutes), until a medic gets to you (your damage levels decrease) or someone uses the "first aid" action that's added to you. After that, depending on your "mode", your body armor is entirely regenerated, or you're left without it. Note that although units that are unconscious can call an AI medic to help them, it doesn't always work (depends on at what angle the medic approaches if the knocked down AI can use the medic action or not).

As of v.1.0, a knocked-out player or AI will automatically "call for help" within a 50 meter radius, prompting any friendly AI unit nearby to move to the knocked out unit's location and perform first aid. Note that the AI will smartly first check if any known enemies are closer than 100 meters: if that is the case, the fighting is still too intense to perform healing actions. Note that as team leader, you can still order the AI to heal someone (for instance you) via the action menu, regardless of the proximity of enemies.

Caveats: Since this uses a simple "hit" eventhandler with setdamage, the body armor does not take into account WHERE you are hit; headshots, legshots, they're all the same. Also, certain large caliber weapons such as the .50 cal, rockets, etc. will still kill you immediately (unless using mode 3). And finally, I have no idea if this works on a larger scale or not, or how it takes to streaming and such. 

This is more or less finished now, although I sort of wrote it pretty quickly over the weekend, so it's no master piece of coding. But it's kind of nifty, I think. Attached example mission (sorry about the size) and script. Note both the mission and the script still has a bunch of hints and such in it to track the progress of stuff. Enjoy! 

Version history:
0.1 BETA
-Initial release
1.0 RC
- Added ability for AI to independently administer first aid
- Added modes 2 and 3.
- Minor changes to demo mission (can choose mode at start, random weather/time just for fun, player = team leader...)
1.1 RC
- Fixed some minor bug with the helpers
- Other slight fixes and tweaks
- Minimized size of demo mission
- Added an explanation to the script itself on how to call it

Wolfrug out.

RUG_Bodyarmor v1.1

[LeeHunt]

hi Wolfrug,

Gave this demo a try, i like the idea.  The body armor "unconscious" hit appeared to work- my player was knocked down prone and unable to move but also appeared to be "setcaptive true" as you mentioned.  My teammates however had the notorious Scalar Bool Array error come up when they were hit.  Not sure what's going on.  It is a cool idea though and I like it, just initial test thoughts here...

[Wolfrug]

The scalar bool error in the hints (if that's what you're referring to) comes from me renaming a variable in the last moment, which I forgot to rename in the actual hint. In this case it's just the second value in the array passed to the script by the "hit" eventhandler, namely causedBy; which I don't use at all. So it shouldn't be a problem.

Also I tested the script as a team leader yesterday evening: telling them to use the action via the action menu will actually have the AI soldier move all the way over to your "unconscious" body and begin the heal action :O Maybe it's an ArmA novelty, but at least back in OFP telling them to do stuff like that would just make them magically activate the action from wherever they were - be it hundreds of klicks away.

Knowing this, I'll script in some kind of algorithm that checks for nearby friendlies, and if said friendlies are capable of helping, they will. Should make stuff a bit better.

Another thing: as you've noticed, the transition to unconscious happens through a pretty ugly switchmove to "DeadState". I could use some other animation as well, but at least DeadState looks very particular when you're...dead. If you use playMove with "DeadState", then the unit plays the appropriate death animation, depending on its stance etc. However, for some weirdo reason, you can't get out of the playmove -_- No matter what you try, the unit will always go back to playing the "I die now" animation, which is really fricken annoying. If anyone knows how to break out of a "dead" playmove, do tell.

Anyway: this script is mostly meant as a small enhancement to your own squad or your allies' groups; just something that makes them a -little- less likely to die en-masse the first time they smell an enemy. It's no true body armor, since it doesn't care about headshots or legshots or anything else, but for those quick firefights where you're not really looking where the enemy's shots are landing, I think it's pretty cool. 

By the way: for a mission maker to manually reset the body armor, simply use: UnitName setVariable ["RUG_BodyArmor", 0]; <- will put the total damage of the body armor back to 0. To manually set (or check) the maximum damage sustainable, use: UnitName setVariable ["RUG_BA_MaxD", #]; With # representing the number. You can also change the "mode" on the fly using, surprise surprise; UnitName setVariable ["RUG_BA_Mode", #]; So far, there are only the two modes mentioned above.

Any more suggestions on features and the like, feel free to tell!

Wolfrug out.

[Mandoble]

You might try to consider the following just for MP:
The unit locality for a group will change depending on the locality of the leader, and hit EH is local to the unit that receives the impact. Lets suppose the following:
group A: leader is player A, second in rank is player B. Player A dies definitively or leaves the game, now the units of the group should be local to player B.  But, the internal variables you are using are local too, so these values set by Hit EH when units were local to A doesnt exist for client B. This might generate a problem for this script.

[Wolfrug]

Hey there!

As I've stated elsewhere, online locality is still more or less a complete mystery to me, but I'm sure I can add those things if you walk it through with me step by step

Hypothetical MP scenario:

Group A, led by Player A has the script initiated on each member of the group. For all intents and purposes, the group is now "protected" on everybody's computer, even if Group B, led by Player B, is on the opposite side shooting at them?

Now, Player A disconnects ; does that mean all variables set with setVariable in Player A;s group are effectively nulled? I.e., the script can no longer update the state of the bodyarmor since the variables don't exist (which I think would lead to everyone in the group automatically getting knocked unconscious...either that or they'd have constant invulnerability O.o)?

What if player A isn't the leader, but just a group member. Is the group -still- local to Player A then?

In any which case, this could be fixed by having a check that checks if a player is in the group or not, and then rerun the script as necessary. But what happens if Player C joins the game and takes control over/enters Group A? Will the variables be nulled again/will the script not work on Player C's character/what? And what happens if Player A reconnects?

  Multiplayer. What about the 1.09b command addPublicVariableEventHandler? Could that maybe be used...somehow? Although that would make the script rely on 1.09beta. 

Phoie.

I'm planning on adding the following to the script:
More modes:
Mode 2: The unit will have no body armor after revival until it has been -entirely- healed by a medic or a medic tent (or script), thus necessating a sort of "medivac" after performing first aid on units.
Mode 3: The unit is invincible (can't be killed by high caliber weapons nor by shooting when down), but can be knocked out and revived as many times as is necessary. For "quest NPCs" and the like.
Maybe more?
Mode 4: Specific-class only mode? Only medics/SF/anyone you want can revive? Maybe, we'll see.

More AI features:
AI ability to find unconscious teammates and attempt a revival, depending on how safe they deem the situation. Unsure if this should work outside the group or not, I'm thinking yes - not sure how yet though.
AI ability to drag their teammates to safety using animations....yeah right.  I'll leave that to Solus and his SLX, since there is just no way to make that look any good without a proper addon.

Wolfrug out.

[Mandoble]

To make the story shorter. I understand you are basing your script in Hit Event Handler. Hit EH code is executed only in the client (or server) where the unit is local (well, this is what BIKI claims  ). So, if the locality of that unit changes, then the next time the unit is hit, the code associated with the EH will be executed in a different client or server.

Now the second rule, a unit is local to where the leader of its group is local. A vehicle is local to where the driver of the vehicle is local. So, if leadership of a group changes, the locality of the remaining AI units might change. For example, with player B becoming the leader. As you are using local vehicle internal variables and globals which are local to the client executing that script, then a change in the locality of the unit receiving the hit will generate a problem, as these variables are not published and the new computer (client) executing the code of the Hit EH might have different values for these variables for the very same unit.

So, might be you should have a "monitoring" script running in every client and the server attending to units (local or not) based on info published by code executed by local Hit EHs. This script might set locally the values of these internal vehicle variables. So, lets say this is named script S1, running in every machine. Script S2 (code based on hit EH) is executed in client A, and publish a flag and a value that is catched by every client running script S1. This script puts the value in local variables for the specified unit, so every client has the very same value for that internal variable of that unit.

Well, probably my explanation is not the best one, but at least a base to start designing a viable fix for the potential problem.

[Wolfrug]

Mandoble, I still honestly have no idea how to do that or what you're talking about

And anyway, there are things like Norrin's Revive script for MP enthusiasts - this thing was mostly meant for SP anyway. The code is faaar too unoptimized for proper large-scale MP usage, I'd dare say. And I have no idea how it'd work with respawning etc...a regular nightmare. Maybe? If someone -does- want to take a look at the code and try to turn it into MP, feel entirely 100% free to do so!

Report any bugs and such, and enjoy. 

Wolfrug out.

[Mandoble]

Should we consider this final and ready for submission?

[Wolfrug]

If it works for you, and it works for me, sure.  The demo mission is slightly unnecessarily large though, since it's just a copy-paste of the default "Clean Sweep" mission into Rahmadi (= it has pictures and briefings and sound files), but aside from that it should be all good. If you want to create an alternative demo mission which removes all the extra files, you can do that too.

I might update it in the future if there's need (adding more modes and the like, or, god forbid, allowing MP compatibility), but that's for the future!

Wolfrug out.

[Mandoble]

If you want to create an alternative demo mission which removes all the extra files, you can do that too.

The author is who determines which demo he wants the users to download. If the current one is good for you, we'll proceed with it.

[Wolfrug]

Actually hold it off a moment longer - I playtested this some more, and at least in 1.09beta, empty vehicles are also caught in the radius-of-help around people  And yes, I'll cut down on the demo mission's size a bit and fart out a v.1.1 soonish, which can then be submitted

Wolfrug out.

[Rommel92]

fart out a v.1.1 soonish

Now that gave me the giggles.

Great idea, and although I won't use it, its definetly given me an idea for a script thats a bit different, same knockdown concept, but you come back to conciousness yourself, might check what ammo the opponent is firing aswell, because if the shooters firing a 50cal round or tank shell, somehow unconciousness doesn't quite fit the bell.

Excellent work, and i'll be putting credits. 

[Wolfrug]

Well, you DO come back to consciousness yourself as well in this script, only it takes a while (something like a couple of minutes) to bounce back without help. It's this part of the RUG_BA_Down script that determines the amount of time before you get up:

Code: [Select]

_timer = [] spawn {sleep (120 + (random 15))};
Just increase or decrease that as you see fit!

Also, a couple of lines above that are these lines:

Code: [Select]

_id = _unit addAction [_text, "RUG_BodyArmor.sqf", _id, 9.8, true, true];
[_unit, _id] spawn RUG_BA_AIAction;

Removing or commenting out those lines will remove the "first aid" option.

And finally, regarding the different ammo types and such : if I had found some foolproof and simple way of determining a) where you were hit and b) what type of ammo was used, I could've added a much more complex "getting hit and going down" simulation. But I ran into some problems - maybe you'll be able to fix them, in which case you've definitely created a superior "bodyarmor" simulation!

1) Using the dammaged eventhandler, it's possible to gauge where a unit's been hit (head, arms, legs). However, the dammaged eventhandler simply isn't -fast- enough for the setdamage -5 to kick in! Try it yourself : place down one unit with this init field:

Code: [Select]

this addeventhandler ["dammaged", {_this select 0 setDamage -5}];
And one unit with this in his init field:

Code: [Select]

this addeventhandler ["hit", {_this select 0 setdamage -5}];
The latter one will survive your barrage of bullets, whereas the former won't. Although I suppose a dammaged eventhandler -might- work for very far away, low-damage shots, where you can still say stuff like a headshot is immediately lethal, whereas a bodyshot would not be. However, here's the problem: say you're simulating no bodyarmor on the legs. Your unit gets hit in the leg, and goes down to 0.5 health. What now? Using setDamage 0 or setDamage 0.5 or somesuch in a dammaged or hit eventhandler isn't going to prevent death, meaning your 'bodyarmor' just got pretty much useless because someone got hit in the legs. This is sadly due to the hitpoint system in ArmA, and I can't really see any immediate solution for it right now. :-/

2) How were you planning on doing this? And anyway, there already is a system like this of sorts in place. Have you tried opening up with a .50 cal on one of the default (not mode = 3) units with bodyarmor? The -5 setdamage won't be able to stop that, meaning the damage goes over the pain threshold, meaning the unit dies before the script has time to kick in. This is the only basic difference between mode = 3 (invincibility) and the other modes : in mode 3, the unit receives a whopping -500 damage instead, meaning not even dropping a GBU or shooting a D-30 shell into his face is going to make any difference.
However, if you feel the units are -still- a bit too hardy, simply change the -5 to something less like -3 or -2 or somesuch : the risk of them getting two consecutive shots of something high-caliber that knocks them out is considerably greater. I didn't add a simple system for changing the minus-modifier in the whole script, stupid me, so you'll just have to go around switching all the cases of -5 to whatever minus you want.

Anyway, good luck with your effort as well! The knockdown effect is really the main reason I made this script, not for the somewhat hokey 'bodyarmor' effect - too bad dammaged is such a crappy eventhandler, and too bad Hit doesn't return the -actual- total damage done (i.e., a hit to the head and a hit to the legs register the same damage, even though one is lethal and the other is not).

Wolfrug out.

[Rommel92]

Does the hit event handler not return: [unit, causedBy, damage].
In which case you could check the object or causedBy for the ammo type? Shame it doesnt have a "FiredBy" if it is indeed a bullet, but none the less.

For the damaged event handler:

Code: [Select]

_hitselection = _this select 1;

? (_hitselection == "body") etc
Thats worked for me in the past?

the unit receives a whopping -500 damage instead, meaning not even dropping a GBU or shooting a D-30 shell into his face is going to make any difference.

haha, guess you called it invincible for a reason.

Sorry if my reply seemed smug, it was in no way meant to offend you.

[Wolfrug]

Yes causedBy = the unit who damaged you. Now, you -could- use this information to figure out the potential weapon used to harm your character, by checking what weapons the unit dishing out the damage is wielding at the time. But what about tanks or helicopters or vehicles with more than one weapon? AFAIK, there's no way to tell which weapon was selected at the time of the shooting. Same thing with personal weapons, really, since a unit might have shot at you with his primaryWeapon, his secondary, or his launcher (yes : there are some scripts that are capable of checking the weaponInHand thing, but between shooting at you and you getting hit the person might've switched weapons). Besides, as mentioned : setdammage -5 isn't enough to stop .50 cal bullets at close range anyway, not to mention rockets and other things that go big-boom, so I figured I might as well let it be.

And the damaged eventhandler does return bodyparts, but, as I already explained, it's not as fast as the hit eventhandler. I don't know why, but that's the way it is. Also, you can't use both a dammaged and a hit eventhandler together, since the dammaged never runs if you immediately set the damage back to -5 on a hit. So I'm guessing there's some kind of internal order in which eventhandlers are run as well.  Although I'm sure the dammaged eventhandler could work on long-distance shots that aren't immediately lethal. But here's the thing: you want to make a real bodyarmor that covers only the torso, not the legs or the arms or the head. So, you create a script that, say, heals you back to whatever your current health was before getting hit whenever you're hit in the torso instead of any other body part. Even then, there're other problems:1) setdamage evens out damage across the whole body, meaning if you couldn't shoot properly/walk before getting your torso hit, you probably can now! 2) If you're already hurt, your bodyarmor will probably be useless, since a single shot to the torso will kill you anyway before the setdamage has time to kick in. That's why I use setdamage -5 instead of 0 : if I used 0, the unit would die half the times. 3) the aforementioned slowness of the dammaged eventhandler.

But good luck nonetheless!  If you manage to solve some of these problems, you'll definitely make a much better bodyarmor script than me.

Wolfrug out.