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: obsolete information, and no links to their sources. So rather than rummage and re-order everyone else's 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, and can be 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 to 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. (Seems 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. Restating the formula: caliber = (mm penetration @speedX)*1000 / (bulletPenetrability * speedX). <!>Adding caliber values to missile or rockets results 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. Note! Values >=0.7 nullify penetration capability of the projectile, so keep values below this if you want the projectile to be able to penetrate armor at all. Note that this property has nothing to do with 'splash' damage--that is covered by "indirectHit".

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

[1>=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. [ 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].

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 ]