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

How much the projectile slows down as it travels through air. 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. (Also appears to be equivalent to Bird-Livingston's "ballistic K factor" * 0.0000001). [A, B, "WW2 Ballistics: Armor and Gunnery" (Bird-Livingston, 2001)]

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 = more penetration. And, of course, as the projectile slows, penetration decreases. Restating the formula: caliber = (mm penetration @speedX)*1000 / (bulletPenetrability * speedX). <!>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.

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".

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 angular milliradian = 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 (global)

Total hit points/'health' for the vehicle. Supposedly object radius somehow modifies this value, although the formulas offered by BI don't make much sense. 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 decrease 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].

secondaryExplosion

[obsolete?]. Does not appear to be used in Arma 3. There are secondary explosions for certain types of destroyed vehicles, but they are perhaps 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

explosionShielding

[float>=0]. A factor applied to indirectHit damage. Values < 1 make a location resistant to indirectHit damage, while those > 1 would make it more sensitive (this has not been confirmed--some properties have undocumented, hardcoded upper or 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 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 ]