Config Properties Megalist

Intro

Arma 3 documentation is scattered to the 4 winds, and this applies to config file properties as much as anything. This is an attempt to make a single master list of properties with links to [sources]. Yes, there are other partial lists but they have problems: short/confusing "official" descriptions, obsolete information, and no links to further sources. So rather than rummage and re-order the partial lists, this is an attempt to make a more comprehensive resource (at least by Arma standards!).

(P.S. This list was initially compiled in Fall of 2014, and should be up-to-date as of that point.~Olds.)

Existing Config pages

Here is a list of existing config pages on the Biki. They contain semi-official descriptions of properties. The descriptions tend to be short, incomplete, and/or confusing:

CfgVehicles Config Reference
CfgAmmo Config Reference
CfgMagazines Config Reference
CfgWeapons Config Reference
Model Config

This page is like a "Config Properties for Dummies" or a "Config Properties Explained". If you want the official description, go to the linked pages. If you want a more thorough explanation, use this page.

How Do Configs Work?

All configs get merged into one big config in memory when the game starts. Where duplicates exist, which config takes precedence depends on load order - the last config loaded "wins" by overwriting any previous value(s). Load order is determined by mod folder order, PBO name, but most importantly/properly by the "requiredAddons" section of the CfgPatches class.

CfgPatches & requiredAddons

The requiredAddons array in CfgPatches is how you control the load order of configs. "requiredAddons" means "load these other config files before you load this one." (And "this one" means the name of the class containing the requiredAddons statement). [ A,...]

How Many Config Files?

One consequence of the above discussion is the fact that you can technically spread your configs across tons of little files or ball them up into one big one or anything in between--with some exceptions^ (which are dicussed further below). Barring those exceptions, there is no iron-clad rule that requires certain classes (e.g. CfgAmmo, CfgVehicles, etc.) to be separated or located within particular filenames. It is essentially a matter of clarity, ease of editing, and consistency to help others understand your work.

^Known exceptions:

1. #include'd .h/.hpp files are usually in the same folder or a subfolder of the #include'ing config, but apparently they can be anywhere as long as you #include "pathtofile".
2. CfgSkeleton & CfgModels classes should be in either: a "model.cfg" file or a "[same-name-as-P3D].cfg" file. Unlike other config classes, these ones should not be thrown into random files.
3. The model.cfg file must be in the same folder as--or in a parent folder of--the object (P3D) it configures.

Weapons

For understandable reasons, weapons data is scattered across several different config classes. Defining a weapon properly requires working with all these classes.

CfgAmmo

Most projectile-specific properties are located here. Related properties--muzzle velocity for example--are located in other classes (either CfgMagazines or CfgWeapons).

airFriction

[float]. How much the projectile slows down as it travels through the air^. (A way of expressing aerodynamic drag). The formula is:

airFriction = deceleration / velocity^2

