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!).

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

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.

How Many Config Files?

A corollary to the discussion above is 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

Projectile-specific properties

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]

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

CfgMagazines

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

initSpeed

tbd

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

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. [ 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 the texture swaps. (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 ]