{"name":"Arma 3: Vehicle Handling Configuration","title":"Arma 3: Vehicle Handling Configuration","type":"topic","url":"https://community.bistudio.com/wiki/Arma_3:_Vehicle_Handling_Configuration","revid":376731,"updated":"2025-11-15T04:52:37Z","aliases":["Arma 3 Vehicle Handling Configuration"],"markdown":"### Common\n\n#### General parameters\n\n##### simulation\n\nDefines simulation type of the vehicle. PhysX simulation ends with letter \"x\". Can be:\n\n- **carx**   for PhysX cars\n- **tankx** for PhysX tanks\n- **shipx** for PhysX boats\n\n##### thrustDelay\n\n**thrustDelay** is time in second in which thrust (as an input value) goes from 0 to 1 when standing still (doesn't affect driving car during change of gears).\n0.5 is the minimum value. You may want to tweak this to higher values if wheels slide during initial acceleration.\n\n- *: float*\n- *: >= 0*\n- *: 0.5*\n\n```cpp\nthrustDelay = 0.5;\n```\n\n##### accelAidForceCoef\n\n**accelAidForceCoef** is an artificial aid force applied to a vehicle when accelerating. Goes from x1 when standing still to x0 at a speed defined in accelAidForceSpd. Ideally a vehicle should be configured with this property set to zero and it should only be used for final fine-tuning.\n\n- *: float*\n- *: >= 0*\n- *: 5.0*\n\n```cpp\naccelAidForceCoef = 3.0;\n```\n\n##### accelAidForceSpd\n\nThis is a minimum speed in **m/s** when accelAidForceCoef becomes zero and is no longer applied.\n\n- *: float*\n- *: >= 0*\n- *: 5.0*\n\n```cpp\naccelAidForceSpd = 5.0;\n```\n\n##### accelAidForceYOffset\n\nThis is a vertical offset from the vehicle's center of mass where the accelAidForceCoef will be applied. Used to accent the vehicle's weight shifting during an acceleration.\n\n- *: float*\n- *: >= 0*\n- *: 0.0*\n\n```cpp\naccelAidForceCoef = -1.0;\n```\n\n##### maxSpeed\n\nDefines the maximum driving speed of the vehicle when driving by \"Car Fast Forward\" action. Set in **km/h**. Works as a limiter - the vehicle's thrust will get cut around this speed.\n\n- *: float*\n- *: >= 0*\n\n```cpp\nmaxSpeed = 100;\n```\n\n##### slowSpeedForwardCoef\n\n##### normalSpeedForwardCoef\n\nCoefficients of maxSpeed that are used to limit the actual maximum speed depending on which - \"Car Forward\", \"Car Slow Forward\" or \"Car Fast Forward\" - action is used. \"Car Fast Forward\" uses directly the maxSpeed value.\n\n- **slowSpeedForwardCoef** is set to 0.3 by default\n- **normalSpeedForwardCoef** is set to 0.85 by default\n- default speed coefficient for fast movement is 1 meaning that full throttle is applied and maximal speed is maxSpeed of the vehicle (it is going to apply less throttle upon reaching the limit)\n\n```cpp\nslowSpeedForwardCoef = __EVAL(30/100);\nnormalSpeedForwardCoef = __EVAL(50/100);\n```\n\n##### waterLeakiness\n\nShould be the amount of water in liters that goes into selected object per second.\nThis is set to zero by engine for all vehicles with simulation of a ship or having `canFloat = 1;` (until they are toppled or destroyed, then config value takes precedence).\n`WaterLeakiness = 10;` seems to be a good value to start with for all kinds of vehicles no matter the size.\n\n- *: float* (or *sink*)\n- *: >= 0*\n\n```cpp\nwaterLeakiness = 10;\n```\n\n#### Engine parameters\n\n##### enginePower\n\nPower of the engine **in kW**.\n\n- *: float*\n- *: >= 0*\n- *: (required)*\n\n```cpp\nenginePower = 600;\n```\n\n##### maxOmega\n\nThis is the maximum rotational speed of the engine expressed in **radians per second**. It could be calculated from maximum engine RPM like this:\n\n```\nmaxOmega = (maxRpm * 2 * Pi) / 60\n```\n\n- *: float*\n- *: > 0*\n- *: 600 which is cca 6000 rounds per minute.*\n\n```cpp\nmaxOmega = __EVAL((6000 * 2 * PI) / 60);\n```\n\n##### minOmega\n\nThis is the idle (minimum) rotational speed of the engine expressed in **radians per second**.\n\n- *: float*\n- *: > 0*\n- *: 0*\n\n```cpp\nminOmega = __EVAL((800 * 2 * PI) / 60);\n```\n\n##### idleRpm\n\n**idleRpm** sets the idle RPM solely for the sound engine. Expressed in **revolutions per minute**.\n\n##### redRpm\n\n**redRpm** sets the maximum RPM solely for the sound engine. Expressed in **revolutions per minute**.\n\n##### peakTorque\n\nThis is the maximum torque that is ever available from the engine. This is expressed in **Newton metres**.\nA starting value might be around 600.\n\n- *: float*\n- *: > 0*\n- *: value calculated from enginePower according to http://en.wikipedia.org/wiki/Horsepower#Relationship_with_torque*\n\n```cpp\npeakTorque = 600;\n```\n\n##### torqueCurve\n\nThis is a graph of peak torque versus engine rotational speed.\nCars typically have a range of engine speeds that produce good drive torques, and other ranges of engine speed that produce poor torques.\nA skilled driver will make good use of the gears to ensure that the car remains in the \"good\" range where the engine is most responsive.\nTuning this graph can have profound effects on gameplay.\n\nThe x-axis of the curve is the normalised engine speed; that is, the engine speed divided by the maximum engine speed. The y-axis of the curve is a multiplier in range (0,1) that is used to scale the peak torque. The samples do not have to be equally spaced apart. You can distribute the points between both 0% rpm and 100% rpm points as you wish.\n\n- *: Array[i][2] where i = number of samples,* maximum 8'\n- *: { { 0.0, 0.8 }, { 0.33, 1.0 }, { 1.0, 0.8 } }*\n\n```cpp\ntorqueCurve[] = { { 0.0, 0.8 }, { 0.33, 1.0 }, { 1.0, 0.8 } };\n```\n\n**NOTE:** you can also use math in this definition, here is the same example from above using this technique:\n\n```cpp\ntorqueCurve[] = { { __EVAL(0/2400), __EVAL(80/100) }, { __EVAL(792/2400), __EVAL(100/100) }, { __EVAL(2400/2400), __EVAL(80/100) } };\n```\n\n##### engineMOI\n\nThis the moment of inertia of the engine around the axis of rotation. Larger values make it harder to accelerate the engine, while lower values make it easier to accelerate the engine. A starting value of 1.0 is a good choice. Tweak together with engine damping rates.\n\n- *: float*\n- *: >= 0*\n- *: 1.0*\n\n```cpp\nengineMOI = 1.0;\n```\n\n##### dampingRateFullThrottle\n\n##### dampingRateZeroThrottleClutchEngaged\n\n##### dampingRateZeroThrottleClutchDisengaged\n\nThese three values are used to compute the damping rate that is applied to the engine.\nIf the clutch is engaged then the damping rate is an interpolation between **dampingRateFullThrottle** and **dampingRateZeroThrottleClutchEngaged**, where the interpolation is governed by the acceleration control value generated by the gamepad or keyboard.\nAt full throttle **dampingRateFullThrottle** is applied, while dampingRateZeroThrottleClutchEngaged is applied at zero throttle.\nIn neutral gear, the damping rate is an interpolation between dampingRateFullThrottle and dampingRateZeroThrottleClutchDisengaged.\n\nThe three values allow a range of effects to be generated: good acceleration that isn't hampered by strong damping forces,\ntunable damping forces when temporarily in neutral gear during a gear change,\nand strong damping forces that will bring the vehicle quickly to rest when it is no longer being driven by the player.\n\nTypical values in range (0.25,3). The simulation can become unstable with damping rates of 0.\n\n- *: float*\n- *: > 0*\n- *: 0.08, 2.0, 0.35*\n\n```cpp\ndampingRateFullThrottle = 0.08;\ndampingRateZeroThrottleClutchEngaged = 2.0;\ndampingRateZeroThrottleClutchDisengaged = 0.35;\n```\n\n#### Transmission parameters\n\n##### clutchStrength\n\nThis describes how strongly the clutch couples the engine to the wheels and how quickly differences in speed are eliminated by distributing torque to the engine and wheels.\n\nWeaker values will result in more clutch slip, especially after changing gear or stamping on the accelerator.\nStronger values will result in a reduced clutch slip, and more engine torque delivered to the wheels.\n\nThis value is to be edited only for very fine tweaking of the vehicle.\nSome clutch slip can be attributed to the numerical issues in the simulation at large timesteps, while some is a natural consequence of driving the car in an overly aggressive manner.\nA value of 10 is a good starting point.\n\n- *: float*\n- *: >= 0*\n- *: 10.0*\n\n```cpp\nclutchStrength = 10.0;\n```\n\n##### latency\n\nThis is the minimum time (in **seconds**) that must pass between each gear change that is initiated by the autobox.\nThis should be set to value higher than switchTime.\nSetting this time too low makes some issues with changing gears - the car then slows down a lot.\n\n- *: float*\n- *: >= 0*\n- *: 2.0*\n\n```cpp\nlatency = 1.0;\n```\n\n##### switchTime\n\nThe switch time describes how long it takes (in seconds) for a gear change to be completed.\nIt is impossible to change gear immediately in a real car.\nManual gears, for example, require neutral to be engaged for a short time before engaging the desired target gear.\nWhile the gear change is being completed the car will be in neutral.\nA good trick might be to penalise players that use an automatic gear box by increasing the gear switch time.\n\n- *: float*\n- *: >= 0*\n- *: 0.01*\n\n```cpp\nswitchTime = 0.5;\n```\n\n##### changeGearType\n\nDefines which changeGear condition type is used for the automatic gearbox. If set to \"rpmratio\" the gears will be switched based on RPM ratio max/min pairs defined in changeGearOmegaRatios. If set to \"effective\" the gears will be switched based on engine torque ratios defined in changeGearMinEffectivity.\n\n- *: string*\n- *: [\"rpmatio\",\"effective\"]*\n- *: effective*\n\n```cpp\nchangeGearType = \"rpmratio\";\n```\n\n##### changeGearMinEffectivity\n\nValue of minimal gear effectivity to hold current gear. If there is better gear and effectivity is below this value then change gear. Used when changeGearType is set to \"effective\".\n\n- *: Array[i] where i = number of gears*\n- *: 0..1*\n- *: 0.95 for every value*\n\n```cpp\nchangeGearMinEffectivity[] = { 0.95, 0.15, 0.95, 0.95, 0.95, 0.95, 0.95 };\n```\n\n##### changeGearOmegaRatios\n\nPairs of maximum and minimum engine RPM to hold the current gear. Used when changeGearType is set to \"rpmratio\".\n\n- *: Array[i] where i = number of gears * 2*\n- *: 0..1*\n\n```cpp\nchangeGearOmegaRatios[] = {\n __EVAL(6000/6000) , __EVAL(1000/6000), // R1\n __EVAL(1000/6000) , 0, // N\n __EVAL(5800/6000) , __EVAL(1000/6000), // D1\n __EVAL(5500/6000) , __EVAL(3000/6000), // D2\n __EVAL(5300/6000) , __EVAL(2800/6000), // D3\n __EVAL(5300/6000) , __EVAL(2500/6000), // D4\n __EVAL(5300/6000) , __EVAL(2500/6000) // D5\n};\n```\n\n##### class complexGearbox\n\n- All PhysX 3 vehicles use complex gearbox to give some data to PhysX gearbox\n- Complex gearbox settings is inside **class complexGearbox** which is a subclass of vehicle class\n- **GearboxRatios[]** is an array of gear names and gear ratios starting with reverse gear (with negative ratios), neutral gear (which should have zero ratio) and forward ratio (eg: *{\"R1\",-3.231,\"N\",0,\"D1\",2.462,\"D2\",1.870,\"D3\",1.241,\"D4\",0.970,\"D5\",0.711};*). Gear names are not used in retail version, they are just for **epevehicle** diagnostics. **Important**: There can only be one reverse Gear (which must have negative value) and one Neutral gear (which must have 0 as ratio). All forward gears must have a value greater than zero and they must be ordered from high ratio to low\n- **TransmissionRatios[]** is an array of remaining drivetrain ratios in the same format as gearboxRatios. Most of cars have only one final drive, some heavy trucks may have a double reduction gear . The final ratio is then gearboxRatio * TransmissionRatio, that means transmissionRatios shouldn't be multiplicates of each other and gearbox ratios to prevent the same final ratio for two different gears.\n- **gearBoxMode** is set to full-auto by engine. The full-auto mode can skip gears to get the best possible gear for each condition.\n- **moveOffGear** defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default.\n- **driveString**, **neutralString** and **reverseString** define displayed strings for driving forward, neutral and backward.\n\n```cpp\ncomplexGearbox\n{\n GearboxRatios[] = {\n \"R1\", -3.231,\n \"N\", 0,\n \"D1\", 2.462,\n \"D2\", 1.870,\n \"D3\", 1.241,\n \"D4\", 0.970,\n \"D5\", 0.711\n };\n\n // Optional: defines transmission ratios (for example, High and Low range as commonly found in offroad vehicles)\n TransmissionRatios[] = { \"High\",4.111 };\n\n // defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default.\n moveOffGear = 1;\n\n driveString = \"D\"; // string to display in the HUD for forward gears.\n neutralString = \"N\"; // string to display in the HUD for neutral gear.\n reverseString = \"R\"; // string to display in the HUD for reverse gears.\n};\n```\n\n#### Differential parameters\n\n##### differentialType\n\nA number of differential types are supported: 4-wheel drive with open differential, 4-wheel drive with limited slip, front-wheel drive with open differential, front-wheel drive with limited slip, rear-wheel drive with open differential, rear-wheel drive with limited slip.\n\n- *: string; accepable values: \"all_open\", \"all_limited\", \"front_open\", \"front_limited\", \"rear_open\", \"rear_limited\"*\n- *: \"all_limited\"*\n\n```cpp\ndifferentialType = \"all_limited\";\n```\n\n##### frontRearSplit\n\nIf a 4-wheel drive differential is chosen (open or limited slip) this option allows the drive torque to be split unevenly between the front and rear wheels.\nChoosing a value of 0.5 delivers an equal split of the torque between the front and rear wheels; that is, the total torque delivered to the front wheels is equal to the total torque delivered to the rear wheels. Choosing a value greater than 0.5 delivers more torque to the front wheels while choosing a value less than 0.5 delivers more torque to the rear wheels.\nThis value is ignored for front-wheel drive and rear-wheel drive differentials.\n\n- *: float*\n- *: 0..1*\n- *: 0.5*\n\n```cpp\nfrontRearSplit = 0.5;\n```\n\n##### frontBias\n\nLimited slip differentials work by only allowing a certain difference in wheel rotation speed to accumulate.\nThis prevents the situation where one wheel is slipping but ends up taking all the available power.\nFurther, by allowing a small difference in wheel rotation speed to accumulate it is possible for the vehicle to easily corner by permitting the outside wheel to rotate quicker than the inside wheel.\n\nThis parameter describes the maximum difference in wheel rotation speed that is allowed to accumulate.\nThe front bias is the maximum of the two front-wheel rotation speeds divided by the minimum of the two front-wheel rotation speeds.\nWhen this ratio exceeds the value of the front bias the differential diverts torque from the faster wheel to the slower wheel in an attempt to preserve the maximum allowed wheel rotation speed ratio.\n\nThis value is ignored except for front-wheel drive or four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\nfrontBias = 1.3;\n```\n\n##### rearBias\n\nThis is similar to frontBias except that it refers to the rear wheels.\n\nThis value is ignored except for rear-wheel drive or four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\nrearBias = 1.3;\n```\n\n##### centreBias\n\nThis value is similar to the frontBias and rearBias, except that it refers to the sum of the front wheel rotation speeds and the sum of the rear wheel rotation speeds.\n\nThis value is ignored except for four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\ncentreBias = 1.3;\n```\n\n#### Wheel parameters\n\n##### boneName\n\nName of the bone, used for wheel and suspension animations.\nThe standard bone structure would be as such: damperbone → steeringbone → rotatingbone (example: wheel_1_1_damper → wheel_1_1_steering → wheel_1_1).\nAs boneName you would set the rotatingbone (e.g. wheel_1_1).\nIn the visual LODs this \"rotatingbone\" is generally the selection of the tire.\n\n- *: string*\n- *: \"\"*\n\n```cpp\nboneName = \"wheel_1_1\";\n```\n\n##### steering\n\nIf true, wheel is steerable, false - wheel is fixed.\n\n- *: bool*\n- *: (required)*\n\n```cpp\nsteering = true;\n```\n\n##### side\n\nDefines if wheel is on vehicle left or right side\n\n- *: string*\n- *: \"right\"*\n\n```cpp\nside = \"left\";\n```\n\n##### center\n\nCenter of the wheel (axis)\n\n- *: memory point*\n- *: (required)*\n\n```cpp\ncenter = \"wheel_1_1_axis\";\n```\n\n##### boundary\n\nPoint on the outside rim of the tire, used to calculate radius of the wheel (distance between center and boundary).\n\n- *: memory point*\n- *: (required)*\n\n```cpp\nboundary = \"wheel_1_1_bound\";\n```\n\n##### width\n\nThis is the full width of the wheel in metres. It affects wheels collision detection\n\n- *: float*\n- *: > 0*\n- *: 0.3 * (radius of the wheel)*\n\n```cpp\nwidth = 0.2;\n```\n\n##### mass\n\nThis is the combined mass of the wheel and the tire in kg. Typically, a wheel has mass between 20Kg and 80Kg but can be lower and higher depending on the vehicle.\n\n- *: float*\n- *: > 0*\n- *: 10.0*\n\n```cpp\nmass = 150;\n```\n\n##### MOI\n\nThis is the component of the wheel's Moment of Inertia (M.o.I) about the rolling axis.\nLarger values make it harder for the wheel to rotate about this axis, while easier values make it easier for the wheel to rotate about the rolling axis.\nAnother way of expressing this is that a high MOI will result in less wheel spin when stamping on the accelerator because it is harder to make the wheel spin.\nConversely, lower values of MOI will result in more wheel spin when stamping on the accelerator.\nIf the wheel is approximately cylindrical then a simple formula can be used to compute MOI:\n\n```\nMOI = 0.5 * Mass * Radius * Radius\n```\n\nThere is no reason, however, to rely on equations to compute this value.\nA good strategy for tuning this number might to be start with the equation above and then make small tweaks to the value until the handling is as desired.\n\n- *: float*\n- *: > 0*\n- *: 0.5 * WheelMass * WheelRadius * WheelRadius*\n\n```cpp\nMOI = 40;\n```\n\n##### dampingRate\n\n##### dampingRateDamaged\n\n##### dampingRateDestroyed\n\nThese values describe how quickly a freely spinning wheel will come to rest.\nThe damping rate describes the rate at which a freely spinning wheel loses rotational speed.\nHere, a freely spinning wheel is one that experiences no forces except for the damping forces arising from the wheel's internal bearings.\nHigher damping rates result in the wheel coming to rest in shorter times, while lower damping rates result in the wheel maintaining speed for longer.\nValues in range (0.25, 2) seem like sensible values. Experimentation is always a good idea, even outside this range.\nAlways exercise some caution with very small damping rates. In particular, **a damping rate of exactly 0 should be avoided**.\n\n- *: float*\n- *: > 0*\n- *: 0.1*\n\n```cpp\ndampingRate = 0.1;\ndampingRateDamaged = 1.0;\ndampingRateDestroyed = 1000.0;\n```\n\n##### maxBrakeTorque\n\nThis is the value of the torque applied to the wheel when the brakes are maximally applied.\nHigher torques will lock the wheel quicker when braking, while lower torques will take longer to lock the wheel.\nThis value is strongly related to the wheel MOI because the MOI determines how quickly the wheel will react to applied torques.\n\nA value of around 1500 is a good starting point for a vanilla wheel but a google search will reveal typical braking torques.\nOne difficulty is that these are often expressed by manufacturers as braking horsepower or in \"pounds inches\".\nThe values required here are in *Newton metres*.\n\n- *: float*\n- *: >= 0*\n- *: 2500*\n\n```cpp\nmaxBrakeTorque = 7500;\n```\n\n##### maxHandBrakeTorque\n\nThis is the same as the max brake torque except for the handbrake rather than the brake.\nTypically, for a 4-wheeled car, the handbrake is stronger than the brake and is only applied to the rear wheels.\nA value of 4000 for the rear wheels is a good starting point, while a value of 0 is necessary for the front wheels to make sure they do not react to the handbrake.\n\n- *: float*\n- *: >= 0*\n- *: 2 * maxBrakeTorque*\n\n```cpp\nmaxHandBrakeTorque = 0;\n```\n\n##### tireForceAppPointOffset\n\nThis is almost the same as the suspension force app point except for the lateral and longitudinal forces that develop on the tire.\n\nA good starting point is to duplicate the suspension force application point.\nOnly for really detailed editing is it advised to start tweaking the tire force app offset independently of the suspension force app offset.\n\n- *: memory point*\n- *: suspForceAppPointOffset*\n\n```cpp\ntireForceAppPointOffset = \"wheel_1_1_axis\";\n```\n\n#### Suspension parameters\n\n##### dampersBumpCoef\n\nDefines how much dampers react to random little bumps on surface.\nThis only has a visual effect and doesn't influence driving simulation. It is only taken into account when calculating damper animation.\n\n- *Type: float*\n- *: >= 0*\n- *Default: 0.0*\n\n```cpp\ndampersBumpCoef = 0.3;\n```\n\n##### maxCompression\n\n##### maxDroop\n\nThese values describe the maximum compression and elongation in metres that the spring can support.\nThe total travel distance along the spring direction that is allowed is the sum of **maxCompression** and **maxDroop**.\n\nA simple way to illustrate the maximum droop and compression values is to consider a car that is suspended in mid-air so that none of the wheels are touching the ground.\nThe wheels will naturally fall downwards from their rest position until the maximum droop is reached.\nThe spring cannot be elongated beyond this point. Now consider that the wheel is pushed upwards, first to its rest position, then further pushed until the spring can no longer be compressed.\nThe displacement from the rest position is the maximum compression of the spring.\n\nIt is important to choose the maximum compression value so that the wheel is never placed where the visual mesh of the wheel intersects the visual meshes of the car chassis.\nIdeally, these values will be exported from the 3D modeller.\n\n- *: float*\n- *: >= 0*. Important: If one of the values is zero, the other must be greater than zero\n- *: 0.15*\n\n```cpp\nmaxCompression = 0.15;\nmaxDroop = 0.15;\n```\n\n##### sprungMass\n\nThis is the mass in kg that is supported by the suspension spring.\n\nA vehicle with rigid body centre of mass at the centre of the four wheels would typically be equally supported by each of the suspension springs;\nthat is, each suspension spring supports 1/4 of the total vehicle mass.\nIf the centre of mass was moved forward then it would be expected that the front wheels would need to support more mass than the rear wheels.\nConversely, a centre of mass nearer the rear wheels ought to result in the rear suspension springs supporting more mass than at the front.\nAll the mass of the vehicle must be \"carried\" by the sprung mass values, means: The sum of sprungMass values for all Wheels must be equal to the vehicle's weight.\n\n- *: float*\n- *: > 0*\n- *: vehicleMass / numberOfWheels*\n\n```cpp\nsprungMass = 2066;\n```\n\n##### springStrength\n\nThis is the strength of the suspension spring in Newtons per metre.\nThe spring strength has a profound influence on handling by modulating the time it takes for the vehicle to respond to bumps in the road and on the amount of load experienced by the tire.\n\nKey to the understanding the effect of spring strength is the concept of a spring's natural frequency.\nConsider a simple spring system, such as a pendulum swinging back and forth.\nThe number of trips per second that the pendulum makes from full left to full right and then back again is called the natural frequency of the pendulum.\nA more powerful pendulum spring will result in the pendulum swinging faster, thereby increasing the natural frequency.\nConversely, increasing the pendulum mass will result in a slower oscillation, thereby reducing the natural frequency.\n\nIn the context of a suspension spring supporting a fixed portion of vehicle mass, the strength of the spring will affect the natural frequency;\nthat is the rate at which the spring can respond to changes in load distribution. Consider a car taking a corner.\nAs the car corners, it leans into the turn, putting more weight on the suspensions on the outside of the turn.\nThe speed at which the spring reacts by applying forces to redistribute the load is controlled by the natural frequency.\nVery high natural frequencies, such as those on a racing car, will naturally produce twitchy handling because the load on the tires, and therefore the forces they can generate, is varying very rapidly.\nVery low natural frequencies, on the other hand, will result in the car taking a long time to straighten up even after the turn is complete.\nThis will produce sluggish and unresponsive handling.\n\nAnother effect of strength and natural frequency is the response of a car to a bump in the road.\nHigh natural frequencies can result in the car responding very strongly and quickly to the bump, with the wheel possibly even leaving the road for a short while.\nThis not only creates a bumpy ride but also periods of time when the tire is generating no forces.\nWeaker springs will result in a smoother trip over the bump, with weaker but more constant tire forces.\nA balance must be found to tune the car for the expected types of turn and terrain.\n\nThe natural frequency of the spring presents a challenge for computer simulation.\nA smooth and stable simulation requires that the spring is updated at a frequency much greater than the spring's natural frequency.\nAn alternative way of expressing this is to consider the period of the spring relative to the timestep of the simulation.\nThe period of the spring is the time the spring takes to complete a single oscillation and is mathematically equal to the reciprocal of the natural frequency.\nIn order to achieve a stable simulation, the spring must be sampled at several points during each oscillation.\nA natural consequence of this observation is that the simulation timestep must be significantly smaller than the period of the spring.\nTo discuss this further it is helpful to introduce a ratio that describes the number of simulation updates that will occur during each spring oscillation.\nThis ratio is simply the spring period divided by the timestep:\n\n```\nalpha = sqrt(sprungMass / springStrength) / timestep\n```\n\nwhere `sqrt(sprungMass / springStrength)` is the period of the spring.\nAn alpha value of 1.0 means that the chosen timestep and spring properties only allow a single sample of the spring during each oscillation.\nAs described above, this is almost guaranteed to produce unstable behavior.\nIn fact, the argument presented so far suggests **a value of alpha significantly greater than 1.0 is essential to produce a smooth simulation**.\nThe exact value of alpha at which stability emerges is very difficult to predict and depends on many other parameters.\nAs a guide, however, it is recommended that the timestep and spring properties are chosen so that they produce an alpha value greater than 5.0; that is, a minimum of five simulation updates per spring cycle.\n\nWhen tuning a suspension spring it can be very useful to use manufacturer data to discover typical values used across a range of vehicle types.\nThis data is not always readily available.\nAn alternative strategy would be to think in terms of the natural frequency of the spring by imagining how quickly the car would oscillate up and down if it was dropped onto the ground from a height of, say, 0.5m.\nThe springs of a typical family car have natural frequency somewhere between 5 and 10; that is, such a car would make 5-10 oscillations per second if gently dropped to the ground.\nIf the mass supported by the spring is already known then the spring strength can be calculated from the following equation:\n\n```\nspringStrength = naturalFrequency * naturalFrequency * sprungMass\n```\n\n- *: float*\n- *: > 0*\n- *: sprungMass * 5.0 * 5.0*\n\n```cpp\nspringStrength = 51653;\n```\n\n##### springDamperRate\n\nThis describes the rate at which the spring dissipates the energy stored in the spring.\n\nKey to the understanding of damper rate are the concepts of under-damping, over-damping, and critical damping.\nAn over-damped pendulum displaced from rest is unable to make a single back-and-forth trip before it dissipates all its energy,\nwhile an under-damped pendulum would be able to make at least a single back-and-forth trip.\nA critically damped pendulum makes exactly a single back-and-forth trip before expending all its energy.\n\nFor vehicle suspension springs, it is typically important to make sure that the spring has a damper rate that produces over-damping but not by too much.\nWhen cornering, for example, it is important that the spring doesn't over-respond by shifting the weight from the left suspension to the right suspension then back again.\nIf this happened the tire load, and the forces generated, would be extremely variable, resulting in twitchy and uncontrollable handling.\nA very heavily over-damped spring, on the other hand, will feel sluggish and unresponsive.\nThe concept of critical damping can be used to help tune the damping rate of the spring.\nIt is helpful to introduce a value known as the damping ratio, which helps to mathematically describe the under-damping, critical damping and over-damping regimes:\n\n```\ndampingRatio = springDamperRate / (2 * sqrt(springStrength * sprungMass))\n```\n\nA dampingRatio with value greater than 1.0 produces over-damping, a value of exactly 1.0 generates critical damping, and a value less than 1.0 is under-damped.\nIt can be useful to first think about whether the spring will be under-damped or over-damped, then think about how far it will be from critical damping.\nThis process allows a number to be subjectively applied to the damping ratio.\nFrom here the damping rate can be directly computed by rearranging the equation above:\n\n```\nspringDamperRate = dampingRatio * 2 * sqrt(springStrength * sprungMass)\n```\n\nA typical family car is probably slightly over-damped, having dampingRatio with value perhaps just over 1.0.\nA guideline would be that values very far from critical damping are likely to be unrealistic and will either produce sluggish or twitchy handling.\nIt is difficult to put an exact figure on this but somewhere between 0.8 and 1.2 seems like a good starting point for the damping ratio.\n\n- *: float*\n- *: >= 0*\n- *: 0.4 * 2 * sqrt(springStrength * sprungMass)*\n\n```cpp\nspringDamperRate = 8264;\n```\n\n##### suspTravelDirection\n\nThis is the direction of the suspension in the downward direction in the rest configuration of the vehicle.\nA vector that points straight downwards is a good starting point.\n\n- *: Array[3]*\n- *: { 0, -1, 0 }*\n\n```cpp\nsuspTravelDirection[] = { 0, -1, 0 };\n```\n\n##### suspForceAppPointOffset\n\nThis is the application point of the suspension force.\n\nIn a real vehicle, the suspension forces are mediated through the suspension strut.\nThese are often incredibly complex mechanical systems that are computationally expensive to simulate.\nAs a consequence, instead of modeling the details of the suspension strut, it makes sense to assume that the suspension strut has an effective point at which it applies the force to the rigid body.\nChoosing that point, however, needs careful consideration.\nAt the same time, it opens up all sorts of tweaking possibilities, freed from the constraints of the real world.\n\nDeciding on the suspension force application point requires some thought.\nThe suspension is very close to the wheel so the wheel center is a good starting point.\nConsider a line through the wheel center and along the suspension travel direction.\nSomewhere along this line seems like an even better idea for the application point, albeit not completely scientific.\nFor a standard 4-wheeled car it makes sense that the application point is somewhere above the wheel center but below the centre of mass of the rigid body.\nIt is probably above the wheel centre because the suspension is mostly above this point.\nIt can be assumed that it is somewhere below the rigid body centre of mass because otherwise, vehicles would lean out of the turn rather than into the turn.\nThis narrows down the application point to really quite a small section of a known line.\n\nWhen editing the suspension force application point, it is important to bear in mind that lowering the app point too far will result in cars leaning more into the turn.\nThis can have a negative effect on handling because the inner wheel can take so much load that the response saturates, while the outer wheel ends up with reduced load and reduced turning force, the result being poor cornering.\nConversely, setting the app point too high will result in cornering that looks unnatural. The aim is to achieve a good balance.\n\n- *: memory point*\n- *: center*\n\n```cpp\nsuspForceAppPointOffset = \"wheel_1_1_axis\";\n```\n\n#### Tire parameters\n\n##### longitudinalStiffnessPerUnitGravity\n\nThe longitudinal tire force is approximately the product of the longitudinal stiffness per unit longitudinal slip (in radians) per unit gravity and the longitudinal slip and the magnitude of gravitational acceleration.\n\nIncreasing this value will result in the tire attempting to generate more longitudinal force when the tire is slipping.\nTypically, increasing longitudinal stiffness will help the car accelerate and brake.\nThe total tire force available is limited by the load on the tire so be aware that increases in this value might have no effect or even come at the expense of reduced lateral force.\n\n- *: float*\n- *: 10000*\n\n```cpp\nlongitudinalStiffnessPerUnitGravity = 5000;\n```\n\n##### latStiffX\n\n##### latStiffY\n\nThese values together describe the lateral stiffness per unit lateral slip (in radians) of the tire.\nThe lateral stiffness of a tire has a role similar to the longitudinal stiffness, except that it governs the development of lateral tire forces, and is a function of tire load.\nTypically, increasing lateral stiffness will help the car turn more quickly.\nThe total tire force available is limited by the load on the tire so be aware that increases in this value might have no effect or even come at the expense of reduced longitudinal force.\n\nThe combination of the two values latStiffX and latStiffY describe a graph of lateral stiffness as a function of normalized tire load.\n\nTypical for car tires is a graph that has linear response close to zero load but saturates at greater loads.\nThis means that at low tire loads the lateral stiffness has a linear response to load; that is, more load results in more stiffness.\nAt higher tire loads the tire has a saturated response and is in a regime where applying more load will not result in more tire stiffness.\nIn this latter regime, it would be expected that the tire would start slipping.\n\nThe **latStiffX** parameter describes the normalized tire load above which the tire has a saturated response to tire load.\nThe normalized tire load is simply the tire load divided by the load experienced when the vehicle is perfectly at rest.\nA value of 2 for latStiffX means that when the tire has a load more than twice its rest load it can deliver no more lateral stiffness no matter how much extra load is applied to the tire.\nThe **latStiffY** parameter describes the maximum stiffness per unit of lateral slip (in radians) per unit rest load.\nThe maximum stiffness is delivered when the tire is in the saturated load regime, governed in turn by latStiffX.\n\nA good starting value for latStiffX is somewhere between 2 and 3.\nA good starting value for latStiffY is around 18 or so.\n\n- *: float*\n- *: 25, 180*\n\n```cpp\nlatStiffX = 2.0;\nlatStiffY = __EVAL(0.3125 * (180.0 / Pi));\n```\n\n##### frictionVsSlipGraph\n\nThese six values describe a graph of friction as a function of longitudinal slip.\nVehicle tires have a complicated response to longitudinal slip and this graph attempts to quickly describe this relationship.\n\nTypically, tires have a linear response at small slips.\nThis means that when the tire is only slightly slipping it is able to generate a response force that grows as the slip increases.\nAt greater values of slip, the force can actually start to decrease from the peak value that occurs at the optimum slip.\nBeyond the optimum slip, the tire eventually stops behaving less and less efficiently and hits a plateau of inefficiency.\n\nThe first two values describe the friction at zero tire slip:\n\n```\nfrictionVsSlipGraph[0][0] = 0\nfrictionVsSlipGraph[0][1] = friction at zero slip.\n```\n\nThe next two values describe the optimum slip and the friction at the optimum slip:\n\n```\nfrictionVsSlipGraph[1][0] = optimum slip\nfrictionVsSlipGraph[1][1] = friction at optimum slip.\n```\n\nThe last two values describe the slip at which the plateau of inefficiency begins and the value of the friction available at the plateau of inefficiency:\n\n```\nfrictionVsSlipGraph[2][0] = slip at the start of the plateau of inefficiency\nfrictionVsSlipGraph[2][1] = the friction available at the plateau of inefficiency.\n```\n\nThe friction values described here are used to scale the friction of the ground surface.\nThis means they should be in range (0,1) but this is not a strict requirement.\nTypically, the friction from the graph would be close to 1.0 in order to provide a small correction to the ground surface friction.\n\nA good starting point for this is a flat graph of friction vs slip with these values:\n\n```\nfrictionVsSlipGraph[0][0] = 0.0\nfrictionVsSlipGraph[0][1] = 1.0\nfrictionVsSlipGraph[1][0] = 0.5\nfrictionVsSlipGraph[1][1] = 1.0\nfrictionVsSlipGraph[2][0] = 1.0\nfrictionVsSlipGraph[2][1] = 1.0\n```\n\ngiving this array as a result:\n\n```cpp\nfrictionVsSlipGraph[] = { { 0.0, 1.0 }, { 0.5, 1.0 }, { 1.0, 1.0 } };\n```\n\n- *: Array[3][2]*\n- *: { { 0.0, 1.0 }, { 0.5, 1.0 }, { 1.0, 1.0 } }*\n\n```cpp\nfrictionVsSlipGraph[] = { { 0.0, 0.4 }, { 0.5, 1.0 }, { 0.75, 0.60 } };\n```\n\n### CarX specifics\n\n- Anti-roll bars is the system in a vehicle that should prevent it to do a barrel-roll during sharper turns. Using ARB enables us to make the center of mass realistically high and cause cars to roll down the steep slopes if placed sideways to the slope. It works the same way as the real ones - system computes the difference of applied weight to wheels in pair and tries to compensate difference by applying opposite forces.\n- **antiRollbarForceCoef** is a coefficient of applied force, could be taken as the strength of the system. Setting this value to zero disables ARB (and all next values), which is good for civilian vehicles, higher values reduce not only the risk of rolling but effects of suspension.\n- **antiRollbarForceLimit** is the highest strength of ARB applied to the vehicle. We may want to roll the car at certain situations (full van taking a sharp handbrake turn at high speed), tunning without diag mode is almost impossible because we are not able to imagine forces needed (values are rather low, 2 should be high enough for most of the vehicles)\n- **antiRollbarSpeedMin** and **antiRollbarSpeedMax** are limits of applied force coefficient. The coefficient is 0 at speeds lower than antiRollbarSpeedMin, interpolates to antiRollbarForceCoef at antiRollbarSpeedMax and is set to antiRollbarForceCoef for any higher speeds. This allows cars to drive on steep slopes using their radial speed, falling off the hill once they stop and rolling over at too high speeds (where coefficient doesn't grow and force is limited by the limit).\n\n##### brakeIdleSpeed\n\n**brakeIdleSpeed** is speed in **m/s** under which the brakes are automatically applied to the vehicle.\nThis speed should be reasonably low, higher value would mean strange breaking of slow cars, too low value would cause inability to stop the car.\n\n- *: float*\n- *: > 0*\n\n```cpp\nbrakeIdleSpeed = 0.2;\n```\n\n##### antiRollbarForceCoef\n\n**antiRollbarForceCoef** is a coefficient of applied force, could be taken as strength of the system.\nSetting this value to zero disables ARB (and all next values), which is good for civilian vehicles.\nHigher values reduce not only the risk of rolling but effects of suspension.\n\n##### antiRollbarForceLimit\n\n**antiRollbarForceLimit** is the highest strength of ARB applied to vehicle.\nWe may want to roll the car at certain situations (full van taking a sharp handbrake turn at high speed), tuning without diag mode is almost impossible because we are not able to imagine forces needed (values are rather low, 2 should be high enough for most of the vehicles)\n\n##### antiRollbarSpeedMin\n\n##### antiRollbarSpeedMax\n\n**antiRollbarSpeedMin** and **antiRollbarSpeedMax** are limits of applied force coefficient.\nCoefficient is 0 at speeds lower than **antiRollbarSpeedMin**, interpolates to antiRollbarForceCoef at antiRollbarSpeedMax and is set to antiRollbarForceCoef for any higher speeds.\nThis allows cars to drive on steep slopes using their radial speed, falling off the hill once they stop and rolling over at too high speeds (where coefficient doesn't grow and force is limited by the limit).\n\n##### terrainCoef\n\nSets the importance of surfaceFriction on limiting the vehicle maximum speed on various surfaces. The bigger the value to slower the vehicle will be able to go over rough surfaces.\n\n- *: float*\n- *: >= 0*\n- *: 1.0*\n\n```cpp\nterrainCoef = 2.0;\n```\n\n##### turnCoef\n\nDefines the maximum steering angle of a car.\n\n- *: float*\n- *: >= 0*\n- *: 2.0*\n\n```cpp\nturnCoef = 3.0;\n```\n\n### TankX specifics\n\nMain differences from CarX:\n\n- More wheels to be set up\n- Few additional params used\n- Less complicated Center of Mass tweaking\n- Vehicle config parameter: **tankTurnForce**\n- Importance of wheel config parameters: **MOI**, **dampingRate**, **dampingRateInAir**\n- `boneName = \"\"` in Wheel classes needs to be the damper bone in model.cfg (instead of the visual wheel bone for CarX)\n\n##### tankTurnForce\n\nInitial force applied to turning in [0, tankTurnForceAngMinSpd] angular speed range to help the tank overcome friction when turning.\n\n- *: float*\n- *: (required)*\n\n```cpp\ntankTurnForce = 0.66e6; // start from 11x vehicle mass in kg and tweak until fine\n```\n\n##### tankTurnForceAngMinSpd\n\nAngular speed (in **rad/s**) where tankTurnForce starts fading to 0 @ tankTurnForceAngSpd\n\n- *: float*\n- *: >= 0*\n- *: 0.0*\n\n```cpp\ntankTurnForceAngMinSpd = 3.0;\n```\n\n##### tankTurnForceAngSpd\n\nAn angular speed (in **rad/s**) where tankTurnForce becomes 0\n\n- *: float*\n- *: >= 0*\n- *: 4.0*\n\n```cpp\ntankTurnForceAngSpd = 3.0;\n```\n\n### ShipX specifics\n\n*TODO - see Arma 3: Ships Config Guidelines*\n\n### See also\n\n- Arma 3: Cars Config Guidelines\n- Arma 3: Tanks Config Guidelines\n- Arma 3: Ships Config Guidelines\n- CfgVehicles Config Reference","sections":[{"heading":"Common","level":3,"markdown":""},{"heading":"General parameters","level":4,"markdown":""},{"heading":"simulation","level":5,"markdown":"Defines simulation type of the vehicle. PhysX simulation ends with letter \"x\". Can be:\n\n- **carx**   for PhysX cars\n- **tankx** for PhysX tanks\n- **shipx** for PhysX boats"},{"heading":"thrustDelay","level":5,"markdown":"**thrustDelay** is time in second in which thrust (as an input value) goes from 0 to 1 when standing still (doesn't affect driving car during change of gears).\n0.5 is the minimum value. You may want to tweak this to higher values if wheels slide during initial acceleration.\n\n- *: float*\n- *: >= 0*\n- *: 0.5*\n\n```cpp\nthrustDelay = 0.5;\n```"},{"heading":"accelAidForceCoef","level":5,"markdown":"**accelAidForceCoef** is an artificial aid force applied to a vehicle when accelerating. Goes from x1 when standing still to x0 at a speed defined in accelAidForceSpd. Ideally a vehicle should be configured with this property set to zero and it should only be used for final fine-tuning.\n\n- *: float*\n- *: >= 0*\n- *: 5.0*\n\n```cpp\naccelAidForceCoef = 3.0;\n```"},{"heading":"accelAidForceSpd","level":5,"markdown":"This is a minimum speed in **m/s** when accelAidForceCoef becomes zero and is no longer applied.\n\n- *: float*\n- *: >= 0*\n- *: 5.0*\n\n```cpp\naccelAidForceSpd = 5.0;\n```"},{"heading":"accelAidForceYOffset","level":5,"markdown":"This is a vertical offset from the vehicle's center of mass where the accelAidForceCoef will be applied. Used to accent the vehicle's weight shifting during an acceleration.\n\n- *: float*\n- *: >= 0*\n- *: 0.0*\n\n```cpp\naccelAidForceCoef = -1.0;\n```"},{"heading":"maxSpeed","level":5,"markdown":"Defines the maximum driving speed of the vehicle when driving by \"Car Fast Forward\" action. Set in **km/h**. Works as a limiter - the vehicle's thrust will get cut around this speed.\n\n- *: float*\n- *: >= 0*\n\n```cpp\nmaxSpeed = 100;\n```"},{"heading":"slowSpeedForwardCoef","level":5,"markdown":""},{"heading":"normalSpeedForwardCoef","level":5,"markdown":"Coefficients of maxSpeed that are used to limit the actual maximum speed depending on which - \"Car Forward\", \"Car Slow Forward\" or \"Car Fast Forward\" - action is used. \"Car Fast Forward\" uses directly the maxSpeed value.\n\n- **slowSpeedForwardCoef** is set to 0.3 by default\n- **normalSpeedForwardCoef** is set to 0.85 by default\n- default speed coefficient for fast movement is 1 meaning that full throttle is applied and maximal speed is maxSpeed of the vehicle (it is going to apply less throttle upon reaching the limit)\n\n```cpp\nslowSpeedForwardCoef = __EVAL(30/100);\nnormalSpeedForwardCoef = __EVAL(50/100);\n```"},{"heading":"waterLeakiness","level":5,"markdown":"Should be the amount of water in liters that goes into selected object per second.\nThis is set to zero by engine for all vehicles with simulation of a ship or having `canFloat = 1;` (until they are toppled or destroyed, then config value takes precedence).\n`WaterLeakiness = 10;` seems to be a good value to start with for all kinds of vehicles no matter the size.\n\n- *: float* (or *sink*)\n- *: >= 0*\n\n```cpp\nwaterLeakiness = 10;\n```"},{"heading":"Engine parameters","level":4,"markdown":""},{"heading":"enginePower","level":5,"markdown":"Power of the engine **in kW**.\n\n- *: float*\n- *: >= 0*\n- *: (required)*\n\n```cpp\nenginePower = 600;\n```"},{"heading":"maxOmega","level":5,"markdown":"This is the maximum rotational speed of the engine expressed in **radians per second**. It could be calculated from maximum engine RPM like this:\n\n```\nmaxOmega = (maxRpm * 2 * Pi) / 60\n```\n\n- *: float*\n- *: > 0*\n- *: 600 which is cca 6000 rounds per minute.*\n\n```cpp\nmaxOmega = __EVAL((6000 * 2 * PI) / 60);\n```"},{"heading":"minOmega","level":5,"markdown":"This is the idle (minimum) rotational speed of the engine expressed in **radians per second**.\n\n- *: float*\n- *: > 0*\n- *: 0*\n\n```cpp\nminOmega = __EVAL((800 * 2 * PI) / 60);\n```"},{"heading":"idleRpm","level":5,"markdown":"**idleRpm** sets the idle RPM solely for the sound engine. Expressed in **revolutions per minute**."},{"heading":"redRpm","level":5,"markdown":"**redRpm** sets the maximum RPM solely for the sound engine. Expressed in **revolutions per minute**."},{"heading":"peakTorque","level":5,"markdown":"This is the maximum torque that is ever available from the engine. This is expressed in **Newton metres**.\nA starting value might be around 600.\n\n- *: float*\n- *: > 0*\n- *: value calculated from enginePower according to http://en.wikipedia.org/wiki/Horsepower#Relationship_with_torque*\n\n```cpp\npeakTorque = 600;\n```"},{"heading":"torqueCurve","level":5,"markdown":"This is a graph of peak torque versus engine rotational speed.\nCars typically have a range of engine speeds that produce good drive torques, and other ranges of engine speed that produce poor torques.\nA skilled driver will make good use of the gears to ensure that the car remains in the \"good\" range where the engine is most responsive.\nTuning this graph can have profound effects on gameplay.\n\nThe x-axis of the curve is the normalised engine speed; that is, the engine speed divided by the maximum engine speed. The y-axis of the curve is a multiplier in range (0,1) that is used to scale the peak torque. The samples do not have to be equally spaced apart. You can distribute the points between both 0% rpm and 100% rpm points as you wish.\n\n- *: Array[i][2] where i = number of samples,* maximum 8'\n- *: { { 0.0, 0.8 }, { 0.33, 1.0 }, { 1.0, 0.8 } }*\n\n```cpp\ntorqueCurve[] = { { 0.0, 0.8 }, { 0.33, 1.0 }, { 1.0, 0.8 } };\n```\n\n**NOTE:** you can also use math in this definition, here is the same example from above using this technique:\n\n```cpp\ntorqueCurve[] = { { __EVAL(0/2400), __EVAL(80/100) }, { __EVAL(792/2400), __EVAL(100/100) }, { __EVAL(2400/2400), __EVAL(80/100) } };\n```"},{"heading":"engineMOI","level":5,"markdown":"This the moment of inertia of the engine around the axis of rotation. Larger values make it harder to accelerate the engine, while lower values make it easier to accelerate the engine. A starting value of 1.0 is a good choice. Tweak together with engine damping rates.\n\n- *: float*\n- *: >= 0*\n- *: 1.0*\n\n```cpp\nengineMOI = 1.0;\n```"},{"heading":"dampingRateFullThrottle","level":5,"markdown":""},{"heading":"dampingRateZeroThrottleClutchEngaged","level":5,"markdown":""},{"heading":"dampingRateZeroThrottleClutchDisengaged","level":5,"markdown":"These three values are used to compute the damping rate that is applied to the engine.\nIf the clutch is engaged then the damping rate is an interpolation between **dampingRateFullThrottle** and **dampingRateZeroThrottleClutchEngaged**, where the interpolation is governed by the acceleration control value generated by the gamepad or keyboard.\nAt full throttle **dampingRateFullThrottle** is applied, while dampingRateZeroThrottleClutchEngaged is applied at zero throttle.\nIn neutral gear, the damping rate is an interpolation between dampingRateFullThrottle and dampingRateZeroThrottleClutchDisengaged.\n\nThe three values allow a range of effects to be generated: good acceleration that isn't hampered by strong damping forces,\ntunable damping forces when temporarily in neutral gear during a gear change,\nand strong damping forces that will bring the vehicle quickly to rest when it is no longer being driven by the player.\n\nTypical values in range (0.25,3). The simulation can become unstable with damping rates of 0.\n\n- *: float*\n- *: > 0*\n- *: 0.08, 2.0, 0.35*\n\n```cpp\ndampingRateFullThrottle = 0.08;\ndampingRateZeroThrottleClutchEngaged = 2.0;\ndampingRateZeroThrottleClutchDisengaged = 0.35;\n```"},{"heading":"Transmission parameters","level":4,"markdown":""},{"heading":"clutchStrength","level":5,"markdown":"This describes how strongly the clutch couples the engine to the wheels and how quickly differences in speed are eliminated by distributing torque to the engine and wheels.\n\nWeaker values will result in more clutch slip, especially after changing gear or stamping on the accelerator.\nStronger values will result in a reduced clutch slip, and more engine torque delivered to the wheels.\n\nThis value is to be edited only for very fine tweaking of the vehicle.\nSome clutch slip can be attributed to the numerical issues in the simulation at large timesteps, while some is a natural consequence of driving the car in an overly aggressive manner.\nA value of 10 is a good starting point.\n\n- *: float*\n- *: >= 0*\n- *: 10.0*\n\n```cpp\nclutchStrength = 10.0;\n```"},{"heading":"latency","level":5,"markdown":"This is the minimum time (in **seconds**) that must pass between each gear change that is initiated by the autobox.\nThis should be set to value higher than switchTime.\nSetting this time too low makes some issues with changing gears - the car then slows down a lot.\n\n- *: float*\n- *: >= 0*\n- *: 2.0*\n\n```cpp\nlatency = 1.0;\n```"},{"heading":"switchTime","level":5,"markdown":"The switch time describes how long it takes (in seconds) for a gear change to be completed.\nIt is impossible to change gear immediately in a real car.\nManual gears, for example, require neutral to be engaged for a short time before engaging the desired target gear.\nWhile the gear change is being completed the car will be in neutral.\nA good trick might be to penalise players that use an automatic gear box by increasing the gear switch time.\n\n- *: float*\n- *: >= 0*\n- *: 0.01*\n\n```cpp\nswitchTime = 0.5;\n```"},{"heading":"changeGearType","level":5,"markdown":"Defines which changeGear condition type is used for the automatic gearbox. If set to \"rpmratio\" the gears will be switched based on RPM ratio max/min pairs defined in changeGearOmegaRatios. If set to \"effective\" the gears will be switched based on engine torque ratios defined in changeGearMinEffectivity.\n\n- *: string*\n- *: [\"rpmatio\",\"effective\"]*\n- *: effective*\n\n```cpp\nchangeGearType = \"rpmratio\";\n```"},{"heading":"changeGearMinEffectivity","level":5,"markdown":"Value of minimal gear effectivity to hold current gear. If there is better gear and effectivity is below this value then change gear. Used when changeGearType is set to \"effective\".\n\n- *: Array[i] where i = number of gears*\n- *: 0..1*\n- *: 0.95 for every value*\n\n```cpp\nchangeGearMinEffectivity[] = { 0.95, 0.15, 0.95, 0.95, 0.95, 0.95, 0.95 };\n```"},{"heading":"changeGearOmegaRatios","level":5,"markdown":"Pairs of maximum and minimum engine RPM to hold the current gear. Used when changeGearType is set to \"rpmratio\".\n\n- *: Array[i] where i = number of gears * 2*\n- *: 0..1*\n\n```cpp\nchangeGearOmegaRatios[] = {\n __EVAL(6000/6000) , __EVAL(1000/6000), // R1\n __EVAL(1000/6000) , 0, // N\n __EVAL(5800/6000) , __EVAL(1000/6000), // D1\n __EVAL(5500/6000) , __EVAL(3000/6000), // D2\n __EVAL(5300/6000) , __EVAL(2800/6000), // D3\n __EVAL(5300/6000) , __EVAL(2500/6000), // D4\n __EVAL(5300/6000) , __EVAL(2500/6000) // D5\n};\n```"},{"heading":"class complexGearbox","level":5,"markdown":"- All PhysX 3 vehicles use complex gearbox to give some data to PhysX gearbox\n- Complex gearbox settings is inside **class complexGearbox** which is a subclass of vehicle class\n- **GearboxRatios[]** is an array of gear names and gear ratios starting with reverse gear (with negative ratios), neutral gear (which should have zero ratio) and forward ratio (eg: *{\"R1\",-3.231,\"N\",0,\"D1\",2.462,\"D2\",1.870,\"D3\",1.241,\"D4\",0.970,\"D5\",0.711};*). Gear names are not used in retail version, they are just for **epevehicle** diagnostics. **Important**: There can only be one reverse Gear (which must have negative value) and one Neutral gear (which must have 0 as ratio). All forward gears must have a value greater than zero and they must be ordered from high ratio to low\n- **TransmissionRatios[]** is an array of remaining drivetrain ratios in the same format as gearboxRatios. Most of cars have only one final drive, some heavy trucks may have a double reduction gear . The final ratio is then gearboxRatio * TransmissionRatio, that means transmissionRatios shouldn't be multiplicates of each other and gearbox ratios to prevent the same final ratio for two different gears.\n- **gearBoxMode** is set to full-auto by engine. The full-auto mode can skip gears to get the best possible gear for each condition.\n- **moveOffGear** defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default.\n- **driveString**, **neutralString** and **reverseString** define displayed strings for driving forward, neutral and backward.\n\n```cpp\ncomplexGearbox\n{\n GearboxRatios[] = {\n \"R1\", -3.231,\n \"N\", 0,\n \"D1\", 2.462,\n \"D2\", 1.870,\n \"D3\", 1.241,\n \"D4\", 0.970,\n \"D5\", 0.711\n };\n\n // Optional: defines transmission ratios (for example, High and Low range as commonly found in offroad vehicles)\n TransmissionRatios[] = { \"High\",4.111 };\n\n // defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default.\n moveOffGear = 1;\n\n driveString = \"D\"; // string to display in the HUD for forward gears.\n neutralString = \"N\"; // string to display in the HUD for neutral gear.\n reverseString = \"R\"; // string to display in the HUD for reverse gears.\n};\n```"},{"heading":"Differential parameters","level":4,"markdown":""},{"heading":"differentialType","level":5,"markdown":"A number of differential types are supported: 4-wheel drive with open differential, 4-wheel drive with limited slip, front-wheel drive with open differential, front-wheel drive with limited slip, rear-wheel drive with open differential, rear-wheel drive with limited slip.\n\n- *: string; accepable values: \"all_open\", \"all_limited\", \"front_open\", \"front_limited\", \"rear_open\", \"rear_limited\"*\n- *: \"all_limited\"*\n\n```cpp\ndifferentialType = \"all_limited\";\n```"},{"heading":"frontRearSplit","level":5,"markdown":"If a 4-wheel drive differential is chosen (open or limited slip) this option allows the drive torque to be split unevenly between the front and rear wheels.\nChoosing a value of 0.5 delivers an equal split of the torque between the front and rear wheels; that is, the total torque delivered to the front wheels is equal to the total torque delivered to the rear wheels. Choosing a value greater than 0.5 delivers more torque to the front wheels while choosing a value less than 0.5 delivers more torque to the rear wheels.\nThis value is ignored for front-wheel drive and rear-wheel drive differentials.\n\n- *: float*\n- *: 0..1*\n- *: 0.5*\n\n```cpp\nfrontRearSplit = 0.5;\n```"},{"heading":"frontBias","level":5,"markdown":"Limited slip differentials work by only allowing a certain difference in wheel rotation speed to accumulate.\nThis prevents the situation where one wheel is slipping but ends up taking all the available power.\nFurther, by allowing a small difference in wheel rotation speed to accumulate it is possible for the vehicle to easily corner by permitting the outside wheel to rotate quicker than the inside wheel.\n\nThis parameter describes the maximum difference in wheel rotation speed that is allowed to accumulate.\nThe front bias is the maximum of the two front-wheel rotation speeds divided by the minimum of the two front-wheel rotation speeds.\nWhen this ratio exceeds the value of the front bias the differential diverts torque from the faster wheel to the slower wheel in an attempt to preserve the maximum allowed wheel rotation speed ratio.\n\nThis value is ignored except for front-wheel drive or four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\nfrontBias = 1.3;\n```"},{"heading":"rearBias","level":5,"markdown":"This is similar to frontBias except that it refers to the rear wheels.\n\nThis value is ignored except for rear-wheel drive or four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\nrearBias = 1.3;\n```"},{"heading":"centreBias","level":5,"markdown":"This value is similar to the frontBias and rearBias, except that it refers to the sum of the front wheel rotation speeds and the sum of the rear wheel rotation speeds.\n\nThis value is ignored except for four-wheel drive with limited slip.\n\nA good starting value is around 1.3.\n\n- *: float*\n- *: >= 1.0*\n- *: 1.3*\n\n```cpp\ncentreBias = 1.3;\n```"},{"heading":"Wheel parameters","level":4,"markdown":""},{"heading":"boneName","level":5,"markdown":"Name of the bone, used for wheel and suspension animations.\nThe standard bone structure would be as such: damperbone → steeringbone → rotatingbone (example: wheel_1_1_damper → wheel_1_1_steering → wheel_1_1).\nAs boneName you would set the rotatingbone (e.g. wheel_1_1).\nIn the visual LODs this \"rotatingbone\" is generally the selection of the tire.\n\n- *: string*\n- *: \"\"*\n\n```cpp\nboneName = \"wheel_1_1\";\n```"},{"heading":"steering","level":5,"markdown":"If true, wheel is steerable, false - wheel is fixed.\n\n- *: bool*\n- *: (required)*\n\n```cpp\nsteering = true;\n```"},{"heading":"side","level":5,"markdown":"Defines if wheel is on vehicle left or right side\n\n- *: string*\n- *: \"right\"*\n\n```cpp\nside = \"left\";\n```"},{"heading":"center","level":5,"markdown":"Center of the wheel (axis)\n\n- *: memory point*\n- *: (required)*\n\n```cpp\ncenter = \"wheel_1_1_axis\";\n```"},{"heading":"boundary","level":5,"markdown":"Point on the outside rim of the tire, used to calculate radius of the wheel (distance between center and boundary).\n\n- *: memory point*\n- *: (required)*\n\n```cpp\nboundary = \"wheel_1_1_bound\";\n```"},{"heading":"width","level":5,"markdown":"This is the full width of the wheel in metres. It affects wheels collision detection\n\n- *: float*\n- *: > 0*\n- *: 0.3 * (radius of the wheel)*\n\n```cpp\nwidth = 0.2;\n```"},{"heading":"mass","level":5,"markdown":"This is the combined mass of the wheel and the tire in kg. Typically, a wheel has mass between 20Kg and 80Kg but can be lower and higher depending on the vehicle.\n\n- *: float*\n- *: > 0*\n- *: 10.0*\n\n```cpp\nmass = 150;\n```"},{"heading":"MOI","level":5,"markdown":"This is the component of the wheel's Moment of Inertia (M.o.I) about the rolling axis.\nLarger values make it harder for the wheel to rotate about this axis, while easier values make it easier for the wheel to rotate about the rolling axis.\nAnother way of expressing this is that a high MOI will result in less wheel spin when stamping on the accelerator because it is harder to make the wheel spin.\nConversely, lower values of MOI will result in more wheel spin when stamping on the accelerator.\nIf the wheel is approximately cylindrical then a simple formula can be used to compute MOI:\n\n```\nMOI = 0.5 * Mass * Radius * Radius\n```\n\nThere is no reason, however, to rely on equations to compute this value.\nA good strategy for tuning this number might to be start with the equation above and then make small tweaks to the value until the handling is as desired.\n\n- *: float*\n- *: > 0*\n- *: 0.5 * WheelMass * WheelRadius * WheelRadius*\n\n```cpp\nMOI = 40;\n```"},{"heading":"dampingRate","level":5,"markdown":""},{"heading":"dampingRateDamaged","level":5,"markdown":""},{"heading":"dampingRateDestroyed","level":5,"markdown":"These values describe how quickly a freely spinning wheel will come to rest.\nThe damping rate describes the rate at which a freely spinning wheel loses rotational speed.\nHere, a freely spinning wheel is one that experiences no forces except for the damping forces arising from the wheel's internal bearings.\nHigher damping rates result in the wheel coming to rest in shorter times, while lower damping rates result in the wheel maintaining speed for longer.\nValues in range (0.25, 2) seem like sensible values. Experimentation is always a good idea, even outside this range.\nAlways exercise some caution with very small damping rates. In particular, **a damping rate of exactly 0 should be avoided**.\n\n- *: float*\n- *: > 0*\n- *: 0.1*\n\n```cpp\ndampingRate = 0.1;\ndampingRateDamaged = 1.0;\ndampingRateDestroyed = 1000.0;\n```"},{"heading":"maxBrakeTorque","level":5,"markdown":"This is the value of the torque applied to the wheel when the brakes are maximally applied.\nHigher torques will lock the wheel quicker when braking, while lower torques will take longer to lock the wheel.\nThis value is strongly related to the wheel MOI because the MOI determines how quickly the wheel will react to applied torques.\n\nA value of around 1500 is a good starting point for a vanilla wheel but a google search will reveal typical braking torques.\nOne difficulty is that these are often expressed by manufacturers as braking horsepower or in \"pounds inches\".\nThe values required here are in *Newton metres*.\n\n- *: float*\n- *: >= 0*\n- *: 2500*\n\n```cpp\nmaxBrakeTorque = 7500;\n```"},{"heading":"maxHandBrakeTorque","level":5,"markdown":"This is the same as the max brake torque except for the handbrake rather than the brake.\nTypically, for a 4-wheeled car, the handbrake is stronger than the brake and is only applied to the rear wheels.\nA value of 4000 for the rear wheels is a good starting point, while a value of 0 is necessary for the front wheels to make sure they do not react to the handbrake.\n\n- *: float*\n- *: >= 0*\n- *: 2 * maxBrakeTorque*\n\n```cpp\nmaxHandBrakeTorque = 0;\n```"},{"heading":"tireForceAppPointOffset","level":5,"markdown":"This is almost the same as the suspension force app point except for the lateral and longitudinal forces that develop on the tire.\n\nA good starting point is to duplicate the suspension force application point.\nOnly for really detailed editing is it advised to start tweaking the tire force app offset independently of the suspension force app offset.\n\n- *: memory point*\n- *: suspForceAppPointOffset*\n\n```cpp\ntireForceAppPointOffset = \"wheel_1_1_axis\";\n```"},{"heading":"Suspension parameters","level":4,"markdown":""},{"heading":"dampersBumpCoef","level":5,"markdown":"Defines how much dampers react to random little bumps on surface.\nThis only has a visual effect and doesn't influence driving simulation. It is only taken into account when calculating damper animation.\n\n- *Type: float*\n- *: >= 0*\n- *Default: 0.0*\n\n```cpp\ndampersBumpCoef = 0.3;\n```"},{"heading":"maxCompression","level":5,"markdown":""},{"heading":"maxDroop","level":5,"markdown":"These values describe the maximum compression and elongation in metres that the spring can support.\nThe total travel distance along the spring direction that is allowed is the sum of **maxCompression** and **maxDroop**.\n\nA simple way to illustrate the maximum droop and compression values is to consider a car that is suspended in mid-air so that none of the wheels are touching the ground.\nThe wheels will naturally fall downwards from their rest position until the maximum droop is reached.\nThe spring cannot be elongated beyond this point. Now consider that the wheel is pushed upwards, first to its rest position, then further pushed until the spring can no longer be compressed.\nThe displacement from the rest position is the maximum compression of the spring.\n\nIt is important to choose the maximum compression value so that the wheel is never placed where the visual mesh of the wheel intersects the visual meshes of the car chassis.\nIdeally, these values will be exported from the 3D modeller.\n\n- *: float*\n- *: >= 0*. Important: If one of the values is zero, the other must be greater than zero\n- *: 0.15*\n\n```cpp\nmaxCompression = 0.15;\nmaxDroop = 0.15;\n```"},{"heading":"sprungMass","level":5,"markdown":"This is the mass in kg that is supported by the suspension spring.\n\nA vehicle with rigid body centre of mass at the centre of the four wheels would typically be equally supported by each of the suspension springs;\nthat is, each suspension spring supports 1/4 of the total vehicle mass.\nIf the centre of mass was moved forward then it would be expected that the front wheels would need to support more mass than the rear wheels.\nConversely, a centre of mass nearer the rear wheels ought to result in the rear suspension springs supporting more mass than at the front.\nAll the mass of the vehicle must be \"carried\" by the sprung mass values, means: The sum of sprungMass values for all Wheels must be equal to the vehicle's weight.\n\n- *: float*\n- *: > 0*\n- *: vehicleMass / numberOfWheels*\n\n```cpp\nsprungMass = 2066;\n```"},{"heading":"springStrength","level":5,"markdown":"This is the strength of the suspension spring in Newtons per metre.\nThe spring strength has a profound influence on handling by modulating the time it takes for the vehicle to respond to bumps in the road and on the amount of load experienced by the tire.\n\nKey to the understanding the effect of spring strength is the concept of a spring's natural frequency.\nConsider a simple spring system, such as a pendulum swinging back and forth.\nThe number of trips per second that the pendulum makes from full left to full right and then back again is called the natural frequency of the pendulum.\nA more powerful pendulum spring will result in the pendulum swinging faster, thereby increasing the natural frequency.\nConversely, increasing the pendulum mass will result in a slower oscillation, thereby reducing the natural frequency.\n\nIn the context of a suspension spring supporting a fixed portion of vehicle mass, the strength of the spring will affect the natural frequency;\nthat is the rate at which the spring can respond to changes in load distribution. Consider a car taking a corner.\nAs the car corners, it leans into the turn, putting more weight on the suspensions on the outside of the turn.\nThe speed at which the spring reacts by applying forces to redistribute the load is controlled by the natural frequency.\nVery high natural frequencies, such as those on a racing car, will naturally produce twitchy handling because the load on the tires, and therefore the forces they can generate, is varying very rapidly.\nVery low natural frequencies, on the other hand, will result in the car taking a long time to straighten up even after the turn is complete.\nThis will produce sluggish and unresponsive handling.\n\nAnother effect of strength and natural frequency is the response of a car to a bump in the road.\nHigh natural frequencies can result in the car responding very strongly and quickly to the bump, with the wheel possibly even leaving the road for a short while.\nThis not only creates a bumpy ride but also periods of time when the tire is generating no forces.\nWeaker springs will result in a smoother trip over the bump, with weaker but more constant tire forces.\nA balance must be found to tune the car for the expected types of turn and terrain.\n\nThe natural frequency of the spring presents a challenge for computer simulation.\nA smooth and stable simulation requires that the spring is updated at a frequency much greater than the spring's natural frequency.\nAn alternative way of expressing this is to consider the period of the spring relative to the timestep of the simulation.\nThe period of the spring is the time the spring takes to complete a single oscillation and is mathematically equal to the reciprocal of the natural frequency.\nIn order to achieve a stable simulation, the spring must be sampled at several points during each oscillation.\nA natural consequence of this observation is that the simulation timestep must be significantly smaller than the period of the spring.\nTo discuss this further it is helpful to introduce a ratio that describes the number of simulation updates that will occur during each spring oscillation.\nThis ratio is simply the spring period divided by the timestep:\n\n```\nalpha = sqrt(sprungMass / springStrength) / timestep\n```\n\nwhere `sqrt(sprungMass / springStrength)` is the period of the spring.\nAn alpha value of 1.0 means that the chosen timestep and spring properties only allow a single sample of the spring during each oscillation.\nAs described above, this is almost guaranteed to produce unstable behavior.\nIn fact, the argument presented so far suggests **a value of alpha significantly greater than 1.0 is essential to produce a smooth simulation**.\nThe exact value of alpha at which stability emerges is very difficult to predict and depends on many other parameters.\nAs a guide, however, it is recommended that the timestep and spring properties are chosen so that they produce an alpha value greater than 5.0; that is, a minimum of five simulation updates per spring cycle.\n\nWhen tuning a suspension spring it can be very useful to use manufacturer data to discover typical values used across a range of vehicle types.\nThis data is not always readily available.\nAn alternative strategy would be to think in terms of the natural frequency of the spring by imagining how quickly the car would oscillate up and down if it was dropped onto the ground from a height of, say, 0.5m.\nThe springs of a typical family car have natural frequency somewhere between 5 and 10; that is, such a car would make 5-10 oscillations per second if gently dropped to the ground.\nIf the mass supported by the spring is already known then the spring strength can be calculated from the following equation:\n\n```\nspringStrength = naturalFrequency * naturalFrequency * sprungMass\n```\n\n- *: float*\n- *: > 0*\n- *: sprungMass * 5.0 * 5.0*\n\n```cpp\nspringStrength = 51653;\n```"},{"heading":"springDamperRate","level":5,"markdown":"This describes the rate at which the spring dissipates the energy stored in the spring.\n\nKey to the understanding of damper rate are the concepts of under-damping, over-damping, and critical damping.\nAn over-damped pendulum displaced from rest is unable to make a single back-and-forth trip before it dissipates all its energy,\nwhile an under-damped pendulum would be able to make at least a single back-and-forth trip.\nA critically damped pendulum makes exactly a single back-and-forth trip before expending all its energy.\n\nFor vehicle suspension springs, it is typically important to make sure that the spring has a damper rate that produces over-damping but not by too much.\nWhen cornering, for example, it is important that the spring doesn't over-respond by shifting the weight from the left suspension to the right suspension then back again.\nIf this happened the tire load, and the forces generated, would be extremely variable, resulting in twitchy and uncontrollable handling.\nA very heavily over-damped spring, on the other hand, will feel sluggish and unresponsive.\nThe concept of critical damping can be used to help tune the damping rate of the spring.\nIt is helpful to introduce a value known as the damping ratio, which helps to mathematically describe the under-damping, critical damping and over-damping regimes:\n\n```\ndampingRatio = springDamperRate / (2 * sqrt(springStrength * sprungMass))\n```\n\nA dampingRatio with value greater than 1.0 produces over-damping, a value of exactly 1.0 generates critical damping, and a value less than 1.0 is under-damped.\nIt can be useful to first think about whether the spring will be under-damped or over-damped, then think about how far it will be from critical damping.\nThis process allows a number to be subjectively applied to the damping ratio.\nFrom here the damping rate can be directly computed by rearranging the equation above:\n\n```\nspringDamperRate = dampingRatio * 2 * sqrt(springStrength * sprungMass)\n```\n\nA typical family car is probably slightly over-damped, having dampingRatio with value perhaps just over 1.0.\nA guideline would be that values very far from critical damping are likely to be unrealistic and will either produce sluggish or twitchy handling.\nIt is difficult to put an exact figure on this but somewhere between 0.8 and 1.2 seems like a good starting point for the damping ratio.\n\n- *: float*\n- *: >= 0*\n- *: 0.4 * 2 * sqrt(springStrength * sprungMass)*\n\n```cpp\nspringDamperRate = 8264;\n```"},{"heading":"suspTravelDirection","level":5,"markdown":"This is the direction of the suspension in the downward direction in the rest configuration of the vehicle.\nA vector that points straight downwards is a good starting point.\n\n- *: Array[3]*\n- *: { 0, -1, 0 }*\n\n```cpp\nsuspTravelDirection[] = { 0, -1, 0 };\n```"},{"heading":"suspForceAppPointOffset","level":5,"markdown":"This is the application point of the suspension force.\n\nIn a real vehicle, the suspension forces are mediated through the suspension strut.\nThese are often incredibly complex mechanical systems that are computationally expensive to simulate.\nAs a consequence, instead of modeling the details of the suspension strut, it makes sense to assume that the suspension strut has an effective point at which it applies the force to the rigid body.\nChoosing that point, however, needs careful consideration.\nAt the same time, it opens up all sorts of tweaking possibilities, freed from the constraints of the real world.\n\nDeciding on the suspension force application point requires some thought.\nThe suspension is very close to the wheel so the wheel center is a good starting point.\nConsider a line through the wheel center and along the suspension travel direction.\nSomewhere along this line seems like an even better idea for the application point, albeit not completely scientific.\nFor a standard 4-wheeled car it makes sense that the application point is somewhere above the wheel center but below the centre of mass of the rigid body.\nIt is probably above the wheel centre because the suspension is mostly above this point.\nIt can be assumed that it is somewhere below the rigid body centre of mass because otherwise, vehicles would lean out of the turn rather than into the turn.\nThis narrows down the application point to really quite a small section of a known line.\n\nWhen editing the suspension force application point, it is important to bear in mind that lowering the app point too far will result in cars leaning more into the turn.\nThis can have a negative effect on handling because the inner wheel can take so much load that the response saturates, while the outer wheel ends up with reduced load and reduced turning force, the result being poor cornering.\nConversely, setting the app point too high will result in cornering that looks unnatural. The aim is to achieve a good balance.\n\n- *: memory point*\n- *: center*\n\n```cpp\nsuspForceAppPointOffset = \"wheel_1_1_axis\";\n```"},{"heading":"Tire parameters","level":4,"markdown":""},{"heading":"longitudinalStiffnessPerUnitGravity","level":5,"markdown":"The longitudinal tire force is approximately the product of the longitudinal stiffness per unit longitudinal slip (in radians) per unit gravity and the longitudinal slip and the magnitude of gravitational acceleration.\n\nIncreasing this value will result in the tire attempting to generate more longitudinal force when the tire is slipping.\nTypically, increasing longitudinal stiffness will help the car accelerate and brake.\nThe total tire force available is limited by the load on the tire so be aware that increases in this value might have no effect or even come at the expense of reduced lateral force.\n\n- *: float*\n- *: 10000*\n\n```cpp\nlongitudinalStiffnessPerUnitGravity = 5000;\n```"},{"heading":"latStiffX","level":5,"markdown":""},{"heading":"latStiffY","level":5,"markdown":"These values together describe the lateral stiffness per unit lateral slip (in radians) of the tire.\nThe lateral stiffness of a tire has a role similar to the longitudinal stiffness, except that it governs the development of lateral tire forces, and is a function of tire load.\nTypically, increasing lateral stiffness will help the car turn more quickly.\nThe total tire force available is limited by the load on the tire so be aware that increases in this value might have no effect or even come at the expense of reduced longitudinal force.\n\nThe combination of the two values latStiffX and latStiffY describe a graph of lateral stiffness as a function of normalized tire load.\n\nTypical for car tires is a graph that has linear response close to zero load but saturates at greater loads.\nThis means that at low tire loads the lateral stiffness has a linear response to load; that is, more load results in more stiffness.\nAt higher tire loads the tire has a saturated response and is in a regime where applying more load will not result in more tire stiffness.\nIn this latter regime, it would be expected that the tire would start slipping.\n\nThe **latStiffX** parameter describes the normalized tire load above which the tire has a saturated response to tire load.\nThe normalized tire load is simply the tire load divided by the load experienced when the vehicle is perfectly at rest.\nA value of 2 for latStiffX means that when the tire has a load more than twice its rest load it can deliver no more lateral stiffness no matter how much extra load is applied to the tire.\nThe **latStiffY** parameter describes the maximum stiffness per unit of lateral slip (in radians) per unit rest load.\nThe maximum stiffness is delivered when the tire is in the saturated load regime, governed in turn by latStiffX.\n\nA good starting value for latStiffX is somewhere between 2 and 3.\nA good starting value for latStiffY is around 18 or so.\n\n- *: float*\n- *: 25, 180*\n\n```cpp\nlatStiffX = 2.0;\nlatStiffY = __EVAL(0.3125 * (180.0 / Pi));\n```"},{"heading":"frictionVsSlipGraph","level":5,"markdown":"These six values describe a graph of friction as a function of longitudinal slip.\nVehicle tires have a complicated response to longitudinal slip and this graph attempts to quickly describe this relationship.\n\nTypically, tires have a linear response at small slips.\nThis means that when the tire is only slightly slipping it is able to generate a response force that grows as the slip increases.\nAt greater values of slip, the force can actually start to decrease from the peak value that occurs at the optimum slip.\nBeyond the optimum slip, the tire eventually stops behaving less and less efficiently and hits a plateau of inefficiency.\n\nThe first two values describe the friction at zero tire slip:\n\n```\nfrictionVsSlipGraph[0][0] = 0\nfrictionVsSlipGraph[0][1] = friction at zero slip.\n```\n\nThe next two values describe the optimum slip and the friction at the optimum slip:\n\n```\nfrictionVsSlipGraph[1][0] = optimum slip\nfrictionVsSlipGraph[1][1] = friction at optimum slip.\n```\n\nThe last two values describe the slip at which the plateau of inefficiency begins and the value of the friction available at the plateau of inefficiency:\n\n```\nfrictionVsSlipGraph[2][0] = slip at the start of the plateau of inefficiency\nfrictionVsSlipGraph[2][1] = the friction available at the plateau of inefficiency.\n```\n\nThe friction values described here are used to scale the friction of the ground surface.\nThis means they should be in range (0,1) but this is not a strict requirement.\nTypically, the friction from the graph would be close to 1.0 in order to provide a small correction to the ground surface friction.\n\nA good starting point for this is a flat graph of friction vs slip with these values:\n\n```\nfrictionVsSlipGraph[0][0] = 0.0\nfrictionVsSlipGraph[0][1] = 1.0\nfrictionVsSlipGraph[1][0] = 0.5\nfrictionVsSlipGraph[1][1] = 1.0\nfrictionVsSlipGraph[2][0] = 1.0\nfrictionVsSlipGraph[2][1] = 1.0\n```\n\ngiving this array as a result:\n\n```cpp\nfrictionVsSlipGraph[] = { { 0.0, 1.0 }, { 0.5, 1.0 }, { 1.0, 1.0 } };\n```\n\n- *: Array[3][2]*\n- *: { { 0.0, 1.0 }, { 0.5, 1.0 }, { 1.0, 1.0 } }*\n\n```cpp\nfrictionVsSlipGraph[] = { { 0.0, 0.4 }, { 0.5, 1.0 }, { 0.75, 0.60 } };\n```"},{"heading":"CarX specifics","level":3,"markdown":"- Anti-roll bars is the system in a vehicle that should prevent it to do a barrel-roll during sharper turns. Using ARB enables us to make the center of mass realistically high and cause cars to roll down the steep slopes if placed sideways to the slope. It works the same way as the real ones - system computes the difference of applied weight to wheels in pair and tries to compensate difference by applying opposite forces.\n- **antiRollbarForceCoef** is a coefficient of applied force, could be taken as the strength of the system. Setting this value to zero disables ARB (and all next values), which is good for civilian vehicles, higher values reduce not only the risk of rolling but effects of suspension.\n- **antiRollbarForceLimit** is the highest strength of ARB applied to the vehicle. We may want to roll the car at certain situations (full van taking a sharp handbrake turn at high speed), tunning without diag mode is almost impossible because we are not able to imagine forces needed (values are rather low, 2 should be high enough for most of the vehicles)\n- **antiRollbarSpeedMin** and **antiRollbarSpeedMax** are limits of applied force coefficient. The coefficient is 0 at speeds lower than antiRollbarSpeedMin, interpolates to antiRollbarForceCoef at antiRollbarSpeedMax and is set to antiRollbarForceCoef for any higher speeds. This allows cars to drive on steep slopes using their radial speed, falling off the hill once they stop and rolling over at too high speeds (where coefficient doesn't grow and force is limited by the limit)."},{"heading":"brakeIdleSpeed","level":5,"markdown":"**brakeIdleSpeed** is speed in **m/s** under which the brakes are automatically applied to the vehicle.\nThis speed should be reasonably low, higher value would mean strange breaking of slow cars, too low value would cause inability to stop the car.\n\n- *: float*\n- *: > 0*\n\n```cpp\nbrakeIdleSpeed = 0.2;\n```"},{"heading":"antiRollbarForceCoef","level":5,"markdown":"**antiRollbarForceCoef** is a coefficient of applied force, could be taken as strength of the system.\nSetting this value to zero disables ARB (and all next values), which is good for civilian vehicles.\nHigher values reduce not only the risk of rolling but effects of suspension."},{"heading":"antiRollbarForceLimit","level":5,"markdown":"**antiRollbarForceLimit** is the highest strength of ARB applied to vehicle.\nWe may want to roll the car at certain situations (full van taking a sharp handbrake turn at high speed), tuning without diag mode is almost impossible because we are not able to imagine forces needed (values are rather low, 2 should be high enough for most of the vehicles)"},{"heading":"antiRollbarSpeedMin","level":5,"markdown":""},{"heading":"antiRollbarSpeedMax","level":5,"markdown":"**antiRollbarSpeedMin** and **antiRollbarSpeedMax** are limits of applied force coefficient.\nCoefficient is 0 at speeds lower than **antiRollbarSpeedMin**, interpolates to antiRollbarForceCoef at antiRollbarSpeedMax and is set to antiRollbarForceCoef for any higher speeds.\nThis allows cars to drive on steep slopes using their radial speed, falling off the hill once they stop and rolling over at too high speeds (where coefficient doesn't grow and force is limited by the limit)."},{"heading":"terrainCoef","level":5,"markdown":"Sets the importance of surfaceFriction on limiting the vehicle maximum speed on various surfaces. The bigger the value to slower the vehicle will be able to go over rough surfaces.\n\n- *: float*\n- *: >= 0*\n- *: 1.0*\n\n```cpp\nterrainCoef = 2.0;\n```"},{"heading":"turnCoef","level":5,"markdown":"Defines the maximum steering angle of a car.\n\n- *: float*\n- *: >= 0*\n- *: 2.0*\n\n```cpp\nturnCoef = 3.0;\n```"},{"heading":"TankX specifics","level":3,"markdown":"Main differences from CarX:\n\n- More wheels to be set up\n- Few additional params used\n- Less complicated Center of Mass tweaking\n- Vehicle config parameter: **tankTurnForce**\n- Importance of wheel config parameters: **MOI**, **dampingRate**, **dampingRateInAir**\n- `boneName = \"\"` in Wheel classes needs to be the damper bone in model.cfg (instead of the visual wheel bone for CarX)"},{"heading":"tankTurnForce","level":5,"markdown":"Initial force applied to turning in [0, tankTurnForceAngMinSpd] angular speed range to help the tank overcome friction when turning.\n\n- *: float*\n- *: (required)*\n\n```cpp\ntankTurnForce = 0.66e6; // start from 11x vehicle mass in kg and tweak until fine\n```"},{"heading":"tankTurnForceAngMinSpd","level":5,"markdown":"Angular speed (in **rad/s**) where tankTurnForce starts fading to 0 @ tankTurnForceAngSpd\n\n- *: float*\n- *: >= 0*\n- *: 0.0*\n\n```cpp\ntankTurnForceAngMinSpd = 3.0;\n```"},{"heading":"tankTurnForceAngSpd","level":5,"markdown":"An angular speed (in **rad/s**) where tankTurnForce becomes 0\n\n- *: float*\n- *: >= 0*\n- *: 4.0*\n\n```cpp\ntankTurnForceAngSpd = 3.0;\n```"},{"heading":"ShipX specifics","level":3,"markdown":"*TODO - see Arma 3: Ships Config Guidelines*"},{"heading":"See also","level":3,"markdown":"- Arma 3: Cars Config Guidelines\n- Arma 3: Tanks Config Guidelines\n- Arma 3: Ships Config Guidelines\n- CfgVehicles Config Reference"}],"categories":["ArmA: Armed Assault: Modelling","Arma 3: Vehicle Configuration"],"groups":["Tools and File Formats"]}