e.g. a projectile with a muzzle velocity of 1640m/s which slows down 94m/s/s (i.e. by 94m/s in the first second) has an airFriction of: -94/1640^2 = ~-3.5e-5. (This property appears to be equivalent to Bird-Livingston's "ballistic K factor" * 0.0000001). [A, B, "WW2 Ballistics: Armor and Gunnery" (Bird-Livingston, 2001)]

^A different formula based on bulletPenetrability & caliber is applied to slow projectiles passing through solid targets (fire geometry).

caliber

[float>=0]. Penetrative power of a projectile based on speed. (A value of 1 is standardized as 15mm of RHA penetration at 1000m/s.) The formula for mm of penetration is:

(projectile speed / 1000)x(caliber)x(bulletPenetrability of the target BISURF)

So higher values mean more penetration. And, of course, as the projectile slows down during its flight, penetration decreases. Restating the formula:

caliber = (mm penetration @speedX)*1000 / (bulletPenetrability * speedX)

Note! Adding caliber values to missile or rockets is bugged and results in missiles flying through targets. [A]

explosive

[1>=float>=0]. Proportion of damage that is explosive (rather than kinetic) and thus not reduced as projectile speed slows. This property has nothing to do with the colloquial sense of an explosion as 'splash' damage--that property is covered by "indirectHit". NOTE! Values >=0.7 nullify the penetration capability of the projectile, so keep values below this if you want the projectile to be able to penetrate armor at all.

hit

[float>0]. The damage done by a direct hit from this projectile.

Damage is applied to global hitpoins as well as locational ones. (The actual formula for applying damage is somewhat complex, so there is not necessarily a one-to-one application of hit value against hitpoints).[A]

indirectHit

[float>=0]. 'Splash' damage done by a near miss from this projectile. Projectiles with indirectHit values do damage within a sphere around their impact point (whether they hit the ground or an object). The size of the sphere is determined by "indirectHitRange". [A]

indirectHitRange

[float>=0, m]. Base radius in meters in which indirectHit damage is applied. indirectHit damage is actually applied out to 4x this radius, with linear falloff starting at indirectHit and ending at 0. [A]

initTime

[float>=0, s]. Missiles: how long it takes after launch for the missile's rocket motor to start. At which point the missile is moving based on its thrust parameters. (see "thrust", "thrustTime").

manualControl

[bool]. Missiles: true means the missile has SACLOS guidance (i.e. it continuously adjusts to fly toward wherever the player's crosshairs point). [A,B]

maxSpeed

[float >0, m/s]. Missiles: imposes an upper limit to the speed at which a missile can travel, regardless of its thrust properties. (see "thrust", "thrustTime").

muzzle velocity

Surprise! Muzzle velocity for a projectile is not found in CfgAmmo at all! Instead it is defined in the relevant CfgMagazines class and the property is called "initSpeed".

thrust

[A,B]

thrustTime

[float>0, s]. Missiles: how many seconds the rocket motor will produces thrust before dying out. (Keep in mind that regardless of these thrust properties, "maxSpeed" puts a ceiling on missile speed). [A,B, C]

typicalspeed

[int (m/s)]. Speed at which the projectile produces full "hit" damage; anything lower produces proportionately less damage (exception: "explosive" damage component is always full value regardless of the impact speed). Note that this property does nothing to influence the projectile velocity, it used only in the damage calculation. (See "explosive").

CfgMagazines

Magazine properties plus some projectile-specific stuff that gets stored here instead of CfgAmmo.

initSpeed

[int (m/s)]. Sets the muzzle velocity of the projectile type fired from this Magazine.

CfgWeapons

Gun/launcher-specific properties.

autoFire

[bool]. Whether the weapon will continue to fire if you hold down trigger. [A].

dispersion

[float>=0]. Weapon's dispersion in radians (1 milliradian = 1 angular mil = 0.001 dispersion, 1 MOA = 0.000290888 dispersion)

weaponLockSystem

[cumulative int]. What type(s) of lockDetectionSystem is set off in a vehicle targeted by this weapon: 0 = none, 1 = CM_Lock_Visual, 2 = CM_Lock_IR, 4 = CM_Lock_Laser, 8 = CM_Lock_Radar. Presumably canLock must = 1 for this to be relevant. [A].

Vehicles

tbd

CfgVehicles

armor (int)

[int>0]. Overall hit points/'health' for the vehicle. Supposedly object radius somehow modifies this value, although the formulas offered by BI don't make much sense.

Note that locational hit-points are derived from this value--determined by the HitPoint class's own "armor" (float) value. So the lower this value, the weaker all the vehicle's corresponding location HitPoints will also be (i.e. the more damage a location takes with each hit). [ A, B, C ].

armorStructural

[int>=0]. Divisor to global damage; the higher the value, the greater the reduction in global damage ("armor"/"hit points") taken whenever the vehicle gets hit by something. HitPoints class location damage is unaffected by this property, however; the location takes damage from the hit without modification. Extremely high values practically nullify the (in)famous cumulative "hit points" system of vehicle damage (e.g. plinking a tank to death with a rifle). [A].

damageResistance

Tells AI units how resistant this vehicle is to damage (so they can decide whether or not to bother attacking based on the weapons they are carrying). The calculation appears to be based only on the target's global armor and size, along with the weapon's hit value; armor & penetration are not factors. The formula for deriving this value is supposedly

(hit^2) / ( armor*((0.27/tgtRadius)^2) )

where "hit" is the value for the weakest weapon that the AI should find useful against the vehicle. How exactly the value is used by the game is a mystery. If the formula is correct, low values imply a weak weapon is useful, while high ones suggest only high-damage weapons should be used. [A,B]

hiddenSelections[]

[string array]. These are references to particular "sections" from the CfgModel (which in turn correspond to selection sets in the P3D) for this vehicle. These sections are designed to create variety within a single model by allowing the parts to be hidden and/or have alternate textures swapped out for variety.

[ A,B, fab.ofp.free.fr/Tutorials/Hidden_Selections.htm, tactical.nekromantix.com/wiki/doku.php?id=arma2:texturing:hiddenselectionstextures]

hiddenSelectionsTextures[]

[string array]. A list of (pathed) textures for use with hiddenSelections[]. The textures are assigned to the hiddenSelections[] elements in the order they are listed (first texture goes to the first element, and so on). hiddenSelections[] elements with no texture listed will be hidden at game startup, while those with a texture will be displayed and use the texture assigned. (see "hiddenSelections[]").

secondaryExplosion

[obsolete?]. Does not appear to be used in Arma 3. There are secondary explosions for certain types of destroyed vehicles, but they appear to be hardcoded. [A].

visionmode[]

[string array]. Which vision types are available to toggle through ("N" key) in this optics view. Options are "Normal","TI","NVG".

HitPoints class properties

armor (float)

[float>=0].

explosionShielding

[float>=0]. A factor applied to indirectHit damage. Values < 1 make a location resistant to indirectHit damage. Theoretically, values > 1 would make the location more sensitive (this has not been confirmed--some properties have undocumented, hardcoded upper/lower limits). [ A, B ].

name

[string]. Associates the HitPoints location with a named selection set of vertices in the relevant P3D's HitPoints LOD. Incidentally, the set name should be the same as a CfgSkeletons bone (so the game knows which verts move with which vehicle part). (See "visual").

passThrough

[0<=float<=1]. Proportion of damage to this location that is passed on to damage global vehicle hit points. 0 = the location can be destroyed without affecting overall vehicle health. This cannot be used to make a location cause extra global damage (since values over 1 are treated as = 1). (For that feature, see "depends").

radius

[float>0]. Defines the size of the HitPoint vertices in this location of the vehicle's P3D model. The radius creates a "sphere" of effect around each vertex. When fire geometry within this sphere is hit, the location takes damage. [ A].

visual

[string]. Associates the HitPoints location with a corresponding model "section" (defined in CfgModels). This is purely for visual purposes--if the section has multiple damage textures/states, this lets the game know which location damage causes a particular section's appearance to change. (See "name"). [Samples_F\Test_Tank_01\CfgVehicles.hpp].

Typical HitPoints classes

Existing HitPoints classes being used in the game have certain (hard-coded?) properties that you should be aware of.

HitHull

Used in tracked vehicles, this location automatically destroys the vehicle when depleted (regardless of remaining global health/"armor").

HitFuel

Used in wheeled vehicles, this location automatically destroys the vehicle when depleted (regardless of remaining global health/"armor").

HitTrack

Restricts mobility when depleted. Because these locations are not protected by armor plates, they extremely vulnerable to damage unless protected by tweaking explosionShielding (<1) and(/or) minimalHit (>0).

HitWheel

Restricts mobility when depleted. Because these locations are not protected by armor plates, they extremely vulnerable to damage unless protected by tweaking explosionShielding (<1) and(/or) minimalHit (>0).

HitTurret

Prevents the turret (turret optics view) from rotating when depleted.

HitGun

Gun (turret optics view) is stuck at minimum elevation when depleted.

HitAmmo

Ammo locations are not used in vanilla Arma 3, but could be added. Because it has no hard-coded properties, the only way to make it destroy a vehicle is to use the "depends" property to pass on its damage to HitHull/HitFuel.

HitEngine

Restricts mobility when depleted.

HitAvionics

Used in aircraft, it makes the HUD display flicker and disappear when depleted.

HitVRotor

Used in helicopters to represent the tail rotor, it causes the aircraft to spin out of control when depleted.

HitHRotor

Used in helicopters to represent the main rotor, the aircraft loses power when this location is depleted.

Model.cfg

A game model is defined by its P3D file and an associated model.cfg config file that describes the model's components. It consists of two classes: CfgSkeletons & CfgModels. [ A, B, C, D ]