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 limitations: short/confusing "official" descriptions, obsolete information, and no links to further sources. So rather than wreak havoc with those lists, this article is an attempt to make an easier-to-digest resource.

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

WARNING! Page is still in an alpha state! Major work in progress! Lots of missing entries, resorting to do, etc. I will remove this warning once all my basic entries are in and it turns into a 'normal' page. -- User:Olds

Existing Config Pages

Here is a list of existing config pages on the Biki. They tend to contain semi-official descriptions of properties (though some entries have detailed descriptions). Unfortunately, the 'official' descriptions tend to be short, incomplete, and/or confusing--particularly for new modders:

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 an explanation in plain English, use this page.

(Once this page is complete, a sensible route may be to integrate its information into the existing pages to reduce redundancy).

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

Config Properties ProTips

A few tips and things to watch out for in config properties:

• "epe" in a property name refers to "external physics engine", i.e. NVIDIA's PhysX API.
• "Gunner" is often used in a propety name as a catch-all term that refers to whichever crewmember is in control of a turret/view (e.g. the commander is the "gunner" in the commander's turret).
• A few properties have somewhat misleading names, in that the common English meaning of a word is not what the property actually refers to (e.g. "caliber", "explosive").
• Inconsistent units: it's not uncommon for related properties to use different units for no good reason (e.g. radians per second vs. revolutions per minute). At least almost everything is in metric.

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. Some relevant properties you might expect to find here however--muzzle velocity for example--are located in the other weapon 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).

This & initSpeed define a projectile's trajectory in Arma (for unpowered ones like Bullets & Shells--Rockets & Missiles have additional rocket thrust features that influence their flight). As soon as an unpowered projectile is fired, it starts to slow down due to drag. The formula is:

airFriction = deceleration / velocity²

e.g. a projectile with a muzzle velocity of 1640 m/s which slows down 94 m/s/s (i.e. by 94 m/s in the first second) has an airFriction of:

-94/1640² ≈ 0.0000035

