Damage Description – Arma 3
Intro
An ongoing investigation on how damage and armor actually works in Arma 3. This page was initially based on Olds (talk) research during the creation of the Real Armor Mod ("RAM").
Sometime in Q1 of 2015, the RAM information will be removed from this page and relocated to its own wiki.
Damage vs. Penetration
It's important to understand that penetration and damage are not exactly the same thing in Arma 3--they have a slightly indirect relationship. For damage to occur, a vehicle must have:
- Fire Geometry modeled in its P3D file and
- HitPoints defined in its config.cpp file
Simply put: an attack must simultaneously penetrate both fire geometry and a hitpoint radius to cause (significant^) damage to a vehicle.
(^ In actuality, the game will perform a damage calculation as long as any fire geometry is hit--even if no hitpoint spheres are penetrated. However, the amount of damage caused by this effect is pretty negligible. So, while case D below produces no damage, case C produces some minimal damage.)
In the diagram above, attacks A-D are examples of direct attacks (indirectHit & indirectHitRange = 0). Attack E is an example of an indirectHit attack. As the diagram shows, armor (in the form of fire geometry) can protect against direct damage--but indirectHit damage can easily occur without penetration (especially when indirectHitRange is large). Only a hitpoint's minimalHit and explosionShielding values can protect against indirectHit reaching through armor to cause damage.
The consequences of the damage system for armor modeling is discussed later in this page.
The Typical Damage Process
This is how damage usually transpires with stock Arma vehicles (and most mod content as well, since it tends to conform to BI standards of vehicle creation).
1. Pre-impact
A projectile is headed for the target. (For our discussion let's assume its a kinetic round on track for a direct hit vs. an AFV)
2. Initial Impact
The projectile impacts the target. It has not penetrated any armor yet. And if it doesn't have the ballistics to go further it will terminate here doing only this initial damage. Regardless, the following things happen: Every major location on the target takes some damage. The location nearest the impact point gets the most, and it falls off geometrically. The target's global health is generally damaged the most. Several factors affect the amount of damage taken: obviously the hit value of the weapon is important, but various weapon & target config values are also involved (minimalHit, explosive, etc.). That's right, some damage has already been done regardless of whether it's pistol-round vs. tank or sabot vs. bunny. If the hit values are high enough, this initial impact alone can destroy the target (essentially by knocking out global health) ...regardless of penetration!
3. Penetrating Damage
If the projectile can penetrate the target's armor, it will continue moving and doing damage as it goes. Here's what happens: Every major location continues to take damage as in step 1. But something new happens as well... ...as the projectile travels past the armor it starts doing much more damage to the area immediately around itself. Global health continues to get damaged and can really get clobbered now. BTW, this happens even if every passThrough value is set to zero(!). The projectile will terminate here or travel on through the target if it has penetration power remaining to do so.
Keep in mind there are (sometimes significant) variations to how this works for things like explosive weapons, indirectHit, deflections, etc. More on those below. And, yes, this description holds true for human targets (shoot someone in the hand, and their head will take some damage).
Indirect(Hit) & "Explosive" Damage
IndirectHit
IndirectHit represents damage from explosions (not to be confused with the BIS "explosive" property). IndirectHit damage is applied whenever a weapon with that config property hits something (you, the ground, etc.) It causes damage out to 4x it's indirectHitRange (which is a radius) and--although BI claims the damage falls off linearly--empirical tests in Arma show a different pattern:
- Within 1x iHR: a large amount of bonus damage is caused whether the impact is direct or not--the damage is roughly 10x iH (!)
- 2-3x iHR: linear falloff from iH value as advertised
- 4x iHR: damage is minimal within this final range zone--roughly 5% of iH (whereas advertised linear falloff should start at 25% and go to 0%).
- The net effect is something of a simplified "bell curve" with extra damage at close range, and minimal damage at the edge of the range envelope.
If a target is within range (our trusty tank in the above diagram), it takes the same all-location damage described in part A. (The location closest to the impact takes the most damage and so on...) And just as before, global health takes the most damage. Ranged indirectHit damage bypasses your armor and damages you anyway. Only the explosionShielding (and minimalHit) property can mitigate this.
Note: the indirectHit 'explosion' radius effect appears to occur whenever a new surface is hit. This can occur just once when the ground is hit, or multiple times if the projectile has a high "caliber" and passes through several pieces of fire geometry.
Explosive
Not the "explosion" effect you're thinking of--that's indirectHit. This weapon property does only one thing: it controls how much hit damage falls off with speed. Weapons with no or 0 explosive value are considered fully 'kinetic' and lose hit value as they slow below their typicalSpeed. Weapons with explosive=1 are considered fully 'explosive' and do full damage regardless of the projectile speed. Values between 0 and 1 control the ratio of kinetic-to-explosive damage (i.e. explosive = 0.5 means half the damage falls off with speed and half does not). <!> QUIRK! Values >=0.7 nullify a weapon's armor penetrating ability (as if caliber=0)!. Use values <0.7 if you want your weapon to have normal penetration behavior!
Penetration & Ballistics
Bullet/Shell
Bullet/Shell ballistics are very simple and quite accurate. The only properties that influence trajectory are initSpeed (CfgMagazines) and airFriction (CfgAmmo). Such projectiles travel based on their muzzle velocity (initSpeed) and aerodynamic drag (airFriction), along with gravity-induced vertical drop. Penetration is simply a factor of [remaining projectile speed at impact] and [CfgAmmo>"caliber"].
Projectile slowing through armor (or any other kind of fire geometry), appears to be handled purely by the projectile's speed & "caliber" and the fire geometry's bulletPenetrability(WithThickness). "airFriction" ceases to be a factor unless the projectile makes it's way through the target back out into open air. No other target material properties (Density, etc.) appear to factor in to the simulation.
Missile/Rocket
Missile/Rocket ballistics are more complex (let's call them M/R's for short). However, unlike Bullet/Shell penetration--which works quite well--M/R penetration is broken in the Arma 3 code. BI ignores penetration effects for these weapons and relies on exaggerated hit/indirectHit values to cause target damage. (RAM fixes this bug/limitation--and adds some new features along the way--with some scripting).
Unguided
These projectiles still use the same two properties as Bullet/Shells to determine their trajectories, but add some more (all in CfgAmmo): initTime, thrust, thrustTime, and maxSpeed. The four new properties account for the additional effect of a rocket motor: after "initTime", "thrust" is added to accelerate the projectile until it runs out ("thrustTime"), while "maxSpeed" puts a cap on the projectile's top speed. "sideAirFriction" & "maneuvrability" (from CfgAmmo) and mass (from the P3D model) get honorable mention here. But it's not clear that they add anything to the simulation of unguided M/R trajectories.
Guided
These projectiles work as unguided M/R's above, but with added properties to account for the fact that they manuever to track a target. "sideAirFriction" is used like airFriction to create drag, but in the lateral axes (as the missile turns to follow a target). "manuevrability" controls the rate of turning ability (mass may also play a role here--in that higher mass M/R's have a harder time turning due to momentum--but testing is required to confirm this). There are also a few simple properties that pertain to how tracking is achieved, but they are beyond the scope of this discussion.
Ballistics and Network Code
Unguided Bullets, Shells, and Rockets (simulation = "shotRocket") ballistics are calculated locally/on the client only. They do not cause undue network traffic in multiplayer. Guided missiles on the other hand (simulation = "maverickweapon") broadcast their trajectory over the network, generating much more data traffic in multiplayer every time one is in flight. Think of guided missiles as little airplanes, clogging up the network with traffic as they fly around.
Limits & Peculiarities of the Penetration Sim
Arma fully simulates the trajectory through a piece of fire geometry only for projectiles that make it all the way through. The game does not really simulate movement within fire geometry. If a projectile is stopped by a piece of fire geometry, the game essentially^ treats it as if it stopped at the surface. (This is noticeable if you fire weapons while using a projectile tracing script).
Furthermore, if you fire a sufficiently high "caliber" bullet at a series of plates with setAccelTime set very low, you will notice a related curiosity. The bullet will slowly approach the plates and then appear to 'zip' through them in rapid succession, only slowing back down when travelling through air. This is also a consequence of the penetration code 'shortcut'. A bullet's travel time while inside a piece of fire geometry is not represented. As soon as the bullet impacts the geometry, the game calculates whether it has enough penetration to make it through. If it does, the bullet is instantly teleported to the other side of the geometry. (If it doesn't--as discussed above--it stops at the surface).
^There is one exception to this "shortcut": hitpoint damage. The game does (instantly) calculate the precise depth of a partial penetration for the purpose of determining whether any hitpoint radii were hit.
Armor Methods & Recommendations
This section contains advice about designing your vehicle's fire geometry ("FG") and hitpints based on the research presented in this elsewhere on this page.
Fire Geometry Placement
Some 'rules of thumb' regarding the preparation of vehicle FG:
- Use the most detailed and accurate armor data you can when creating your vehicle's P3D FG (armor). Correctly calibrated weapons are only going to give realistic results if your armor settings are realistic.
- Use accurate thicknesses, accurate angles, and accurate materials. Arma's penetration simulation is very detailed and takes all these factors into account to generate an accurate "line-of-sight" path of a projectile through vehicle materials/armor.
- Of course, the FG model is simplified and does not need to contain every little piece of geometry. Use just enough detail to capture the key armor areas of the vehicle (the Samples_F T-72 tank is a reasonably good example--although it could be just a bit more detailed).
- The material used for armor pieces should usually be "armour.rvmat" (with thickness is defined by your model geometry). Preset-thickness materials ("armour_plate", etc.) respect LOS thickness, so you can use those where necessary.
- Regardless of what the real vehicle uses for armor (aluminum, composite, etc.), the best practice is to translate them into RHA-equivalent thickness. (To be specific, we are speaking here of "RHAe-KE": the equivalent thickness of rolled homogenous armor steel vs. kinetic attack).
- Internal structure should be blocked in for receiving damage--see #Hitpoint Placement for Damage Consistency below.
- Avoid overlapping FG. Arma projectiles can skip through interpenetrating pieces of FG without noticing some of them. Arma projectiles tend to only "notice" the first piece of FG they hit if other FG is embedded within it. The greater the interpenetration, the more likely the error.
- In fact, it's desirable to leave some space--at least a few cm--between pieces of FG that don't need to be directly touching.
General Hitpoint Placement & Armor
As discussed earlier, Hitpoints are required for a vehicle to take damage. The style of hitpoint placement affects how a vehicle takes damage with respect to things like armor and penetration. One of the reasons that (stock) Arma vehicles take damage in the somewhat puzzling way that they do is due to their choice of hitpoint placement.
Hitpoint Radii
Recall from the "Damage vs. Penetration section that an attack must simultaneously affect both fire geometry and a hitpoint to produce damage.
Consider the following two approaches to hitpoint placement for the same vehicle--the front view of a simplified AFV. The polygons represent FG and the purple circles represent the virtual spheres created by hitpoint vertices and their radii.
Old Arma Approach
Modified "Internal" Approach
In the first approach, the vehicle will take major damage from non-penetrating hits. This is because the hitpoint spheres poke through the vehicle's FG. In the second approach, the hitpoints are constrained to be inside the armor layer (blue polygons). The second vehicle will take only trivial damage from non-penetrating hits.
Obviously, if you have non-armored parts of a vehicle that should be damaged by non-penetrating hits (tires, glass windscreens, unarmored vehicle parts, etc.), then their hitpoint spheres should "poke through" the FG in the "old" manner.
Hitpoint Stacking
Now let's consider two different approaches to hitpoint "stacking":
Old Arma Approach to Stacking
Modified "Overlapping" Approach
In the first example, hitpoint spheres are stacked so they do not overlap. This occurs frequently in Arma 3 vehicles. The second approach allows the spheres to overlap, with two resulting benefits:
- Generally a smaller number of (higher-radius) spheres can be used to define a volume.
- There are less "holes" between the spheres where a projectile can pass through without causing damage.
There don't appear to be any negative side effects to the overlapping approach; for example, overlapping spheres do not cause "extra" damage when a projectile penetrates through the overlap. BI itself increasingly has been using overlapped hitpoints in their models, so this approach should be considered safe.
Hitpoint Placement Recommendations
In summary: combine the two "modified" approaches for improved armor and damage performance:
- All hitpoint spheres should be "overlapping", and
- Any hitpoint spheres protected by armor should be "internal"
Note: BI itself has been moving away from the "Old Arma" method of hitpoint placement. Looking at recent revisions of the game (2015), you will notice that their tanks in particular largely follow the "modified" approach.
Hitpoint Placement for Damage Consistency
The previous section focused on general hitpoint placement with respect to armor and the penetration sim. But your FG must also accommodate the way the damage sim works. It is extremely easy to get very random damage results if you don't build your damage-receiving fire geometry and hitpoint (spheres) according to some very specific rules.
The diagram above shows 3 different methods of assigning hitpoint spheres to fire geometry ("FG"). The red FG represents an area you want to receive damage, while the blue FG represents armor that should not cause damage when hit. The purple circles represent hitpoint spheres (P3D vertices with radii defined by hitpoint class config file).
- A is the recommended way to handle FG. The damage-FG is separate from the armor FG and is evenly encased within hitpoint spheres. Whenever the damage-FG is hit, it will receive consistent, predictable damage.
- B is not ideal but can still work. It is not as predictable in its damage results as "A". In this case, the area without hitpoint spheres is intended to function as armor--receiving minimal/no damage. The rest of the geometry is encased in hitpoint spheres as in "A".
- C is not an acceptable approach. It combines several problems, and hits on geometry like this will produce very inconsistent damage results:
- the damage FG is not fully encased in spheres
- the spheres are not evenly placed within the FG
- several of the spheres are submerged inside the FG
Hitpoint Properties
The recommendations above will do nothing to make a vehicle safe from explosive damage--termed "indirectHit" damage in Arma terminology. IndirectHit damage reaches freely through fire geometry to damage hitpoints.
The only way to protect a vehicle from such damage is by adjusting minimalHit and explosionShielding properties. (These properties apply to hitpoint locations--BI has also recently added equivalent properties for global vehicle health called minTotalDamageThreshold and explosionShielding). Armored vehicles in particular should have a large enough minimalHit and small enough explosionShielding value to protect against minor indirectHit weapons. But they should not be so heavily protected that they are immune to large-scale indirectHit weapons (IED's, laser-guided-bombs, etc.).
Concluding Remarks on Armor & Penetration in Arma 3
- In vanilla A3, the effects of armor are largely ignored by the damage system.
- More accurately: armor penetration is present, but its significance is overwhelmed by the global hitpoint effect
- this due in part to the way hitpoint "spheres" are placed in many Arma vehicles
- the effects are particularly dramatic for high damage-value weapons and for indirectHit weapons.
- Caliber-based ballistics work very well, but caliber is bugged for rockets & missiles (it can't be added).
- Nor can the submunition feature be used as a workaround (it is also bugged for missiles, and limited/unreliable for anything other than high-trajectory artillery shells).
- A script-based approach must be used to enable those weapon types to penetrate armor correctly. RAM contains such an approach.
Adjusting Config Properties for RAM
(Expand for a summary)
(See the Config Properties Mega-List for an explanation of the properties themselves. This information is somewhat old and will be replaced with a new wiki for the RAM update coming in Q1 of 2015.)
airFriction, caliber
RAM adjusts caliber & airFriction values based on real-world data whenever possible. This yields accurate penetration values and ballistic trajectory. It corrects the Missile/Rocket penetration bug by editing those weapon types to create regular (bullet/shell based) projectile submunitions on impact, restoring penetration ability. (Rocket & Missile improvement cannot be achieved by adjusting vanilla configs - this requires script adjustment).
explosive
RAM either caps explosive values at <0.7 to prevent the no-penetration bug, or creates a penetrating submunition (e.g. HEAT warheads).
hit
BI tends to greatly exaggerate hit values for large caliber weapons, while RAM generally reduces them values to prevent armor-overwhelming damage.
Vehicle Config Properties
Global:
armorStructural
RAM generally ramps up these values to more or less cancel out the effect of global damage. (BI seems to have taken up the idea, and is creeping up armorStructural values in more recent configs).
Hit Location:
explosionShielding
These values are usually much lower in RAM than vanilla A3 (i.e. more protection against indirectHit).
passThrough
These tend to be zeroed out in RAM.
radius
[#>0,m?] the radius (in m?) of the location's hitpoint vertices in the vehicle's P3D model. The idea here is to spread the vertices throughout the internal structure such that they do not spill out into or beyond the vehicle's armor plates. Unless you have control over the P3D source file, you probably don't want to mess with this value.
HitTrack
[location class] Keeping in mind that this location generally has no armor geometry protecting it and is thus easily damaged by the slightest hit, RAM generally increases the protective properties of explosionShielding and minimalHit to make tracks more resistant to minor weapons.
Useful Links
(The VBS links are very useful, but do contain some obsolete/irrelevant information)