(This property appears to be equivalent to Bird-Livingston's "ballistic K factor" * 0.0000001).

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

[A, B, "WW2 Ballistics: Armor and Gunnery" (Bird-Livingston, 2001)]

airLock

bool

Whether this ammo type (& AI using it) can lock onto airborne targets.

Provided the related CfgWeapons also has locking capability--"canLock" is true. Unlike irLock & laserLock--which have corresponding CfgVehicles properties that they lock onto, airborne targets are identified in some other way. (see "irLock", "laserLock").

[A,B,C].

caliber

float≥0

Ability of the projectile to penetrate through target fire geometry (buildings, vehicle armor and components, people, etc.).

Penetration power is dependent on caliber and the projectile's speed--higher = more penetration. The formula for mm of penetration is:

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

So--as you would expect--penetration decreases as the projectile slows down during its flight. Restating the formula:

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

(A value of 1 is standardized as 15mm of RHA penetration at 1000m/s.) Note! Adding caliber values to missile or rockets is bugged and results in missiles flying through targets.

[A]

cost

int, ~$, (AI only)

A "monetary" value for each weapon.

This helps AI units decide on whether a weapon is worth using. Presumably AI does not waste high-cost weapons on low-threat or otherwise inappropriate targets. Seems to be vaguely calibrated in units of 1/3-1/4 $USD.

[A, B (contradictory)]

deflecting

90≥int≥0, angle in degrees

Determines how much a projectile ricochets.

When the ammo impacts something at this angle or less, there is a chance it will ricochet--bouncing off the target and doing less than full kinetic damage. Impact angles greater than this will not ricochet. If deflecting = 0, the projectile will never ricochet, while a value of 90 gives all impacts a chance to ricochet. Ricochets occur from impacts to targets or the ground.

[A]

explosive

1≥float≥0

The proportion of the projectile's damage that is explosive (rather than kinetic).

Unlike kinetic damage, explosive damage does not fall off as the projectile gradually loses speed. A value of 1 means the damage is fully explosive, while 0 means fully kinetic. (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. (See "hit", "typicalSpeed").

hit

float>0

The damage done by a direct hit from this projectile.

Damage is applied to global hitpoints ("armor" int) as well as locational ones ("armor" float). (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" and targets within the sphere receive damage.

[A]

indirectHitRange

float≥0, meters

Describes the range of a projectile's 'splash' damage.

This is the base radius within 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. (See "indirectHit"). [A]

initTime

float≥0, seconds, (Missiles only)

How long it takes the missile's rocket motor to start producing thrust after launch.

Missiles are launched at initSpeed. After initTime, the missile starts accelerating based on its thrust parameters. (see "thrust", "thrustTime").

irLock

bool

Whether this ammo type (& AI using it) can lock onto radar targets (CfgVehicles.irTarget = true).

irTarget vehicles are ones that are config'ed to show up on the game's simple "radar" overlay--i.e. tanks, trucks, etc., not humans. (You'd think "ir" would refer to infrared, but it actually refers to radar). (Provided the related CfgWeapons also has locking capability--"canLock" is true).

[A].

laserLock

bool

Whether this ammo type (& AI using it) can lock onto "laser targets", i.e. a laser designator dot (CfgVehicles.laserTarget = true). (Provided the related CfgWeapons also has locking capability--"canLock" is true).

[A,B].

manualControl

bool, (Missiles only)

A type of missile guidance.

True means the missile has SACLOS guidance (i.e. it continuously adjusts to fly toward wherever the player's crosshairs point).

[A,B]

manuevrability

float>0, (Missiles only)

Affects missile turning ability.

Higher is more manueverable. It's claimed very high values (>30) may cause missiles to over-manuever and spin out of control.

[A, [1]]

maxControlRange

int>0, meters, (Missiles only)

Maximum range for guided missile flight--whatever the guidance type--after which the missile spins out of control. (See "timeToLive").

[A, B]

maxSpeed

float>0, m/s, (Missiles only)

Missile speed limit.

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

nvgOnly

bool

Whether tracer is visible using NVG optics only.

If false, the projectile's tracer is normal and can be seen with unaided optics as well as when using NVG (infrared or thermal) optics. If true, the tracer is invisible unless the viewer is using NVG optics.

simulationStep

float>0, seconds(?)

How often the game updates the ammo's trajectory in flight.

The default appears to be around 0.033-0.05(?) If you assign a lower value, the game tracks the projectile more often giving a finer grained precision to its trajectory. This is presumably useful for things like fast moving projectiles, fast maneuvering guided missiles, projectiles with a high airFriction value, etc.. A higher value tracks the projectile with less detail. The results can be a bit unpredictable (e.g. values less than 0.001 can cause bizarre trajectories), so experimentation with a projectile tracing script is useful if you feel like there may be something wrong with your projectile's trajectory.

Contrary to the information in the VBS documentation linked below, this property can be assigned to a projectile of any simulation type, not just missiles.

[A]

thrust

float>0

Engine power of missiles and rockets. (See "thrustTime").

[A,B]

thrustTime

float>0, seconds, (Missiles only)

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]

timeToLive

float>0, seconds

Maximum lifetime for the projectile until it is culled by the game engine.

After a projectile is fired and this time has elapsed, the projectile is deleted from the game for optimization purposes; most projectiles simply disappear at this point, although certain types of explosive projectiles explode instead of vanishing.

[A]

typicalspeed

int>0, m/s

Influences how much damage the projectile does when it hits.

Speed at which the projectile produces full "hit" damage; anything lower produces proportionately less damage (exception: any "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 "initSpeed", "explosive").

visibleFire

float, meters?, "(AI only)

Distance from projectile that AI units will notice it. (See "visibleFireTime").

Not clear if this refers to the projectile in flight, when fired, at impact, or all three.

[A]

visibleFireTime

float, seconds, "(AI only)

How long AI units will notice the projectile. (See "visibleFireTime").

Values less than 5 supposedly cause problems because there can be 5 seconds between AI attention tests.

[A, B]

CfgMagazines

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

initSpeed

int>0, m/s

Sets the muzzle velocity of ammo fired from this Magazine.

(Not to be confused with typicalSpeed, which does not affect projectile speed at all and is instead used for damage calculation only).

CfgWeapons

Gun/launcher-specific properties.

aiDispersionCoefX/Y

float≥1.0, (AI only)

AI unit inaccuracy using this weapon (in X/Y).

These two properties are coefficients multiplied by the inherent weapon "dispersion" value. These are maximum values for inexperienced AI; as AI experience goes up, these values are shifted toward 1.0 (no extra dispersion). Supposedly there are other factors that influence AI inaccuracy besides these dispersion properties. (See "dispersion").

[A]

autoFire

bool

Whether the weapon will continue to fire if you hold down the trigger.

[A].

canLock

bool

Whether the weapon can lock on to a target (e.g. when a player hits the TAB key)

Must be true for any of the other lock modes to work (airLock, irLock, laserLock). 0 = never, 1 = in cadet mode only, 2 = always.

[A, B]

dispersion

float>0

Basic weapon accuracy.

This is the inherent accuracy of the weapon^. It affects all projectiles fired from this weapon independent of other effects like AI skill, etc. It describes the weapon's dispersion in radians (1 milliradian = 1 angular mil = 0.001 dispersion, 1 MOA = 0.000290888 dispersion).

^IRL these are things like straightness of the barrel, consistency of the ammunition powder charge, etc.--dispersion should actually be different per ammunition type, but in Arma it is a weapon property only.

max/mid/minRange

int>0, m/s, (AI only)

Determines the tendency of AI units to use this weapon based on their range to target.

At this range down to the previous __Range, an AI unit will attack with the corresponding __RangeProbab probability. Think of the three pairs of values (__Range, __RangeProbab) as creating a graph of attack probability at different ranges. (See "max/mid/minRangeProbab").

[A]

max/mid/minRangeProbab

float>0, (AI only)

Determines the tendency of AI units to use this weapon based on their range to target.

At this __Range down to the previous __Range, an AI unit will attack with the corresponding __RangeProbab probability. Think of the three pairs of values (__Range, __RangeProbab) as creating a graph of attack probability at different ranges. (See "max/mid/minRangeProbab").

[A]

weaponLockSystem

cumulative int

How this weapon triggers a target vehicle's warning system.

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

Vehicle properties are numerous and are contained both in the CfgVehicles class (usually in its own file), as well as CfgSkeletons & CfgModels (usually combined into a single file called model.cfg). CfgVehicles describes the vehicle's gameplay features, while CfgSkeletons & CfgModels describe its P3D model file.

Keep in mind that just about every major actor belongs to the "Vehicle" class in Arma, from planes to tanks to humans.

CfgVehicles

animationSource___

string, model.cfg Animations class name, (Turret class)

Defines the animating portions of a turret (_Body, _Gun, _Hatch, _Roll).

The name used is one of the "class Animations" names in the vehicle's model.cfg. (This class in turn identifies bones and selection sets in the cfg file and P3D model). e.g.

class YourModel:InheritedFromSomeWhere
{
 class Animations:Animations
 {
   class MainTurret
   {
    type="rotationY"; //type of movement involved
    source="mainTurret"; //The controller that provides input above
    selection="OtocVez"; //The name of the skeleton bone used.
    axis="OsaVeze"; //name of the axis in the P3D model.
    ...

The typical uses are as follows. _Body controls the basic slewing/left-right motion of the turret. _Gun controls weapon elevation/up-down movement. _Hatch controls hatch movement (if any) for a crewmember turning in/out. _Roll presumably controls tilting motion of the turret (if any).

[A, B]

armor (global)

int>0

Overall hit points/'health' for the vehicle. Once fully depleted by damage, the vehicle blows up killing its occupants.

You will often see this property referred to as "armor (int)". 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 each 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

This makes global health resistant to damage, without affecting local health.

The value is used as a divisor to global damage; the higher the value (beyond 1), the less global damage ("armor"/"hit points") occurs whenever the vehicle gets hit. HitPoints class location damage is not affected by this property; the location takes damage from the hit without being affected by this property. 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].

brakeIdleSpeed

float>0, meters/second, (PhysX)

Speed below which brakes are automatically applied to slow the vehicle to a stop.

If the value is too low, it will make the vehicle very difficult to bring to a complete stop. If it is too high, the vehicle will brake while you are trying to drive slowly.

[A, B]

cost

int>0, (AI only)

Tells the AI how valuable this vehicle is to attack relative to others.

From VBS link: "This value reflects how important a unit/vehicle is for enemy AI to kill. When all other considerations are equal. For instance, a soldier is not interested in Air [targets, due to his "threat[]" property], despite it's highly attractive cost values. On the other hand, he is interested in a machinegunner, since a machinegunner (in normal configs) has a relatively higher cost, than other [infantry threat types], including the officer, even though the machinegunner's cost is much lower than an airplane."

(See "threat[]").

[A]

changeGearMinEffectivity[]

float array, (PhysX)

Tells the transmission when to switch gears. (All transmissions in Arma 3 behave as if automatic).

Note that there is a value for every GearboxRatios value (usu. starting with reverse, then neutral, etc). In BI configs, this array never seems to vary much from the default: 0.95 for everything except neutral which is 0.15 (so it gets switched out of very quickly) and reverse which is 0.5. BI says "if there is [a] better gear and effectivity is below this value then [the game] change[s] gear"--not very clear what this means. However, reading NVIDIA documentation suggests the array values may simply represent the proportion of max engine RPM rather than some abstract "effectivity" value; in that case once the engine revs above(below) the RPM value, the game will shift one gear up(down).

[A, B]

clutchStrength

float>0, (PhysX)

How 'tight' the clutch is--how quickly gear changes affect vehicle speed.

Low values will mean more 'slippage' and slower acceleration after gear changes, higher values mean less slippage and quicker delivery of power to the wheels after a gear shift. BI recommends starting with a value of 10 (for CarX anyway, TankX config values are typically closer to 100). (See "thrustDelay").

[A, B]

crewVulnerable

bool, (AI only)

If true, AI units will shoot at the vehicle to wound exposed crewmembers even if damageResistance is too high for them to otherwise bother attacking. (See "damageResistance").

[A]

damageResistance

float>0, (AI only)

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:

(minHit^2) * (1/armor) * ([0.27/tgtRadius]^2)

where "miHit" is the "hit" 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. Possibly the AI check their weapon with this formula and compare it to the config value. Simplifying, one could say the AI checks it's weapon "hit" value against the minimum useful "hit" value the config has defined; if the AI weapon is >= the minimum value, the AI will consider attacking. If the AI's weapon is weaker, it won't.

[A,B,c]

discreteDistance[]

int array, meters

These are the available weapon range settings for this Optics/Turret view. (i.e. what you switch through with the PgUp/PgDown key).

discreteDistanceInitIndex

int

This is the array index of the default range setting from discreteDistance[]. (Remember all arrays are "zero-based"--that is, the first entry is #0).

epeImpulseDamageCoef

int≥0, (PhysX)

<?>Undocumented: the name suggests this is a coefficient influencing how much damage the vehicle takes from physics-controlled impacts (i.e. crashing into a wall, another vehicle, etc.). Higher numbers suggest the vehicle takes more damage from such events.

[undocumented]

engineLosses

int≥0, Newton-meters, (PhysX)

A force that helps bleed speed from the vehicle (presumably most noticeable as the vehicle coasts).

engineLosses bleed energy from the vehicle due to inefficiencies in the engine. As such, they are multiplied by the gear ratio (unlike transmissionLosses). (See "transmissionLosses").

[A, c]

enginePower

int>0, kilowatts, (PhysX)

Engine power in kW. (hp * 0.745699872 = kW).

[A]

explosionShielding (global)

float≥0

Modifies how global vehicle health is affected by 'splash' damage (indirectHit).

This works the same way as explosionShielding for HitPoint locations: indirectHit damage received is multiplied by this value.

(This property is 10-24-14 devbranch only currently)

forceHide__

bool

Whether a crewmember has the ability to "turn out" or not. (1 = cannot turn out, 0 = can turn out).

[A]

extCameraPosition[]

float array, meters

These are the XYZ coordinates of the 3rd person camera view for this vehicle.

The 3 members of the array represent coordinates in meters [X,Y,Z] = (side-to-side, vertical, close/forward-far/back.) The distances are calculated relative to the center of the vehicle.

[A]

__Fov

float≥0, 1=120 degrees

Field of View / magnification for the Optics class it is found in.

"init__", "min__", "max__" with "initFov" being the default. Smaller values mean a narrower FOV and thus a higher magnification.

[A]

fuelCapacity

int>0, liters

Vehicle fuel capacity.

(While VBS3 uses 0.1 liter units, Arma 3 appears to use 1 liter units based on config values). Regardless, the fuel consumption model in the game is very simplified so real-world values--while a useful starting point--may need tweaking in order to translate them into good in-game values.

[A]

gunnerOpticsModel

string

P3D model used when for this turret when crewmember is "turned in". (filename should include path).

[A]

gunnerOutOpticsModel

string

P3D model used when for this turret when crewmember is "turned out". (filename should include path).

[A]

gunnerOpticsEffect[]

string

Optical effects overlay (blur, etc.) applied to this turret in "turned in" mode.

gunnerHasFlares

bool

<??>Whether the crewmember at this Turret can launch the vehicle's countermeasures, if such are available (aircraft flares, AFV smoke grenades).

[A, (comment in "Samples_F\Test_Tank_01\CfgVehicles.hpp")]

hiddenSelections[]

string array

HiddenSelections lets you toggle visibility or texture on specified parts of your vehicle.

The names in the array must correspond to: 1) named selection(s) in the P3D file, 2) identically named entries in the model.cfg file under class CfgModel { sections[] }, e.g.

class CfgModels
{
  class Jeep
  {
      sectionsInherit = ""; //(let's assume there is no inheritance in this example)

      sections[] =
      {
         //names must match named selection sets in the P3D model file
         //you should use the same selection set names across all the visual LOD's in the P3D
         "spareTire",
         "flag"
      };

The purpose of listing certain sections here is to create variety within a single model by allowing the parts to be hidden and/or have alternate textures swapped out for variety.

Using hiddenSelections gives you the ability to change the sections' textures and materials via script with the setObjectMaterial and setObjectTexture(/Global) commands. (Note that changing an object's material does not appear to change its associated bisurf properties--this system is intended for changing visual appearance only; you can't use it to cleverly change fire geometry properties.)

Note: hiddenSelections are not intended for hiding or texture-swapping damaged hit locations; there is a more direct approach to that with 'damageHide'.

See also: #hiddenSelectionsTextures[]

[ A,B, C, D E]

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.

This might be a little confusing so let's use an example. Imagine we are using the vehicle in the hiddenSelections[] example above. Let's look at different ways hiddenSelections might be configured:

class CfgVehicles
{
  class Jeep_base
  {
    //this vehicle has both the "spareTire" and "flag" sections showing whenever the vehicle is spawned
    //they are referred to using commands like setObjectMaterial by array # (0 = spareTire, 1 = flag)
    //textures are assigned to the hiddenSelections in order (tire gets tire.paa, flag gets flag.paa)
    hiddenSelections[] = {"spareTire","flag"};
    hiddenSelectionsTextures[] = {"jeepMod\textures\tire.paa","jeepMod\textures\flag.paa"};
  }
  class Jeep_cheap: Jeep_base
  {
    //because "flag" is not included here, it is hidden--you also don't have access to it via script either
    hiddenSelections[] = {"spareTire"};
    hiddenSelectionsTextures[] = {"jeepMod\textures\tire.paa"};
  }
  class Jeep_fancy: Jeep_base
  {
    //both sections are available via script, but spareTire is hidden by giving it no texture ("")
    hiddenSelections[] = {"spareTire","flag"};
    hiddenSelectionsTextures[] = {"","jeepMod\textures\flag.paa"};
  }

See also: #hiddenSelections[]

hideWeapons__

bool

If true, the game hides any weapons being carried by the crewmember/passenger when he is riding in the vehicle.

[A, B, C, D]

idleRpm

int>0, RPM (revolutions per minute)

RPM level when engine is idling--this affects the engine sound. (See "redRpm").

[A]

inGunnerMayFire

bool

If true, the crewmember at this turret can move the view and fire any attached weapon when he is "turned in".

"Gunner" is used to mean whichever crewmember has access to this turret/view (e.g. the Commander is the "Gunner" in the Commander's turret).

[A

magazines[]

string array

List of magazines available to the weapons at this turret. (Magazine names come from CfgMagazines class[es]).

[A]

maxOmega

int>0, radians per second, (PhysX)

Maximum rotational speed of engine. (revolutions-per-minute * 0.104719755 = radians-per-second).

[A, B]

minTotalDamageTreshold

float≥0

Protects global vehicle health from damage.

This works the same way as minimalHit does for HitPoint locations: damage received below this value is ignored. This is just the global version of "minimalHit".

(This property is 10-24-14 devbranch only currently)

normalSpeedForwardCoef

float>0

<?> Proportion of top speed that is considered "normal speed" (as opposed to "fast speed" or "slow speed"). Not at all sure what this does in the game, read the cryptic description in the link and see what you can decipher from it...

[A]

outGunnerMayFire

bool

If true, the crewmember at this turret can move the view and fire any attached weapon when he is "turned out".

"Gunner" is used to mean whichever crewmember has access to this turret/view (e.g. the Commander is the "Gunner" in the Commander's turret). Note: apparently the game engine assumes helicopter crew are "turned out", so this property should be set to true for helicopters.

[A]

peakTorque

int>0, Newton-meters, (PhysX)

Maximum engine torque. (=enginePower*1000/maxOmega).

[A, B]

redRpm

int>0, RPM (revolutions per minute)

Maximum engine RPM--this affects the engine sound; just use "maxOmega" translated into RPM (multiply by ~9.5493). (See "idleRpm").

[A]

secondaryExplosion

float, ??

It is not clear how this value is used. VB documentation claims that it is a boolean, but the Arma config values are all over the place (e.g. -1, -0.1, 1000). There are secondary explosions for certain types of destroyed vehicles, but they appear to be hardcoded<?>.

[A, B].

simulation

string

Which simulation type governs this vehicle's physical behavior--for most vehicles this is generally one of the PhysX systems ("TankX", "CarX", "ShipX", "HelicopterX", "AirplaneX", <?>).

[A]

smokeLauncherAngle

int≥0, degrees

The angular spread/arc in which the countermeasure smoke grenades are launched.

The orientation of the spread is determined by "smokeLauncherOnTurret". The game will evenly distribute the number of grenades (smokeLauncherGrenadeCount) over this arc. Apparently the in-game angle tends to be smaller than this value, so the Samples_F comment suggests increasing the angle somewhat beyond the IRL value.

[(comment in "Samples_F\Test_Tank_01\CfgVehicles.hpp")]

smokeLauncherGrenadeCount

int≥0

Total number of smoke grenades launched when the countermeasure is used. (See the other "smokeLauncher__" properties for more details on how the smokescreen is generated).

[(comment in "Samples_F\Test_Tank_01\CfgVehicles.hpp"), B]

smokeLauncherOnTurret

bool

Whether the smoke grenades countermeasure launches from the turret or the body of the vehicle.

1= launcher on turret, grenades fire in direction turret is facing (this is typical for tanks). 2= launcher on hull, grenades fire in direction hull is facing.

[,B]

smokeLauncherVelocity

int≥0, m/s

Speed at which the grenades are launched. <?>Perhaps this affects height or distance of the resulting smokescreen.

[(comment in "Samples_F\Test_Tank_01\CfgVehicles.hpp"), ]

tankTurnForce

int>0, (PhysX)

How well a tank can turn, higher = better turning ability.

This is possibly some kind of coefficient that generates turning power for a TankX vehicle. The value apparently needs to be very high, on the order of 20-30 * vehicle weight (in kg) or more<?>.

[(comment in "Samples_F\Test_Tank_01\CfgVehicles.hpp"), A]

thermalMode[]

int array

Defines color modes available for thermal sights.

If a Turret has "TI" in its visionMode[], it can list one or more thermalMode[]'s. Any thermalMode[]'s are added to the "N"-key vision mode toggle set. The following modes are available: 0=white-hot, 1=black-hot, 2=green-hot,3=green/black-hot, 4=red-hot, 5=red/black-hot, (others?). (See "visionMode[]").

threat[]

float array, 1≥values≥0, (AI only)

How important it is for {AI Infantry, AI Armor, AI Aircraft} to attack this vehicle.

[A]

thrustDelay

int≥0, seconds, (PhysX)

Time it takes for engine to send power to the wheels from a stop.

This property does not affect already moving vehicles (see "clutchStrength" for something along those lines). Values >0 are suggested to reduce the chance that the vehicle's wheels slip every time it starts from a stop.

[A]

torqueCurve[]

float array, (PhysX)

An array describing how much torque the engine generates at various rotational speeds.

The values are normalized (0-1) so any units can be used to derive these values. The array consists of pairs of values in the form { {rotation1,torque1},{rotation2, torque2}, ...}. The first value in each pair tells the game how far along the RPM curve we are, the second value tells it how much to scale the peakTorque output. These are used to create a virtual graph which the game uses to determine engine power at various rotational speeds.

[A, B]

transmissionLosses

int≥0, Newton-meters, (PhysX)

A force that helps bleed speed from the vehicle (presumably most noticeable as the vehicle coasts).

transmissionLosses bleed energy from the vehicle due to inefficiencies in the transmission system. As such, they are not multiplied by the gear ratio (unlike engineLosses). (See "engineLosses").

[A,c]

transportSoldier

int≥0

How many passengers the vehicle can carry as cargo. (Crewmembers--gunner, driver, etc.--are not included in this value).

The vehicle's P3D model must also contain this number of proxies in the cargo area.

[A]

viewGunnerInExternal

bool

Controls whether the crewmember (at this turret) is rendered and damageable.

1= render crewmember when he is buttoned/"turned in", 0= render crewmember only when unbuttoned. Apparently this needs to be set =1 in order for crew to be damaged by penetrating hits (i.e. if crew is not rendered, they cannot be damaged).

[A]

visionMode[]

string array

Which vision types are available to toggle through ("N" key) in this optics view. Options are "Normal" (regular vision),"TI" (thermal imaging view),"NVG" (infrared/ambient light enhancement view).

Note that multiple thermalMode[] values add extra toggle steps to vision mode switching. (See "thermalMode[]").

waterPPInVehicle

bool

Whether passenger area floods when vehicle is swimming (i.e. passengers see water in their interior view).

If false(?), the interior of the vehicle does not flood when swimming--passengers don't see themselves underwater.

[A]

weapons[]

string array

List of weapons at this turret. (Weapon names come from CfgWeapons class[es]).

[A]

class complexGearbox

A series of PhysX properties grouped under the "complex Gearbox" class.

class HitPoints

armor (local)

float>0

Proportion of global health assigned to this location.

You will often see this property referred to as "armor (float)". The formula for determining location health appears to be simple:

location health = ("armor" local) * ("armor" global)

(if we assume the mysterious vehicle size measurement does not play a role). (See "armor (global)").

depends

string

Allows one location to apply its damage to another.

Formulas can be used to enhance this effect. e.g.

class HitTurret
{...};
class HitGun
{	...
	//for every point of damage HitTurret receives, HitGun gets 5
	depends = "5 * HitTurret";
};

Another requirement of this property is that the dependant class (HitGun in this example) must be listed after the, um, 'dependor' class (HitTurret).

[recent feature, undocumented]

explosionShielding

float≥0

Modifies how global vehicle health is affected by 'splash' damage (indirectHit).

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

See also: #explosionShielding (global).

[ A, B ].

minimalHit

float≥0

Protects the location from damage.

Damage received below this value is ignored. A value of 0 means the location acts 'normally' and even the slightest damage will reduce its health. (See "armor (local)", "minTotalDamageThreshold").

name

string

Associates the HitPoints location with a named selection set of vertices in the relevant P3D's HitPoints LOD. This way, the game knows what vertices in the model go with what hit location. Additionally, the set name should be the same as a CfgSkeletons bone (so the game also knows which verts move with which vehicle part). (See "visual").

passThrough

1≥float≥0

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 (unless it is a special hit location with hardcoded properties) . 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].

^It's actually a bit more complex than this. It appears that the game applies some damage to all locations based on their distance from the hit, with the nearest location taking the most damage of course.

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

class HitPoints names

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.

class Wheels

A series of PhysX properties grouped under the "Wheels" class.

boneName

string, (PhysX)

The name of the bone used for wheel & suspension animations in the model's P3D/model.cfg file.

[A]

boundary

string, (PhysX)

Refers to a vertex in the model's P3D file used to determine wheel radius. The vertex is usually place on the ground plane in the P3D file.

[A]

center

string, (PhysX)

The axis of wheel's rotation in the model's P3D/model.cfg file.

In the P3D file, 2 vertices are combined in a named selection set and are used to define the axis of the wheel's rotation.

[A]

damping

float>0, (PhysX)

Shock-absorber strength, it diminishes vehicle bounciness defined by the spring__ properties.

Presumably this property works with the other 3 spring properties to control vehicle bounciness (#springMass, #springStrength, #springDamperRate). (Not to be confused with the other "damping__" properties, which appear to be torque or rotation coefficients).

[A, B]

dampingRate

float>0, (PhysX)

Spinning friction of the Wheel (the rate at which it slows down).

Higher equals more friction/harder to move. All the damping__ properties appear to be coefficients affecting the friction of the Wheel against the ground. (Presumably different ground materials influence final friction). BI recommends values between 0.25-2 (for CarX anyway)

[A, B]

dampingRateDamaged

float>0, (PhysX)

Spinning friction of the Wheel (the rate at which it slows down) when it is damaged.

Higher equals more friction/harder to move; this value should be higher than dampingRate but less than dampingRateDestroyed. All the damping__ properties appear to be coefficients affecting the friction of the Wheel against the ground. (Presumably different ground materials influence final friction). (see "dampingRate", "dampingRateDestroyed").

[A, B]

dampingRateDestroyed

float>0, (PhysX)

Spinning friction of the Wheel (the rate at which it slows down) when it has been destroyed.

Higher equals more friction/harder to move; this value should be higher than dampingRateDamaged. All the damping__ properties appear to be coefficients affecting the friction of the Wheel against the ground. (Presumably different ground materials influence final friction). (see "dampingRate", "dampingRateDamaged").

[A, B]

dampingRateInAir

float>0, (PhysX)

Related to the mass of the Wheel, this property influences spin-slippage and acceleration.

This property is used (somehow<?>) with MOI to determine maximum speed for tanks. (See "MOI"). Theoretically, this is the rate at which the wheel slows down when spinning freely with the vehicle suspended in the air. As you increase MOI to prevent initial-wheel-spinning, you may need to counteract the speed boost(?) this creates by increasing dampingRateInAir. BI says only "tweak [dampingRateInAir] together with MOI to adjust maximum speed".

[A]

frictionVsSlipGraph[]

float array, (PhysX)

This array helps define Wheel (tire) traction when turning.

This array creates a simple 3-point virtual graph of friction (2nd #) at different levels of longitudinal slip (1st #). The friction values are applied as a coefficient on ground friction values--values below 1 make the vehicle more slippery, while values over 1 give it extra traction. Typically a tire would have a friction peak somewhere in the middle of the slip axis with lower values on either side. (You will often find this not to be the case in BI configs, however, where they tend to set friction quite high at all slip levels--at least with tracked vehicles).

[A,B]

latStiffX/Y

int>0, stiffness per unit of lateral slip in radians, (PhysX)

These two properties help define Wheel traction when turning.

"latStiffX" & "latStiffY" describe "tire lateral stiffness". They create a simple virtual graph describing the tire's lateral (side-to-side) stiffness. Roughly speaking, higher values are supposed to create better turning ability.

[A,B,C]

longitudinalStiffnessPerUnitGravity

int>0, stiffness per unit of longitudinal slip in radians, (PhysX)

Influences braking & acceleration performance.

Tire longitudinal (front-back) stiffness. Higher roughly = more responsive braking & acceleration.

[A,B]

mass

int>0, kg, (PhysX)

Weight of this Wheel in kilograms.

Appears to be redundant with "weight" property. Used somehow in the PhysX simulation.

See also: #weight

[A, B]

maxBrakeTorque

int>0, Newton-meters?, (PhysX)

Wheel braking power.

This is the maximum braking power. Appears to be roughly equal to peakTorque * 2 in some BI configs.

[A, B]

maxDroop

float>0, meters, (PhysX)

The maximum distance the wheel will hang (by its suspension) down from the body of the vehicle.

(Imagine picking the vehicle up off the ground with a crane: how far do the wheels hang down?).

See also: #maxCompression.

[A, B]

maxCompression

float>0, meters, (PhysX)

The maximum distance the wheel can get pushed up into the body of the vehicle when it's being compressed.

See also: #maxDroop.

[A, B]

MOI

int>0, kg square meters, (PhysX)

Related to the mass of the Wheel, this property influences spin-slippage and acceleration (as well as tank max speed somehow).

"Moment of Inertia". Low = wheels spin & slip easily, high = wheels spin more slowly and slow acceleration. This property is used (somehow<?>) with dampingRateInAir to determine maximum speed for tanks. Technically you can derive MOI = Mass * (radius in meters)^2, but BI recommends you use this only as a starting point. (See "dampingRateInAir").

[A]

side

string, "left"/"right", (PhysX)

Which side of the vehicle the wheel is on. ("left" = port side?)<?>

[A]

springDamperRate

int>0, (PhysX)

How fast the suspension loses energy as it bounces.

You can derive the "damping ratio" using this formula:

damping ratio = springdamperRate / [ 2*SQRT(springStrength * sprungMass) ]

Use it to determine whether a spring is over-damped (>1), just-damped (1), or under-damped (<1); BI says a typical family car is slightly over-damped with a damping ratio of just over 1.0.

See also: #springStrength, #sprungMass.

[A, B]

springStrength

int>0, Newtons/meter, (PhysX)

Strength of the suspension spring.

You can derive the "natural frequency" (bounces per second) of the spring using this formula:

natural frequency = SQRT(springStrength / sprungMass)

BI says a typical family car has a natural frequency of 5-10.

[A, B]

sprungMass

int>0, kg, (PhysX)

Mass supported by the suspension spring.

Total vehicle mass is distributed across all the wheels/springs. Note that if the vehicle's center of mass is not at its midpoint, some springs should carry more mass than others.

[A, B]

steering

bool, (PhysX)

Whether or not the Wheel turns when driver turns the steering-wheel. True = turns, false = does not turn.

[A]

weight

int>0, kg, (PhysX), [obsolete?]

Weight of this Wheel in kilograms.

Appears to be redundant with "mass" property (given same value). Not clear whether this property is actually used, while "mass" does appear to play a role in the PhysX simulation.

See also: #mass.

A, B]

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 ]

CfgModels

class Animations

[A, B]

type

string

Choose from one of the preset animation types (rotation, translation, hide, etc.)

[A, B]

source

string

What property the animation is dependent on. This may be one of the many preset sources tracked by the game (damage, speed, etc.). Or it may be a custom source defined in config.cpp>CfgVehicles >AnimationSources. (A custom source can be something as simple as another bone with its own preset source, or as complex as a user script).

[A, B]

selection

string

The thing which is animated. This can be either a bone defined in CfgSkeletons, or any Named Selection in

axis

string

The name of the axis for the animation, it is defined by two vertices within a Named Selection in the P3D file's "Memory" LOD. The first vertex placed indicated the 'direction' of the axis. Think of this as defining the axis of a bone that's been defined in CfgSkeletons.

Remember, Arma's modeler (aka Oxygen) is not as advanced as standard 3D modeling software. In the later, you can define a hierarchy of bones visually, and each bone automatically gets an axis created along with it. In Arma you define only the bone hierarchy in CfgSkeletons; the bone axes and positions must be defined in Oxygen using vertices in the "Memory" LOD.

ARMOR (Materials)

BISURF properties

BISURF material files are assigned to fire geometry in a vehicle's P3D file. They define the physical properties of whatever geometry they've been assigned to. Critical among these properties is armor value as defined by bulletPenetrability (or bulletPenetrabilityWithThickness & Thickness).

bulletPenetrability

int>0

Material strength in terms of how well it resists penetration: lower is stronger.

This is based on how far in mm a BI-standard "7.62mm NATO round" travelling at 1000m/s will penetrate the material. For example, RHA = 15. (Considering it penetrates 15mm of RHA, this is some kind of AP bullet obviously!) It doesn't really matter though, just make sure new weapons are correctly calibrated to penetrate real-world depths based on real-world velocities.

bulletPenetrabilityWithThickness

int>0

If the material has a "thickness" property specified, put its bulletPenetrability value here instead. (See "bulletPenetrability").

deflection

??

<?> Speculation: refines the ricochet system by letting materials affect the final deflection probability. (See CfgAmmo "deflecting").

[A] (new undocumented property as of 11-6-2014 devbranch)

Thickness

int>0

Sets a thickness ceiling to the geometry--the idea is to make it easier to model small/thin fire geometry. If the fire geometry is thinner, the actual thickness is used. If the fire geometry is thicker, the "thickness" property overrides it and is used. The game does appear to take into account LOS thickness by evaluating an incoming projectile's angle-of-incidence (relative to the geometry normal).