CHAPTER 11 – PHYSICS, VEHICLE DATA AND CONFIGURATION FILES

At this point the AC graphics engine knows how to communicate with our visual 3D model, but we still need to define all the nice technical data around our
vehicle that the physics engine will use for the simulation.

The files inside the data folder of any car (or the packed/encrypted data.acd file) are responsible for every behaviour, from physics to animated graphic
elements; it’s important to understand that each one has a very specific function here. However the subject will be treated as a whole, since all these
configuration documents influence the entire driving experience (the so-called “feel”) of your vehicle in a different way.

The data examples and explanations of Par. 6.3.3 are dedicated to vanilla AC, but there also explanations about modded CSP features (extended physics).

If you want to work with vanilla data/physics properly, I would recommend to disable Custom Shaders Patch.

Be aware that you may encounter bugs or crashes of any kind after disabling the mod, especially with assets that require its features to work, cars or tracks.

To disable it completely, delete or move in another folder the dwrite.dll file the patch puts in the AC root folder during the install process. It is the hook for
the patch's files, and the extension folder is its companion resource directory where it actually stores all the default settings along with the modified shaders.
Another way you can deactivate CSP, if you have CM, is by unticking the Active checkbox in the settings dedicated to CSP (Fig. 11.0).

Fig. 11.0 - How to disable CSP in CM. Keep in mind that AC may crash with specific mods that aren’t supported on vanilla (CSP only).

Keep in mind that many CSP features can be added without altering vanilla data, via a config override in the extension folder of your mod, but in some cases
lines of code have to be added in the original AC vehicle files, which therefore must be as correct as possible in advance.

Pro tip: You could complete the vanilla part of the physics/data first, and later “build on it” with CSP, but the mod actually fixes some bugs that are present in AC, so you should
use it from the beginning if you want a more bug-free experience and minimize the need of backtracking errors.
Here is a list of the fixes:
- Fix for anti-effects suspension geometries (anti-squat, …)
- Fix of the mass bug for STRUT suspension types
- Fix for progressive rates of suspensions (springs and bumpstops)
- Fix for
Be aware that the mod itself is under development, so other non-bug-fixing features may be buggy. It is a compromise, so there are diminishing returns the more you use it.

Unlike all other features focused on compatibility with original AC, all physics extensions require specifically modified car data: this way, none of existing
cars behave any differently. Cars utilizing new features (extended physics) won’t work in AC without the patch.

303
11.1 – PHYSICS PREREQUISITES
This paragraph (very loosely defined as such) will show you many concepts that will be taken for granted in the continuation of this book. It may be an occasion
to revise for those who already know them.
Just to summarize, below are the topics that will come into play when going deep into vehicle physics. They are considered prerequisites when taking this
subject as a university course.
• From Mathematics courses: trigonometry; limits, derivation and integration of functions; Taylor series and Maclaurin series of common functions; linear differential equations
with constant coefficients; partial derivatives; derivation of implicit functions; matrices and vectors, linear systems; reference systems; eigenvalues and eigenvectors; rotation
matrices; parametric equations of curves; conics and quadrics.
• From Physics courses: kinematics and dynamics of the material point. Energy and momentum. Relative motions. Centres of gravity and moments of inertia. Kinematics and
dynamics of the rigid body in plane motion. Cardinal equations. Lagrange equations. Basic elements of fluid mechanics.
In the next pages we will take a look at the theory of vehicle physics, with practical applications (where possible). If you are not well versed in all this, I advise
you to study further; if you take things too quickly here you won’t comprehend anything. Some theoretic concepts may require not only the knowledge of
mathematic operations like derivatives and integrals, but also basic physics principles, like vectors and fields, to be fully understood, but don’t worry too much
about them (at least for now). If you’re a physics nerd, like me, you will have fun either way.
Along the line you may find also reflections and insights of the engineer’s or the scientist’s thought process (e.g., how we solve problems). This will be the
sum-up of various years of study and passion of mine into few lines.
Obviously my explanations won’t replace a good textbook, and may lack the necessary depth, but I hope they will stimulate you enough to become curious.

11.1.1 – PHYSICS IS MODELS

Let’s admit it. We’re lazy, very lazy, and we have a hard time when it comes to understanding the world around us. But we created many tools with our mind.
One of them is math. The quantification of a property allows us to write down (in our computers store) variables and treat them with common rules, for example
addition or subtraction, multiplication or division. Many operations can be done with numbers, and we invented some of the latter to solve specific situations.
Take for example imaginary numbers, they come in handy when you operate a square root on a negative number, that for the math level of a middle-school
student is impossible to solve:
2
√−4 = �(−1) ∙ 4 = √4 ∙ √−1 = 2√−1 = 2𝑖𝑖
The 𝑖𝑖 is our friendly imaginary number. Often called imaginary unit, 𝑖𝑖 is equal to √−1 , and 𝑖𝑖 2 = −1. Seems absurd, right? Squared numbers are always
25 25 625
positive (e.g. 52 = 5 ∙ 5 = 25, or (−12,5)2 = (−25/2)2 = �− 2 � ∙ �− 2 � = 4 = 156,25). But that’s exactly what this symbol is for.

Now, math and physics do not explain the world, they just try to do it, with various tricks such as the one we just mentioned, fruits of our creativity. This means
that there is a lot going on behind the scene. Allow me to elaborate further.
When we have a system composed of many parts, each one with an almost infinite number of features (imagine how many things we still don’t know of the
universe!), we do not consider an object “as is”, in the sense that we do not include all the characteristics that determine its existence. That would be painful
and philosophically contorted, while we need to be pragmatic.
The objective is to represent any type of body (even things that aren’t really bodies) with the lowest effort possible, in order to focus on the properties we’re
interested into. Based on our experience, nature is quite reliable and lets us divide problems into various parts.
The question then is: how can we create a mathematical model of a complex natural phenomenon and simplify it as much as needed, without losing any piece
of the puzzle (ergo, without being inaccurate)?
Engineers (but also physicists and any kind of scientists) can proceed this way: you try to understand completely the experimental evidence, and you formulate
some of the following hypothesis:
• Some effects cancel each other: an example is the weight of a pen on your table and the constraint reaction force of the table which “pushes” it upwards: this depends on
Newton’s Third Law of physics, where every action (force) causes a reaction of equal intensity (later, magnitude) and opposite direction. This is called EQUILIBRIUM.
• Some effects have so little (negligible) impact on the general behaviour that they can be ignored. A lot of trouble is caused by this part, involving mostly guessing and
tolerances. Yes, engineers do still guess many things. And sometimes become mad scientists. Try delving into metallurgy & steel alloys and tell me how much empiric stuff
is there. Very often (read: always) companies have their own recipes, literally handed between professionals.
• Assumptions can be made.

To apply these principles, we can consider the Brownian motion: it is the random movement of a particle (most of the time atoms and molecules) suspended
in a medium (a liquid or a gas). Fig. clarifies the problem, which tries to give an explanation to a chaotic system.

304
Fig. – Sample drawings of the Brownian motion. This path is given by the interactions (collisions, but more correctly repulsions, since they don’t touch) between atomic elements.

This motion is very complex and it happens every day in our life at a micrometric [μm] scale, in the air we breathe, in the water we drink, in our blood, in the
fuel mixture of internal combustion engines. Its laws can be applied to other contexts too, mainly statistic. But race car engineers and our simulator, both
working with aerodynamics, couldn’t care less about it. The movement of one molecule has almost no impact on the downforce generated by the rear spoiler
of our prototype. What we care about is the total behaviour, the movement of the fluid volume net of intermolecular forces, not what the singular molecules
do. That detailed part is reserved to chemists, physicists and probably very specialized surface aerodynamics engineers.
We use the Gas laws based on experimental evidence to do all the calculations then. These rules simplify with few parameters the properties of a fluid and
significantly reduce the number of operations we need.
The same happens with tires. WIP

11.1.2 - MODELS ARE “SIMPLE”: REFERENCE SYSTEMS, VECTORS, COORDINATES

For our purposes, physics steal concepts from geometry and algebra, since in our reality everything happens into a space. The three disciplines are actually
made from and for each other.

So as our first instance we have the need to specify where our object is and where it is going, if it’s moving. Thus, we’re going to explain the following
definition:

“Coordinate systems Ki are introduced as orthonormal systems, where the coordinate axes xi; yi; zi are defined as being perpendicular to each other. Unit or base vectors
exi; eyi; ezi, having a length of 1, belong to their respective axis”. (Schramm et al., 2014)

Let’s imagine three grids, like tiled floors, that cover various directions, perpendicular to each other, the latter we call axes x, y, z (Fig. left). These grids are
indefinitely long and intersect each other at a place that we call origin O.

Fig. – It’s just like the corner of your room.

We can assume that the side of each tile is one unit long; they can be metres, miles, centimetres or anything you want. If we forget about the unit, we can
associate a pure number to every line of the grid (Fig. right). We call this number coordinate.

This is what we call reference system of our 3D space. Every calculation, either done by hand or by the computer, depends on it. To represent it with math
symbols, we could write S = (x, y, z), but a more appropriate notation is 𝑲𝑲1 = �𝑂𝑂1 ; 𝑒𝑒𝑥𝑥1 ; 𝑒𝑒𝑦𝑦1 ; 𝑒𝑒𝑧𝑧1 �, where O1 is the aforementioned origin. The number
1 appears because it is the first system we considered. This will become useful later, as Assetto Corsa uses many of them, at least two.

305
If we want to highlight a point in space, we can do it with a dot, and call it “A”; that is not enough if we want to actually define our position. We must use the
coordinates like a ruler, and write down the numbers we get. In Fig. left below our point in space is defined like this: A (4,5; 3; 2,5)

Fig. -

Because A is moving, let’s just draw a straight arrow pointed towards the destination, long enough to cover the entire distance. The tip will be at a “B” point,
���� you just drew a vector, that shall be indicated with the symbol 𝑣𝑣⃗ (Fig. right).
defined as B (3,5; 1,5; 1,5). There you have it; within the segment 𝐴𝐴𝐴𝐴

In this example, since the direction is negative (towards left), it is the result of the following sum: 𝑣𝑣⃗ = 𝑣𝑣 𝑣𝑣𝑎𝑎 If the origin of 𝑣𝑣⃗ was on B and the tip on
����⃗𝑏𝑏 − ����⃗.
A, we would have had 𝑣𝑣⃗ = ����⃗ 𝑣𝑣𝑏𝑏 This highlights the importance of sign (+/-) and direction of vectors (Fig.).
𝑣𝑣𝑎𝑎 − ����⃗.

The beginning and the end of a vector must be distinguishable then, and its arrow cannot be missing in the drawing (meanwhile the arrow in the symbol 𝑣𝑣⃗
is often omitted in textbooks and such, so we’ll use the following notation: 𝑣𝑣). In our case, we can measure the length with this formula:

|𝑣𝑣⃗| = �(𝑥𝑥𝐴𝐴 − 𝑥𝑥𝐵𝐵 )2 + (𝑦𝑦𝐴𝐴 − 𝑦𝑦𝐵𝐵 )2 + (𝑧𝑧𝐴𝐴 − 𝑧𝑧𝐵𝐵 )2 (hjgkhk)

Where |𝑣𝑣⃗| is called modulus or norm 42 of the vector, its absolute length, and 𝑥𝑥𝑖𝑖 , 𝑦𝑦𝑖𝑖 , 𝑧𝑧𝑖𝑖 are the coordinates of the points in the 3D space. We obtain a
length of 2,062 units.

At this point you also probably understood what the base vectors are for: they determine the “size” of your tile. In Fig. is a more serious drawing of our
orthonormal coordinate system.

Fig. -

Elementary algorithms for vectors

The introduction of the term vector is illustrative, as the vector itself always has a geometrical or physical meaning. The following elementary algorithms are
applicable:

• Sum and product:

𝑎𝑎 + 𝑏𝑏 = 𝑏𝑏 + 𝑎𝑎 commutative law,
𝑎𝑎 + (𝑏𝑏 + 𝑐𝑐) = (𝑎𝑎 + 𝑏𝑏) + 𝑐𝑐 associative law,
𝑎𝑎 ∙ (𝑏𝑏 + 𝑐𝑐) = 𝑎𝑎 ∙ 𝑏𝑏 + 𝑎𝑎 ∙ 𝑐𝑐 distributive law.

42
Euclidean norm.

306
• Scalar product:
𝑎𝑎 ∙ 𝑏𝑏 = |𝑎𝑎||𝑏𝑏| cos 𝜃𝜃
𝑎𝑎 ∙ 𝑏𝑏 = 𝑏𝑏 ∙ 𝑎𝑎 commutative law.
• Vector product or cross product
• Scalar triple product
• Vector triple product
• Vector quadruple product (LAGRANGE’s identity)

As you can see, vectors can be summed and subtracted (𝑢𝑢 �⃗ + 𝑣𝑣⃗ = �𝑢𝑢𝑥𝑥 + 𝑣𝑣𝑥𝑥 , 𝑢𝑢𝑦𝑦 + 𝑣𝑣𝑦𝑦 , 𝑢𝑢𝑧𝑧 + 𝑣𝑣𝑧𝑧 �); they can also be multiplied by numbers (𝛽𝛽 ∙ 𝑣𝑣⃗ =
𝛽𝛽𝑣𝑣⃗ = (𝛽𝛽𝑣𝑣𝑥𝑥 , 𝛽𝛽𝑣𝑣𝑦𝑦 , 𝛽𝛽𝑣𝑣𝑧𝑧 )) or with each other 43, and you can determine their angle.

In any computer-graphics engine, included Assetto Corsa’s one, calculations such as these are processed multiple times per second for each point, that can
be a geometrical vertex (meshes, empties) or a physical location (centres of gravity, suspension linkages and joints), to define the position of every entity
with coordinates. Geometry data is merged, compared or overlapped with physical data; this happens at high rates, especially in a simulator.

Everything works on a scale of million and billion times per second, with tons of vectors, and to optimize this huge work programmers usually adopt a matrix
system (array), that can be stored, loaded and manipulated quickly at the machine-code level, unlike the formulas we commonly use and see in the physics
literature. A matrix is a group of numbers (elements) that are arranged in rows and columns. In general, an m × n matrix is a rectangular array of mn
elements arranged in m rows and n columns. If m = n the matrix is called a square matrix. The basic and complex mathematical operations are adapted to
this scheme, that is managed via normal coding languages such as C, C++ and C# which are then compiled and translated into functional assembly code
that can be directly read by the CPU of our computer.

Going back on topic with one of the most important concepts, the origin O of the 3D grid is our reference point, where you, the one who is observing a
body, are. It can also be considered as the vector whose length is zero, with the symbol �0⃗ = (0, 0, 0), or a generic vector multiplied by zero (0 ∙ 𝑣𝑣⃗ = 0 �⃗).
The previously mentioned reference system is based on your point of view of the phenomenon, while it’s happening. If you don’t have one, you can’t tell
who is who and where it is going, thus your vector is meaningless.
Is the sun moving in the sky or is it the Earth rotating on its axis? No-flat-earthers zone. Is the train travelling or the landscape flowing? It depends on the
perspective of the observer.
The origin doesn’t necessarily have to be where he is located, but for now I won’t overcomplicate it (you’d need to understand the basics of Galilean
relativity).

The number of axes can be assimilated to the dimension of the space considered; written more appropriately, with two axes (x, y) a two-dimensional plane
is obtained, often called Cartesian plane; with just one (x) you obtain a mono-dimensional space, basically a line.

With four or more you get a n-dimensional space (if it can still be considered a space), and as n goes to infinity:

S 𝑛𝑛 = {(𝑎𝑎1 , 𝑎𝑎2 , 𝑎𝑎3 , … , 𝑎𝑎𝑛𝑛 ) | 𝑎𝑎1 , 𝑎𝑎2 , 𝑎𝑎3 , … , 𝑎𝑎𝑛𝑛 ∈ 𝐑𝐑}

Where Sn is the vector space, ai is the vector coordinate, and R is the field of real numbers that includes whole numbers (3), rational numbers (-16/7)
13
and irrational numbers ( √17, π, e, etc.).

Usually in physics a four-dimensional space has time as the fourth variable, even though it’s not mandatory: S 4 = {(𝑥𝑥, 𝑦𝑦, 𝑧𝑧, 𝒕𝒕)}. This is called space-time.

With vectors you can represent almost anything. There are few exceptions, but those are not really our business. Since the vector is just a segment, its
length, called magnitude, can really be whatever you want, from the force on a suspension to the gravitational field in the proximity of a planet.

Let’s see then what a vector can portray that is of our interest:

• Position: coordinates, displacement

• Velocity: linear, angular (rotational)
• Acceleration: linear, gravitational, centrifugal, centripetal
• Force: weight, elastic, friction
• Momentum: inertia, angular

WIP

43
There are two types of multiplication between vectors, one of them involving trigonometric functions such as sin(θ) and cos(θ), where θ is the angle generated by the directions.

307
11.1.3 - VEHICLE DEFINITION
Before embarking into the development of mathematical models, it is perhaps advisable to discuss a little what ultimately is (or should be) a driveable road
vehicle.
Since a road is essentially a long, fairly narrow strip, a vehicle must be an object with a clear heading direction, which as we already saw can be portrayed by
a vector. For instance, a shopping cart is not a vehicle, since it can go in any direction. Another common feature of road vehicles is that the driver is carried
on board, thus undergoing the same dynamics (which, again, is not the case of a shopping cart).
Moreover, roads have curves. Therefore, a vehicle must have the capability to be driven in a fairly precise way. This basically amounts to controlling
simultaneously the yaw rate, that is the angular velocity changing the direction of motion of the vehicle, and the magnitude and direction of the vehicle speed.
To fulfill this task a car driver can act (at least) on the brake and accelerator pedals and on the steering wheel. And here it is where vehicle dynamics comes
into play, since the outcome of the driver actions strongly depends on the vehicle dynamic features and state.
An example of proper turning of a road vehicle is something like in Fig. (left).

Fig. – (left) In blue, a vehicle’s expected (ideal) behavior when negotiating a curve. (right) In yellow, acceptable (real) behaviors for a road vehicle.

Small deviations from this target behavior, like those shown in Fig. right, may be tolerated. They are pretty much the understeer and oversteer conditions
you can find explained at pag. of this book (PART 1: AC User Manual). On the other hand, Fig. shows two unacceptable ways to negotiate a bend.

Fig. – Unacceptable behaviors for a road vehicle.

All road vehicles have wheels, in almost all cases equipped with pneumatic tires. Indeed, also wheels have a clear heading direction. This is why the main
way to steer a vehicle is by turning some (or all) of its wheels 44.
To have good directional capability, the wheels in a vehicle are arranged such that their heading directions almost “agree”, that is they do not conflict too
much with each other. However, tires do work pretty well under small slip angles and, as will be shown, some amount of “disagreement” is not only
tolerated, but may even be beneficial.
Wheel hubs are connected to the chassis (vehicle body) by means of suspensions. The number of possible different suspensions is virtually endless.
However, as we will see when discussing Assetto Corsa’s vehicle configuration files (pag.), suspension systems can be broadly classified into two main
subgroups: dependent and independent. In a dependent suspension the two wheels of the same axle are rigidly connected together. In an independent
suspension they are not, and each wheel is connected to the chassis by a linkage with “mainly” one degree of freedom. Indeed, the linkage has some
compliance which, if properly tuned, can enhance the vehicle behavior.

44
Roughly speaking, the wheels’ location does not matter to the driver. But it matters to engineers.

308
11.1.4 – INTRODUCTION TO VEHICLE DYNAMICS
A land vehicle has three main aspects that will be the subject of our studies:
• LONGITUDINAL dynamics;
• LATERAL dynamics;
• VERTICAL dynamics;
Longitudinal dynamics deals with the laws under which the vehicle moves according to a rectilinear trajectory, making uniform, accelerated or decelerated
motions. The basic aspects related to longitudinal dynamics concern:
- Powertrain sizing;
- Sizing of the braking system and distribution of braking forces to the axles;
- Selection of transmission gear ratios;
Lateral dynamics studies the laws by which a vehicle moves along a curved trajectory (usually by setting a law of motion). The curved trajectory, the object of
study, can be set by the steering system (steering), or by an external perturbation. Depending on which way the curvilinear trajectory is set, different objects
of study are identified:
- the oversteering or understeering behavior of the vehicle if the curve is set by means of the guidance system, as is the case in the study of a motor vehicle;
- the ride stability at high speeds and the vehicle's cornering attitude, if the lateral dynamics is due to an external perturbation. This field of investigation
generally arises in the study of the lateral dynamics of a railway vehicle.
Vertical dynamics studies the vibratory motions by which the vehicle reacts in the presence of road irregularities. This study is related to both comfort and
ride safety issues, in relation to the phenomena of wheel detachment or rollover.

Finally, one should talk about all aspects related to the control of driving dynamics. Increasing the performance of a motor vehicle today is closely connected
with the use of appropriate control systems, both on the road (ABS, traction control, ESP, active suspension & steering systems, etc.) and on railways (anti-
skid, active suspension, etc.).

The forces that are exchanged in the motion of the vehicle are of various kinds:
• forces at the wheels;
• aerodynamic forces;
• driving forces generated by the powertrain;
• braking forces due to the action of the brakes.
The latter two types of forces are properly internal forces in the system, but because they generate work, they must be taken into account when evaluating
vehicle dynamics.

309
11.1.4 - VEHICLE BASIC SCHEME
We’re back to models. A mathematical model of a vehicle should be simple, yet significant. Of course, there is not a unique solution. Perhaps, the main point
is to state clearly the assumptions behind each simplification, thus making clear under which conditions the model can reliably predict the behavior of a real
vehicle.
There are assumptions concerning the operating conditions and assumptions regarding the physical model of the vehicle. Concerning the operating
conditions, several options can be envisaged:
• Performance: the vehicle goes straight on a flat road, possibly braking or accelerating (nonconstant forward speed);
• Handling: the vehicle makes turns on a flat road, usually with an almost constant forward speed;
• Ride: the vehicle goes straight on a bumpy road, with constant forward speed.

Obviously, real conditions are a mixture of all of them.

A significant, yet simple, physical model of a car may have the following features:
1. the vehicle body is a single rigid body; we can find exactly the latter in Assetto Corsa thanks to the ODE solver’s basic features (pag.)(inertia+CG>>>>car.ini).
2. each wheel hub is connected to the vehicle body by a one-degree-of-freedom linkage (independent suspension);
3. the steering angle of each (front) wheel is mainly determined by the angular position δv of the steering wheel, as controlled by the driver;
4. the mass of the wheels and axles (unsprung mass) is very small if compared to the mass of the vehicle body (sprung mass);
5. the wheels have pneumatic tires (remember AC’s empirical tire brush model);
6. there are springs and dampers (and, maybe, inerters, see bumpstops in suspensions.ini) between the vehicle body and the suspensions, and, likely, between the two
suspensions of the same axle (anti-roll bar). Front to rear interconnected suspensions are possible, but very unusual (not present in AC?);
7. there may be aerodynamic devices, like wings, that may significantly affect the downforce. These are ultimately present in AC.
The first two assumptions ultimately disregard the elastic compliances (here deformations) of the chassis and of the suspension linkages, respectively, while
the third assumption leaves room for vehicle models with compliant steering systems. This description corresponds to what is portrayed by our simulator
(ACC does have chassis flex instead).
A vehicle basic scheme is shown in Fig., which also serves the purpose of defining some fundamental geometrical parameters:
1. the vehicle longitudinal axis x, and hence the vehicle heading direction i;
2. the height h from the road plane of the center of gravity G of the whole vehicle (often called CGH);
3. the longitudinal distances a1 and a2 of G from the front and rear axles, respectively;
4. the lateral position b of G from the longitudinal axis x;
5. the wheelbase l = a1 + a2;
6. the front and rear tracks t1 and t2 (suspensions.ini);
7. the geometry of the linkages of the front and rear suspensions;
8. the position of the steering axis for each wheel.

Fig. - Vehicle basic scheme and body-fixed reference system. Here b≈0 so it is not indicated.

310
All these distances are positive, except possibly b, which is usually very small (since the vehicle is for the most part symmetrical) and hence typically set
equal to zero, like in Fig.

It is useful to define the body-fixed reference system S = (x, y, z; G), with unit vectors 45 (i, j, k). It has origin in the center of mass G and axes fixed
relative to the vehicle. The horizontal x-axis marks the forward direction, while the y-axis indicates the lateral direction. The z-axis is vertical, that is
perpendicular to the road, with positive direction upward.

To be more precise, in Assetto Corsa for any car there are actually two reference systems:
1. One, 𝐊𝐊1 , is for vehicle dynamics (inertia, masses, aero, tires), and follows the common (x, y, z) convention. O1 is located at G (vehicle centre of gravity).
2. The other, 𝐊𝐊 2𝑖𝑖 , is for per-wheel vehicle component positioning (i.e., suspensions) and is Z-forward Y-up, while the x-axis direction depends on the corner considered.
O2𝑖𝑖 can be attached to the WHEEL_# dummy (pag.) or to the center of the axle, depending on the suspension type chosen.
The symbol 𝑖𝑖 stands for the wheel numbering convention in AC: 0 is wheel LF, 1 is wheel RF, 2 is wheel LR and 3 is wheel RR (Fig.).

O21
x21

x20
O20
O23

x23

x22

O22

Fig. – Visual representation of the system 𝐊𝐊 2𝑖𝑖 . (add the other y-z axes)

Very early in the physics creation process it becomes pretty obvious that in order to work correctly with the 𝐊𝐊1 reference system, the CG must be located
properly. This implies getting right the weight distribution and CG height first. It shall become a first order priority. You will have to take a look the configuration
files explained at par. , specifically car.ini and suspensions.ini for that, where more details will be given in this regard.
𝐊𝐊 2𝑖𝑖 has a peculiarity: when working on suspensions linkages, any changes to the geometry happen on both sides of the car. For example, altering the
coordinate along x20 of a joint will modify the respective coordinate along x21 of the same quantity 46. So while you don’t have to worry about making twice
the work, you are not allowed to obtain special configurations where right corners are different than the left corners (aside from what you can achieve with
setups).
It must be remarked that whenever, during the vehicle motion, there are suspension deflections, several of these geometrical parameters may undergo small
changes. Therefore, it is common practice to take their reference value under the so-called static conditions, which means with the vehicle moving straight
on a flat road at constant speed, or, equivalently if there are no wings, when the vehicle is motionless on a horizontal plane. That’s what is called the design
height of the suspension.
Accordingly, the study of the performance and handling of vehicles is greatly simplified under the hypothesis of small suspension deflections, much like
assuming very stiff springs (which is often the case for race cars). Yet, suspensions cannot be completely disregarded, at least not in vehicles with four or
more wheels. This aspect will be thoroughly discussed.
The vehicle shown in Fig. has a swing arm rear suspension and a double wishbone front suspension. Perhaps, about the worst and one of the best kind of
independent suspensions. They were selected to help explaining some concepts, and should not be considered as an example of a good vehicle design.

(wip) 11.1.5 - VEHICLE MODEL FOR HANDLING AND PERFORMANCE

45
Unit vectors are
46
Keep in mind that with respect to 𝐊𝐊1 , these are opposite directions. Galilean relativity is implied here.

311
11.2 - THE ASSETTO CORSA PHYSICS ENGINE
Due to AC’s modular nature, the physics engine can be attached and detached from the graphics, so it could be (relatively) easily replaced by the devs if
necessary, given the fact that they possess the source code.
We do not have this privilege, but can reverse engineer the 64-bit architecture acs.exe in the main install folder and discover what is officially called the
“Kunos Simulazioni Physics Engine” (Fig.), and divide it in two parts, due to their recognizability: a base physics solver and several additional physics
formulas. Let’s explain both for a while.

Fig. – Directly from the code in execution. Apparently Kunos doesn’t have much fantasy with their internal names. You can also see some lines for the CPU multithreading.

11.2.1 - THE PHYSICS SOLVER

First of all, what is a physics solver?
It is what truly powers the simulation. It usually consists of a platform that does all the calculation work, generating the container 2D/3D environment (the
world), creating all the objects (entities) of the virtual space, their kinematic parameters and their properties, the latter of which we can subdivide in two
categories, defined by physical quantities:
• Intensive, such as velocity, mass density (ρ), specific volume (v), energy density, specific internal energy (u), pressure (p), temperature (T), hardness;
• Extensive, where we find size, mass (m), volume (V), internal energy (U), spring stiffness (k), heat capacity (Cp), entropy (S), enthalpy (H) and more.
An intensive property does not depend on the size nor the amount of material in the system. It is not necessarily homogeneously distributed in space and
can vary from place to place in a body of matter and radiation. By contrast, an extensive property is a physical quantity whose value is proportional to the
size of the system it describes, or to the quantity of matter in it. For example, the mass of a body is an extensive quantity as it depends on the amount of
substance the object is made of.
These properties are widely used in real-world applications.
The fundamental quantities in kinematics are the position, speed, acceleration and time, which is very often used as independent variable, as a function of
which the other quantities are expressed.
A very simplified and visual idea of a physics solver would be the default scene of a game editor (e.g. Unreal Engine, Unity, etc.), where you have the
freedom to create objects and specify how they should behave (Fig.).

Fig. – An empty level with a simple box in Unreal Engine 4.

The physics solver of Assetto Corsa is ODE (Open Dynamics Engine, Fig.), which is “a free, high performance, industrial quality library for simulating
articulated rigid body dynamics” (R. L. Smith, 2001). It is integrated with a C++ API.

312
 Fig. – The official ODE logo.

This physics engine was written by Russell L. Smith in C/C++. Its two main components are a rigid body dynamics simulation engine and a collision
detection engine. It is free software licensed both under the BSD license and the LGPL. The official website is www.ode.org.

The project was started in 2001 and has already been used in many applications and games, such as Assetto Corsa, BloodRayne 2, Call of Juarez,
S.T.A.L.K.E.R., Titan Quest, World of Goo, X-Moto and OpenSimulator.

By default this solver defines a rigid body’s position, orientation, mass, forces 47, adding joints, constraints and the aforementioned collision system.

ODE is good for simulating articulated rigid body structures. An articulated structure is created when rigid bodies of various shapes are connected
together with joints of various kinds. Examples are ground vehicles (where the wheels are connected to the chassis), legged creatures (where the legs
are connected to the body), or stacks of objects.

The engine is designed to be used in interactive or real-time simulation. It is particularly good for simulating moving objects in changeable virtual
reality environments. This is because it is fast, robust and stable, and the user has complete freedom to change the structure of the system even while
the simulation is running. It uses a highly stable integrator, so that the simulation errors should not grow out of control. The physical meaning of this is
that the simulated system should not "explode" for no reason. Speed and stability are emphasized over physical accuracy.

ODE has hard contacts. This means that a special non-penetration constraint is used whenever two bodies collide. The alternative, used in many
other simulators, is to use virtual springs to represent contacts, which is difficult to do right and extremely error-prone. (R. L. Smith, 2006)

It is also not tied to any particular graphics package although it includes a basic one called drawstuff. It supports several geometries: box, sphere, capsule
(cylinder capped with hemispheres), triangle mesh (which AC uses for car colliders and physical roads), cylinder and heightmap.

A typical ODE simulation, from beginning to end, will proceed like this:

1. Create a dynamics world.

2. Create bodies in the dynamics world.
3. Set the state (position etc) of all bodies.
4. Create joints in the dynamics world.
5. Attach the joints to the bodies.
6. Set the parameters of all joints.
7. Create a collision world and collision geometry objects, as necessary.
8. Create a joint group to hold the contact joints.
9. Loop:
1. Apply forces to the bodies as necessary.
2. Adjust the joint parameters as necessary.
3. Call collision detection.
4. Create a contact joint for every collision point, and put it in the contact joint group.
5. Take a simulation step.
6. Remove all joints in the contact joint group.
10. Destroy the dynamics and collision worlds.

11.2.2 - THE PHYSICS FORMULAS

The formulas are really the nucleus of Kunos’s work. Using the ODE solver as a physics platform, several systems can be implemented. We do not entirely
know all the equations, but many times the developers explained them, and said that a lot come almost directly from vehicle dynamics theory. Thus, it is
possible to understand which calculations are being done.

For example, collision detections for tires can be approached in 2 ways.

1. Brute force triangle-triangle approach. Here you get every single triangle from object1 and test for a collision with every single triangle in object2. Of course there are
ways to simplify this test but it's easy to see the drawbacks. For a wheel for example, using a 3D object will require a very highly tassellated (many triangles) shape to
approach the smootness of a wheel. More triangles=more calculations=slower.
2. Basic shape approach. Where you assume that your object is tightly inscribed into a geometrical shape such as, sphere, cylinder, box and so on. A car's tire for example
could be represented with a very good approximation by a cylinder. So rather then testing every triangle agains every triangle you can test the "logical" cylinder against
every triangle in the track. Triangle to "shape" collision function are a big research argouments and it's not difficult to find code on the internet to show how to do it. That's
why I suggested to look for a "torus to triangle" routine.
In netKar Pro Kunos used a raycast plus a torque around the tire "Z" (forward) axis proportional to the camber angle. Pacejika suggests this in his book
giving some parameters. Of course the torque around the Z is also proportional the the tire width.

47
Forces are mass times acceleration (F=ma), following Newton’s second law of motion, and they determine the existence of torques.

313
11.2.3 - PHYSICS RATE
In a computational environment time is relative. To tell time computers use clocks (come on?), and the clocks use a quartz crystal oscillator that creates a
stable, periodic electromagnetic signal or vibration. But many types of oscillators exist, and computers are special ones, because they do not only tell the
time, they do many other things in the meanwhile. This means a machine’s “perception” of time is in intervals, called ticks, not in a continuum like us
humans. As a consequence, all the calculations happen “from time to time”, in short repetitive bursts with huge amounts of data. Everything is designed to
be very fast, and in a simulation, quick enough to complete everything before any frame is drawn on screen.

If you played vintage games from the early years (1980s-1990s), you will know that the framerate and physics of many titles depended on the speed of the
core processor unit (CPU). These are called CPU-speed sensitive games. Few examples are Alien Legacy (1994), Unreal (1998) and Grand Prix Legends
(1998). Thus, your game could run too fast and start glitching if your machine was more powerful than what the software was designed for. Many
videogames were becoming unplayable as technology evolved at an exponential rate, and software developers weren’t prepared. It was a true compatibility
issue.

To solve the problem, often back then machines had a software or hardware switch, the famous turbo button, to slow down the CPU clock (Fig.). The logic
was counter-intuitive but it worked. There are cases where the speed was increased instead, but they are quite unusual.

Fig. – You even had the CPU frequency display back then. It was almost mandatory at the time. Notice that they’re Megahertz (106), not Gigahertz (109)!

This problem luckily was solved; nowadays each game has its own calculation frequencies, not directly linked to the CPU speed, and works identically 48 on
every machine that is powerful enough to run it.

So Assetto Corsa has its own rates too. Its physics work at a whopping 333Hz (=3ms). That is the clock frequency (tick) of the engine 49.

Very stiff F1 cars have ride frequencies that can't simulate smoothly at that frequency, so professional simulators usually obtain measurable changes by
bumping the physics frequency up to twice as much (>600Hz / ~1.5ms, and even more, up to 800Hz / 1.25ms), but that requires a lot more
performance from the CPU. Double the update rate and you've doubled CPU time dedicated to physics, and this quickly becomes expensive. For 99.9% of
cars this is not a concern, and increasing the frequency wouldn’t be worth and noticeable for normal users, so a 3ms rate is fine. Also, with lower rates,
physics are more likely to miss something that would cause a problem.

If you’re interested, you can calculate how much track length the physics skip between every tick with the following kinematic equation (units in square
brackets):

𝑑𝑑𝑑𝑑 [𝑚𝑚] = 𝑣𝑣[𝑚𝑚/𝑠𝑠] ∙ 𝑑𝑑𝑑𝑑[𝑠𝑠] [1.0]

48
Almost identically. Even music CDs are not flawlessly reproduced on different machines. Error corrections and sampling rates exist for these very reasons. See the Nyquist frequency.
49
It shall be mentioned that this is not the FFB (Force Feedback) frequency, which is different.

314
A ms is a millisecond, so 3ms = 0.003 seconds; input this number in [1.0] as dt.

To convert the speed from [km/h] to [m/s] (metres per second) you can use the formula below, then input the result into [1.0]:
𝑣𝑣[𝑘𝑘𝑘𝑘/ℎ]
𝑣𝑣[𝑚𝑚/𝑠𝑠] = [1.1]
3.6

So, for example, if your car is travelling on a straight at 50 km/h, the physics are active every ~0.042m, so every 4.2 centimetres of track. This length
will increase the faster you’re driving and this can have an impact for example when taking a curb at different speeds: the physics ticks won’t cover the entire
bump, but only specific points, in our example every 4.2cm. You can calculate what this number will become going faster. Another example is in Fig. 6.1.

Fig. 6.1 - A visual representation of the physics’ clock while driving. Physics are active during each tick, corresponding to a point on the track, depending on the car speed. (. instead ,)

We can make a little comparison between the physics rate in AC vs other known sims/games:

1998 Grand Prix Legends - 144 Hz

2000 F1 2000 - 50 Hz [from Blackhole Motorsports article]
2001 F1 2001 - 200 Hz [from Blackhole Motorsports article]
2002-'08 Live for Speed - 100 Hz (collision detection) / 2000 Hz (vehicle dynamics) [posted by Scawen on lfsforum]
2005 rFactor - 400 Hz
2005 Forza Motorsport - 180 Hz
2006 Test Drive Unlimited - 100 Hz (collision detection) / 1000 Hz (vehicle dynamics)
2006 NetKar Pro - 333 Hz [posted by Kunos on RSC]
2007 Forza Motorsport 2 - 360 Hz [from wikipedia article]
2008 rFactor Pro - 800 Hz [from official website]
2008 iRacing - 360 Hz [from AutoSimSport]
2009 Forza Motorsport 3 - 360 Hz [from gamespot article]
2012 rFactor 2 - 400 Hz [posted on forum.studio-397.com]
2014 Assetto Corsa - 333 Hz [posted by Kunos on assettocorsa.net]
2015 Automobilista - 720 Hz [from game-automobilista.com]
2015 BeamNG - 2000 Hz [from beamng.gmbh]
2017 Project CARS 2 - 600 Hz [posted by Ian Bell on forum.projectcarsgame.com]
2018 iRacing - 360 Hz / 720 Hz for force calculation [from article on iRacing.com]
2018 Assetto Corsa Competizione - 400Hz [posted by Kunos on assettocorsa.it]

A higher or a lower phy clock doesn’t mean that the physics are directly better or worse in a proportional way, as they are handled by a complex mathematical
model in the first place, and that has a lot more influence in making the difference, especially between sims and games. The tick has a minor impact (at least
for normal/average people), but understanding how it works is important.

Actually, the tick becomes relevant whenever you play in online multiplayer. The number of the server’s ping is the time interval between any call and response
between the server and the client of the session. A ping of 60ms for example is far slower than the physics rate, and programmers have to consider these
aspects when designing their software. That’s the reason why online sessions are often full of glitches. The server and the clients must be synced to operate
correctly.
315
For the development of Assetto Corsa, Stefano Casillo used two computer clients in his studio at Vallelunga, ad a server in Singapore which gave him around
200ms of latency, which is realistic for testing.
(if possible going deeper into Assetto Corsa’s infamous multiplayer glitches).
AC always runs physics at 3ms per tick no matter what FPS you get, to make sure it behaves the same for any player, it only slows down graphics related to
the CPU usage if you have a low framerate; it is valid in offline sessions too. You will notice this if your system has got poor hardware specs. I encountered
it quite often back in the day. You’ll find yourself driving in a seemingly slow-motion state, even if the car is speeding at more than 100 km/h, as reported by
the HUD and the various tachometers. The speed of the graphics will stutter, increase or decrease depending on how heavy is the scene rendered. There is
no way a vehicle can be driven safely in said state. You can particularly notice the effect if you switch the camera to look backwards, where the car is hidden.
You’ll have an immediate FPS boost. The optimizations brought by the CSP mod mitigated a lot the problem, which is encountered more often in vanilla.
Obviously in replays physics are not calculated.

11.2.4 – RESOURCE UTILIZATION

100% occupancy generally happens on the main core of the CPU, which has to run the non-multithreaded parts of AC, so FMOD (the sound engine),
DirectX, etc. If you have a multicore CPU, this doesn't put much of a load on it because it can move around which core is calculating things, but it depends
on single thread performance.
As a general principle, multithreading can only work effectively on things that don't depend on each other. For example if you're simulating 2 cars in
different parts of the racetrack, neither has to know where the other car is to calculate tire temperatures, G forces, etc. So large numbers of AI just spread
across a multicore CPU. On the other hand, collisions need to be completely synchronized so every other calculation waits while it figures out which cars are
running into each other.
You can alter the number of CPU threads dedicated to physics and how they’re managed in the assetto_corsa.ini config, under the
%root%\assettocorsa\system\cfg folder. You can change these parameters:
[THREADING]
USE_TIMER_PROCESS=0 ; -1= Automatic, no timer process for CPU with more than 2 cores, timer process for dual cores. 0=Always off. 1=Always on.
SET_THREAD_AFFINITY_MASK=0 ; 0= Windows scheduler will decide where to run the threads. 1= Main thread assigned to Core0, physics thread to Core1

[PHYSICS_THREADING]
THREADS=-1 ; -1 = automatic, 0 = disabled, 1...n = number of threads dedicated to physics

It’s worth noting that some CSP settings deal with multithreading.

11.2.5 – LOW-SPEED PHYSICS (LSPHYS)

There is no speed sensitivity in AC's physics besides the low-speed physics, a different set of physics which kick in automatically when you go slower than
3 Km/h.
It’s normal that the LSPHYS are a bit wonky. Getting things accurate when going super slow is another story. When you become really slow, a lot of physics
calculations become super stretched and unstable, when standing still you even have things divided by zero.
Vanilla basically stops the simulation for tires at speeds under 3 Km/h to avoid the 'jitters' that used to happen in earlier versions when sitting in the pits.
This won’t affect the suspensions.
There is some kind of “dampening” of the cars under the aforementioned speed, in order to and avoid errors.
You can find the parameter that manages the LSPHYS in the assetto_corsa.ini script, and it consists of the following lines:
[LOW_SPEED_FF] ; Low speed Force Feedback (LSPHYS)
SPEED_KMH=3 ; LSPHYS activate at speeds lower than this value [km/h]
MIN_VALUE=0.01 ; The FF multiplier for 0kmh.

The game will crash if you take off low speed physics.

11.2.6 – ENGINE STALL & CLUTCH

There is no engine stall simulation in vanilla AC, therefore when you come to a stop an artificial hold is applied, like an “auto handbrake”, and the engine
RPM drops to zero, but it won't stall.
This has nothing to do with low-speed physics.
In order to start the car moving again, you just push the throttle, there is no need to put it into neutral in order to avoid the engine stall because there is
none, the engine RPM just cuts off until you hit the throttle again. Driving out purely on idle is impossible, but as long as you give it any throttle (even
0.001%), the lock, bound to pedal input and not to torque, will be gone and idle will pull the car away. So there is no problem launching without any
wheelspin. You can't launch a car with just clutch even with 500NM at idle.

This "movement lock" is a simple solution to more complex problem. You see, some tracks have start grids and pit lanes on inclines, so during races you'd
need to make sure everybody uses handbrakes, then you’d have to create more rules governing movement before start (how much can you roll from your
spot before semaphore lights go out etc). AI would need more code for that too.
Also because the game has to run on LSPHYS below 3km/h, you'd have to make sure these physics are better, with correct static rolling resistance (would
have to be a new variables made for all cars).
And after all the work, it would have to be automated anyways (so like what we have it right now, with the auto brake) for people with gamepads or mouse
steering. Then people on public servers (or even in career) would complain about crashing the car before starting the race, and automatic mode would be
made default and after some time everybody would forget that it can be disabled.
A bit sad but it just wasn't worth the hassle for AC devs.

316
What about CSP 64 bit physics? WIP

11.2.7 - FAQ: CAR DATA AND PHYSICS

QUESTION [1]: Where can I find the X_data_file that I need? There isn't the data folder in the mod’s folder, there's only an encrypted data.acd file instead.
ANSWER [1]: There are two methods to obtain the data files, both of them involve the decryption (unpacking) of the data.acd archive. Be aware that you
should not unpack files of official vehicles made by Kunos. Yes, you can do it, but only to fill knowledge gaps that tutorials or guides won't fill, because
editing copyrighted content is illegal (and if you do it, at least don’t publish it online). That’s part of the reason why this manual of mine exists, so that you
can learn everything you need without committing any crime. Even with mods, remember to treat others' data with respect. Educating yourself is one thing,
but don't abuse it. Someone worked hard to fill up that ACD originally. Not to mention that it may contain very sensitive data. Having a critical spirit and a
modicum of wisdom can make all the difference.

METHOD 1:

1. You can use Content Manager to unpack (decrypt) the data.acd of a specific car.

• Look for these tabs in Content Manager: Content > Cars, then select the car whose data you want to retrieve, then click on the Unpack data button (Fig. 4.1);
• If you can’t find the Unpack data feature, you need to enable Developer mode in CM to activate it: click repeatedly (spam-click) on the version number in the About tab.
Check Fig. 4.2 below.
• This method may not work with cars where the data.acd file has been encrypted with unofficial methods brought by CSP. More about it at par.

2. Look into data folder of the car and you will find the specific data file you want to edit;

3. Open it with Notepad++ or one of the other recommended text editors (pag.) and modify it.

Fig. 4.1 – All the steps you need to follow in order to unpack car data with CM. After you press the Unpack data button, a File Explorer will open with the newly created data folder.

317
Fig. 4.2 – How to enable and disable CM’s Developer mode.

METHOD 2:

1. Use the QuickBMS tool (currently 0.11 release) to unpack (decrypt) the data.acd of a specific car. It doesn’t require CM and CSP, as it is a small
standalone software.

Fig. 4.3 – The QuickBMS tool. The file selection window (File explorer) will open automatically.

The program is available in the extras of this manual, with its extraction and rebuilding scripts (assetto_corsa_acd.bms and assetto_corsa_acd_rebuilder.bms), required
specifically for AC, as this utility can be used to decrypt files from many other games. You can also download it from here: https://aluigi.altervista.org/quickbms.htm (QuickBMS)
and https://zenhax.com/viewtopic.php?t=90 (the specific .acd encryption scripts).

The usage is simple: after extracting the tool’s package in any folder you like,

• Double-click on quickbms.exe;
• Select the script for the type of archive you want to extract/decrypt, in our case assetto_corsa_acd.bms;
• Select the input archive or multiple files, so at this point you will select the data.acd in the mod’s folder.
• Select the output folder where the files will be extracted. This time you will have to create the data folder from File Explorer.
• Watch the progress status of the extraction and the final message.
• If everything went smoothly, you finished.
• If it doesn’t work, try opening the program as Administrator (right click on quickbms.exe > Run as Administrator). Otherwise stick to method 1.

2. Look into data folder of the car and you will find the data file you want to edit;

3. Open it with a text editor and modify it.

With QuickBMS you can also rebuild the data.acd file from a data folder using the assetto_corsa_acd_rebuilder.bms script, following basically the same
steps mentioned above.

If both methods explained here don’t work, most probably the data.acd file has been unofficially encrypted with CSP. See par.

QUESTION [2]: I’m working with the configs in the data folder but nothing changes on the car, even if I made a Lada into a Ferrari with two turbo engines.
ANSWER [2]: Vanilla AC gives the priority to the data.acd file, if present. Move it into another path outside your FIN mod folder, or backup & delete it.
Otherwise, if you use Content Manager, make sure in the Drive tab you have Use unpacked data if exists ticked on. Vadim says thanks.

QUESTION [3]: I want to swap/clone physics files between two cars, is it ok to do such a thing? Or it will break my mods?
ANSWER [3]: It will usually not work well (models not aligned with wheels anymore, dashboard non-functional, potentially crashing the game) so best is to
figure out which files in particular you want and carefully swap those, only one file at a time, testing after each file replacement that the car still loads and
works properly.

You may still need to open some configs and edit a few parameters in the code (for example car.ini is half referred to physics and half to the 3D model,
tyres.ini needs the physical tire radius to match that of the visual wheel, etc.).

Be aware that many lines refer to meshes and/or empties inside the car models, so very often the swap won't work, unless you check also for those.

I get that there are many video tutorials on the topic, but they are made by and dedicated to people who make do, people who make a living from "doing"
and have no time to waste, people who want to get a job done no matter how rough, even rightly so, you can't have perfection. When you see someone
working with physics on Content Manager, it will not be a clean piece of work. But the car will definitely get you from Dover to Calais in a day.

Cloning physics is not an easy thing at all, it's not a direct copy-paste process. Especially with F1 cars, that have a lot more functions and consequently
more lines, more file references (especially .luts, look-up-tables), so generally more things that can go wrong.

In addition, you’re giving to a car the physics from a different vehicle; as a consequence the result will not correspond to reality at all.

Not to mention that putting too much trust into other authors is wrong; you don’t know if anything you’re copying was made with care and good effort. On
the same page, try to ask for permission and give credit as much as possible to the original authors of the physics “donor” car, especially if you intend to
republish it.
318
We can highlight some other issues you may encounter when swapping physics:
Cars with third-party encryption
The data.acd file cannot be unpacked on cars where it has been encrypted with unofficial methods brought by the CSP mod and its derivatives, along with other systems.
Thus you cannot swap the physics, as the single physics files cannot be edited, and swapping the entire .acd file is not feasible, unless the car 3D model is exactly the same
(which is not 99.9% of the times).
Floating or sinking wheels
The car has the wheels that sink in the asphalt or that aren’t touching ground (Fig. ).

Fig. – Top left: RADIUS is too small. Top right: RADIUS is too big. Bottom image: the correct size. Look at the scripts (pag.) to understand what this parameter does.

tyres.ini is the right place to fix this, changing the RADIUS value: you have to make sure the radius of the physical tire matches the radius of the actual 3D model; if the car
has animated suspensions modifying this may override the maximum up/down travel limits though.
Various session crashes due to missing objects
This problem depends on the fact that empties and meshes in the 3D model of the physics donor car are not present in the receiving mod. The scripts that are prone to give
errors of this kind are: analog_instruments.ini, digital_instruments.ini.
Various session crashes due to missing textures
Usually this is due to missing flame textures, under the FIN\texture\flames folder. Missing digital displays tex under the same path may cause issues too.

Vehicle cameras not properly set

If you copy car.ini and cameras.ini from a Formula car and paste them to a stock/road car, the points of view will be located very low above ground. Vice versa the same will
happen but this time the POVs will be too high. There’s a ton of mods out there, especially old and low effort conversions, that suffer from this problem.

Floating car
The car is flying on every track (Fig.). The tire size is correct in the physics files.

319
Fig. – The car stuck mid-air.

Check colliders.ini. The position of the collision boxes may be set too low with respect to the car.
About tires taken from other vehicles
If you clone the tires, I would suggest that weight is a larger factor than just dimensions: for example if you pick tires built for a heavier car and stick them to
a more lightweight vehicle, the grip will be super high, as the tire won’t be operating at the loads designed (with the load sensitivity the coefficient will
reduce with load, so if your peak loads are lower than the car you borrowed the tires from, then it won't really be appropriate without some modification).

QUESTION [4]: What happens with online multiplayer racing if I edit my vehicles? Will they still work there? What is the checksum?
ANSWER [4]: You can edit car 3d models and still use it online, only data.acd should be checksummed, unless the server admin is crazy and put the kn5
files on the server to be checksummed too. If instead you modify the car data, the checksum will fail. There’s a workaround though, that lets you edit the car
data for single player without losing the compatibility of the original files with online vanilla servers. It is the data override you can do with the CSP config
scripts.

The server manager can turn off checksum, while the clients cannot, that's the whole point. For example, if the server doesn’t have track checksums, should
you increase the grips in surfaces.ini and cheat? Well, what’s the point of doing it? I didn’t say anything…

ABOUT CSP: Extended physics are not generated in any way online. It works for single player only. If u want to drive with ExtPhys online, u have to upload
the (in single player mode) created data.acd files to the server for each car. Then u have to provide a download link for the players to these data.acd files.
Easiest way is to create a MOD, which player can activate via JSGME or CM with one click and after that they can join the server without a checksum error.

320
11.3 - HOW TO CREATE DATA FOR YOUR VEHICLE
As a physics creator of simulation vehicles, your goal is to obtain real-world information about the vehicle, referred to as data, interpret it correctly and input
it into the simulation as parameters, in order to produce the intended input-output behaviour.
A simplified model for creating car physics could be as follows: Look for data > Find good data > Calculate parameters from the data > Input into the .ini files
> Test and verify > Back to the beginning.
The simulation in AC is sufficient enough that accurate parameters are able to produce reasonably accurate behaviours. In the case that numbers cannot be
determined with complete certainty, given the fact that the reproducibility 50 conditions are not met (i.e., you often don’t have a car to test), as is the case when
creating most car physics in the context of an amateur hobbyist, educated guesses must be made. However, the large majority of the car should be created
on the basis of acquiring more accurate information and striving to implement it correctly into the simulation.
Pro tip: Lesson #1 for learning, testing and troubleshooting is to try wild numbers in both directions (positive or negative) to figure out how something works.

Not every car is equally dealt with when it comes to amount and fidelity of the data present. Ideally one should make a car that they own themselves, have
access to and have acquired detailed data for from road testing and K&C (Kinematics and Compliance) testing, dynamometer and wind tunnel testing.
This is not always a reasonable expectation. If one is willing to accept a somewhat lacking simulation accuracy, one can make a car that has less resources
available to aid in the process. Choosing to do that will place higher stress on having a sound fundamental mechanical understanding and a “common sense”
for reasonable values used by real manufacturers. I would suggest the reader picks a relatively popular car that they can find data for, but at the beginning,
you should primarily make something that interests you enough to commit to it. Physics creation is an ever-iterative process so you can always come back to
the car later.

11.3.1 - WHERE AND HOW TO LOOK FOR DATA

Useful resources for gathering data are primarily the manufacturer’s own publications, such as workshop manuals, service and user manuals (Fig.).

Fig. – Service and repair manual for the vintage Fiat 500, along with one of the pages dedicated to the suspensions that shows a drawing of the assembly. This book doesn’t come directly
from the manufacturer of the vehicle; nonetheless it contains details you can rely on. OEM manuals do exist too, don’t worry, but the problem is often getting them. Being in contact with
owner clubs of the specific car helps a lot in this case.

Aftermarket information is also useful, as sometimes the company has measured or acquired data themselves from the standard car and reference it in relation
to their products. Homologation documents are probably the highest quality third-party info you can find (Fig.).

50
The ISO 21748:2017 defines reproducibility conditions as “observation conditions where independent test results are obtained with the same method on identical test items in different facilities
with different operators using different equipment”. They are not met since AC does not model real-world behaviors entirely, and recreating identical scenarios when driving is pretty much impossible
(in replays physics are not calculated, but maybe you can configure a predetermined set of inputs and feed it to virtual controller peripherals; an Arduino electronic board could help).
321
Fig. – (left) Italian homologation form of the Fiat Abarth OTS 1000 Coupé. (right) German homologation form of the Audi 100 Coupé S.

Online forums also occasionally have resourceful users who post their own measurements or findings, so don’t ignore them. Car magazines can be trusted
to some extent, but their reliability is limited.
When you’re surfing the web, always bookmark in your browser important pages and websites, and download/save the most important stuff on your PC, as it
might disappear, you never know. Do NOT rely on it being hosted online. Save videos locally if they contain much relevant data or good footage. If the Save
As option is not available when you right-click on the element in the page, disable Javascript or use the Developer tab to inspect and find the link (activates
on Mozilla Firefox with the F12 key), or use other tools specialized for the website you find yourself in (e.g. YouTube video downloaders).
Squeeze like a lemon every forum that has a search function. Take screenshots of conversations, they will definitely come in handy as reminders. And if it
takes too long or the search blocks itself, like on the Discord social platform can happen, download the entire website/chat. At that point it won’t escape from
your hard drive. It is possible with software like HTTrack, DiscordChatExporter or similar. Then you will be able to use your browser’s search function (which
often is a lot faster), and delete things you don’t need, like dumb posts or wasted trash conversations. It’s a lot more productive. Be hungry for information.
E-books and pdfs are some of the best sources of information available, but don’t focus only on them. A lot of good stuff can be found also in articles, studies
and research publications, especially recent ones.
Some good websites to find info are:
• http://www.kolumbus.fi/leif.snellman/gpw5.htm: Grand Prix race regulations from 1895 to 1949. Very useful for pre-war race cars.
• https://www.nhtsa.gov & https://www.regulations.gov/search?filter=nhtsa: the US National Highway Traffic Safety Administration, which publishes inertia data. Download the crash
test reports. They are really detailed.
• https://historicdb.fia.com: the historic database of the FIA (Federation International de l’Automobile) with homologation rules and info for cars from the 1950s to this day.
• https://www.carfolio.com/car-makes: it won’t be the most complete for the single vehicle, but there are a lot of cars, even quite obscure models.
• https://www.automobile-catalog.com/browse.php#gsc.tab=0: there’s so much info you almost ask yourself where they got it. Since 1945. Bah, seems reliable enough.

Do exercise extreme caution when interpreting data, even if it is manufacturer data. Not all of it is necessarily in the context you assume it to be in, such as
suspension height, tire size, occupants in the vehicle etc. Take care to determine what is the reference point for the information. Look online for EPC (Electronic
Parts Catalogue) websites, or try to find paper parts catalogues, as they can sometimes give hints for parameters such as shared mechanical parts between
different vehicles (e.g., springs, stabilizers, but also tires, engines, etc.) and occasionally have dimensions, stiffnesses and such reported. Do not ignore video
publications and footage by competent drivers either; on the other hand, try not to listen too much to neophytes who have never driven a car on the racetrack.
Driving normally on the highway does not help much when trying to understand how a car truly behaves.
Moreover, there are standard design choices and solutions used especially in road cars for their reliability, but there can be a large variation between how
cars are designed and how they behave, even within the same manufacturer’s vehicle line-up and especially between manufacturers. This applies to every
aspect of the vehicle: while generally similar trends and logics should be followed, outlier data 51 may be present.
For example, with bigger tire flex the lateral force usually peaks at higher slip angles at increased loads but, with the words of Stefano Casillo from Kunos,
“I've seen some test data showing the opposite trend: lower slips at higher load”.

51
This is a term used in statistics to define, in a set of observations, an abnormal and aberrant value, that is a value clearly distant (numerically) from other available observations. While most of
your data will probably follow a linear, a Gaussian or other types of distributions, you may encounter points that do not follow the trend (e.g., points that don’t satisfy Chauvenet’s criterion for a
Gaussian distribution have to be considered outliners).

322
Thus, you will often encounter a bias, which according to the ISO 21748:2017 is the “difference between the expectation of a test result or measurement
result and a true value”. Since we don’t know what is the true value, which as a concept exists only in a theoretical ideal world, we can only estimate. Indeed,
the same regulation tells you that “the accepted reference value is substituted for the true value”.
A physics creator should refrain from making “opinion based” changes to the physics of cars, especially when good data is present and tread with utmost
care when seemingly going against data. However the data should always be thought of to only be to a certain degree of accuracy, and interpretation by the
creator is just as important. That’s where some insight from Kunos developers may help you:

Try to find the actual engineers that worked with the car. Possibly have access to the car, be kind enough, give lots of Italian pasta and wine, and they will let you go in
the car and measure all the parts; talk with them, get lap times, and hopefully you will have something important by the end of that process.
Real professional drivers’ feedback is very important. But equally important is to have the experience to understand what they are saying.
Because every driver wants just one thing, to go faster, if he cannot do that it means the car is terrible for him. For example, we were working with James Glickenhaus’
car. Fantastic car, great guys. Great data from the engineers.
Finally we had the car ready, and Giovanardi, a very famous Italian pilot, was driving the car on the Nürburgring; he comes to us and says he would like to try the car on
the simulator for training and so on. He started driving: no problem. This is something really good. We put real drivers on the simulator. If they can get on it and drive the
car naturally without crashing straight out of the pits, this is a huge deal for us. We want them to feel totally at home in the simulator, as they would in their car.
Lap after lap he goes faster and faster, improving as he would in the real car. That already is a very good sign. But the most important thing is once he comes out of the
car from driving for about a half an hour, so he says, “Yeah, okay, that’s enough”. He gets out from the cockpit.
How was it? “Ehh, not so great. I could have gone faster”. I thought we were in a mess now, really scared. “It doesn’t turn well, and then when I accelerate, boots are on
the mat, and then when I brake, I have to be very careful with the down shifting because otherwise the car won’t be stable.” And while he was speaking and literally bringing
hell onto me, I had his race engineer behind me give me thumbs up.
So I asked the race engineer what the hell he meant by the “thumbs up”? I thought the race driver hated the simulation, I was heartbroken after so much hard work to get
it ready for him.
After the driver leaves, the race engineer says to me that we have done an amazing job. It turns out that the racing driver hates the car just as much in real life, and that
the notes he was giving me were the exact same feedback he gives to his race engineer when he gets out of the real car. (Aristotelis Vasilakos, 2016)

The “top guys” usually have years of experience in simulators or engineering, so they know what is possible and what not, in terms of action, and restraint.
For example, studying in the mechanical field, one can consider to use CAD software to get data that is not available out there. Model the parts or get them
online if someone already did it, and then assign a material from a class of steel or aluminum alloys to determine features like the weight of suspension arms,
rims and similar. With software like Solidworks it can be done very easily (Fig.), if you can untangle yourself between the various alloy types.

Fig. – Working on an CAD model of a historic wheel to get its mass in Solidworks. In 1924, wheelmakers used rolled and stamped steel to make steel disc wheels. These wheels were
heavy but easy to produce and repair. But aluminum wheels are older than you may think - very early sports cars used aluminum wheels. The Bugatti Type 35 bore aluminum rims in
1924. Their lighter weight made the wheels turn faster, and aluminum’s ability to dissipate heat made for better braking.

Physics creation is not a short process; there’s a huge amount to learn. In terms of tips, just absorb as much information as possible.

323
11.3.2 - DATA IMPORT AND ORGANIZATION PROCESS
Don’t throw important references into one big folder. Name your files in an understandable manner. Make a .txt file or two where you can copy data and
forum posts into as a lightweight text format for quick reference. If you do any manual calculations, split them all up into their own files or preferably use a
spreadsheet for automated calculations.
Often you will find specifications with numbers only, but many things will be represented with X-Y coordinates (commonly linear or logarithmic) on a plane,
like the engine torque, the power, the aerodynamics of wings, the load/slip curve of a tire, and other curves (Fig. ).

Fig. – The power and torque curves of a VR6 engine, measured on a dynamometer. This is what you find in a typical dyno sheet. For internal combustion engines the power is

These are all very useful, but when surfing the internet most of the times the ones you see are raster images, not vector ones. So how can you grab the values
from the graphs you find?
WebPlotDigitizer comes in handy here. It is a small software that semi-automatically calculates the coordinates of the curves after you pinpoint some of the
units on the main axes and specify the pixels of the line you want to be considered. It’s easy to use and properly formatted LUTs (Look-up-tables, about them
at par. 6.3.2) can be created, after you set which points of the curve shall be “grabbed”.

Let’s see what you can do with this program:

1. Load the image of the graph you want to grab the values from and specify which type of plot it is (Fig. left).

Fig. – (left) A File Explorer window will open after you click on Load Image (1) > Choose file (2). Select the image you want to process. The 2D (X-Y) plot type (3) is the most common.
(right) The graph I chose is another power curve. The selected dot will always appear with a green colour (5). You can also adjust the zoom level.
2. Locate four known points on the axes of the graph (Fig. right). It doesn’t really matter where they are, but if they’re located on opposite ends the result may be more
accurate. You can use the zoom window to adjust the positions with precision. You can click on the points and move them 1 pixel at a time, using the arrow keys.
3. Enter the respective values of the pinpointed units on the plot (Fig.) so that the program can calculate every value.

324
Fig. – The values come directly from the graph’s axes. A rotation correction can be added if the lines are not perfectly straight, if you have a scan from a printed document (like here).
4. Select the Pen tool and highlight the curve you want to be analysed. In my case I want only one of the three curves, but if you want you can assign each one to a different
data set. The width of the pen and of the eraser can be adjusted. For a fast selection, you can use the Box tool, but points on the grid may be included, depending on their
colours. You’ll have to choose which colour will be considered as data on the plot indeed, and as you can see on the right of Fig. , the software already determined the
dominant colors of the image. In my case I will select the darkest one.

Fig. – The Automatic Extraction (7) will be used with any of the tools (Pen, Erase, Box). It will do most of the work, so there’s no need to use the Manual Extraction unless you have to fix
by hand the result calculated by the software (some coordinates may not be considered, dots can be in the wrong places, etc.). The dx and dy parameters (ΔX & ΔY) are basically the
distances (along the X and Y axes; in pixels) between each calculated dot. Don’t lower them too much (use 10<d<30), as AC doesn’t need a ton of coordinates for LUTs. You can
choose a different algorithm too.
5. You can correct little errors made by the program using the Manual Extraction (Fig.).

Fig. – With the Adjust Point and Delete Point tools any created dot can be relocated or removed easily.
6. Here you have the clean, final result after the corrections (Fig.).

325
Fig. – For curves that are quite linear, like this one, it is possible to increase ΔX and ΔY to reduce the number of points and remove some of them, here in the 2500-4000 RPM range.
7. Then how do we get our numbers? Well, pretty simple: click on View Data and you will find all the values that WebPlotDigitizer calculated (Fig.). You can copy these values
to an Excel sheet for your calculations. If you don’t like the default formatting, which by the way is just not right for the AC *.lut files, it is possible to change the number of
digits; we will use a fixed notation and zero decimal digits after the comma. For this kind of graph, hand drawn on a piece of paper, any decimal quantity will basically fall
within the margin of error, so we don’t need those extra digits.
Every value will be correctly approximated, as you can see. The column separator has to be changed too: use | instead of the semicolon. Then click on Copy to Clipboard
and paste it on a text file, or click on Download .CSV to save it as an MS-Excel sheet. There you have it, a LUT (Look Up Table) ready to be used in AC files! Yay!

Fig. – It wasn’t difficult, right?

8. If you still aren’t sure, clicking on the Graph in Plotly button will let you visually check the curve obtained in a dedicated window (Fig.).

Fig. – This is neat, and as you can see WebPlotDigitizer can be very precise. Still, there is some noise, which you can see at various spots, and that should be corrected manually.

326
This specific LUT, being related to power, can be used to create the torque.lut Assetto Corsa data file; you may be tempted keep it as-is, but you may not know
that the values will have to be converted to torque, so what you see in the last picture is not the end. Take this as a lesson: you have to know if the numbers
you get are correct for the job; often (if not always!) creating data is not a copy-paste process. You want to learn some more about it? Keep reading this manual
then!

11.3.3 – DATA CREATION: HOW TO BEGIN

A good starting point for the vehicle data creation is the car.ini script, followed by suspensions.ini and tyres.ini: determine your total mass, unsprung mass,
wheelbase, track, CGH, inertia and tire radius first. Those will determine the general behaviour of the automobile.

Pro tip: the main tricky thing that you'll have to do before anything else is setting up the location of the vehicle CoG (Center of Gravity). You sort of have to do it in order.
1. Set wheelbase in suspensions.ini.
2. Set front weight percent (weight distribution, CG_LOCATION) in suspensions.ini.
3. Set the Y-offset (BASEY) of axles in suspensions.ini (Y = height in this context, it's the distance above or below CoG for that axle at 'design height' which is wherever you
measured it at).
4. Move the 3D model with the help of the graphics offsets in car.ini to match the wheels.
If for some reason you have to change the numbers, you'll have to carry through the steps again. Lots of positional physics references are relative to the CoG, so you need to
set it first.
Even if you forget about this tip, don’t worry, you will encounter it later on, with more details, where you will need it.

You don’t have to focus on finding very specific information, but if you get the chance, input the right numbers from the beginning. We don’t want to do a lot
of trial-and-error later.

Depending on your resources you will need to conduct testing in different ways. At worst, watch videos of the vehicle driving and measure it against yours,
or ask drivers of the real car what they think. This process however varies in accuracy and rarely results in anything very useful being uncovered. Telemetry
analysis is a lot better; it is not terribly practical for most cars, as most of them do not have real-world telemetry available, but if you start learning about
vehicle dynamics, you can get awesome results interpreting the simulated telemetry and looking at possible errors you made.

Having right car weight and its distribution, aerodynamics, engine power, gear ratio, tire grip factor, and an accurate track model (even without accurate
bump data), you can get pretty good correlation to the real-life data. The suspension geometry doesn't have be 100% perfect, but it has to be very close.

Until you start building experience, just find more data and keep gauging its reliability. You should fill gaps in your understanding with other data. You can
make an educated guess about some parameters based on what you see and hear, but it is always preferable to get some hard numbers. Although the
simulation is very sound and capable of good correlation, beware that some minor aspects are not modelled or might not work as intended or how you
believe they work which will all add up in the end. That’s why you should read this very manual thoroughly, to learn which aspects of real-life does AC
portray.

Ideally you will not know very much about what is right in your car, but more about what is wrong and how. The tires will often ultimately be a bigger source
of error than anything else in your suspensions, drivetrain or aerodynamics. A very good practice is to try getting the intended behaviour out of the same
thing in two different contexts, such as a shared suspension geometry and shared tires mounted on another car with similar, but different parameters.
Manufacturers often re-use suspension layouts and some parts, which will give a good opportunity for cross-correlating parameters.

11.3.4 - THE UNIT SYSTEM IN ASSETTO CORSA

When you use numbers in your calculations, you have to know what they represent, otherwise you add up onions and carrots. That’s why units of
measurement exist.

In general AC uses the metric system (SI) for the physics and the scripts. However, to make things a lot easier, in this guide the units will be specified near
almost all the important parameters. As a matter of fact, the following units are the most common:

[m] (meter), [mm] (millimetre), [Kg] (kilogram), [°C] (Celsius), [L] (litres), [psi] (pressure), [deg] (degrees).

Keep in mind that units like [N] (Newton), [J] (Joule), and other kinematic, mechanical and thermodynamic derived SI units are used too.

Width, height, length will be the standard format used by Assetto Corsa dimensions.

11.4 - DATA FILES AND EXAMPLES (with ANALYSIS)

The following paragraphs contain the lists of all the data files; most of the times you will need less, depending on the specific features that differ from car to
car (for example not all of them have electronic devices, active wings and so on).

Keep in mind that without some of these files the car will not load and the game will crash. The remaining configs are required if you want to avoid
behaviours detrimental to the driving experience (including any kind of related bug).

Please note that if you’re using CSP you might encounter errors and crashes anyway!

327
11.4.1 - CONFIGURATION FILES (.ini) (page numberssss)
1. aero.ini p.
2. ai.ini p.
3. ai_tyres.ini p.
4. ambient_shadows.ini p.
5. analog_instruments.ini p.
6. blurred_objects.ini p.
7. brakes.ini (also ctrl_ebb.ini and steer_brake_controller.ini) p.
8. cameras.ini p.
9. car.ini p.
10. colliders.ini p.
11. ctrl_4ws.ini p.
12. damage.ini p.
13. dash_cam.ini p.
14. digital_instruments.ini p.
15. digital_panels.ini p.
16. driver3d.ini p.
17. drivetrain.ini (also final.rto, ratios.rto, ctrl_single_lock.ini and ctrl_awd_center_lock.ini) p.
18. drs.ini p.
19. electronics.ini p.
20. engine.ini (also ctrl_turbo.ini (ctrl_turbo0.ini, ctr_turbo1.ini, etc.) p.
21. ers.ini (also ctrl_ers.ini, ctrl_ers_front.ini) p.
22. escmode.ini p.
23. extra_animations.ini p.
24. flame_presets.ini p.
25. flames.ini p.
26. fuel_cons.ini p.
27. lights.ini p.
28. lods.ini p.
29. mirrors.ini p.
30. proview_nodes.ini p.
31. setup.ini (also ai_default.ini) p.
32. sounds.ini p.
33. suspensions.ini (also suspension_graphics.ini) p.
34. tyres.ini (also ac_tyres.ini) p.
35. wing_animations.ini p.

CSP files?

328
11.4.2 - OTHER FILES
Here we have important stuff. You better learn to use these files, they’re the ones that bring realism and accuracy to the simulation in AC.

LUTs : LOOK UP TABLES

The .lut files you can find in the vehicle data are Look-Up-Tables, hence the extension: you can open them with one of the suggested text editors.
Each line in the LUT maps an input value to an output value; the file itself doesn't say what either of these values means, but every table can be linked to a
specific config file, if its name is written in specific lines of code. With LUTs the physics of a vehicle can be recreated in the most realistic way possible in
AC, so you may be interested in how they work.
These tables should be specific to a car but are more likely to be generic (for example a LUT can recreate a specific behaviour for a tire, and that tire can be
used on many cars).
Every type of LUT you may need will be fully explained in each one of the correlated scripts, under the paragraphs with the title “ABOUT RELATED FILES”.
For now, as a general rule, keep in mind that empty.lut files contain only 0|0 or 0|1 values and are often used as fillers.

DYNAMIC CONTROLLERS
What are controllers?
Controllers are a cascade (or sequence) of lookup tables that combine either by addition or by multiplication, to produce a desired behaviour.
The system looks for the sequence of [CONTROLLER_#], and as soon as the section is not found the sequence ends. So, if for example you have
[CONTROLLER_0] followed by [CONTROLLER_2], [CONTROLLER_2] is not used at all because when the system does not find [CONTROLLER_1] it exits.

The principle behind controllers is that they emulate what real electronic controllers do. They read car data (for example the wing angle, on cars like the Pagani
Huayra, or the KERS working automatically on the Ferrari LaFerrari), and you can write algorithms to generate output values.
Here we have the list of all the vanilla dynamic controller inputs:
• AVG_TRAVEL_REAR
• BRAKE
• CONST
• GAS
• GEAR
• LATG
• LOAD_SPREAD_LF
• LOAD_SPREAD_RF
• LONG
• OVERSTEER_FACTOR
• REAR_SPEED_RATIO
• RPMS
• SLIPANGLE_FRONT_AVG
• SLIPANGLE_FRONT_MAX
• SLIPANGLE_REAR_AVG
• SLIPANGLE_REAR_MAX
• SLIPRATIO_AVG
• SLIPRATIO_MAX
• SPEED_KMH
• STEER
• STEER_DEG
• SUS_TRAVEL_LR
• SUS_TRAVEL_RR
• WHEEL_STEER_DEG

Meanwhile, Custom Shaders Patch adds the following inputs:

• HEADLIGHTS
• CLUTCH
• HANDBRAKE
• HORN
• GEAR_ALT: unlike original GEAR, this one does not go through neutral when shifting
• LIGHT_EXTRA_A
• LIGHT_EXTRA_B
• LIGHT_EXTRA_C
• LIGHT_EXTRA_D
• LIGHT_EXTRA_E (added in 0.1.76)
• LIGHT_EXTRA_F (added in 0.1.76)
• AXLES_DIFFERENCE_RELATIVE: relative difference in angular speed of axles (averaging wheels angular speed)

329
• AXLES_DIFFERENCE_ABSOLUTE: absolute difference
• AXLES_DIFFERENCE_SIGNED: above zero if front axle spins faster than rear one
• FRONT_AXLE_DIFFERENCE_RELATIVE: relative difference in angular speed of front wheels
• FRONT_AXLE_DIFFERENCE_ABSOLUTE: absolute difference
• FRONT_AXLE_DIFFERENCE_SIGNED: above zero if left wheel is faster
• REAR_AXLE_DIFFERENCE_RELATIVE: same, but for rear axle
• REAR_AXLE_DIFFERENCE_ABSOLUTE
• REAR_AXLE_DIFFERENCE_SIGNED
• DAMAGE_ENGINE: from 0 to 1 (added in 0.1.76)
• DAMAGE_GEARBOX

Some files include controllers inside, for example aero.ini has them for the wings. Standalone controllers instead have to be used in the following files:

ctrl_4ws.ini
ctrl_arb_front.ini
ctrl_arb_rear.ini
ctrl_awd2.ini
ctrl_awd_center_lock.ini
ctrl_ebb.ini
ctrl_ers_#.ini
ctrl_ers_front_#.ini
ctrl_single_lock.ini
ctrl_turbo#.ini
ctrl_wastegate*.ini

Whenever you may need them, it will be specified in the next paragraphs. The only exception to this rule is ctrl_4ws.ini, which will have a dedicated section.

330
11.4.3 – EXPLANATION AND ANALYSIS OF EACH .ini SCRIPT
This section of our manual will be pretty long, as we’ll give examples for each configuration file, along with descriptions of what each function and line of
code does. You can copy the text from this document to make your config files, but I suggest you to use the ones included in the archive of the project
(WIP), or to copy them from another vehicle, as the scripts written in this manual are not formatted for proper use.

1. aero.ini
The following code defines and all wing-type objects, including DRS. Wings determine the downforce and drag levels of your car.
[HEADER]
VERSION=3 ; version=3 has YAW_CL_GAIN values that can stall wings depending on yaw angle.

[WING_0] ; SYNTAX: [WING_ID]. Wing identifier. A car can have as many wings as necessary. ID starting from zero.
NAME=BODY_LIFT ; Name of the wing
CHORD=2.0 ; Length of the wing. [unit: meters]
SPAN=1.0 ; Width of the wing. [meters]

% ▲ Along with CHORD, SPAN helps determine the area of the wing. Single unit is used to simplify calculations. Area is in [square meters] (or rather,
it's CHORD * SPAN).

POSITION=0.2,0.1,0.0 ; Position in x,y,z starting from the CoG.

LUT_AOA_CL=wing_body_AOA_CL.lut ; Coefficient of Lift lookup table
LUT_GH_CL= ; Ground height (GH) aero lift multiplier lookup table

% ▲ If set to empty.lut, gives no lift generated from this wing.

CL_GAIN=1 ; Coefficient of Lift multiplier (for easy fine tuning). [dimensionless]

% ▲ CL_GAIN just multiplies whatever the results of the LUTs are. Same thing for CD_GAIN below. If you want an up-force you can use a negative number
here or in the lut. Positive CL_GAIN = downforce, negative CL_GAIN = up-force (lift) in Assetto Corsa. If you set CL_GAIN to 0, you won’t ever get
downforce.

% To get the overall CL, you multiply CL_GAIN with every involved .lut (AOA * GH if present) of the wing.

LUT_AOA_CD=wing_body_AOA_CD.lut ; Coefficient of Drag lookup table

% ▲ If set to empty.lut, gives no drag generated from this wing.

LUT_GH_CD= ; Ground height (GH) aero drag multiplier lookup table

CD_GAIN=1 ; Coefficient of drag multiplier (for easy fine tuning). [dimensionless]

% ▲ If you set CD_GAIN to 0, you won’t ever get drag. Just moving it 10% up or down (=±0.1) will make a considerable difference. Changing downforce (CL)
doesn’t change drag (CD).

ANGLE=0 ; Default starting wing angle which the car loads in game with. For car setup. [degrees]

% ▲ This is the default value used in the car setup. The actual angle is relative to the design heights of the suspension and the velocity the surface is
travelling at vs the rake angle of the car.

ZONE_FRONT_CL=0.0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_FRONT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_REAR_CL=0.0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_REAR_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_LEFT_CL=0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_LEFT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_RIGHT_CL=0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_RIGHT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)

% ▲ These are coefficients in the formulas for the wing’s CD and CL, and they are related to the damage model. It is a simple way to reduce lift and
increase drag when the car goes through an accident and the aerofoils are damaged. If set to zero they don’t do anything.

YAW_CL_GAIN=-0.0

% ▲ YAW_CL_GAIN doesn't do anything for wings with positive lift on them.

[WING_1]
[WING_2]
[...]

% ▲ A vehicle can have as many wings as necessary.

[FIN_0] ; Vanilla physics have a "fin" wing type that gives sideways lift with yaw (equivalent of AOA).

% ▲ Front and rear fins can yaw at different angles.

NAME=FIN
CHORD=0.8
SPAN=0.4
POSITION=0,0.00,-1.32
LUT_AOA_CL=fin_AOA_CL.lut
LUT_GH_CL=
CL_GAIN=0.5
LUT_AOA_CD=fin_AOA_CD.lut
LUT_GH_CD=
CD_GAIN=0.5 ; For fins CD always comes from where the car is headed, while CL is purely lateral
ANGLE=0 ; The angle of attack is yaw angle (taking into account wind)

% Skipping lines dedicated to damage for the purposes of this book.

YAW_CL_GAIN=0.0

[DYNAMIC_CONTROLLER_0] ; Active aero. Dynamically controls the inclination of a wing, relative to various telemetry factors.
WING=4 ; Wing identifier to activate (wing number on [WING_ID])
COMBINATOR=ADD ; How to behave: COMBINATOR MODE: ADD or MULT
INPUT=BRAKE ; Telemetry channel input. Options: LONG LATG BRAKE0-1 GAS0-1 STEER-1+1 SPEED
LUT=wing_controller_brake.lut ; Input data to wing angle lookup table
FILTER=0.90 ; Movement filter. Controls speed of wing movement from one angle to another.
UP_LIMIT=6 ; Wing angle max limit
DOWN_LIMIT=0 ; Wing angle min limit

[DYNAMIC_CONTROLLER_1]
WING=4
COMBINATOR=MULT
INPUT=SPEED_KMH
LUT=wing_controller_speed.lut
FILTER=0.90
UP_LIMIT=6
DOWN_LIMIT=0

331
LITTLE EXPLANATION
- GH or Ground Height is the distance from the middle of the wing to the ground.
AOA instead is Angle of Attack (α, alpha). It is the pitch angle of the wing relative to its direction of
travel (Fig.), not to be confused with climb angle, which is the angle of pitch relative to the ground.
It can be considered the current angle the wing is moving through the air. The higher α is, the more
lift you will get out of a given wing with two very important caveats.
First, as AOA increases, drag increases, which means fuel efficiency goes down. Second, and more
importantly, there is a max angle at which the wing can generate lift. Angles of Attack greater than
this will cause the wing to “stall”. Note that stall used in the aerodynamic context has nothing to do
with the engines. It refers to the wing. A wing stalls because the air flow over the top portion separates
from the wing surface, causing higher pressure and thus degrading the lift generated by the wing.
- About CD and CL. Lift depends on the density of the air, the square of the velocity, the air's viscosity and compressibility, the surface area over which the
air flows, the shape of the body, and the body's inclination to the flow. In general, the dependence on body shape, inclination, air viscosity, and
compressibility is very complex.
One way to deal with complex dependencies is to characterize the dependence by a single variable. For lift, this variable is called the lift coefficient,
designated CL. This allows us to collect all the effects, simple and complex, into a single equation.
For some simple flow conditions and geometries and low inclinations, aerodynamicists can determine the value of CL mathematically. But, in general, this
parameter is determined experimentally.
Determining the value of the drag coefficient CD is more difficult than determining the lift coefficient because of the multiple sources of drag. The drag
coefficient given above includes form drag, skin friction drag, wave drag, and induced drag components. Drag coefficients are almost always determined
experimentally using a wind tunnel.
In the PHYSICS section there will be a more detailed explanation of the aerodynamic principles for these coefficients, which are dimensionless constants that
work at any speed. You might see "20lb at 100mph" of force in a magazine but any detailed wing analysis uses CL and CD.
- What if you wanted to implement a full aeromap for your vehicle? Sadly in vanilla AC you can’t, but thanks to the Custom Shaders Patch mod you are able
to. See the CSP ADDITIONS section for more details.

- The intended usage of wings is BODY for overall body drag, and FRONT/REAR for separated front/rear lift (centred respectively on front splitter and rear wing).
This allows fine tuning of front-rear aero balance in a manner similar to real cars, as a common way of measuring lift is front/rear axle loads.
- Wings in AC aren't real airfoils, they're just surfaces where aero forces can be applied, so anything about size/shape/angle must be baked into the coefficients
you enter into the lookup tables (LUTs). There's nothing “physical” about them nor do they represent anything “physical”, they’re just a simplified mathematical
model: there isn’t a fluid/airflow simulation in AC, imagine how many calculations/second it would require such a thing. Their NAME (BODY, FRONT, REAR,
SCREEN, DIFFUSER, DRS, etc.) also doesn’t really matter; in addition you can technically name two wings the same (although it is not recommended).

- Every WING has a POSITION. The values are x, y, z in meters from the CoG of the car. Obviously you can calculate this, but the easiest way (at least until
you don't have a very complex aero) is to put your WINGs inside the aero.ini file, go in-game, drive slowly (you need to move the car) and open and check
the WINGS dev app. It shows everything (and aero front % balance) in real time. Of course, everything uses proper physics values and with the help of
wolfram alpha and some Excel work, you can calculate everything before going ingame... honestly though, until you get VERY complex aero situations, the
WINGS dev app is all you need. Works wonders.
- Always locate your wings properly, as their positions set where the forces (lift, drag) apply, relative to the CoG of the car. Examples of correct wing
placement are in Fig.. However, the forces do not actually respond to how the respective wings look like. There are various reasons for this:
• In Assetto Corsa the lift force is always applied directly downwards relative to the car and drag directly against the direction of travel (except for FINs). The angle of the
wing basically influences the resultant of the vector sums of the lift and drag forces.
• Size (CHORD ∙ SPAN) is really for visualization purposes only, as the force can be adjusted to whatever you want. You want to make the area smaller/bigger?
Increase/decrease the force. So really only the center point, specified by the POSITION, really matters. But if it was just 6 single pixel dots on the car it'd be hard to see
the wings. Thus each wing defines how large it is so you can spot which is which. And there is the convenience to make them a 1m by 1m square to simplify calculations.
Each one's POSITION point is where that wing's force on average gets applied to the car. So the body one is at the center of aero pressure for drag, usually. If you're
using CFD they don't necessarily line up with the model's wings because you're going for the same total forces rather than trying to make it match the visual model.
• Moreover, in real life the center of a wing's aerodynamic forces isn't actually the center of the wing (same with a diffuser): it's a bit forward of that (Fig.) and the "wing" in
AC should therefore look offset (unless you design it to account for the different position).

Fig. – (Courtesy NASA Glenn Research Center).

332
Thus, never make the body produce downforce or lift. The way you should simulate the body generating lift is to put in some imaginary wings so to speak at
the positions of the lift. Use the body wing to set up the drag instead.
- FINs in aero.ini apply the side-forces 90 degrees aligned from the wind direction, not the surface. You can make a true side-force with some math and
side-drag application. Putting in a more realistic lateral aerodynamics model has big implications for drifting. It has made it a lot easier and it's kind of funny
how difficult it would be without aero.
As a side note, you should realize how the F1 cars by Kunos don’t have FINs modeled (Fig.), but in the real world the splitters and spoilers are designed to
create lateral forces too. So the aero could have been more accurate, but it isn’t. Once again, the software is capable of doing it, but it wasn’t implemented.
- You can have 20 wings and the weighted average of their positions is where the CoP (Center of Pressure) is. It’s just a Kunos practice to make a body
drag wing + front/rear/diffuser. Actually some of the official cars have more wings, especially F1 cars (Fig.).

Fig.- The wings of the Ferrari F138 by Kunos. As expected, aerodynamics have a huge impact on F1 cars. Do not expect the making of a Formula car mod to be easy.

However you should avoid an excessive number of wings (Fig.). They will be mostly useless, since all the aerodynamic properties of multiple wings can be
“baked” onto a single wing, especially for the car body.

333
Fig. – I knew someone would have thought about doing this. Do not replicate at home. Another bad modding practice. LOOK AT THE WINGS APP!

- If you have a race car, obviously the rear wing and body produce drag, so you have to work with that. But with a streetcar it's only the body. Set the
wing_body_AOA_CD.lut (or whatever you called it for the BODY wing) to 1|1, and then set the CD number for the body to whatever the drag coefficient is.
Everything else for a road car can be on 0, regarding drag.

- Stalling wings at a certain speed is done with the 'active aero' code. It switches from an angle that's preset to stalled behaviour (no lift) to a different angle
that generates lift at a determined car speed mark. You can see the wing move in the aero debug app.

- To get to the actual forces you use the physics equations for drag and lift, which are:
The Drag Equation (link)
The Lift Equation (link)

They’re almost the same equation, so to switch between them you just need to choose the proper coefficient (CD or CL). In the physics literature they are
written like this:
𝐶𝐶𝐶𝐶∙𝐴𝐴∙𝜌𝜌∙𝑣𝑣 2
𝐿𝐿 = (1.0)
2

𝐶𝐶𝐶𝐶∙𝐴𝐴∙𝜌𝜌∙𝑣𝑣 2
𝐷𝐷 = (1.1)
2
% Standard air density (ρ) is 1.225 [kg/m^3]; velocity in m/s will give you force in Newtons [N].

If you have the speed in km/h, you can convert it in m/s with this little formula:
𝑣𝑣 [𝑘𝑘𝑘𝑘/ℎ]
𝑣𝑣 [𝑚𝑚/𝑠𝑠] = (1.2)
3,6

If you have the speed in miles/h, you can convert it in m/s with this other little formula:
𝑣𝑣 [𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚/ℎ]∙1,609344
𝑣𝑣 [𝑚𝑚/𝑠𝑠] = = 𝑣𝑣 [𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚/ℎ] ∙ 0,44704 (1.3)
3,6

So:
A * CL (AREA * Coefficient of lift) in Assetto Corsa is: (CHORD * SPAN) * CL_GAIN * LUT_AOA_CL (#) * LUT_GH_CL (#)
A * CD (AREA * Coefficient of drag) in Assetto Corsa is: (CHORD * SPAN) * CD_GAIN * LUT_AOA_CD (#) * LUT_GH_CD (#)

% ▲ Hashtags (#) indicating a lookup table.

% So drag force at a given velocity is: F = 0.5 * (CHORD * SPAN) * CD_GAIN * LUT_AOA_CD(AOA) * LUT_GH_CD(GH) * air_density * V^2

- Does AC simulate altitude, with different air pressure? Only with Custom Shaders Patch. Without it each track just has a certain fixed air pressure.

- With regards to wings in aero.ini, the controllers are included in the file itself, they’re not separate, unlike some other car features. You can then make
dynamic aero with the [DYNAMIC_CONTROLLER_#] section(s). Keep in mind that the controllers are acting sequentially, one adding the effect to the
previous one. I suggest you put the brake controller as a last one. This way, whatever the wing does during SPEED_KMH or LATG, the BRAKE controller will
add up all the degrees it can whenever the brake pedal is pressed.

- Assetto Corsa features an aero damage model.

- A simple parachute braking system (for example used in drag racing) is possible in AC (Fig.). You can set up some dynamic wings with controllers (tied to
brake pedal input) and animations. The drag force will be there, but the chute won’t respond to the air pressure building up inside, so its movement will be
entirely fictional. But who knows, maybe you can bake a short cloth simulation in the animation with Blender. Still, the sequence cannot be indefinitely long,
so you won’t get anything realistic, just a piece of tissue that extends and retracts itself in the parachute backpack. Can be fun nevertheless.

334
Fig. – (top) Fully deployed parachute, for a drag racing vehicle. (bottom) The opening animation of the chute (the closing one is identical, just reversed) is just a scaling.

ABOUT RELATED FILES

LUTs:
- From the script explained in the previous pages you may have understood that there are two types of aero look-up-tables, one related to the AOA (Angle of
Attack), and one related to GH (ground height).

Thus, the input of an aero LUT can be, depending on the type, either AOA or ground height GH, and the output is a multiplier coefficient, usually CD or CL.
So for each wing to determine its overall drag, you take the area times the ini coefficient times any relevant lut coefficients.

- You can add as many wings you wish, but don't forget to add the corresponding _CD and _CL .lut files for them.

- Here you have some examples of names you can use for your various look-up-tables related to aero:
wing_front_AOA_CL.lut
wing_front_AOA_CD.lut
height_frontwing_CL.lut
height_frontwing_CD.lut
wing_rear_AOA_CL.lut
wing_rear_AOA_CD.lut
wing_diffuser_AOA_CL.lut
height_diffuser_CL.lut
wing_diffuser_AOA_CD.lut
height_diffuser_CD.lut
wing_rearmovable_AOA_CL.lut
wing_rearmovable_AOA_CD.lut
wing_controller_brake.lut
wing_controller_speed.lut

- It is advised to reference empty.lut it in all the empty aero.ini areas.

- Regarding aero.ini, you are not allowed to use inline LUTs (you can’t write the table in the script, unlike for some other config files). But the CSP mod adds
the option to do it.

335
CSP ADDITIONS
- Since Assetto Corsa is quite limited in terms of aero, the mod brings a full aero map implementation, with a 2D lookup table and other features. In the
aero.ini config must be added the following section:
[MAP_0]
NAME = name
MAP_CL_RH = filename.2Dlut ; cl*area versus meters (ride heights at each axle)
MAP_CD_RH = filename.2Dlut ; cd*area versus meters (ride heights at each axle)
MAP_BALANCE_RH = filename.2Dlut ; ratio of front:rear cl*area versus meters (ride heights at each axle)
MAP_YAW_CL = filename.lut ; degrees|multiplier
MAP_YAW_CD = filename.lut ; degrees|multiplier
MAP_YAW_BALANCE = filename.lut ; degrees|addition
MAP_ROLL_CL = filename.lut ; degrees|multiplier
MAP_ROLL_CD = filename.lut ; degrees|multiplier
MAP_ROLL_BALANCE = filename.lut ; degrees|addition
MAP_STEER_CL = filename.lut ; degrees (average at wheels)|multiplier
MAP_STEER_CD = filename.lut ; degrees (average at wheels)|multiplier
MAP_STEER_BALANCE = filename.lut ; degrees (average at wheels)|addition
MAP_SPEED_CL = filename.lut ; kph|multiplier
MAP_SPEED_CD = filename.lut ; kph|multiplier
MAP_SPEED_BALANCE = filename.lut ; kph|addition
FRONT_RH_OFFSET = 0.00 ; meters (static ride height offset; it adds to the ride height input that's sent to the 2D-LUT lookup)
REAR_RH_OFFSET = 0.00 ; same as above
CL_MULT = 1.00
CD_MULT = 1.00
BALANCE_OFFSET = 0.00 ; %/100
INTERPOLATION = LINEAR ; LINEAR, CUBIC
DRAG_OFFSET = 0.00, 0.00 ; meters, meters - left/right, up/down
FRONT_FORCE_DELAY=0.05 ; delay for forces at the front of the car - higher numbers mean less lag
REAR_FORCE_DELAY=0.04 ; delay for forces at the rear of the car - higher numbers mean less lag
DRAG_FORCE_DELAY=0.045 ; delay for drag forces - higher numbers mean less lag

2D LUT example (x-axis is front ride height, y-axis is rear - axis values must ascend as you move right and down):
0.015 0.020 0.025

0.020 1 1 1

0.025 1 1 1

0.030 1 1 1

0.035 1 1 1

0.040 1 1 1

Tab/space-separated for ease of import from spreadsheet software (e.g. MS Excel). It is recommended that you build the table in Excel and copy and paste it
into your 2D LUT file.

There are also a new related tab available in the setup screens, with the option to choose between the different CSP aeromaps you may create within
aero.ini. You can add the following section to setup.ini:
[AEROMAP]
SHOW_CLICKS=0
TAB=AERO
NAME=Aero Configuration ; the setup option's title
LUT=aero_map_setup.lut ; format: display_name|aeromap_index
DEFAULT=0 ; the default index of map (others contained in the LUT will be switched off unless selected in the setup window)
POS_X=0.5
POS_Y=9
HELP=NULL ; vanilla AC options only, for now.

- Added the option to use inline LUTs within the aero.ini script.

- There is a new HEADLIGHTS input for aero controllers. Example:

[DYNAMIC_CONTROLLER_0]
WING=1
COMBINATOR=ADD ; or MULT, same as any other controller
INPUT=HEADLIGHTS
LUT=controller.lut ; 0 is off, 1 is on
FILTER=0.5
UP_LIMIT=90
DOWN_LIMIT=0

CURIOSITIES AND AMENITIES

- Very, very, very old aero.ini files used to have a section called [DATA]:
[HEADER]
VERSION=0.9

[DATA]
REFERENCE_AREA=1.910 ; Frontal area in m^2
CD=0.45 ; Drag coefficient
CL=0.98 ; lift coefficient (positive is downforce, negative is lift)
FRONT_SHARE=0.46 ; percentance of drag on front axis
CDX=1
CDY=1

So if you see this section in any mod (look also at the HEADER), it means that it’s outdated, and the mod itself is way outdated (at least with respect to this
config file).

FAQ
QUESTION [1]: I want to increase downforce on the rear by 25%. How can I do it?
ANSWER [1]: You can just make CL_GAIN=1.25 for the rear wing. Or just calculate 125% of the value already present and just add the difference.

336
Q [2]: Game crashes when I set extended physics (CSP) in my car's aero.ini. I was trying to add a fan element (CSP) and I edited aero.ini like this:
[HEADER]
VERSION=extended-2 ; using extended-2 or extended-1 you can enable extended physics

% ▲ Error: you can set extended physics (CSP) in car.ini only.

[skipping wings and eventual fins]

[FAN_0] ; below are the functions that add physics for a fan to the car (check)
NAME=FAN
MAP_FORCE_RH=FAN_FORCE.2Dlut ; meters (ride heights at each axle) vs. force produced
MAP_BALANCE_RH=FAN_BALANCE.2Dlut ; meters (ride heights at each axle) vs. front balance (%/100)
MAP_SPEED_FORCE=FAN_SPEED_FORCE.lut ; kph|force_multiplier
MAP_SPEED_BALANCE=FAN_SPEED_BALANCE.lut ; kph|balance_offset
FRONT_RH_OFFSET=0.000 ; meters (static ride height offset)
REAR_RH_OFFSET=0.000 ; meters (static ride height offset)
FORCE_MULT=-100.00
BALANCE_OFFSET=0.00 ; %/100
INTERPOLATION=LINEAR ; LINEAR, CUBIC

A [2]: That's because you need to have CSP installed for extended physics, and you activate them with VERSION=extended-1; extended-2 only the in
car.ini HEADER. If you do otherwise, expect crashes.

Q [3]: How can I calculate the front area of the car for a BODY wing in aero.ini when I have very little data?
A [3]: The front area can be determined using and a photograph of the front of the car: overlay the picture with transparent graph paper. Or take measures in
pixels on digital images. If you already made the 3d model things will be way easier and you can even use section planes if you want, but that’s another
story. Here’s an example on how to do it with a photo (especially in case you want to get data for a really old car without schematics). Keep in mind that you
shall separate eventual splitters from the BODY wing (and so from its area). The Caterham below doesn’t have front splitters.

Enclose your car in a grid (Fig. 4.4). Calculate the area of a rectangle which would encompass the front of the vehicle like in Fig. 4.5. In this example we
know from manufacturer data that our car is 1.61m wide and 1.07m high. While working with wings you can estimate some measures if you don’t have
enough specs. Look at the tires for example, if you know their diameter and width you already have a starting point to make some proportions. You can also
try looking at homologation rules for wheels or known visible elements (shock absorbers, suspensions, etc).

Fig. 4.4 – As you can see, a grid has been drawn to Fig. 4.5 – Area of the rectangle that completely covers the Fig. 4.6 - In total there are 600 squares.
enclose the front of this Caterham. You might want to do vehicle ( = length x width). In this case 1.61m x 1.07m ≈
this more precisely, i.e. closer to the car. 1.72m²

Calculate the total no. of squares and the no. of squares not covered by the silhouette (Fig. 4.6). The design of the transparent grid overlay helps. The total
not contained in the silhouette here is 135. This means the race car takes up 465 squares.

By multiplying the proportion of squares covered by the total area, you can find your racing cars actual frontal area, or at least a good approximation:

465/600 = 0.775 –> 77.5%

Typical adjusting values are 80-85% for cars, 70% for motorcycles, and 100% for trucks.
From this you can now calculate your vehicle’s frontal area:

Area = 77.5% * 1.72m² = 1.333m²

Now you can use this area to make a BODY wing and for any aero calculation you want to do with the equations (1.0) and (1.1).

Personally, I think the most time-consuming part of this process is finding a decent image. This is because most images are at an angle to make them look
better! Once you have it though, hopefully you will be able to follow the steps.

Q [4]: Where should I look for the downforce levels of cars?

A [4]: There is this website: http://www.mulsannescorner.com/data.html; it is a good resource, but the prototype/open wheeler downforce levels tend to be
slightly optimistic.

Q [5]: About active aero, is it possible to have a wing that goes from 0 to 20° at 120km/h and then back to 0° when you go lower than 80km/h?
A [5]: Yes, it's possible. Assuming it is wing 1, you can add the following controller for example:
[DYNAMIC_CONTROLLER_0]
WING=1
COMBINATOR=ADD
INPUT=SPEED_KMH
LUT=wing_controller_speed.lut
FILTER=0.90
UP_LIMIT=20

337
DOWN_LIMIT=0

While the respective wing_controller_speed.lut should look like this:

0|0
80|0
120|20

Obviously you'd need to change the wing number to be appropriate for the wings you have.

Q [6]: Can I use a CFD simulation software to calculate the aerodynamics of my car?
A [6]: Yes, you can, but the program must be able to provide useful data. You can try with OpenCFD, it has been used to create the mod of the KRB Audi S1
Silhouette (https://www.racedepartment.com/downloads/krb-audi-s1-silhouette.14447), Fig. .

Fig. – Aero CFD simulation (OpenCFD) for the KRB Audi S1 Silhouette mod by @AccAkut.

338
PHYSICS - AERODYNAMICS
In order to set the various parameters for the aerodynamics of our car, we first need to understand how the physics work in real life. After grasping the basic
concepts of aerodynamic theory, we will be able to ask the right questions when we’ll go in search of the technical data of our car.
Land vehicle aerodynamics concerns the study of the interactions between a vehicle in motion near the ground. As such it uses the conceptual tools of fluid
dynamics, with several specific aspects related to the type of geometries that are used and the velocities involved.

1.0 - Main physical properties of air

Fluid dynamics, and aerodynamics in particular, uses a continuous description of a fluid, which in our case is air. It is a gas whose behaviour is well described
by the perfect gas model. The classic equation of state is
𝑝𝑝𝑝𝑝 = 𝑁𝑁𝑘𝑘𝐵𝐵 𝑇𝑇
Where p is the thermodynamic pressure in Pascal [Pa] (for our purposes just consider atmospheric pressure at ground level ~1atm = 101325 Pa), V is
the volume of gas, T the absolute temperature (measured in Kelvin [K]), N is the number of gas molecules contained in the aforementioned volume and
𝑘𝑘𝐵𝐵 = 1.38 × 10−23 𝐽𝐽/𝐾𝐾 in [Joule/Kelvin] is the Boltzmann constant 52.
Usually the number of molecules is expressed in moles, one mole being an Avogadro number (𝑁𝑁𝐴𝐴 = 6.022 × 1023 ) of particles 53.
This way, introducing the universal gas constant, 𝑅𝑅 = 𝑘𝑘𝐵𝐵 𝑁𝑁𝐴𝐴 = 8.314472 𝐽𝐽𝐽𝐽/𝑚𝑚𝑚𝑚𝑚𝑚, the equation of state is written as
𝑝𝑝𝑝𝑝 = 𝑛𝑛𝑛𝑛𝑛𝑛
Where 𝑛𝑛 = 𝑁𝑁⁄𝑁𝑁𝐴𝐴 is the number of moles.
Air is a mixture of gases composed of different species (i.e., atoms and molecules). We have to account for this. A mole (or molar) fraction is defined as the
ratio of the number of moles of a certain chemical species S normalized to the number of total moles, 𝑋𝑋𝑆𝑆 = 𝑁𝑁𝑆𝑆 /𝑁𝑁. It’s basically the percentage of that
species in the substance 54. The molar mass instead is the ratio between the mass and the amount of substance (measured in moles) of any sample of
compound. You can find the molar masses of single atoms in the periodic table, corresponding to the atomic weight 55 (Fig.).

Fig. – The periodic table. Chemistry is involved in aerodynamics, yes. All subjects are connected. That’s what makes you a better engineer.

You can find that at sea level, dry air (~35°C and without impurities) consists of molecular nitrogen, N2 molar mass 𝑚𝑚𝑁𝑁2 ≅ 2 ∙ 14.006 ≅ 28, present with
the molar fraction 𝑋𝑋𝑁𝑁2 ≅ 0.7808; molecular oxygen O2 with 𝑚𝑚𝑂𝑂2 ≅ 2 ∙ 15.999 ≅ 32, present with 𝑋𝑋𝑂𝑂2 ≅ 0.20947; argon, 𝑚𝑚𝐴𝐴𝐴𝐴 ≅ 39.948 with
𝑋𝑋𝐴𝐴𝐴𝐴 ≅ 0.0934; carbon dioxide CO2, with 𝑚𝑚𝐶𝐶𝐶𝐶2 ≅ 2 ∙ 15.999 + 12.0096 ≅ 44.0076 and 𝑋𝑋𝐶𝐶𝐶𝐶2 ≅ 0.000314, plus traces of other species (0.003%).
Thus, the mass in grams of one mole of air (average molar mass) is the following weighted average:
𝑋𝑋𝑁𝑁2 𝑚𝑚𝑁𝑁2 + 𝑋𝑋𝑂𝑂2 𝑚𝑚𝑂𝑂2 + 𝑋𝑋𝐴𝐴𝐴𝐴 𝑚𝑚𝐴𝐴𝐴𝐴 + 𝑋𝑋𝐶𝐶𝐶𝐶2 𝑚𝑚𝐶𝐶𝐶𝐶2
𝑚𝑚𝑎𝑎 = ≅ 0.7808 ∙ 28 + 0.20947 ∙ 32 + 0.00934 ∙ 39.95 + 0.000314 ∙ 44.0076 ≅ 28.95 𝑔𝑔/𝑚𝑚𝑚𝑚𝑚𝑚
𝑋𝑋𝑁𝑁2 + 𝑋𝑋𝑂𝑂2 + 𝑋𝑋𝐴𝐴𝐴𝐴 + 𝑋𝑋𝐶𝐶𝐶𝐶2

52
Being a constant, you don’t really need to know where it does come from, just take it as granted. If you are curious do a little search on the web.
53 One mole of a certain substance is the quantity of said substance that contains as many elementary entities (atoms, ions, molecules, electrons or other specified entities) as how many atoms are
contained in exactly 12 grams of 126𝐶𝐶 , which is a particular isotope of carbon. Dividing the total mass of one mole of carbon by the mass on one atom, you obtain the number of Avogadro. This is
a convention in chemistry. The mole is one of the fundamental SI measurement units.
54
In fact, if you take a look at the data immediately below, air has around 0.7808=78% of nitrogen, 0.2095=20% of oxygen and 1% of argon.
55
This is due to the fact that compounds from Earth have a typical isotope composition. But we won’t delve any further into the topic.

339
Be aware that usually in chemistry calculations are necessary quite a few decimal numbers, otherwise the results become quite imprecise right away.

The percentage composition of the main constituents (nitrogen, oxygen and rare gases) does not change up to 80-100 km of height in the atmosphere. This
is because there are large-scale turbulences that cause continuous mixing.

The mass of N moles of air is therefore Ma = Nama, so the equation of state can be expressed as

where Ra = R/ma = 287.05J/(KgK) is the air gas constant and the mass is expressed in kg. The equation of state can be rewritten in terms of density 𝜌𝜌 =
𝑀𝑀𝑎𝑎 /𝑉𝑉,

From the equation of state we obtain the density of air. For example at a temperature of 273K (≅0°C) and a pressure of 760mmHg ' 1 atm ' 105 Pa we find
⇢ ' 1.3Kg/m3. Under ambient conditions (temperature of of 273K and atmospheric pressure), the air is far from critical conditions (Tc ' 133K, pc ' 3770
kPa), so it actually behaves like a perfect gas.

2.0 – Reynolds number

The forces created by the airflow around a car depend on several factors: the shape of the car, the relative velocity of the air and the car, and other things
such as protuberances on the car. At low speeds these forces are usually low, but at high speeds they can severely affect the performance of the car.
Stability, tire traction, handling ability are all affected, and of particular importance, fuel economy is also affected. Engine power has to overcome
aerodynamic forces, and this takes fuel.

The overall aerodynamic drag on the car we’re interested in consists of five different types of drag: form, lift, surface friction, interference, and internal flow.
• Form drag depends on the form of the shape of the car: how smoothly air passes over the contour of the body and how it breaks away at the rear.
• Lift drag is the result of pressure differences on the bottom and top of the car that create lift.
• Surface friction drag is a result of the viscosity of the air-in other words, how much friction there is between the various layers of air near the car.
• Interference drag is caused by projections on the car body, and internal drag is caused by air passing through the car.

The amount of drag caused by the various forces varies considerably. Percentage-wise, for an average passenger car we can assume the following drags:
form, 55%, interference, 16%, internal, 12%, surface friction, 10%, lift, 7%.

Streamlines, Airflow over the vehicle and Surface friction drag

A small section of the airflow over a car is referred to as a streamline, and the family of streamlines is called the airflow pattern. This pattern depends on the
car’s shape and its speed through the air. It can be seen in a wind tunnel if an opaque gas such as smoke is used (Fig.).

340
Fig. – Smoke tests for various vehicles, in order from top left to bottom right: wooden 1:5 scale model of Jaguar XJ13, Gumpert Apollo Sport, Ferrari 599 GTB Fiorano, Ferrari 430
Scuderia. Look at how splitters and diffusers push the air up or down. You can see that the smoke becomes turbulent on the rear end of the vehicle.

Streamlines in the vicinity of a car are complex. Over the front they generally follow the contours of the vehicle, but they can split and separate. Of particular
importance is the internal friction, or viscosity, of the air. It was shown in 1744 by Jean LeRond D’Alembert that if the viscosity is zero, no tangential forces
can act on the surface of an object, and no forces would therefore be exchanged between the air and the object: in other words, aerodynamic forces would
not exist. This is known as D’Alembert’s paradox.

Of course, in practice, no fluids have zero viscosity, so aerodynamic forces do exist.

Viscosity creates frictional forces between the layers of air that pass over one another. They give rise to what is called the boundary layer. They layer of air in
contact with the surface of the car tends to stick to it so that it moves along with it. The next layer gets dragged along because of friction, but it is faster as it
isn’t in contact with the wing object, so it moves ahead slightly. The third layer moves even farther ahead, and so on. The gradual “lagging” of the layers
gives rise to a gradient, the boundary layer (Fig.).

Fig. – Due to the surface friction between the airfoil and the layer of air in contact with it, the nearest streamlines are slowed down, to the point that a turbulence is created.

How thick is it? It is usually very thin, like a sheet, and as the speed of the car increases, it gets even thinner. It gets thicker, however, as it approaches the
rear of the car. The frictional force due to the layers of air close to the surface is referred to as surface friction drag, or skin friction drag. It acts in a direction
tangential to the surface.

When the friction between the layers is not high, the layers slide over one another quite easily. In this case we have what is called laminar flow (smooth
flow), which occurs only at relatively low speeds over a car.
The transition from laminar flow to turbulent flow is a huge part of aerodynamics and considerable study has gone into it.

Form Drag
As we saw earlier, form drag depends mainly on the shape of the car. Frictional forces produce pressure differences at right angles to the surface, and if we
add up all these pressures over the area of the car we get the total form drag force on it.

Form drag also depends on the splitting of the streamlines and the wake behind the car. It is important to reduce splitting as much as possible and also to
keep the wake to a minimum. The energy that goes into creating the wake is taken out of the kinetic energy of the vehicle and therefore reduces the car’s
horsepower.

Over the years, designers experimented with various shapes to reduce the turbulence in the rear part of vehicles (Fig.).

341
Fig. - The Special version of Norman-Timbs. Manufactured in the 1940s, the vehicle has an aerodynamic coefficient of less than 0.25.

Fig. - This beauty comes from the house of Ferrari. The 512 S Pininfarina Modulo (year 1970) was all about design and performance.

Bernoulli’s Theorem
One of the most important relations in aerodynamics is referred to as Bernoulli’s theorem. It was formulated in the eighteenth century by Daniel Bernoulli. He
showed that as the velocity of a fluid increases, its pressure decreases. Mathematically, we can state this as
𝜌𝜌𝑣𝑣 2
𝑝𝑝 + 2
= 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 (1.4)

𝜌𝜌𝑣𝑣 2
Where p= air pressure, ρ= density of air (at 101.325 kPa (abs) and 20 °C (68 °F), air has a density of approximately 1.204 kg/m3), v= velocity, and
2
is the dynamic pressure.
We can see from this that as dynamic pressure, which depends on velocity, increases, air pressure must decrease, and vice versa. This increase in pressure
is the reason an airplane wing produces lift. It is designed so that the velocity of air across the top is greater than across the bottom. If the velocity is greater,
the pressure is less. This means the pressure beneath the wing is greater, and this in turn produces the lift which allows the plane to fly. Imagine a car
spoiler as a plane wing, but reversed. It will give us the downforce we need in order to obtain the grip we want on our wheels.

Drag Force and Drag Coefficient

But how do you go about testing the aerodynamics of a car? Everything, it turns out, hinges on a simple number called the coefficient of drag (Cd or Cx). If
you know this number, you know most of what is to be known about the aerodynamics of the car.

Both the drag force on a car and the coefficient of drag, Cd, can easily be calculated. The drag force is given by

𝜌𝜌𝑣𝑣 2 𝐴𝐴𝑓𝑓 𝐶𝐶𝑑𝑑

𝐹𝐹𝑑𝑑 = 2
(1.5)

342
Where 𝐴𝐴𝑓𝑓 is the frontal area of the car.
If we measure the drag force in a wind tunnel, we can use the same formula (1.5) to calculate Cd:

2𝐹𝐹
𝐶𝐶𝑑𝑑 = 𝜌𝜌𝑣𝑣 2 𝐴𝐴𝑑𝑑 (1.6)
𝑓𝑓

The coefficient of drag is based on the drag of a flat square sheet; in the wind it has a Cd of 1.00. It was assumed early on that this was the maximum, but
later it was shown that other shapes actually produced larger Cd’s. Early cars typically had a Cx of 0.7. Over the years it has gradually decreased until some
of the lowest values today are less than 0.3. As a rough guide we can say that a car has poor aerodynamics if it has a Cd of 0.5 and good aerodynamics if it
is 0.3 or less.
What are the Cx coefficients of actual cars? Manufacturers do occasionally publish them.

In order to predict a vehicle's Cd, manufacturers often simulate wind turbulence with modeling software applications (Fig.) to quickly evaluate changes to a
model design, allowing greater improvements before the physical prototyping stage.

Fig. – An aerodynamic simulation of the airflow for a van (Volvo).

Once the model has been simulated satisfactorily, production mockups are incrementally created and tested in the wind tunnel to collect actual data to
validate the modeling and to zero in on any final improvements.
As it turns out, aerodynamic drag is not the only force acting against the motion of the car. Rolling resistance is also important. In most cases it is much less
than form drag but it does have an effect. It is relatively difficult to calculate. We’ll see how later.

Front area (𝐴𝐴𝑓𝑓 ) of the vehicle

In the formula for aerodynamic force and coefficient of drag, one of the main components is the frontal area of the vehicle 𝐴𝐴𝑓𝑓 . This area should therefore be
kept as small as possible if the drag force and Cd are to be low. This is important when car manufacturers create a new vehicle design.
The frontal area can be determined with various methods, for example using a laser and a photograph. To a first approximation, we can use 80% of the
height times the width, however we’ve already seen a more accurate way to get the area in the FAQ of aero.ini.

Since frontal area and Cd are both of particular importance, it is worthwhile to consider their product, called the figure of merit. The figure of merit gives a
better comparison between cars, because it is possible that a vehicle with a low Cd has a relatively large frontal area, and vice versa. So, only one of the
numbers does not tell the entire story. Their product, however, does.

Graph

Aerodynamic Lift and Downforce

Popular Explanation vs Physical Explanation

We are going to show you that lift is easier to understand if one starts with Newton’s laws rather than the Bernoulli principle.
We will also show you that the popular explanation that most of us were taught is misleading at best and that lift is due to the wing diverting air down. Most
of this diverted air is pulled down from above the wing.

343
The popular description of lift is based on the Bernoulli principle. The primary advantage of this description is that it is easy to understand and has been
taught for many years. Because of its simplicity, it is used in most manuals. The major disadvantage is that it relies on the "principle of equal transit times",
or at least on the assumption that because the air must travel farther over the top of the wing it must go faster. This description focuses on the shape of the
wing and prevents one from understanding such important phenomena as inverted flight, power, ground effect, and the dependence of lift on the angle of
attack of the wing.

Students of physics and aerodynamics are taught that an airplane flies as a result of the Bernoulli principle, which says that if air speeds up the pressure is
lowered (in fact this is not always true; the air flows fast over the airplane’s static port but the altimeter still reads the correct altitude). The argument goes
that a wing has lift because the air goes faster over the top creating a region of low pressure. This explanation usually satisfies the curious and few challenge
the conclusions.
Some may wonder why the air goes faster over the top of the wing and this is where the popular explanation of lift falls apart. In order to explain why the air
goes faster over the top of the wing, many have resorted to the geometric argument that the distance the air must travel is directly related to its speed. The
usual claim is that when the air separates at the leading edge, the part that goes over the top must converge at the trailing edge with the part that goes under
the bottom. This is the so-called "principle of equal transit times".

One might ask if the numbers calculated by the popular description really work. Let’s look at an example. Take the case of a Cessna 172, which is a high-
winged, four-seat airplane. The wings must lift 1045 kg (2300 lb) at its maximum flying weight. The path length for the air over the top of the wing is only
about 1.5% greater than under the wing. Using the popular Description of lift, the wing would develop only about 2% of the needed lift at 104 km/h (65
mph), which is "slow flight" for this airplane. In fact, the calculations say that the minimum speed for this wing to develop sufficient lift is over 640 km/h
(400 mph). If one works the problem the other way and asks what the difference in path length would have to be for the popular Description to account for
lift in slow flight, the answer would be 50%. The thickness of the wing would be almost the same as the chord length.

But who says the separated air must meet at the trailing edge at the same time? Fig. shows the airflow over a wing in a simulated wind tunnel. In the
simulation, smoke is introduced periodically. One can see that the air that goes over the top of the wing gets to the trailing edge considerably before the air
that goes under the wing. In fact, the air is accelerated much faster than would be predicted by equal transit times. Also, on close inspection one sees that
the air going under the wing is slowed down from the "free-stream" velocity of the air. The principle of equal transit times holds only for wings with zero lift.

Fig. –

The popular explanation also implies that inverted flight is impossible. It certainly does not address acrobatic airplanes, with symmetric wings (the top and
bottom surfaces are the same shape), or how a wing adjusts for the great changes in load such as when pulling out of a dive or in a steep turn?
So, why has the popular explanation prevailed for so long? One answer is that the Bernoulli principle is easy to understand. There is nothing wrong with the
Bernoulli principle, or with the statement that the air goes faster over the top of the wing. But, as the above discussion suggests, our understanding is not
complete with this explanation. The problem is that we are missing a vital piece when we apply Bernoulli’s principle. We can calculate the pressures around
the wing if we know the speed of the air over and under the wing, but how do we determine the speed? As we will soon see, the air accelerates over the
wing because the pressure is lower, not the other way around.

Another fundamental shortcoming of the popular explanation is that it ignores the work that is done. Lift requires power (which is work per time). As will be
seen later, an understanding of power is key to the understanding of many of the interesting phenomena of lift.

The physical description on lift

The Physical Description of lift is based primarily on Newton's three laws and a phenomenon called the Coanda effect. It is also a useful tool for making
rough estimates ("back-of-the-envelope calculations") of lift. The Physical Description of lift is also of great use to a pilot who needs an intuitive
understanding of how to fly an airplane.

Newton’s first law states a body at rest will remain at rest, or a body in motion will continue in straight-line motion unless subjected to an external applied
force. That means, if one sees a bend in the flow of air, or if air originally at rest is accelerated into motion, a force is acting on it. Newton’s third law states
that for every action there is an equal and opposite reaction. As an example, an object sitting on a table exerts a force on the table (its weight) and the table
puts an equal and opposite force on the object to hold it up. In order to generate lift a wing must do something to the air. What the wing does to the air is
the action while lift is the reaction.

Let’s compare two figures used to show streamlines over a wing. In Fig. the air comes straight at the wing, bends around it, and then leaves straight behind
the wing.

344
Fig. - Common depiction of airflow over a wing. This wing has no lift.

We have all seen similar pictures, even in flight manuals. But, the air leaves the wing exactly as it appeared ahead of the wing. There is no net action on the
air so there can be no lift!

Fig. shows the streamlines, as they should be drawn.

Fig. - True airflow over a wing with lift, showing upwash and downwash.

The air passes over the wing and is bent down. Newton’s first law says that them must be a force on the air to bend it down (the action). Newton’s third law
says that there must be an equal and opposite force (up) on the wing (the reaction). To generate lift a wing must divert lots of air down.

The lift of a wing is equal to the change in momentum of the air it is diverting down. Momentum is the product of mass and velocity (mv). The most
common form of Newton’s second law is F= ma, or force equal mass times acceleration.
The law in this form gives the force necessary to accelerate an object of a certain mass. An alternate form of Newton’s second law can be written: The lift of a
wing is proportional to the amount of air diverted down times the vertical velocity of that air. It is that simple. For more lift the wing can either divert more air
(mass) or increase its vertical velocity. This vertical velocity behind the wing is the vertical component of the "downwash". Figure 4 shows how the
downwash appears to the pilot (or in a wind tunnel).

Fig. - How downwash appears to a pilot and to an observer on the ground.

The figure also shows how the downwash appears to an observer on the ground watching the wing go by. To the pilot the air is coming off the wing at
roughly the angle of attack and at about the speed of the airplane. To the observer on the ground, if he or she could see the air, it would be coming off the
wing almost vertically at a relatively slow speed. The greater the angle of attack of the wing the greater the vertical velocity of the air. Likewise, for a given
angle of attack, the greater the speed of the wing the greater the vertical velocity of the air. Both the increase in the speed and the increase of the angle of
attack increase the length of the vertical velocity arrow. It is this vertical velocity that gives the wing lift.

As stated, an observer on the ground would see the air going almost straight down behind the plane. This can be demonstrated by observing the tight
column of air behind a propeller, a household fan, or under the rotors of a helicopter; all of which are rotating wings. If the air were coming off the blades at
an angle the air would produce a cone rather than a tight column. The wing develops lift by transferring momentum to the air. For straight and level flight
this momentum eventually strikes the earth in. If an airplane were to fly over a very large scale, the scale would weigh the airplane.

Let us do a back-of-the-envelope calculation to see how much air a wing might divert. Take for example a Cessna 172 that weighs about 2300 lb (1045 kg).
Traveling at a speed of 140 mph (220 km/h), and assuming an effective angle of attack of 5 degrees, we get a vertical velocity for the air of about 11.5 mph
(18 km/h) right at the wing. If we assume that the average vertical velocity of the air diverted is half that value we calculate from Newton's second law that
the amount of air diverted is on the order of 5 ton/s. Thus, a Cessna 172 at cruise is diverting about five times its own weight in air per second to produce
lift. Think how much air is diverted by a 250-ton Boeing 777 on takeoff.
Diverting so much air down is a strong argument against lift being just a surface effect (that is only a small amount of air around the wing accounts for the
lift), as implied by the popular explanation. In fact, in order to divert 5 ton/sec the wing of the Cessna 172 must accelerate all of the air within 18 feet (7.3 m)
above the wing. One should remember that the density of air at sea level is about 2 lb per cubic yard (about 1kg per cubic meter). Figure 5 illustrates the
effect of the air being diverted down from a wing. A huge hole is punched through the fog by the downwash from the airplane that has just flown over it.

So how does a thin wing divert so much air? When the air is bent around the top of the wing, it pulls on the air above it accelerating that air downward.
Otherwise there would be voids in the air above the wing. Air is pulled from above.
This pulling causes the pressure to become lower above the wing. It is the acceleration of the air above the wing in the downward direction that gives lift.
(Why the wing bends the air with enough force to generate lift will be discussed in the next section.)
As seen in figure 3, a complication in the picture of a wing is the effect of "upwash" at the leading edge of the wing. As the wing moves along, air is not only
diverted down at the rear of the wing, but air is pulled up at the leading edge. This upwash actually contributes to negative lift and more air must be diverted
down to compensate for it. This will be discussed later when we consider ground effect.

345
Normally, one looks at the air flowing over the wing in the frame of reference of the wing. In other words, to the pilot the air is moving and the wing is
standing still. We have already stated that an observer on the ground would see the air coming off the wing almost vertically. But what is the air doing below
the wing? Figure 6 shows an instantaneous snapshot of how air molecules are moving as a wing passes by. Remember in this figure the air is initially at rest
and it is the wing moving. Arrow "1" will become arrow "2" and so on. Ahead of the leading edge, air is moving up (upwash).
At the trailing edge, air is diverted down (downwash). Over the top the air is accelerated towards the trailing edge. Underneath, the air is accelerated forward
slightly.

Fig. - Direction of air movement around a wing as seen by an observer on the ground.

So, why does the air follow this pattern? First, we have to bear in mind that air is considered an incompressible fluid for low-speed flight. That means that it
cannot change its volume and that there is a resistance to the formation of voids.
Now the air has been accelerated over the top of the wing by of the reduction in pressure. This draws air from in front of the wing and expels if back and
down behind the wing. This air must be compensated for, so the air shifts around the wing to fill in. This is similar to the circulation of the water around a
canoe paddle. This circulation around the wing is no more the driving force for the lift on the wing than is the circulation in the water drives the paddle.
Though, it is true that if one is able to determine the circulation around a wing the lift of the wing can be calculated. Lift and circulation are proportional to
each other.
One observation that can be made from figure 6 is that the top surface of the wing does much more to move the air than the bottom. So the top is the more
critical surface. Thus, airplanes can carry external stores, such as drop tanks, under the wings but not on top where they would interfere with lift. That is also
why wing struts under the wing are common but struts on the top of the wing have been historically rare. A strut, or any obstruction, on the top of the wing
would interfere with the lift.

Coanda Effect
A natural question is "how does the wing divert the air down?" When a moving fluid, such as air or water, comes into contact with a curved surface it will try
to follow that surface. To demonstrate this effect, hold a water glass horizontally under a faucet such that a small stream of water just touches the side of the
glass. Instead of flowing straight down, the presence of the glass causes the water to wrap around the glass as is shown in Fig.. This tendency of fluids to
follow a curved surface is known as the Coanda effect. From Newton’s first law we know that for the fluid to bend there must be a force acting on it. From
Newton’s third law we know that the fluid must put an equal and opposite force on the glass.

Fig. - Coanda effect.

So why should a fluid follow a curved surface? The answer is viscosity; the resistance to flow which also gives the air a kind of "stickiness". Viscosity in air
is very small but it is enough for the air molecules to want to stick to the surface. At the surface the relative velocity between the surface and the nearest air
molecules is exactly zero. (That is why one cannot hose the dust off of a car.) Just above the surface the fluid has some small velocity. The farther one goes
from the surface the faster the fluid is moving until the external velocity is reached. Because the fluid near the surface has a change in velocity, the fluid flow
is bent towards the surface by shear forces. Unless the bend is too tight, the fluid will follow the surface. This volume of air around the wing that appears to
be partially stuck to the wing is called the "boundary layer" and is less than one inch (2.5 cm) thick, even for a large wing.
Look again at Figure 3. The magnitude of the forces on the air (and on the wing) are proportional to the "tightness" of the bend. The tighter the air bends the
greater the force on it. One thing to notice in the figure is that most of the lift is on the forward part of the wing. In fact, half of the total lift on a wing is
typically produced in the first 1/4 of the chord length.

Lift as a function of angle of attack

There are many types of wing: conventional, symmetric, conventional in inverted flight, the early biplane wings that looked like warped boards, and even the
proverbial "barn door". In all cases, the wing is forcing the air down, or more accurately pulling air down from above. (Though the early wings did have a
significant contribution from the bottom.) What each of these wings has in common is an angle of attack with respect to the oncoming air. It is the angle of
attack that is the primary parameter in determining lift.

346
To better understand the role of the angle of attack it is useful to introduce an "effective" angle of attack, defined such that the angle of the wing to the
oncoming air that gives zero lift is defined to be zero degrees. If one then changes the angle of attack both up and down one finds that the lift is proportional
to the angle. Figure 8 shows the lift of a typical wing as a function of the effective angle of attack. A similar lift versus angle of attack relationship is found for
all wings, independent of their design. This is true for the wing of a 747, an inverted wing, or your hand out the car window. The inverted wing can be
explained by its angle of attack, despite the apparent contradiction with the popular explanation of lift. A pilot adjusts the angle of attack to adjust the lift for
the speed and load. The role of the angle of attack is more important than the details of the wings shape in understanding lift. The shape comes into play in
the understanding of stall characteristics and drag at high speed.

Fig. - Lift versus the effective angle of attack.

Typically, the lift begins to decrease at a "critical angle" of attack of about 15 degrees. The forces necessary to bend the air to such a steep angle are greater
than the viscosity of the air will support, and the air begins to separate from the wing. This separation of the airflow from the top of the wing is a stall.

Lift is a serious thing particularly in racing cars. It has a serious effect on the control and handling of the car.
Lift occurs because the airflow over the top of a car is faster than across the bottom. This occurs to some degree in all cars. As the speed increases, the
pressure decreases, according to Bernoulli’s theorem. The top of the car therefore has a lower pressure than the bottom, and the result is a lifting force.
Comparing a car to an airplane wing, we see the similarity.
The lift force is given by

Where A is the area of the underside of the car and Cl is the coefficient of lift.

Fig. – Group B racing Jaguar sketches. On the right the sketch shows the rear diffuser area of the car: the concept is that the entire car is an inverted wing profile that
accelerates the airflow and creates low pressure beneath the car, in accordance with the Bernoulli principle, that effectively "sucks" the car towards the road.

wip

Which cars have better aerodynamic designs, square or smooth ones?

There is so much more to aerodynamics than something being just smooth or boxy.
A design will benefit from smooth curving surfaces that lower the Cd, but it doesn't necessarily mean the car will end up being aerodynamically efficient.
The overall purpose of the design is what determines how much drag is wanted or needed.

To illustrate this point, in the following examples (Fig.), the vehicle on the left has a higher Cx than the one on the right.

347
Fig. - The Ferrari F50 has a Cd of 0.372, while the Tatra 77A has a Cd of 0.212.

Fig. – In general Formula 1 cars have a Cd between 0.7-1.1. Pickups, like this beautiful Chevrolet Apache C-10, have a Cd between 0.35-0.45. This coefficient is so high in
F1 cars because they need far more tire grip, improving both acceleration and cornering. The aerodynamic drag is used to create lift efficiently.

So how does the design of the car make it more aerodynamic?

There used to be a word in common use in the 1930s, 40s and 50s called “streamlining”. Nobody uses it now, but it essentially meant changing the shape
of a body so that its resistance to air flowing over it becomes as little as possible (Fig.). They really went overboard then, and even “streamlined” teacups
and kettles were marketed, because it was a buzzword.

Fig. – (left) The difference from a “standard” and a streamlined car (1930s ca.). (right) Main features of a streamlined car.

Streamlining is a way to design a shape that generates as little turbulence as possible, with the purpose of generating less drag. You can see some indicative
examples in Fig. below.

348
Fig. - These figures would correspond to objects at about 140 mph in air. The percentage of drag would vary at different speeds and at very low speeds there would not be much
difference. At higher speeds laminar flow and turbulence come into play with different effects than in these illustrations, which are just indicative. Wind resistance (the drag in air flow)
increases up to the speed of approximately 140 mph, and up to this speed a rough surface gives less drag than a smooth polished surface. This is due to the turbulence at the surface
acting like tiny ball bearings to allow the air layers to pass over more smoothly. At approx. 140 mph the drag drops off as the flow becomes laminar and turbulence creates more drag.
Laminar flow continues as speed and drag increase. (FIND BETTER PIC)

Streamlining would seem to be important, after all, we want the car to move more easily through the air (less drag = faster), but the most dominant reason
behind the large difference in the appearance of the more recently designed multiwinged race car is the focus on using its body and wings to create aerodynamic
downforce. This raises the question of why aerodynamic downforce is needed.
When wings generate lift, they also create drag, which is the force that resists the motion. The drag is usually much smaller than the lift, and it can be
reduced by streamlining the vehicle (having a smooth external surface). Of course, any improvement in a vehicle’s drag leads to potential improvements in
fuel economy, which is why drag is quite important to the passenger car industry.
But the shape of the airfoil is not the entire problem: the condition of the surface affects the movement of the particles that collide with it. As seen in Fig.,
having a mirror finish doesn’t mean less drag. When a particular type of roughness is present on a surface it can also create a skin-friction-drag reduction.
Skin-friction drag is perhaps the most essential manifestation of the dissipative nature of turbulence and accounts for the total drag in the case of planar
walls (as in a zero-incidence flat plate boundary layer, Fig.). Several techniques are available to reduce friction drag below the level typical of a smooth solid
wall; they can be categorized into active (requiring extra energy) and passive ones. The former typically provide larger savings but imply extra complexity
and cost, so that the ideal technique for friction reduction remains a passive one, often embodied in surface patterns performing better than the planar flat
geometry.
Dimples are small concavities imprinted on a flat surface, known to affect heat transfer and also flow separation and aerodynamic drag on bluff bodies when
acting as a standard roughness.
The use of dimples on the surface of bluff bodies is well known (e.g., in golf ball manufacturing, they have been an accepted practice since the 1930s), and
their ability to influence the turbulent boundary layer and the separation on the body is rather well understood; the same concept is also being considered in
sports-car racing and other competitive sports (Fig.).

349
Fig. – (top) Dimples on the very end of the rear spoiler of a race car. (bottom) Bugatti Dimple Airscoop, an active dimple aero device fitted on the 2020 Bugatti Bolide.

It has been proven that when the air flows along the surface of the aerofoil with dimple, there is an acceleration of the flow at the dimple surface and the
boundary layer changes from laminar to turbulent. This transition results in delayed flow separation which reduces the drag. The presence of a dimple therefore
increases the stall angle of the aircraft. This, if incorporated would be extremely beneficial in making an aircraft more maneuverable and increase the aircraft’s
fuel economy. The position and dimensions of the dimple affect the drag and lift characteristics. The total aerodynamic efficiency increases due to the reduced
drag. However, experimental studies have to be performed. It is also necessary to determine the feasibility of generation of dimples on aircraft wings. The
concept of presence of dimples on aircraft wings to reduce drag cannot be applied to all aerofoil profiles. (Rajasai, Tej, Srinath, 2015)

Another study confirms that:

The velocity renderings and the pressure variations observed [in the CFD FLUENT simulations] are in synchronisation with the experimental results. The
dimple parameters were chosen based on the theoretical study of the flow around the body and the past results which led to a 0.3 % reduction in drag value.
But there exists even greater scope for optimisation of the dimple geometry and its positioning over the body surfaces which can lead to a massive reduction
in the drag coefficient. (Grover et al., 2017)

However, no optimization information of dimple sizing is given in literature.

This principle was apparently already employed a long time ago, knowingly or unknowingly: the streamlined Alfa Romeo 40-60 HP Aerodinamica (Fig.)
adopted skin-dimpling to improve its aerodynamic performance and reach a 139 km/h top speed.

350
Fig. - The 1914 Alfa Romeo 40-60 HP Aerodinamica (1970 replica). All this shows how the Bugatti Dimple Airscoop is not really anything new and everything has already been done
before, as always. They are just active dimples. Those Italians knew it all along.

(wip) XD

351
2. ai.ini
This file manages the behaviour of the single-player AI opponents for each car. You don’t need to mess a lot with this config, as you can easily copy it from
another car with a working AI and just change the shifting behaviour in [GEARS]. Nevertheless, always test it in multiple races to verify that everything is
working properly.
[HEADER]
VERSION=3 ; version of the AI behaviour. VERSION=4 introduced differences in the shifting functions below.

[GEARS]
UP=5700 ; Upshipt gear at value RPM (also used for automatic gearbox assist); rpm AI shifts up at.
DOWN=3800 ; Downshift gear at value RPM (also used for automatic gearbox assist); rpm AI shifts down at.

% ▲ for [HEADER] VERSION=4, Kunos changed the downshift behaviour to be a percentage of revs rather than a particular RPM, so it needs to be DOWN=60 (or
70 or 80 or w/e) rather than =5500 or =3800; you can always switch back to version 3

SLIP_THRESHOLD=0.5 ; Slip ratio permitted for AI driving - how well AI rev matches
GAS_CUTOFF_TIME=0.1 ; Gearchange time needed for AI control - how long ai lifts throttle on upshifts

[PEDALS]
GASGAIN=4.0 ; how the AI pushes the throttle pedal vs. in other cars (since they have different engine maps, torque curves, etc)
BRAKE_HINT=0.8 ; how the AI pushes the brake pedal in this car (0.9 = 90% of the recorded line's suggested braking)

% ▲ This parameter regulates the time and space to brake the car, so if the parameter is in 1, for example, the car brakes the fastest possible, but if
the parameter goes down, then the time to stop the car is higher.

TRAIL_HINT=0.2 ; trail braking, same thing

[STEER]
STEER_GAIN=1.5 ; how hard the AI needs to turn the wheel to make corners (depends on ideal slip ratios, the way the car handles
oversteer/understeer, etc.)

[LOOKAHEAD]
BASE=20 ; how far in front of the car the AI looks at the recorded line to know what to do
GAS_BRAKE_LOOKAHEAD=3 ; not sure if this is added to the base. Tells the AI how far it needs to be ready to brake/throttle.
SPEED_GAIN=0.2 ; how much ai increases the distance according to speed (needs to look farther ahead to be ready for corners at higher
speeds)

[DRAG]
SLIP_RATIO_LIMIT=10 ; the AI won't brake or throttle to a higher slip ratio than this; this is for drag mode

[ULTRA_GRIP] ; Changing this value doesn’t affect the AI anymore since VERSION=3
VALUE=1.2 ; how much lateral grip the AI is simulated within braking zones. This helps AIs brake closer to the limit

% ▲ AI cars have a 20% (1.2 * 100 = 120%) tire grip overhead vs the player and some form of (artificial) stability control. They don't try to use the
extra grip normally though. The extra is there so the AI's weird and twitchy inputs don't make them spin. That’s why it’s overhead, they don’t use more
than 100% unless they have to, up to that 20% extra. The value is hardcoded to 1.2.

[PHYSICS_HINTS]
AERO_HINT=0.75 ; how much grip the car gains from aero with speed, so the AI can calculate high speed cornering speeds more accurately
without having to know everything about its aero loads.

[TYRES]
HINT=1.00 ; how much grip the ai will use

LITTLE EXPLANATION:
- AIs in Assetto Corsa don’t make any difference between the real player and another virtual opponent. So, learn how to flow with them.
- Tracks don't use ai.ini. Only cars do. And yes, it's still used. Tracks use ai_hints.ini to influence the AIs, on top of the behaviour already set by the config
file of the single vehicle (ai.ini).
- If you are planning to have a long race, start with a long qualification session and let the AI run and figure out what the real fuel consumption is. Otherwise
they won’t be calculated.
- Not all of these values are being used anymore, famously ULTRA_GRIP is now a hardcoded value, and the line in ai.ini will be ignored.
- To change some parameters of the script live, during a race session, you can use the Kunos AI app. Go to ccxxx for more info about it.
- The TRAIL_HINT works together with the BRAKE_HINT.
- The more the car is complex, the more is the difference between human and artificial intelligence.
- The AC logs are very helpful when trying to understand the behaviour of the opponents because they contain the AI's strategy decisions.

CSP ADDITIONS
CSP brings the New AI Behaviour. It introduces these features (more may be added later on):
• Cool down lap in offline races, for you to gradually get back to pits;
• In track day mode, creates seemingly endless traffic (brought to online servers too);
• Allows to drive wrong way in practice or track day.
• Now AIs (only with some cars) can use wet tyres when raining, and can drive quite well in wet conditions too with the new updates. The ai.ini doesn't manage this feature
though.

FAQ
QUESTION [1]: Have you ever had issues with cars just sitting on the grid after race start?
ANSWER [1]: If it's a track specific problem it means the grid spots are too close together. If it's the car then generally they’re transmission issues. Check
the FINAL gear ratio in drivetrain.ini. It can be also related to the new ai behaviour in CSP, try disabling that as well.
Switch to the AI cars during a replay session and check if they rev up but fail to switch to first gear. If that is the case, it's the ai.ini ‘s fault. You have to
manually adjust the UP and DOWN shifting RPM values. Lower the UP value to something below the engine limiter. The AI only shifts up when it reaches that
value and it can't if set too high.

352
CURIOSITIES AND AMENITIES
- Often the AI doesn't steer into me and they're utter cowards.
They heavily brake on the exit of corners while you're slotting back behind them after they've overtaken you (almost coming to a stop), brake when there's a
car in front instead of overtaking, etc.
I have to say the AI in some cases is not too retarded. It steers into you if you're not careful, but very often they try to brake or avoid you in order to avoid a
collision. So basically their pit-maneuver is mostly your fault, not following the ideal line. If you're getting constantly spun out by the AI then you might want
to either have a look at your settings or your driving style, you can't be too aggressive with the AI, much like real people you need to leave space for them.
Always stay close to the apex if you want to avoid these situations.
- It is a fact that in many situations the AI fails to account of the "space shrink" when speed decreases (ie. if there's space for 2 cars at 200 Km/h there might
be no space for the same 2 cars at 80 Km/h). Add the actual player to this and the situation gets even more difficult to analyse... the users complaining about
AI hitting them and then posting videos of themselves moving around the track as if nobody was there are innumerable in the almost 10 years AC has been
around.
- A fast driver can be frustrated by the AIs, because once you pass them on the outside of a corner, they sort of “give up”. The reason why they abandon the
overtake fight is that they know you are on the outside. Now, as humans, we can do a very complex reasoning:
“if I am on the inside of a corner, I have a better line compared to the guy on the outside and eventually I can get wider and go faster at the exit”.
The AI doesn’t know that. They think they have to take the entire corner on the inside. So they actually brake more. It’s annoying and immersion breaking, as
you immediately know what they’re going to do.
At the same time, “this sense of the AI not fighting is essential for people that are not really that good at driving, so even if you brake in stupid positions, the
virtual opponents need to be able to avoid you” (Stefano Casillo, 2015).
On a real track, if you hit the brakes at the wrong points, you would be taken aside and told that you’re a danger to others and yourself.
- The code for overtaking doesn’t really work for cars that are the same. They actually use more time that they gain doing that manoeuvre. But it works in
situations where you have a vehicle that is faster than another, for example two different classes of GT cars, so they don’t get stuck behind slower types.
- AIs don’t use the exact same physics as players, so the speed an AI can leave a corner is not identical to the player’s one. Very often you can't run the same
line as them since they're using 120% as much grip (to compensate for the jankyness of their trajectory) and you can win because their route is not very
optimal.
- In AC the artificial intelligence is very good when it’s about managing cars with lots of power, because it’s good at putting power down. With cars where you
have to keep the momentum and the flow, be very gentle on the pedals, generally speaking it is not as capable.
- The aggression slider is there to let AIs make moves that risk hitting the player if the player doesn't avoid it. So if you're in a class where "rubbing is
racing" like BTCC, you can move it above 0%. It is the biggest thing you can tweak to get decent AI races, as it impacts how close the cars will get to you
and to each other, which is why at times they will brake in strange ways if they enter a turn with a car in front of them, even if it's another AI car.
Too low on aggression and they brake early causing you to rear end them. Too high on aggression and they won't slow down when you brake ahead of
them and just slam into you. I notice that with low aggression, they never want to pass me even when I leave an opening. Too high aggression makes the AI
pretty much ignore you and just run you off the road even if you have the line. Now I don't mind this because it keeps me on my toes. Then you have to take
different mods into account. And in this paragraph I won't even go into how the track, AI lines, AI Hints, etc. factor into all of this. I'll simply close by saying
that of all racing sims, I still have more fun against the AI with AC than with any other.
- The AIs have always tyre blankets ON, even when they're disabled player-side.
- I've been looking for answers to the question "can AIs drift?".
Of course the answer is NO, at least with standard tires. There are ways that I've seen to render the opponents looser, by manipulating the ai.ini and tyres.ini
files to get slip and counter-steer with low-grip compounds.
You can edit the tires to obtain more slip angle for longitudinal and lateral forces, allowing for a slip raise in ai.ini, and using a different tire pressure
combination, low at the front and high at the rear. Try increasing the FRICTION_LIMIT_ANGLE of your tires (see tyres.ini, pag.) to something unrealistic
like 60 degrees 56. The maximum you can go to is <90°, after that the lateral slip angle becomes “longitudinal” and it ceases to make sense from a physical
point of view.
There aren't other settings to make this happen, unless you change the values to force it to happen, with trial and error.
- In early versions of AC, the AIs did not use the ABS assist, since they were faster without it. Nowadays? (do they use stability control?)
- The AI in Assetto Corsa is probably the best you can get without going to what is called a “generative” AI, a system that learns from its experience. Stefano
Casillo stated (2015) that he did experiment a little with this type of algorithm (which he calls the “expert” system) at the beginning of AC development. The
idea is that the AI has a history: in a single turn, it can divide the tracking in different sections and every time it passes one of them, analyses what happened
and can tell whether the driving is good or not, to self-adjust and generate values similar to the ones portrayed by ai.ini automatically.
The problems with this are (were, at time of AC development):
• The time needed to train to a good degree the AI of each car on each track.
• Every time you change any part of the algorithm, including the vehicle or road physics, all your data becomes invalid, as all the AI assumptions for any part of the track
become wrong. You’ll have to re-train from scratch every car.

- On the leaderboard you can see which tires the virtual opponents are using (Fig.).

56
A normal value would be around 10°.

353
3. ai_tyres.ini
You can find this config in the Ferrari 458 GT2, Ferrari 599XX EVO, BMW M3 GT2, Lotus Evora GX, Mercedes-Benz C9 LM and a lot of other Kunos official
cars. This script helps AIs with picking tires for the qualification session, comparing to the track’s length. It is not for AI pit strategy, as AIs do not change
tires when pitting.
[SS]
MAX_KM=20 ; maybe more info about this value

[S]
MAX_KM=80

[M]
MAX_KM=150

[H]
MAX_KM=300

4. ambient_shadows.ini
This .ini sets the dimension of the ambient shadows of your car. In Chapter 1 you can find info about them.
[SETTINGS]
WIDTH=1.0 ; width of the car’s ambient shadows
LENGTH=2.8 ; length of the car’s ambient shadows

354
5. analog_instruments.ini
This config file sets all the parameters related to the analogue car instruments on the cockpit: basically all the tachometers, gauges, needles and indicators.
Not all the lines of this file are required, depending on the vehicle, but here all the sections will be written down and explained. You can add or remove them
to your liking. We can say that this script is really modular from this point of view.
For all the headers below you can use the same lines of the first [RPM_INDICATOR] section (even though probably you don’t need them all, for example a
LUT is not always necessary). The common ones will be skipped. Eventual additional or differently-functioning lines will be present and explained.
[RPM_INDICATOR] ; The engine tachometer.
OBJECT_NAME=ARROW_RPM ; Name of the object (NULL/dummy) that represents the arrow.

% ▲ The corresponding NULL must be present in the vehicle model, otherwise the session will crash.

ZERO=-20.000 ; The starting position of the arrow. [deg]

% ▲ It is best to export the car model with the arrow object at 0° so you don't need to play with this number and just leave it at 0.

MIN_VALUE=0 ; Minimum threshold value. [RPM]

% ▲ For example if you set this to 10, the instrument should not show anything below 10 (input value).

STEP=0.5 ; Arrow movement angle/engine RPM ratio.

% ▲ Pretty simple, if you want that 1° represents 1 RPM you leave this value at 1, if you want 10 RPM to be 1° then it should be 0.1, etc. For clockwise
movement, it has to be a positive value, for counter clockwise, it has to be negative.

OBJECT_NAME_MAX= ; Name of the telltale object for the main arrow.

LUT=(0=0|1000=10|2000=26|3000=42|4000=71|5000=102|6000=132|7000=163|8000=194|9000=224|10000=254)

% ▲ Look-up-table, left side is value (RPM), right side is degrees of movement. Good for asymmetric tachometer gauges.

[SPEED_INDICATOR] ; The speedometer.

OBJECT_NAME=ARROW_SPEED
STEP=1.398333 ; Arrow movement angle/vehicle speed ratio.

% ▲ If you want that 1° represents 1 speed unit (1 km/h or 1 mph) you leave this value at 1, if you want 10 km/h to be 1° then it should be 0.1, etc. For
clockwise movement, it has to be a positive value, for counter clockwise, it has to be negative.

% ▲ The speed indicator can also use an external LUT file instead of the internal one.

[FUEL_INDICATOR] ; The fuel needle.

OBJECT_NAME=ARROW_FUEL
STEP=1.307692 ; Arrow movement angle/litres of fuel ratio.

% ▲ If you want that 1° represents 1 litre of fuel you leave this value at 1, if you want 10 litres to be 1° then it should be 0.1, etc. For clockwise
movement, it has to be a positive value, for counter clockwise, it has to be negative.

LUT=(0=0|20=30|40=60)

% ▲ Look-up-table, left side is amount of fuel in litres, right side is degrees of movement. Good for asymmetric fuel gauge.

[TURBO_INDICATOR] ; The turbo needle. If more than one, SYNTAX: [TURBO_INDICATOR_ID], ID starting from zero.
OBJECT_NAME=ARROW_TURBO
USE_BAR=0 ; Changes gauge pressure units. Instead of [psi], use [BAR] (=1 for true, =0 for false).

[LIMITER_INDICATOR] ; Engine RPM limiter.

[same as above]

% ▲ The RPM limiter is hard coded, and if the 3D object is named ARROW_LIMITER, this code is not needed. The RPM limiter arrow should be an identical
copy of RPM arrow, with the dummy at same place and same orientation, in order to function properly.

[WATER_TEMP] ; The water temperature needle.

OBJECT_NAME=ARROW_WATER_TEMP
ZERO=0
STEP=-0.49
MIN_VALUE=0
LUT=(1=0.02|75=-36.500|150=-73.500)

% ▲ Look-up-table, left side is temperature in Celsius [°C], right side is degrees of movement. Good for asymmetric water temperature gauges.

[FUEL_WARNING_0]
OBJECT_NAME=FUEL_WARNING_0
FUEL_SWITCH=3

[PLACE_HOLDER_0] ; Generic placeholder gauge. SYNTAX: [PLACE_HOLDER_ID], ID starting from zero.

OBJECT_NAME=ARROW_OIL_TEMP

[PLACE_HOLDER_1]
OBJECT_NAME=ARROW_OILPRESSURE

LITTLE EXPLANATION
- Vanilla AC supports these types of instruments by default:

• Tachometer (RPM)
• Telltale tachometer
• Speedometer (km/h or miles/h)
• Fuel level indicator
• Turbocharger pressure manometer (psi or bar)
• Water temperature

Other instruments are called placeholders in the analog_instruments.ini script, as there are no existing inputs to make them work. CSP brings more options
from this point of view.

- LUTs are not mandatory in order for analog_instruments.ini to work, but when they are used inside said script, the STEP and MIN_VALUE lines of the
specific section are ignored. They can be in-line, but if you have many values it is recommended to specify a separate file.

- The [LIMITER_INDICATOR] section is for the telltale tachometer. It is a tachometer that has a second (usually red) arrow that shows the highest
amount of revs reached (Fig.).

355
Fig. - This one is a Smiths Chronometric tachometer, model number and vintage so far unknown. It is installed in an MGA Twin Cam car along with all of the other standard Jaeger
instruments. Chronometric instruments were always cable driven. It was also common to rotate the instrument in the dash to position the intended red line straight up at top of the dial
face where it is easy to see out of corner of your eye without a direct glance.

It was often used in competition cars. The needle could be set somewhere in the vicinity of the intended red line for the engine. If this engine speed was
exceeded the white tach needle would push the red needle higher, and the red needle would stay there giving indication of the highest engine speed.

RELATED FILES
LUTs:
analog_speed_curve.lut
This is a separate look-up-table table for the speedometer, but it is rarely used. It comes in handy when it’s difficult to obtain a precise reading based on the
ZERO and STEP values alone.

You input the filename in the LUT field of the [SPEED_INDICATOR] section. The file itself looks like a typical LUT, nothing more and nothing less:
0|0
100|45
200|90

On the left side is speed in [km/h], on the right side is the angle of movement of the needle in degrees; regarding STEP and MIN_VALUE, they are
ignored when this LUT is used.

To set up this table properly, the best method is to check in your 3D editor of choice the various angles that the needle generates with respect to the zero
position 57. First, note on a piece of paper the angle of the minimum value which shall be registered (usually corresponding to the zero), see Fig.

Fig. - The angle of the minimum value is -29.3° (rotation along the y-axis). The minus depends on the reference system adopted by your editor; in this example, Blender.

57
I am assuming that you have set up your ARROW_# dummies correctly (see pag.).

356
Second, write down also all the angles of the other positions which you want to include (Fig.). I will proceed with steps of ten units here: one can use less,
or more, depending on how accurate you want the needle to be. But do not cover every single notch, it’s not worth it.

Fig. – Several notches later… the entire range is covered.

At the end it is necessary to subtract the degrees of the needle at the “zero” position from all the angles you note down. In the example I had these values:

0 km/h – 29.3°, 10 km/h – 37°, 20 km/h - 44.4°, 30 km/h - 59.6°, 40 km/h – 75°, 50 km/h – 89.8°, 60 km/h – 105° and so on till 200 km/h, so I have to
remove 29.3° from all the angles (zero included). The final result is the following analog_speed_curve.lut:
0|0
10|7.7
20|15.1
30|30.3
40|45.7
50|60.5
60|75.7

…plus the other values that I won’t list here for matters of length. It’s a tedious process, but the instrument will be very precise.

CSP ADDITIONS
- The mod brings an entirely new set of instruments to the simulator, all set from the ext_config.ini file (pag.). Unlike vanilla, the system is completely
flexible and allows a needle to visualize almost any kind of information, being linked to a new INPUTs system, very similar to what dynamic controllers use.
You can look at p. for a complete list. In any case, regarding analog dials, summarized below are the most important instruments added:

• Clock
• Battery voltage
• Oil pressure
• Oil temperature
• Ambient (air) temperature

(more details in the future)

- Working analog and digital trip odometers are a feature available with CSP.

FAQ
QUESTION [1]: Having a HUD visible on screen I've noticed that the speedometer is around 50 km/h out at high speed. So while 150+ km/h are displayed
on the HUD, the instrument in the cockpit is showing around 200 km/h. How do I set up the analog_instruments.ini to make it more accurate?
ANSWER [1]: Change the STEP line under [SPEED_INDICATOR] until the needle moves correctly. It should be in degrees/unit, so degree/rpm and
degree/kph.

QUESTION [2]: No matter how much I try, the needle won’t measure right; it is correct on certain numbers while on others it is not, and the STEP parameter
doesn’t fix the problem entirely.
ANSWER [2]: When the needle is not precise on the whole measurement range, a LUT can be employed. Let’s make an example; if you read the RELATED
FILES paragraph, you will know that typically the look-up-table for the speedometer is called analog_speed_curve.lut. Obviously the name can be changed
to your liking, but it’s important to realize that different instruments can adopt the same principle. Just add a LUT line in the respective section and configure
it properly (the input values will always be the units measured by the instrument, the outputs will be the angle travelled by the needle).

357
6. blurred_objects.ini
The visuals of wheels spinning at high speed are artificially recreated swapping the fully detailed rim meshes (RIM_LF) with other ones less detailed, that
have a lower polygon count and blurred textures (RIM_BLUR_LF); the switch happens depending on different car speeds.
The following script controls at what velocities of the car an object will appear or disappear.
[OBJECT_0] ; Object identifier; SYNTAX: [OBJECT_ID].
WHEEL_INDEX=0 ; Indexes of the wheels as defined below.

% ▲ AVAILABLE WHEEL INDEXES:

0 = LEFT FRONT
1 = RIGHT FRONT
2 = LEFT REAR
3 = RIGHT REAR

NAME=RIM_LF ; Name of the mesh/object, or of the parent NULL/dummy (look at null hierarchy).
MIN_SPEED=0 ; Minimum speed the object is visible at. [Km/h]
MAX_SPEED=40 ; Maximum speed the object is visible at. [Km/h]

[OBJECT_1]
WHEEL_INDEX=0
NAME=RIM_BLUR_LF
MIN_SPEED=30
MAX_SPEED=10000

% ▲ You’ll never be able to go this fast, so this value is high to keep the blurred rims active at “normal” speeds. If you add more of them, you’ll have
to lower this number for the meshes that should be visible at rotational regimes between your RIM and the RIM_BLUR with the most blurred texture.

[OBJECT_2]
WHEEL_INDEX=1
NAME=RIM_RF
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_3]
WHEEL_INDEX=1
NAME=RIM_BLUR_RF
MIN_SPEED=30
MAX_SPEED=10000

[OBJECT_4]
WHEEL_INDEX=2
NAME=RIM_LR
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_5]
WHEEL_INDEX=2
NAME=RIM_BLUR_LR
MIN_SPEED=30
MAX_SPEED=10000

[OBJECT_6]
WHEEL_INDEX=3
NAME=RIM_RR
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_7]
WHEEL_INDEX=3
NAME=RIM_BLUR_RR
MIN_SPEED=30
MAX_SPEED=10000

LITTLE EXPLANATION
- You can use more than one RIM_BLUR mesh per wheel, so you’ll have smoother transitions, for example with 2 or 3 objects. There’s a lot of space for
implementations. There should be no limit in the number of objects you can put here, so have fun! Be careful with the speeds at which each model transitions
into another, those give you some span for the smoothest result, and keep in mind that the script is just for cosmetic purpose, it doesn’t affect physics.
- You can even enter the names of objects completely different from rims, in order to make them appear/disappear whenever you like. This is what I call
moddability!
- Here is an example of what a blurred rim is made of: a basic mesh with a texture (Fig.).

Fig. – (left) The original wire-spoked rim and the blurred rim mesh with texture applied (no transparency displayed here). Notice how the hub cap was not included in this example. (right)
The car of this example is an open wheeler, thus it is necessary to create four meshes: two for either side, and one of each side with normals flipped in order to make the rows of spokes
visible from both sides of the wheel (this is due to backface culling).

Typically for a blurred rim mesh is necessary to make a simple hollow cone, for special designs and for wheels with hub caps however it may be necessary
to create a more complex geometry; in the example of Fig. the cap was not included due to personal choices (I manage the cap with a different blurred object).

358
The textures can be made very simply by rendering the rim with a light shone directly in front of it, with a transparent background (Fig.). Save the render as
RGBA image to preserve the alpha channel (transparency).

Fig. – Render the rim with Cycles if you use Blender. It doesn’t really matter how bright is the light, as the diffuse can be adjusted in ksEditor later. What’s important is the angle, that
must be perpendicular to the rim circumference plane. Notice how only half of the wires are present, and a huge chunk of the center hub is hidden; that’s because of the technique to
avoid backface culling for open wheelers. You don’t want to double the amount of wires you see in the final result.

Then you take the render, modify it with an image editor like Photoshop make the texture semi-transparent (reduce opacity to 70-80% on the Layers tab) and
add a Spin Blur effect to the rim. That will do the trick.
If you want something more advanced, you can enable the Motion Blur in the Blender Render settings and create a fast rotation animation: the frames will
already portray a blurred wheel. It should be more accurate than the Spin Blur, as you can tune with the timeline how many rotations per second you want the
rim to make, so you can calculate and set the correct switch speed within blurred_objects.ini (thus obtaining optically based effects). It will be much more
accurate, as within Photoshop you can specify any Spin Blur rotation angle without any criteria, while this takes advantage of the Cycles render engine.
Alternatively, you can mix both techniques, like I did in Fig..

Fig. – The first texture on the left was made with Blender’s motion blur and chroma key; the second and third texture are the result of the Spin Blur in Photoshop.

For the shading, in ksEditor you can use the ksPerPixelAlpha shader or another shader with transparency capability; within the SDK editor it’s important to set
the BlendMode parameter to eAlphaBlend, otherwise you will have some trouble with eAlphaTest selected by default.

359
CURIOSITIES AND AMENITIES
There are a couple theories about rim blur:
The first one suggests to avoid it. The main arguments in favour of this philosophy are the following:
1. Blur exists because in old games the frame rate was too low to have the wheels appear rolling smoothly, or even calculating the mesh rotation was too much for the
hardware. Ten years ago a nicely detailed wheel could be modelled, but having to compute all those polygons moving together was too expensive in terms of resources.
2. Screenshots aren’t rendered in real-time and any amount of post-processing can be applied. Rim blur saves sometimes a lot of polygons, especially when activated over
high poly wheels, but it doesn’t improve the graphics, as you are looking through a virtual camera, so the 'walking' or ‘stepping’ effect you see is exactly what you would
see in a real replay. Then it is more like another LOD (info about LODs) that lessens the strain on our device, so you can ignore it completely if your rims are simple.
3. It's added complexity, adding it means you need to make sure that blurred_objects.ini is correct, make sure all the materials/textures/shaders are set right and then edit the
textures in Photoshop with radial blur. Deleting everything to do with them takes 1-2 minutes, making sure everything works with them, probably about 5-10 minutes.
Removing rim blur means 4 less objects. If you want to paint rims, adopting blur objects you would need to paint both the RIM and the blur or make a new blur texture
which implies mapping the rim. In vanilla AC the rim blur also keeps being visible if you're in photo mode and set shutter speed to zero, making the car look still but with
blurred rims.
4. Often the transition between blurred/non-blurred state is jarring even at a distance in replays. This is of course subjective and related to specific cars.
The second one suggests to make it. This is why:
1. If Kunos added it, follow their standard. Keep things as simple as possible including everything. It may seem a paradox, but if you do things right from the beginning, other
people won’t have to edit your mod afterwards to fix its missing or incorrect parts, so you should worry about it, especially if you don’t want your creations to be modified.
You will notice how well-made mods are often those with the smallest number of edited versions made by people unrelated to the original author.
2. When you do have high poly rims, very performance expensive, you must create a nice lower poly rim and use blurred_objects.ini to define when to switch it in.
3. Nowadays we get so much performance from the hardware that choosing between adding blur or not based on this aspect is just a waste of time, unless you consider
players with less powerful machines. Not everyone can afford high-end PCs.
4. You may want to see the blur during the race because you like the effect, which is realistic from the point of view of the human eye, not from the cameras’ perspective.
After all, if a user doesn’t like it, he can always disable it, changing the values in blurred_objects.ini (if the data is/can be unpacked).
5. Rim blur can help with the immersion and reduce eye strain and motion sickness (especially when considering PP filters, but that is another story).
6. Even if you enable Nice Screenshots and the Photo Mode app in the CSP mod settings, the rims will be blurred correctly only in screenshots, look at the example of Fig.
4.7. Photo mode is accumulative, so it renders frames across a small window of time based on shutter speed, and averages the result. However if you don’t add the vanilla
RIM_BLUR to your car mod, you won’t have the effect during the race or replays.
My conclusion? Do create a good rim blur, especially if you have high-poly wheels. Keep in mind that in cockpit view you’ll never see it again, but you can
at least flex you made it and be satisfied of the result when looking at the vehicle from exterior cameras. The first theory is just an excuse for lazy people. It
takes very little effort to create simple geometries and textures. See the examples of the previous page.

Fig. 4.7 – The result with 1/125 set as shutter speed in the Photo Mode app during replay. You can definitely see the rims have been blurred, even if this car mod has no RIM_BLUR
models (note that the speed is 105 kmh).

360
7. brakes.ini
Without this short config file, your car won’t brake at all (or the game will crash). You can also define the brake disk glow behaviour here.
[HEADER]
VERSION=1 ;

% ▲ VERSION=2 enables temperatures for brakes (with cphys? undocumented)

[DATA]
MAX_TORQUE=1400 ; Maximum brake torque. [Nm]

% ▲ 100% brake pedal input will give you this torque value. This is the resistance made by the brakes on the axle. So it's not really like a real brake
pedal.

FRONT_SHARE=0.66 ; Percentage of brake torque at front axis.

% ▲ This is the default value for the brake bias. It’s the one you can find in setup screens, if the bias adjustment is available.

HANDBRAKE_TORQUE=1000 ; Handbrake torque (at the rear wheels); 0= no handbrake. [Nm]

COCKPIT_ADJUSTABLE=1 ; 0= no bias control from cockpit, 1= bias control from cockpit.
ADJUST_STEP=0.5 ; Step for bias adjustment from the cockpit (how much each click/button push changes the bias).

[DISCS_GRAPHICS] ; Lines for the brake disc glow at high temperatures.

% ▲ The brake disk glow works only if you applied the ksBrakeDisc shader to your disc meshes (this implies also the textures for disc glow). See par.

DISC_LF=g_Disk_LF ; Specifies the left front disc mesh that will glow.
DISC_RF=g_Disk_RF ; “ “ right front disc mesh “ “ “ .
DISC_LR=g_Disk_LR ; “ “ left rear disc mesh “ “ “ .
DISC_RR=g_Disk_RR ; “ “ right rear disc mesh “ “ “ .
FRONT_MAX_GLOW=60.0 ; Max emission value the front brakes will have at full heat.
REAR_MAX_GLOW=24.0 ; Max emission value the rear brakes “ “ “ “ “ .
LAG_HOT=0.995 ; Amount of filtering interpolation lag used while making the brakes brighten.

% ▲ Refers to the difference in time between when the disc is normal and when it reaches glowing temperature while braking.

LAG_COOL=0.98 ; Amount of filtering interpolation lag used while spinning up the turbo

% ▲ Refers to the difference in time between when the disc is glowing and when it goes back to normal after releasing the brakes.

LITTLE EXPLANATION
- The temperature behaviour of brakes in vanilla is quite lacking.

ABOUT RELATED FILES

Controllers:
ctrl_ebb.ini
This script allows the controllers to change the brake bias.
[CONTROLLER_0]
INPUT=BRAKE
COMBINATOR=ADD
LUT=prop_valve_r32_brembo.lut
FILTER=0.98
UP_LIMIT=1
DOWN_LIMIT=0.0

FROM ALFA ROMEO GIULIA

[CONTROLLER_0]
INPUT=LOAD_SPREAD_LF ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=ADD
LUT=(|0.3=0.67|0.4=0.66|0.5=0.65|0.6=0.66|0.7=0.67|)
FILTER=0.01
UP_LIMIT=1
DOWN_LIMIT=0.0

[CONTROLLER_1]
INPUT=SLIPANGLE_REAR_MAX ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=MULT
LUT=(|0=1|3.0=1|8.7=1.05|)
FILTER=0.95
UP_LIMIT=1.2
DOWN_LIMIT=0.0

[CONTROLLER_2]
INPUT=BRAKE ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=MULT
LUT=(|0=1|0.1=1.09|1=0.967|)
FILTER=0.95
UP_LIMIT=1.2
DOWN_LIMIT=0.0

steer_brake_controller.ini
This config is used on some Kunos McLaren roadcars only. The script can apply braking to one wheel and is an override for EDL (Electronic Differential
Lock).
It applies rear brake on one side. It’s similar to the F1 fiddle brake but with a controller instead of a manually operated pedal. It is a form of torque vectoring.
The McLaren P1 uses it in real life.
Don't feature it if you plan to use it as an LSD (Limited-slip Differential). Also, this functionality is broken, as it applies braking only to the RR wheel, on both
left and right turns; apparently it’s never applied on LR.
[CONTROLLER_0]
INPUT=STEER_DEG
COMBINATOR=ADD
FILTER=0
UP_LIMIT=1
DOWN_LIMIT=-1
LUT=(-170=-1|-20=0|20=0|170=1)

361
[CONTROLLER_1]
INPUT=SPEED_KMH
COMBINATOR=MULT
FILTER=0
UP_LIMIT=1
DOWN_LIMIT=-1
LUT=(100=0.1|150=0.2|200=0.5)

[CONTROLLER_2]
INPUT=CONST
COMBINATOR=MULT
FILTER=0
UP_LIMIT=100
DOWN_LIMIT=-100
CONST_VALUE=100

CSP ADDITIONS
Custom Shaders Patch adds a new thermal model for brakes, with an object based brake-torque system which requires more configuration and
supplementary lines of code in brakes.ini.

CURIOSITIES AND AMENITIES

Of the dozens of technologies banned by F1’s governing body through the years, McLaren’s rear brake pedal stands out as one of the most unjust.
It was banned early in 1998 as McLaren made a stunningly dominant start to the year. Following a protest by Ferrari the system, that had previously been declared legal, was
outlawed.

Foot operated clutches have been a thing of the past in Formula 1 for many years, so a
drivers footwell typically only features an accelerator and brake. But in the footwell of
Hakkinen’s McLaren F1 car was three pedals; the ‘steer-brake’, the normal brake pedal and
the throttle. The steer-brake pedal was quite stiff and the driver would have to press quite
hard on it to use it. This way, pilots wouldn’t have to worry about tapping it and spinning
out.
The steer-brake pedal operated one rear brake on one side of the car. The side of the car
that it operated changed depending on the race and was decided on a track basis. The
main deciding factor was long high-speed corners in which drivers would normally
experience a high amount of understeer. So if McLaren were set to race on a circuit with a
few tricky righthand turns, the engineers would set up the cars to have the brake-steer
pedal to operate the rear right brake.

“As you applied the brake mid-corner it would brake one of the rear wheels, and as you
didn’t want to slow the car down, you’d open the throttle to compensate.”
“So it was a combination of pressing on two pedals at the same time. In doing that you’re
putting more torque through the outside rear wheel and less through the inside, and that Fig. h - The three pedals–from left to right, fiddle-brake, regular brake, and
puts a yaw moment on the car to steer the car around the corner.” accelerator–of the #8 West McLaren Mercedes MP4/12 F1 car

Not only did the innovation help correct understeer, but it also improved cornering
aerodynamics as the front wheels would be straighter and drivers didn’t have to carry as much front wing on corner entry, making the car more stable.

The pedal allowed the drivers to operate either of the rear brakes independently of the others. This gave them two additional means of controlling the car and improving the
performance – by reducing either understeer or wheelspin depending on which wheel was braked and when.

McLaren continued with the system in 1998 by which time they had leapt from front-of-midfielders to runaway championship leaders. Now their immediate rivals – chiefly
Ferrari – protested the rear brake pedal on the grounds that it was primarily a steering system.
Although the system had previously been passed fit to race by Charlie Whiting the stewards at the Brazilian Grand Prix – the second round of 1998 – ruled against the rear
brake pedal. It was unsavoury to see a perfectly valid system banned on such a dubious technicality when it had been declared legal on other previous occasions. But it was
not the first nor the last time that it happened. It did not stop McLaren from running away with the Brazilian Grand Prix – or from winning both championships that year.

FAQ
QUESTION [1]: Which parameter of which file should I open and modify to increase the braking of a car?
ANSWER [1]: You can increase the MAX_TORQUE in brakes.ini But the braking force is still limited to tire friction. So if you increase it too much you will start
losing grip very easily when braking.

Q [2]: I'm trying to mess with some car values to add ABS to a car that does not originally have ABS. Does anyone know how I can do that? I looked in
brakes.ini but don't really see anything related to ABS.
A [2]: ABS is not under brakes.ini, it’s managed in electronics.ini.

PHYSICS (for brakes.ini)

sdgasghsd

362
8. cameras.ini
This config sets the positions of cameras for the extra views that are activated pressing the F6 key. Imagine each camera represented by a heading
vector. You can easily modify the values in-game using the camera app. More info about it in chapter 6. About the origin of the axis
[CAMERA_0]
POSITION=0,0.92819,-0.34668
FORWARD=0,-0.38871,0.92129
UP=0,0.92135,0.38872
FOV=60 ; Field of View (FOV) of the camera.
EXPOSURE=41
EXTERNAL_SOUND=1 ; select between 0 (off) and 1 (on) to choose between internal and external sound

[CAMERA_1]
POSITION=0.53088,0.51102,-0.065308
FORWARD=0.021429,-0.34203,0.93945
UP=0.0039044,0.93968,0.34203
FOV=60
EXPOSURE=36
EXTERNAL_SOUND=1

[CAMERA_2]
POSITION=-0.2511,0.7385,-0.18799
FORWARD=0.21679,-0.39312,0.89357
UP=0.075636,0.91935,0.38611
FOV=60
EXPOSURE=31
EXTERNAL_SOUND=1

[CAMERA_3]
POSITION=-0.011475,0.68746,0.28223
FORWARD=0.00081515,-0.06956,0.99758
UP=-0.0010552,0.99758,0.06956
FOV=60
EXPOSURE=47
EXTERNAL_SOUND=1

[CAMERA_4]
POSITION=0.51489,0.62795,0.36731
FORWARD=-0.78566,-0.042336,-0.61722
UP=-0.078064,0.99647,0.031015
FOV=70
EXPOSURE=46
EXTERNAL_SOUND=1

[CAMERA_5]
POSITION=0,1.0151,-0.53455
FORWARD=0,-0.36649,-0.9299
UP=0,0.92998,-0.36715
FOV=60
EXPOSURE=26
EXTERNAL_SOUND=1

You can see the standard point of view (official reference positions) for each camera in Fig.. You don’t need to follow an exact order, because the player can
cycle very easily between them. Just be faithful to the standard in the AC content made by Kunos.

Fig. – Here you can see the most important points of view (in no particular order): 1. Top left, the perspective recreates the typical view from F1 footages, when you see the
head of the pilot. In stock cars this camera is located on the roof, slightly looking at the hood. 2. Top right, the wheel view. You can adjust it however you like, just keep the
road ahead widely visible on screen. I have fun trying to drive in this position. Plus on open wheelers it’s nice to see the suspension move. 3. Bottom left, the cockpit cam.
This is aimed at the interior of the car, slightly tilted towards the steering wheel on single-seaters. On two-seater cars, you can place it exactly between the seats, framing the
whole dashboard and the steering wheel. 4. Bottom right, you have the hood cam. It’s very simple to understand.

363
Fig. – These cameras are less important, but let’s take a look at them: 1. On the left you have the pilot’s cam. On single-seaters, it’s located outside the vehicle. On two-
seaters, it’s placed on the dash, looking at the driver and the steering wheel. 2. On the right you have a rear camera. With open-wheelers it’s on the rear wheels, which one
depends on where the exhaust is, to be able to see the flames and bits of suspensions. On stock cars (sedans, coupés, etc.), you shall put it on the trunk of the vehicle,
slightly showing the rear end of the car.

364
9. car.ini
This is a crucial config for the vehicle, because it is general-purpose: it regulates the fundamental parameters for physics and specifies the game UI info.
You can also change the positions of the main vehicle cameras (the ones activated with the F1 key), under the [GRAPHICS] section.
[HEADER]
VERSION=2 ; SYNTAX: [VERSION=1; 2]. Version of the car that AC loads.

% ▲ It does not represent the development version of the car, but how the AC engine will deal with its physics instead. Acceptable inputs are 1 or 2,
with VERSION=1 as the old (first) AC car.ini; VERSION=2 is preferred and recommended, as it introduces various features, for example it adds SHORT_NAME.

[INFO]
SCREEN_NAME=Formula Example 2022 ; Name of the car in UIs, on info apps and to identify it on servers.

% ▲ Upper and lowercase characters may be used alongside numbers; special characters may be limited.

SHORT_NAME=FE 22 ; Abbreviated label used to the name the car in the race session leaderboards. Available if VERSION=2.

[BASIC]
GRAPHICS_OFFSET=0,-0.370,-0.208646 ; 3D axis correction (x,y,z) to move the visual body polygon model in relation to the wheels. [meters]

% ▲ The body is referenced to the center of gravity, or “CG” of the car. This value must be adjusted every time a change to the CG is made.

GRAPHICS_PITCH_ROTATION=0.0 ; Changes the pitch of the visual vehicle body. Values >0 bring the front closer to the ground. [deg]
TOTALMASS=1075 ; Total mass of vehicle with driver, but WITHOUT FUEL. Other types of fluids must be included. [kg]

% ▲ The weight of the driver has to be considered equal to 75 kilograms, no more and no less.

INERTIA=1.0,0.8,2.80 ; Dimensions of a box with same moments of inertia (x,y,z) of the vehicle sprung mass. [m]

% ▲ A solver to solve for sprung inertia from total car inertia is available in the attachments of the manual. Typical values are smaller than the
physical constraints of the vehicle.

[EXPLICIT_INERTIA] ; Optional section, introduced with AC 1.15.

INERTIA=1300,1400,500 ; Enables direct input of inertia values and overrides the box inertia parameter.

[GRAPHICS]
DRIVEREYES=0.484284,0.81469,0.165061 ; 3d axis placement (x,y,z) of driver eyes (POV). [m]
ONBOARD_EXPOSURE=28 ; Onboard camera exposure for HDR.
OUTBOARD_EXPOSURE=31 ; Outboard camera exposure for HDR.
ON_BOARD_PITCH_ANGLE=-9.583473 ; Onboard driver eyes pitch angle relative to the horizon. [deg]
MIRROR_POSITION=0.0,0.6,0.5 ; Position used for the rendered mirror views.
VIRTUAL_MIRROR_ENABLED=0 ; Sets the virtual mirror to permanently enabled (=1) or disabled (=0). check
SHAKE_MUL=2 ; Camera onboard G forces multiplier
USE_ANIMATED_SUSPENSIONS=0 ; Use animated suspensions (1) or not (0). Animated suspensions will not be updated in real time from
setup changes.
FUEL_LIGHT_MIN_LITERS=12 ; Minimum fuel load to activate the Fuel indicator icon

% ▼ With the next few parameters you can set the positions of the main vehicle cameras.

BUMPER_CAMERA_POS=0.010,-0.239,0.910 ; Bumper camera position. [m]

BUMPER_CAMERA_PITCH=-2.990 ; Bumper camera pitch angle. [deg]
BONNET_CAMERA_PITCH=-14.998 ; Bonnet camera pitch angle. [deg]
BONNET_CAMERA_POS=0.000,0.940,-0.330 ; Bonnet camera position. [m]
CHASE_CAMERA_PITCH=0 ; Chase camera pitch angle. [deg]

[CONTROLS]
FFMULT=4.444 ; Force Feedback power multiplier.

% ▲ Controls the car-specific gain for the Force Feedback, from now on referred to as “FFB”. Steering forces are generated via simulation of forces at
the rack-end positions and depend on the situation of the car and relevant suspension geometry.

STEER_ASSIST=1.000 ; Variable steer assist, speed relative.

% ▲ It’s a gamma function for load-based effects of FFB. It does NOT determine power steering or anything similar. Values other than 1.0 should generally
be avoided. The default setting is 1.0, or linear.

% Think of it like a gamma curve for steering force. Lower values amplify low forces (I think at 0 it just means constant force steering). Only deviate
from a value of 1 if you know your steering system isn’t linear.

STEER_LOCK=440 ; Real car's steer lock from center to right. [deg]

% ▲ Controls the in-cockpit steering wheel rotation of the car physics. It must be input in as the real-world value. It’s not required that it matches
the user’s simulation peripheral wheel maximum rotation. The input is from center to one side, so divide the total range by 2 to solve for STEER_LOCK.

STEER_RATIO=12.0 ; Effective steering ratio of the vehicle, used in solving the roadwheel’s steering angle.

% ▲ The real-world rack’s value should be entered if unsure.

LINEAR_STEER_ROD_RATIO=0.0038 ; Because of AC complex suspension geometry, you need to calculate manually this value.

% ▲ This line is used to calculate the roadwheel’s steering angle. Change the sign of the value (from positive to negative or vice versa) if the car
steers in the wrong direction, as it is dependent on the location of the steering rack, in front or behind the wheel center. The definition is meters of
rack travel per degree of steering wheel steering * STEER_RATIO. See the LITTLE EXPLANATION section for more details on how to determine this parameter.

[FUEL]
CONSUMPTION=0.025 ; Fuel consumption in litres per second, expressed as a function of (rpm*gas*CONSUMPTION)/1000. [L/s]

% ▲ If you don’t have data, you can estimate the fuel consumption. Good sources are the race leaderboards. Read the LITTLE EXPLANATION and FAQ sections
for more info.

FUEL=50 ; The amount of fuel the car loads in game with at the beginning of every session. [L]
MAX_FUEL=100 ; Fuel tank capacity. [L]

[FUEL_EXT] ; Vanilla section.

KG_PER_LITER=0.87 ; Option for different fuel density, introduced with AC 1.14. [kg/dm^3]

[FUELTANK]
POSITION=0,0.12,-1.72 ; Position of fuel mass (tank) from CoG (Center of Gravity). [m]

[RIDE]
PICKUP_FRONT_HEIGHT=0.00 ; Height of the front ride height pickup point. [m]
PICKUP_REAR_HEIGHT=0.00 ; Height of the rear ride height pickup point; same as the front. [m]

% ▲ These lines act as reference point for the ride height values shown inside the setup screens. They are also used for the ride height rules. They’re
referenced from CG. They do NOT control anything related to the physics.

The values are positive upwards, and set the height at which the ride height is measured for the rule compliance. Measured from the centre of gravity at
that end of the car. So the height above the ground would be RADIUS + BASEY + PICKUP_FRONT_HEIGHT.

[RULES] ; Setup height rules.

MIN_HEIGHT=0.010 ; Minimum front/rear allowed setup ride height, determined by the lines under [RIDE]. [m]

% ▲ If your setup of the car goes under the minimum height, the Drive button will be disabled after a short 5-second check. You can also set this to 0.0
for no ruling.

365
% Including the MIN_HEIGHT line in your script is not recommended due to some issues with the ground plane calculation.

[PIT_STOP] ; Pit stop timing parameters.

TYRE_CHANGE_TIME_SEC=2 ; Time spent to change all tires. [s]
FUEL_LITER_TIME_SEC=0.05 ; Time spent to pour/pump 1 litre of fuel in the fuel tank. [s]
BODY_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the body damage. [s]
ENGINE_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the engine damage. [s]
SUSP_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the suspension damage. [s]

LITTLE EXPLANATION
- car.ini shall be the first config you work on. It’s the fundamental one, so you better start from it.

- Since you may be at the beginning and that is a delicate phase, we will write this here so you can’t forget. Don’t use the graphical offsets in
suspensions.ini, set those to 0. Use the offset in car.ini which moves the 3D model relative to the centre of gravity. If the suspensions aren’t located
correctly, it most likely means you placed the SUSP dummies the wrong way.

- The moments of inertia (MOI) of a car influence its cornering behaviour, depending on the engine's position. Not only that. They affect the oscillation of the
entire vehicle, thus the suspension system, and the aerodynamics as a consequence. The bigger is the moment of inertia of a body, the more “resistance” it
will put to any change of direction. We could say that it will require more energy to make it move or rotate and to make it stop. So we can state that everything
regarding the handling is deeply rooted in these physical quantities, which can truly make the difference AT THE FOUNDATION.
How are the MOIs represented in AC then?
CoG and inertia are modeled correctly in AC. The CG position is actually fixed at the 0,0,0 coordinates of the car, you move everything else relative to that.
More info about it can be found in the suspensions.ini config file explanations.
The inertia instead is not calculated by taking the weight and position of every single car part. The actual values are calculated for the sprung masses (i.e., the
whole car body, without the wheels and other suspended parts located at the hubs, often called unsprung masses altogether), based on the dimensions a
solid box of uniform density 58. The dimensions of that box are the (x, y, z) components which you input in the INERTIA line.
The sprung mass is calculated by AC from the TOTALMASS line, subtracting the hub (unsprung) masses specified in suspensions.ini. Unsprung masses
generate their own inertia separately.
Pro tip: with the STRUT suspension type in suspensions.ini, the calculations for unsprung masses are handled differently by AC, you should keep that in mind.

When AC pairing the INERTIA with the sprung mass (body), the result is a massive driveable virtual brick, not a car as we're used to know. It is similar to
the model in Fig..

Fig. – An elegant Alfa Romeo design prototype car along with a box portraying the sprung mass inertia. The respective centres of gravity are displayed (SOLIDWORKS).

There is no problem as far as we drive 1-ton bricks around. But how can we describe the inertia of cars and not the physical behaviour of a solid block?
You would need to acquire MOI measurements of the real car, calculate the sprung mass component, then solve for the box that fits the values you get. AC
calculates the MOI from the dimensions of that box, so they need to be representative (the dimensions of the vehicle are not).
Commonly the apparatus used to capture such information is called VIMM, which stands for Vehicle Inertia Measurement Machine. It consists of a
spherically mounted platform where the vehicle is mounted onto, actuated by three hydraulic cylinders (Fig.).

58
In the modding community often called “inertia box” without much afterthought. This can result in misinterpretations, as also the total vehicle inertia can be rendered with an inertia box, taking in
account both sprung and unsprung masses. The latter being a standard practice in vehicle literature, research and testing facilities, always make clear if the MOIs in question are sprung or total.

366
Fig. – MOI and CG measurements for a Tesla Model 3 and a BMW i3.

Within a specific test procedure which includes stationary and dynamic measurements (Fig.), it can be determined the position and height of the center of
gravity, as well as the principal mass moments of inertia for pitch, roll and yaw motion.

Fig. – Dynamic tests are performed by continuously rotating the entire vehicle of a certain number of degrees on the bench. The rotation is periodic, clockwise and anticlockwise, that’s
why the graphs are sine waves.

There's a small set of cars with actual inertia measurements but it's only done by pretty large organizations since the measurement rig is a million-dollar item,
and of those, NHTSA (US National Highway Traffic Safety Administration) is about the only one posting them in public journals.
Even the best AC modders do rarely (if ever) have the occasion to find real values.
But if you don’t have data, you need to guess close enough then correlate from telemetry. Kunos developers stated:
“The calculations inside AC are made in a way that if you put the rough dimensions of the car in the INERTIA line, you can get pretty good behaviour”. (Aristotelis Vasilakos,
2015)
I have to say that this tip should be taken with a grain of salt. You definitely must NOT input in the car dimensions, but anything you will add, subtract or
entirely replace will be based on how much accuracy you want to get.
Starting with coarse approximations, automobiles with the engine further away from the center of the overall sprung mass will have a bigger inertia box, due
to a higher MOI. Mid- and rear-engine cars should have the third value smaller than the car's length.
A “decent” approximation is done with values that are 80% of the vehicle size. That’s just how big real inertia measurements suggest the box should be.
With the amount of variance between regular cars you're not going to be more than around 10-20% wrong.
Kunos advices a box longer than the car for automobiles with the engine at the front/rear or a similar weight distribution, and a box smaller than the car for
vehicles with the engine in the middle. Then, in-game open the CAR PHYSICS dev app and check the "DINDEX" value. This is a perfect help to better
understand how to setup the car in terms of inertia.
There are so many factors that go into figuring out what uniform density box would fit the car, that getting an accurate estimate is almost impossible, due to
cars obviously not being a box, different parts having different density and consequently weight, for example chassis, engine, transmission and fuel tank being
far heavier than the body, as well as the roof being much lighter than the lower panels, especially in race cars.

367
The aforementioned method is just for guessing: it is not the best solution, unless you have telemetry data to make appropriate comparisons; in reality there
is no limitation on how AC works with inertia, it behaves correctly as long as you enter the numbers for only sprung mass correctly. Thus, if you're more
advanced, you can have other options:
1. Calculate all the inertias for every single part of the car with whatever program or method you want to use. Typically it can be done very easily if you have a full 3D model
in an industrial CAD software. Get the values, convert them to the dimensions of a box with the MOI formulas 59 and input them into the INERTIA line.
2. Measure the MOI by yourself on a rig. If you manage to, create a 3D box with the same inertias with the MOI formulas, and input its dimensions in the INERTIA field.
3. Adopt one of the standard estimation methods based on the total vehicle inertia. Look at the PHYSICS section (pag.) for more details.
Inertia is something you either have data for or you don't. If you don't, it is fine to continue using the estimates; it's usually fairly close anyway...it is the
standard option when working with the config files, because inertia measurements are rather rare, and the databases are few.
The official Assetto Corsa cars by Kunos shouldn't be the gold standard to follow for the values... inertia is nowhere near close enough, and it gets worse
the more compact the car is internally. Some of the KS racing cars have up to 90% error per axis in their sprung MOI. That is, their MOI is 90% higher than
the correct value.
For an example of inertia that's far too high, the Kunos Toyota TS040's inertia box is 30% too large on the x-axis (41 cm), 72% too large on the y-axis (44
cm), and 19% too large on the z-axis (72 cm). Imagine this, compared to a car that had less engineering knowledge and far lower budget put into it. For the
BMW M4 indeed, the values input by the devs are totally identical to the real vehicle’s dimensions. And that’s wrong.
- Usually low-quality drift car mods tweak the inertia parameters to make the vehicles a joke to drift, and that’s completely unrealistic; you see, when you
have an inertia box the size of a truck it’s pretty easy to predict the behaviour of the car and counter-steer accordingly.
On average drift car mod packs are not accurate in terms of physics. 5-6 meters of inertia box are pretty common on these mods.
- Technically if you owned the vehicle and had a lot of time you could build yourself a ramp with wood (Fig.) and place scales on the corners of the car to
measure the weight distribution and calculate the CG height.

Fig. – Example of a wooden ramp for vehicle repairs, along with the respective schematic diagram. Everything is held together with threaded connections.

You measure the difference in corner weights and do some maths; it’s the only method of measuring CG that you can do at home.

59
You can do it with the spreadsheet in the attachments of this manual.

368
- Keep in mind that fuel affects inertia by being a mass placed at the location of the fuel tank set in car.ini. I don't know offhand if it has a specific
dimensional inertia box as well, I'd guess no. Even a point mass that's rigidly fixed to the body affects its overall inertia so it's just implicitly added that way.

- If you work in an engine analysis lab and you know how many litres does your vehicle burn per second (instant fuel consumption), you can use the
following formula to obtain a CONSUMPTION value:
1000 ∙ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐
𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 =
𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔
Where 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 is how many litres per second the car burns (aka the fuel consumption), RPM is the rotational regime of the engine and gas is the throttle input
in percent (so in the formula for example 10% is 0.1 and 90% is 0.9).

This will not be very useful if compared to the data you typically find published for vehicles. While in a race on track it can be somewhat important, time is
often irrelevant when talking about commuters that need to go from point A to point B efficiently and economically. Usually when the salesman compares
automobiles in salons, we find more practical to know about relationships of fuel per fixed distance (litres per 100 km), or distance per fixed fuel units, the
famous km/litre, or miles per gallon ratios (reminder that AC adopts SI units, so any conversion is on you).
If you have this type of data available, there is only one method to set up fuel consumption in our simulator, and that is by recreating, or at least estimating
the test conditions of the data you have, then see how much fuel is burned by the car with the in-game apps, and calculate the real fuel consumption in
conjunction with CONSUMPTION values that you’ll have to tune by hand to get the desired 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 .
For example, considering the EPA (United States Environmental Protection Agency) highway cycle tests, you’ll have to drive your car in-game for the length
of the real fuel consumption test (10~20km) at the speed it was done (70~100 km/h) and see how much fuel the car uses, then apply the following
formulas:
𝐹𝐹𝑛𝑛 ∙ 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 1 𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔
𝐹𝐹𝑛𝑛 ∶ 𝐿𝐿𝑛𝑛 = 𝑥𝑥 ∶ 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 ⇒ 𝑥𝑥 = ⇒ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 ∙ 𝑥𝑥 ∙ ∙ ∙ 𝐵𝐵
𝐿𝐿𝑛𝑛 𝑓𝑓𝑏𝑏 1000
You have a proportion, where 𝐹𝐹𝑛𝑛 is the nominal fuel burned by the nominal distance 𝐿𝐿𝑛𝑛 , equal to 100km (litres per 100 km); 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 is the length of the real fuel
cons test (usually 10km), or your estimate of that distance. The unknown 𝑥𝑥 is to be multiplied by CONSUMPTION and 𝑓𝑓𝑏𝑏 (the fuel burned in-game) to know
what is the actual 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 of the vehicle simulated. 𝐵𝐵 is the turbo boost (if separated from the engine data, otherwise ignore it).
Pro tip: in AC boost simply multiplies fuel consumption. If your car has got a turbo fitted but you have data for the NA engine only, since B must be present in the equation
you need to know what boost the turbo creates at the reference RPM/gas (throttle %). In case the engine specs take in account boost already, this is not necessary.

Example: consider a car with a NA engine that consumes 6.4 litres (𝐹𝐹𝑛𝑛 ) per 100km (𝐿𝐿𝑛𝑛 ). It revs to 6400 RPM. Drive it for 20 km at steady state (without
changing the throttle input) on a very long flat, straight track (see test tracks) and watch how much fuel it uses, then multiply your template CONSUMPTION
0 𝑖𝑖
value by 𝑥𝑥 = 6.4⁄(100⁄20) when calculating 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 . Once you obtain a preliminary 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 , adjust the CONSUMPTION, until your definitive 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 will
correspond to the real-world data .60

There's no other effective way to calculate your fuel cons, unless it's a race car in a series with regulated fuel flow (e.g., F1 or LMP1), in that case refer to
QUESTION [3] of the FAQ.
Alternatively look at pag. for an engineering evaluation of fuel consumption.
- None of what AC's fuel consumption does is realistic in terms of efficiency.
- About the optional KG_PER_LITER line: it allows to specify the fuel density. By default AC uses the 0.75 kg/dm3 density of a 95 octane gasoline.
You can use the table below as a reference guide 61 for the values you can choose. Notice the temperature: fluids typically grow in volume as T increases,
but compared to gases, the effect is negligible. Any difference between leaded and unleaded fuel can be ignored too.
Fuel Density (T=15°C) [kg/dm3] Otherwise, if your car is some kind of prototype running on Vodka or apple cider (???),
Diesel 1D (*) 0.875 there is a pretty simple method to calculate the density ρ. You fill a jerrycan with 1 litre of
Diesel 2D (*) 0.849 fuel and measure its weight 62, then apply the following formula:
Diesel 4D (*) 0.959
𝑚𝑚𝑓𝑓 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 [𝑘𝑘𝑘𝑘]
EN 590 Diesel (**) 0.82-0.845 𝜌𝜌 =
𝑉𝑉
=
𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 ([𝐿𝐿] = [𝑑𝑑𝑑𝑑3 ])
⇒ 𝑉𝑉 = 1 ⇔ 𝜌𝜌 = 𝑚𝑚 (666)
Fuel Oil 0.75-0.94
Gas Oil 0.825-0.90
Where mf is the net mass of fluid in kilograms.
Gasoline (generic) 0.71-0.78
Unleaded gasoline 95 RON (***) 0.720-0.775 This means that the weight measured in kilograms of 1L of fuel is directly its density.
Aviation gasoline (avgas) 0.720
Heavy fuel oil 0.80-1.01 If you want to make the fuel weight nothing, set KG_PER_LITER=0, or a very low
Kerosene 0.775-0.84 fraction (0.0001). Useful for electric vehicles. Else, if the line is not present, AC will keep
Natural gas 0.0007-0.0009 the default.
Propane 0.0017
- About STEER_RATIO: the steering ratio is the number of degrees turned at the steering wheel divided by the number of degrees the front wheels are
deflected:

60 𝑖𝑖
The i symbol in 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 represents the indefinite number of adjustments you’ll have to do.
61
All data from https://www.engineeringtoolbox.com/fuels-densities-specific-volumes-d_166.html, except where indicated. RON is a standard for fuel octane. (*) Diesel fuels are in USA broken up into 3
different classes: 1D, 2D and 4D. The difference between these classes depends on viscosity and boiling point ranges. 4D fuels tend to be used in low-speed engines. 2D fuels are used in warmer
weather. 1D is preferred for cold weather as it has a lower viscosity. (**) The EN 590 is an European diesel standard from 2005. (***) Courtesy of Türkiye Petrol Rafinerileri A.Ş.
62
What we are interested in is the net weight of the fluid, not its container, so use a scale with a tare zero function, or weigh the jerrycan first (especially if it is made of metal) and calculate the
difference when the fuel is inside.

369
 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 [°]
𝑆𝑆𝑟𝑟 =
𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒′ 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 [°]
So for example, if the steering wheel is turned 30° and the front wheels only turn 1°, that gives a Sr of 30:1. For most modern cars, it is between 12:1 and
20:1. This, coupled with the maximum angle of deflection of the wheels gives the lock-to-lock turns for the steering wheel. For example, if a car has a
steering ratio of 18:1 and the front wheels have a maximum deflection of 25°, then at 25°, the steering wheel has turned 25°x18, which is 450°. That's only
to one side, so the entire steering goes from -25° to plus 25° giving a lock-to-lock angle at the steering wheel of 900°, or 2.5 turns (900° / 360).
Since we’re on topic, here’s how to set up the steering ratio/steer lock for your vehicle in AC:
1. Create your suspension geometry and just copy the values for steering from the formula_k car.ini template.
2. Set your STEER_RATIO= value from real-world data.
3. Enter AC with developer apps enabled, launch a session and open the Suspensions dev app.
4. Turn your steering wheel at 90 degrees (left or right doesn't matter).
5. Check on the aforementioned app the steering ratio line (STR, see pag.). That is your current steering ratio.
6. Modify the LINEAR_STEER_ROD_RATIO value (with small changes, like 0.00005 at a time), until the in-game STR and car.ini’s STEER_RATIO values are similar. This
implies restarting the session various times (until you’re satisfied), as the car must be reloaded.

Variable steering ratios?

- Frame rigidity: Assetto Corsa does simulate the frame/chassis/uni-body as a single rigid entity, but it doesn’t acknowledge that it flexes.

CSP ADDITIONS
- The mod adds the following values to car.ini, that must be present if you want to use any features of Custom Shaders Patch’s extended car physics for
your vehicle. It allows to make sure everybody is racing in the same conditions.
[HEADER] ; Vanilla header.
VERSION=extended-1 ; Version of the car that AC loads. Inputs: 1, 2, extended-1, extended-2

% ▲ With CSP, extended-1 or extended-2 values may be used instead of the vanilla ones (1, 2) and are necessary to enable extended physics features (rain
physics… etc.), from now on referred to as “cphys”. Recommended input is extended-2 if your car is RWD or AWD. extended- can be considered a prefix.

The idea is that vanilla AC would crash if it encountered these VERSION values, because it can’t parse them as integers. CSP on the other hand catches
them, stops AC from crashing and marks the car being loaded to use extended physics on it.
- Also, since release 1.74, a car can be locked to adopt a specific CSP version with the following lines:
[HEADER] ; Vanilla header.
VERSION=extendedV1 ; The param can still have 1 or 2 at the end to reflect vanilla values. Inputs: extendedV1, extendedV2

[_EXTENSION]
REQUIRED_VERSION=2142 ; Internal development code number of the CSP release.

% ▲ This example is using the 1.79 CSP release code as an example.

The code number above can be found easily in Content Manager > Settings > Custom Shaders Patch > About & Updates > Shaders Patch version ID (Fig. ).

Fig. – The Shaders Patch version ID is what you’re interested into.

Otherwise, if you don’t have CM, you can look in the mod’s files, specifically data_manifest.ini, under %root%\assettocorsa\extension\config, that has the
following section:
[VERSION]
; hidden
SHADERS_PATCH=0.1.80-preview115
SHADERS_PATCH_BUILD=2260

CURIOSITIES AND AMENITIES

- Originally one of the Kunos developers’ ideas for the PICKUP_FRONT_HEIGHT and PICKUP_REAR_HEIGHT values was that sparks would spawn when
this plane touched ground. Sadly this feature was not implemented, but CSP brought it to AC (probably with other methods).
There's a sparks.ini file in the install folder (with many parameters). So it's obvious that the engine can do it, in some way.
And yeah, the sparks you see in the vanilla launcher intro and in the launch trailer (Fig.) is just a video effect. Stefano Casillo said on Twitter:
“Added in video post-production. We have sparks in AC but they've been broken for ages, don’t know if I'll be able to fix in time.”

370
Fig. – Case closed. Actually no, because the Tech Preview DID HAVE sparks.
He also said that it was about car-to-car contact that they left them out, because it wouldn’t look right:
“At the beginning of the AI development in the Early Access, especially on grid starts like in Monza, they were hitting each other all the time, so it was this ridiculous
situation when you had sparks everythere” (Stefano Casillo, 2015)
The code was improved, however the feature never made it to the final game. Another problem was the additional replay data required. But with vfx in the
trailer it’s cheating! Kunoooooooos...

- The 1.15 version of AC added some optional physics parameters for modders. Of those, one was the [EXPLICIT_INERTIA] section, originally
recommended for use with real life inertia data, where the MOI of the vehicle could be input directly.
This is how it looked like:
[EXPLICIT_INERTIA] ; Required header.
INERTIA=1300,1400,500 ; This code enables direct input of inertia values and overrides the box inertia parameter.

Sadly this feature never worked: the code is still present, but I personally tested in 1.16.4 and even in the old 1.15; the inertia of the car goes to zero and
some errors happen. However it’s the proof that from the point of view of real-world values, AC does not have any limitations.

FAQ
QUESTION [1]: Is there a deadzone in the AC’s steering system?
ANSWER [1]: Unless you’re talking about controller settings, there's no deadzone in the AC physics... just raise the steering ratio and you'll get slower steering.

Q [2]: How can I change the ride height of my car?

A [2]: This question begs for more clarification: which height do you want to change, visual or physical? Changing the visual height is a black magic trick, as
the only thing that moves is the car model and everything attached to it, with the offsets inside car.ini. Modifying the physical height instead is what the
mechanic would do to obtain a higher or a lower suspension: you change the ROD_LENGTH in suspensions.ini.

Q [3]: How can I estimate the vehicle’s fuel consumption in a crazy way? I’m desperate.
A [3]: I have a method that should be quite good. It’s not the best, nor the correct way (since AC’s fuel consumption is instant, not average), but it kind of
works if you want to make a very rough estimate (it can be quite good actually). It requires you to know: the length of a race your vehicle took part in, how
much time it took to complete it, the race homologation regulations, and the capacity of the fuel tank (as counterproof).

Now we’ll understand how to proceed with an example. Let’s consider a pre-war vehicle, like the Alfa Romeo P2. There isn’t much data available for this car,
let alone the fuel cons, but we know for sure that it took part in a race on the 9 June 1924 on the Cremona Circuit (Fig.), which is 320km long, and it took 2
hours and 2 minutes.

Fig. – This table comes from Wikipedia, the free encyclopedia.

We know that our fuel tank is 145 L of capacity. This is what we take for granted. We can then take a look at the race regulations per year; the closest I
managed to find with fuel consumption specs is for the 1913 Grand Prix and it consists of 20 litres per 100 km (Fig.).

371
Fig. – From this website: http://www.kolumbus.fi/leif.snellman/gpw5.htm. Very nice info.

Now we know: 320 km of track divided by 100 km gives you 3,2. Multiply it by 20 litres and you get 64 L of gasoline. This is totally possible, because the
car tank is bigger. That’s why knowing its capacity is useful, to compare our result. We can also use longer races and think about the refuelling methods
practiced back in the day.
Anyway, on that infamous day the race took 2 hours and 2 minutes, so let’s convert this amount in seconds:
2ℎ 2′ = 122′ = 122′ ∙ 60′′ = 7320𝑠𝑠
So on average the fuel consumption per second is:
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 [𝐿𝐿] 64
= = 0,00874 [𝐿𝐿/𝑠𝑠]
𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 [𝑠𝑠] 7320

Now we will put this number in the CONSUMPTION formula as 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 :

1000 ∙ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 1000 ∙ 0,00874
𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 = = = 0,00273
𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔 4000 ∙ 0,8

where I estimated the RPM to be at 4000 and the gas at 0,8 on average during the race. gas is once again to be considered a percentage of throttle input,
where 1=100%, so 0,8=80%. I believe the driver was quite aggressive and heavy on the pedal. Probably more, probably less, who knows.
The Alfa P2 could rev up to 5500 RPM, and I don’t think it has had been pushed to the maximum on the Cremona circuit. This is my reasoning.
Even if the race regulations in 1924 would have had been limited to 10 litres per 100 km, or 30 litres per 100 km, we would get a range between 0,0014
and 0,0041, so you already have a tight enough margin of error.

The value we obtained is quite plausible, especially if compared to other mods of vehicles of the same period. We can use it as our CONSUMPTION inside
car.ini. You can always decide for an optimistic or pessimistic estimate if you don’t like it, and personally that’s what I will do.
The difficult part is finding the correct homologation rules for the race you consider, and considering the right RPM and gas values. But with some
experience this process can be much more accurate than using random numbers. Happy now?

372
PHYSICS (for car.ini)
Since car.ini involves some general concepts around car dynamics, we will try to explain how things work the best way possible.
Let’s start with the things that you should absolutely get right first.

1.0 - Centre of gravity (CoG)

1.1 - What is a centre of gravity?

It is a point, near or within a body, through which its weight can be assumed to act when considering forces on the body and its motion under gravity. This
coincides with the center of mass in a uniform gravitational field.
In physics, the center of mass of a distribution of mass in space (sometimes referred to as the balance point) is the unique point where the weighted relative
position of the distributed mass sums to zero. This is the point to which a force may be applied to cause a linear acceleration without an angular acceleration.
Calculations in mechanics are often simplified when formulated with respect to the center of mass. It is a hypothetical point where the entire mass of an object
may be assumed to be concentrated to visualise its motion. In other words, the center of mass is the particle equivalent of a given object for application of
Newton's laws of motion.

In the case of a single rigid body, the center of mass is fixed in relation to the body, and if the body has uniform density, it will be located at the centroid. The
center of mass may be located outside the physical body, as is sometimes the case for hollow or open-shaped objects, such as a horseshoe. In the case of a
distribution of separate bodies, such as the planets of the Solar System, the center of mass may not correspond to the position of any individual member of
the system.

The center of mass is a useful reference point for calculations in mechanics that involve masses distributed in space, such as the linear and angular momentum
of planetary bodies and rigid body dynamics. The center of mass frame is an inertial frame in which the center of mass of a system is at rest with respect to
the origin of the coordinate system.

1.2 - Vehicle CoG and handling properties

The following are important variables in vehicle engineering:

• The vehicle centre of gravity V
• The body (sprung-mass) centre of gravity Bo
• The axle (unsprung mass) centres of gravity 𝑈𝑈𝑓𝑓 or 𝑈𝑈𝑟𝑟 .

The distance of the centres of gravity V and Bo from the front or rear axle and their height above ground are crucial for:
• Braking and acceleration capacity;
• Calculating the climbing ability (not required for AC);
• Designing brake systems and four-wheel drives;
• Designing body centre of gravity and aspects of vibration stability;
• Driving stability investigations;
• Determining mass moment of inertia (the most important part).

Low centres of gravity are always desirable, as they are associated with fewer driving dynamic problems and increased vehicle performance during cornering
and braking, but in practice the design options are relatively restricted.
The position of a vehicle centre of gravity V and the body centre of gravity Bo is highly dependent on the load; when people get into the vehicle or luggage
is loaded in the boot or onto the roof, the centre of gravity changes vis-à-vis the empty condition, both in the longitudinal direction (x-axis) and upwards (z-
direction). The body lowers when it is loaded, i.e. its centre of gravity Bo drops.
The centre of gravity of the people and, in particular, that of the luggage carried on the roof, is higher than that of the body so the end result is usually a
higher overall centre of gravity V (distance ℎ𝑉𝑉 , Fig.XXAN).

Fig. XXAN- Designation of the paths for determining the centres of gravity V of the overall vehicle and Bo of the body. The centres of gravity 𝑈𝑈𝑓𝑓 and 𝑈𝑈𝑟𝑟 of the front and rear axles can
be regarded as being in the centres of the wheels.

373
1.3 - Calculating the vehicle centre of gravity

Calculating the position of the centre of gravity is likely to be possible only with great difficulty and considerable effort. If the vehicle and all its individual
components are shown on a computer in the form of a digital model including body surfaces and properties (digital surfaced model), modern CAD/CAE/CAM
tools make it possible to calculate the position of the centres of gravity of the components and the whole vehicle.
It is much simpler to determine the position experimentally by weighing.

1.4 - Centre of gravity distance to front and rear axle

Fig.XXAN contains the paths and angles necessary for calculating the centres of gravity and Fig. 3.3 the position of the coordinate system. When the vehicle
is weighed, it must be standing on a completely horizontal plane and with each axle on a weighbridge. So as not to distort the weighbridge, it must be
possible to turn the wheels freely. The weighed front axle load 𝑚𝑚𝑉𝑉,𝑓𝑓 and the rear axle load 𝑚𝑚𝑉𝑉,𝑟𝑟 give the total weight 𝑚𝑚𝑉𝑉,𝑡𝑡 of the vehicle in kilograms:
𝑚𝑚𝑉𝑉,𝑡𝑡 [𝑘𝑘𝑘𝑘] = 𝑚𝑚𝑉𝑉,𝑓𝑓 [𝑘𝑘𝑘𝑘] + 𝑚𝑚𝑉𝑉,𝑟𝑟 [𝑘𝑘𝑘𝑘]
The balance of moments around 𝑚𝑚𝑉𝑉,𝑓𝑓 or 𝑚𝑚𝑉𝑉,𝑟𝑟 , in conjunction with the wheelbase 𝑙𝑙 in the longitudinal direction, gives the centre of gravity distances 𝑙𝑙𝑓𝑓 to
the front and 𝑙𝑙𝑟𝑟 to the rear axle:
𝑚𝑚𝑉𝑉,𝑟𝑟 𝑚𝑚𝑉𝑉,𝑓𝑓
𝑙𝑙𝑓𝑓 = 𝑙𝑙 ; 𝑙𝑙𝑟𝑟 = 𝑙𝑙 → 𝑙𝑙𝑓𝑓 = 𝑙𝑙 − 𝑙𝑙𝑟𝑟
𝑚𝑚𝑉𝑉,𝑡𝑡 𝑚𝑚𝑉𝑉,𝑡𝑡
If the lateral distance of the centre of gravity (y-direction) from the vehicle centre-line is required the wheel loads must be weighed to be able to calculate
first of all the lateral offset of the centres of the front and rear axles from the centre-line via similar equations made up from the rear view, and then similarly
for the vehicle centre of gravity from the top view (see Equations).

1.5 - Centre of gravity height

To calculate hV, first the front and then the rear axle must be lifted as high as possible (by the amount h) with an elevating mechanism (autohoist, jack,
crane), with the other axle standing in the centre of a weighbridge (Fig.). The following would need to be ensured:
• The vehicle must be prevented from falling off by inserting wedges from the outside on the axle to be raised. The brake must be released and the gearbox must be in neutral.
It must be possible to turn the wheels on the platform easily; the platform would otherwise distort and the result be imprecise.
• The wheels are held still on the centre of the platform, the vehicle forward movement must be even when the vehicle is raised, in order to prevent wrong measured values
as a result of different force application positions on the horizontal surface.
• If the change in axle load during lifting is measured by means of a crane over a load cell, it is possible to ensure that the direction of lifting is completely vertical.
• The vehicle should be in the on-road condition, i.e. full tank, tools, spare wheel, etc. (as per the curb weight, see).
• Both axles must be prevented from compressing or rebounding before the vehicle is raised. The locking device must be of an adjustable variety so that the amount by
which the body sinks when there are two or four people and luggage in the vehicle can be taken into consideration.
• To eliminate tyre springing during the measurement, it is recommended that the tyre pressure on both axles be increased to 3.0 to 3.5 bar.
Mathematical observation of the measurement is as follows (Fig.):

Fig. 6.2 - Vehicle on a weighbridge with forces and paths for deriving the equation for vehicle centre of gravity height hV included.

374
2.0 - Mass moments of inertia
From the theory of mechanics it is known that when a body is accelerated in a straight line the inertia Fc is given by
Fc = m ax = mass * acceleration (N)
In comparison to this, in the case of accelerated rotational movement, the acceleration moment is influenced by the rotation mass J.
The rotation mass – equivalent to the mass moment of inertia J (kg m2) and also known as second degree mass moment – is a measure of inertia on
rotating bodies. In vehicles, three important rotational movements occur in the various vehicle conditions, to which the variables of the mass moments of
inertia J are related.
• The vehicle moment of inertia JZ,V around the vertical axis (z-axis, Fig.) is required for driving stability studies or even for reconstructing road traffic accidents.
• The body moment of inertia JX,Bo around the vehicle’s longitudinal axis (xaxis) is essential for generally studying body movement (roll behaviour) during fast lane
changes in the driving direction.
• The body moment of inertia JY,Bo around the transverse axis (y-axis) is the determining variable for calculating pitch vibration behaviour.

In addition to this, in general, the inertia moments of power units (engine–gearbox unit) and individual rotationally symmetrical elements, such as steering
wheels, tyred wheels, etc. are of importance.
The position of its centre of gravity and the variables of the moment of inertia are usually determined with the basic design of a vehicle (drive, wheelbase,
dimensions and weight).
In addition to the type of drive, the vehicle’s moment of inertia JZ,V around the vertical axis is the determining factor for its cornering performance.
Manoeuvrability increases as the inertia moment decreases, whereas driving stability when the vehicle is moving in a straight line and on S bends decreases
by the same amount. JZ,V comprises the mass mV,T of the vehicle as a whole and the radius of gyration iZ,V squared:
JZ,V = mV,t i 2Z,V (kg m2)
The magnitude of the radius of gyration iZ,V depends on the length, width and weight distribution of the body, the length and weight of aggregate units
(engine, gear box, differential) and the position and weight of the occupants and the luggage. Series tests with saloons have shown that the radius of
gyration is mainly a function of the load status and only varies within narrow limits from vehicle to vehicle. Fig. shows the average values. Only the
vehicle weight mV,t in the occupancy or load condition to be investigated is necessary for determining the approximate moment of inertia JZ,V (see).

2.2 - Moment of inertia estimation techniques

The moments of inertia, in yaw, pitch, and roll, as well as the center of gravity height are necessary to successfully model the 3D dynamic behaviour of
vehicles. A number of vehicle parameter estimation techniques have been developed and are currently in use in North America and Europe.
Many parameters have been measured by NHTSA and others. The estimation techniques are compared to the available measured values, and
recommendations are made for best estimating the parameters when measured values are not available.
Modeling the 3D dynamic behavior of a vehicle requires a minimum of the vehicle geometry, the center of gravity height and the triaxial moments of inertia.
Because moments of inertia are difficult (but most important, expensive) to measure for a given vehicle, there is a need for estimation techniques that use
easily obtained vehicle measurements.
More complex models like Assetto Corsa require data concerning the sprung and unsprung vehicle masses. For now here will be discussed the whole
vehicle moments of inertia relative to the total vehicle centroidal axes, and the height of the whole vehicle center of gravity.
Theory:
In simple linear Newtonian mechanics, the mass of a vehicle is assumed to be concentrated at the center of gravity location. This assumption may be
appropriate for the simplest dynamic models, pure central collisions, or for very coarse estimation purposes. When the vehicles are involved in rotations, as
is the most common case, then the simple models are inadequate, and the distribution of the vehicle’s mass about the centroid must be considered.
The resistance of an object to rotation is a function of the mass of said object, and the location of the mass with respect to the center of rotation, and is
known as its moment of inertia, 𝐼𝐼.
An idealized motor vehicle can be considered a solid homogeneous slab as shown in Fig. (left).

Fig. – (left) The vehicle as a solid homogeneous slab or prism. (right) The vehicle with concentrated masses.

375
The moments of inertia about the three axes of the slab would be:
1 1 1
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚(𝑊𝑊 2 + ℎ2 ) ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 𝑚𝑚(𝐿𝐿2 + ℎ2 ) ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚(𝐿𝐿2 + 𝑊𝑊 2 )
12 12 12
Regarding vehicles, this is termed the prism method. The yaw moment of inertia for a solid slab is a function of the length and width as well as mass, not
mass alone.
A motor vehicle is not a solid homogeneous slab. It has concentrated masses at the engine, transmission, suspension, etc., as shown in Fig. right
The moment of inertia for any object can be calculated, if enough is known about these distributed masses. However, the MOI of a motor vehicle is more
practically measured by testing, as already mentioned previously (see).
To explain a purely theoretical method, a simplified top view of a vehicle is shown in Fig.

Fig. – Top view of a vehicle being tested for the yaw moment of inertia.

The vehicle is allowed to pivot at its center of gravity, on a massless undamped frictionless frame. The fore/aft mass distribution is 50/50. Yaw inertia is
measured thanks to springs with constant k. The moments sum as follows:
2𝑘𝑘𝑎𝑎2
� 𝑀𝑀 = 𝐼𝐼𝐼𝐼 ; −2(𝑘𝑘𝑘𝑘𝑘𝑘)𝑎𝑎 = 𝐼𝐼𝜃𝜃̈ ; 𝜃𝜃̈ + � � 𝜃𝜃 = 0
𝐼𝐼
Where 𝜃𝜃̈ is the second derivative of the angle, so the angular velocity 𝜔𝜔. The period (the time for a single oscillation) of this oscillating structure is:

𝐼𝐼
𝜏𝜏 = 2𝜋𝜋�
2𝑘𝑘𝑎𝑎2
In this idealized example, one measures the period, the geometry, and the spring constants, and the moment of inertia is readily determined:
1
𝐼𝐼 = 2𝑘𝑘𝑎𝑎2 𝜏𝜏 2
4𝜋𝜋 2
The actual measurement of the inertial properties of vehicles is far more complex than presented here.
Estimation techniques
A number of methods have been proposed to estimate the moments of inertia, and in some cases the height of the center of gravity. These are listed here in
chronological order.
- Grime (1969) proposed the prism method described previously.
- Burg (1982) tested against the measured values of 56 European vehicles and found that the best correlation for the yaw moment for his sample was:
𝐼𝐼𝑧𝑧𝑧𝑧 = 0.1269𝑚𝑚𝑚𝑚𝑚𝑚
- Reide: Researchers at General Motors (1984) tested a number of passenger vehicles “sold commercially somewhere in the world”. No truck or bus types
were included. Body styles ranged from 2-passenger sports cars to station wagons, masses from 575 to 1761 kg, and wheelbases from 2025 to 2953 mm.
Nine were front engine-rear drive, six front engine-front drive, and two were rear engine-rear drive, for a total of 17 cars. They were tested in curb condition,
no passengers and full gas tank. The best fit for the whole vehicle MOIs, relative to the total vehicle centroidal axes, were:
𝐼𝐼𝑥𝑥𝑥𝑥 = 0.37𝑚𝑚 − 86.4, 𝑅𝑅2 = 0.893 ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 2.56𝑚𝑚 − 1103, 𝑅𝑅2 = 0.919 ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 2.86𝑚𝑚 − 1315, 𝑅𝑅2 = 0.920
Where m is the total vehicle mass and R is the average radius of the mass distribution, evaluated to obtain the equations given.
No techniques for estimation of center of gravity heights were given.
- Allen (1987) et al. proposed a method for the roll moment, as a variant of the prism method:
1
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚(𝑊𝑊 2 + ℎ2 )
12
Where this time ℎ2 = 𝛼𝛼1 ℎ1 2 + 𝛼𝛼2 ℎ2 2 , and 𝛼𝛼1 + 𝛼𝛼2 = 1.
The values 𝛼𝛼1 and 𝛼𝛼2 shown in Fig. are weighting coefficients which consider the proportions of the vehicle at various heights.

376
Fig. – The vehicle with averaged height.

Allen suggests that this method of determining the roll moment is accurate to within 20%. The center of gravity height is given as:
ℎ𝑐𝑐𝑐𝑐 = 0.38ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 5%
Allen has offered no recommendations for the pitch moment.
- Garrott: The most complete listing of measured was published by Garrott in 1988. In addition to the values measured, the authors presented a number of
historic “rules of thumb” (in this manual indicated as ROT) and proposed a set of revised rules (all units have been converted to metric) which are listed in
tab. below. tav is the average of front and rear track of the car.
Passenger cars Light trucks Garrott also fitted curves through the measurement data, and presented the MOI
ℎ𝑐𝑐𝑐𝑐 = 540.8 ± 38.1 𝑚𝑚𝑚𝑚 ℎ𝑐𝑐𝑐𝑐 = 678.4 ± 101.6 𝑚𝑚𝑚𝑚 parameters for passenger cars and light trucks as a function of vehicle mass
ℎ𝑐𝑐𝑐𝑐 = 0.395ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 2.6% ℎ𝑐𝑐𝑐𝑐 = 0.387ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 3.5% (herein indicated as f(m)).
𝑚𝑚 ∙ 𝑡𝑡𝑎𝑎𝑎𝑎 ℎ𝑟𝑟 𝑚𝑚 ∙ 𝑡𝑡𝑎𝑎𝑎𝑎 ℎ𝑟𝑟 Passenger cars:
𝐼𝐼𝑥𝑥𝑥𝑥 = (0.73 ± 0.13) 𝐼𝐼𝑥𝑥𝑥𝑥 = (0.67 ± 0.16)
4 4 𝐼𝐼𝑥𝑥𝑥𝑥 = 0.538𝑚𝑚 − 203, 𝑅𝑅2 = 0.80
𝐼𝐼𝑦𝑦𝑦𝑦 = (1.07 ± 0.17)𝑚𝑚𝑚𝑚𝑚𝑚 𝐼𝐼𝑦𝑦𝑦𝑦 = (1.04 ± 0.22)𝑚𝑚𝑚𝑚𝑚𝑚 𝐼𝐼𝑦𝑦𝑦𝑦 = 2.96𝑚𝑚 − 1558, 𝑅𝑅2 = 0.89
𝐼𝐼𝑦𝑦𝑦𝑦 = (1.03 ± 0.08)𝐼𝐼𝑦𝑦𝑦𝑦 𝐼𝐼𝑦𝑦𝑦𝑦 = (1.00 ± 0.1)𝐼𝐼𝑦𝑦𝑦𝑦
𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1635, 𝑅𝑅2 = 0.88
Light trucks:
𝐼𝐼𝑥𝑥𝑥𝑥 = 0.66𝑚𝑚 − 319, 𝑅𝑅 2 = 0.70 ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 3.35𝑚𝑚 − 2247, 𝑅𝑅2 = 0.70 ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1821, 𝑅𝑅2 = 0.73

- Curzon: Later researchers developed the work of Garrott further. Curzon and colleagues (1991) measured the inertial properties of sport utility vehicles,
pickup trucks, and vans, and developed MOI estimations applicable to most light trucks.
They found the prism method was the best estimate for the yaw moment for sport utility vehicles, using the track width instead of the vehicle width.
1
𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚(𝐿𝐿2 + 𝑡𝑡 2 )
12
For the yaw of pickup trucks, the rule of thumb was best: 𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚𝑚𝑚𝑚𝑚
Regarding vans, they recommend either the prism method as for sport utility vehicles, or Garrott’s value for light trucks: 𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1821
The roll moment was best approximated by a sum of prisms, similar to the method first proposed by Allen, that account for the varying cross sections of the
vehicles (Fig.).

Fig. – Prism models for pickup trucks, sport utility vehicles and vans.

The recommended relationship for the roll moment for sport utility vehicles is as follows:
1 𝐿𝐿𝑟𝑟 ℎ𝑟𝑟 2 1 𝐿𝐿𝑟𝑟
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚 � + 𝑊𝑊 2 � + 𝑚𝑚 �1 − � (ℎ𝑤𝑤 − ℎ𝑎𝑎 )2
12 𝐿𝐿 12 𝐿𝐿
Like the earlier work by Allen, the roof length is required to use this technique.
For the roll moments of vans, Curzon recommends either the method above for sport utility vehicles, or Garrott’s value for light trucks: 𝐼𝐼𝑧𝑧𝑧𝑧 = 0.66𝑚𝑚 − 319.
Curzon offered no recommendations for the pitch moment or the CG height.
- Noon: Noon (1994) has proposed three methods to estimate the yaw moment. They have been conveniently called Noon-1, Noon-2, and Noon-3.

377
The first one has the moment being a function of the mass and the overall length:
𝑚𝑚𝐿𝐿2
𝐼𝐼𝑧𝑧𝑧𝑧 =
12
The second has the moment being a function of the mass and the wheelbase alone, assuming the masses are concentrated at half the wheelbase from the
geometric center:
𝑚𝑚𝑙𝑙 2
𝐼𝐼𝑧𝑧𝑧𝑧 =
4
Noon’s third method, Noon-3, considering the engine to be the most significant concentrated mass affecting the application of the prism method, accounts
for the effect of the engine mass with a combination of methods one and two:
𝑚𝑚𝐿𝐿2 𝑙𝑙 2
𝐼𝐼𝑧𝑧𝑧𝑧 = 2(1 − 𝑥𝑥) + (2𝑥𝑥 − 1)𝑚𝑚
12 4
where 𝑥𝑥 is the fraction of vehicle mass borne by the front axle.
This third method assumes that the difference between the weights on the axles is due to a point mass at the heavier axle, and that the centroid is at the
geometric center. Although contradictory, these assumptions are justified for an estimation technique.
Noon offered no recommendations for the pitch or roll moments or the CG height.
- Bixel: Bixel (1996) measured the parameters for 104 passenger cars, 84 multi-purpose vehicles, 82 pickup trucks, and 43 vans.
They found the roll moment for all vehicles The pitch moment for passenger cars: The yaw moment for all vehicles can be
can be estimated as: estimated as:
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝐿𝐿 𝑚𝑚𝑚𝑚𝑚𝑚
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝑡𝑡 𝐼𝐼𝑦𝑦𝑦𝑦 = 𝐼𝐼𝑧𝑧𝑧𝑧 =
𝐾𝐾 𝐾𝐾
𝐼𝐼𝑥𝑥𝑥𝑥 =
𝐾𝐾 The pitch moment of multi-purpose vehicles,
pickup trucks and vans:
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝑙𝑙
𝐼𝐼𝑦𝑦𝑦𝑦 =
𝐾𝐾
Where K is an approximation constant determined for each class of vehicle.
The Bixel K factors are summarized in tab. Bixel notes that these approximation constants must evolve with evolving vehicle design.
Vehicle class Pitch Roll Yaw All the methods proposed by Bixel except yaw use the CG height, a quantity that is not generally
Passenger cars 5.2901 7.9846 2.1942 available on published databases. However, we explained at p. how to determine hcg practically.
Sport Utility, l<2.41 m 4.2193 9.4212 2.2048
Sport Utility, l>2.41 m 3.4510 9.4212 2.2048
The vehicle property estimations obtained with the Bixel method are only appropriate for vehicles
Pickups 3.3783 9.4738 2.1858 that were manufactured since 1980.
Vans 3.4734 7.8854 2.2168
All the estimation techniques mentioned previously are compared in tab. below.

Method 𝐼𝐼𝑥𝑥𝑥𝑥 𝐼𝐼𝑦𝑦𝑦𝑦 𝐼𝐼𝑧𝑧𝑧𝑧 ℎ𝑐𝑐𝑐𝑐 The equations providing the smallest range of standard deviation error (68% confidence limit) are given in the
tables of p.. Note that these equations have been multiplied through by their individual correction factors.
Prism x x x
Burg x x x If the information required to use a recommended equation is not available, another equation from the
methods discussed before may be used with its correction factor taken from the tables at p.. The user must
Reide x x x
then be aware of the slightly greater error being introduced.
Allen x
Garrott x x x x When adjusted, it was found that Garrott's revised rules of thumb provided identical results to the original rules
Curzon x x of thumb. This was expected as Garrott's revised rules are the result of multiplying the original rules by a
Noon x constant. Allen's adjusted equation for center of gravity height also provided identical results to those of the
Bixel x x x rules of thumb for the same reason.
The inertia estimation methods proposed by Garrott and Reide had greater deviations than the other methods. Both the Reide and Garrott methods consider
the moments of inertia to be linearly related to the vehicle mass and do not consider the vehicle geometry.
The only available body of MOI data for European vehicles has been given in the Burg study. No guidance can be offered for those European vehicles not
included in the NHTSA data used for this comparison.
At this point you may say: we only talked about total vehicle inertia estimation, but AC works with the sprung mass inertia. Very well, in the attachments of
this manual there is a solver (come on maaaaan wheeeere) that will allow you to convert the total MOI to the sprung one, once the first is estimated or
measured.
Be aware that the total inertia estimation doesn’t take in account the fuel mass. That’s totally fine, because in AC it is added as a point mass after the internal
calculations with sprung MOIs. Keep that in mind when checking telemetry data.

- If there is a known concentrated mass in a vehicle, due to occupant positioning or cargo loading, remote from the radius of gyration, then the moments
can be summed using the parallel axis theorem:
𝐼𝐼 ′ = 𝐼𝐼 + 𝑚𝑚𝑟𝑟 2

378
 The correction factors are simply to be multiplied by the results you obtain from the original formulas of the different methods, paying attention to the vehicle type. That will give you results correct to the 68% degree of confidence,
which is the same of the Best Adjusted Equations.

The Best Adjusted Equations already have the correction factors applied to them, that is exactly the point of them being adjusted.

The [ROT] and [f(m)] indicators for the Garrott factors refer to the Rules Of Thumb first, and to the formulas function of mass (hence the math symbol f(m)). You can find all of them in the explanations of the previous pages.

The spreadsheet in the attachments of the manual was tested with BMW M3 E30, Jeep CJ-5 and is working properly.

Advice for sports cars (prototypes/open wheelers/hypercars): they centralize the mass as much as they're allowed, so roll is quite lower than the estimate for passenger cars.

I will clean some more the table, putting the methods in the same order for each vehicle type.

379
10. colliders.ini
This small script lets you create additional colliders for the bottom of the car, which handle the collisions with the asphalt and kerbs, because the 3D collider
mesh (more info at Chapter) doesn’t really want to hit the ground in some scenarios, plus running the entire 60 poly object against the ground is too
demanding in terms of computational resources, so at the bottom of the car there are some flat planes.
[COLLIDER_0] ; SYNTAX: [COLLIDER_ID], starting from zero. A car can have as many colliders as necessary.
CENTRE=0 ,-0.23 ,-0.2 ; Where the center of the collision box will be placed. 0,0,0 XYZ reference is the CoG

% ▲ The position depends on how annoying you want it to be; if it exactly matches the mesh your car might have trouble driving over curbs, especially
with F1 cars. If you want to do a fine tuning of the collisions with the ground, make the .kn5 collider smaller than the car, so the panels have some
"give" and handle the underbody with colliders.ini.

SIZE=0.8 ,0.1 ,3 ; The size of the collision box in XYZ [meters]

GROUND_ENABLE=1 ; This value enables the ground collider. 0= disabled, 1= enabled.

[COLLIDER_1]
CENTRE=0 ,-0.16 ,0.40
SIZE=1.4 ,0.15 ,1.5
GROUND_ENABLE=1

[COLLIDER_2]
[COLLIDER_3]
[...]

% ▲ A car can have as many ground colliders as necessary.

LITTLE EXPLANATION
- In Fig. we have some examples of collider models straight from the official content.

Fig. – Images obtained via CM showrooms. (top) The Ferrari 312T by Kunos has got three colliders (the red boxes) in addition to the collider.kn5 (the rainbow-coloured mesh).
(bottom) The Ferrari F138 by Kunos has got six colliders in the config file. The 3D collider has been hidden for clarity purposes. COLLIDER_4, which isn’t at ground level, it is at the
pilot’s head level instead. That’s for the roll hoop, a safety feature of F1 cars. The config isn’t limited only to ground level objects. Even a driver halo’s collider may be added.

Here we have a mod example instead (Fig.).

380
Fig. – You can clearly see how colliders have been used for the front splitter and for the underside of the vehicle.

- It is advisable to use just one collider that goes the front tyres to the rear tyres (Fig.), but to be honest, there aren’t other specific rules about where you
have to place them, so the limit is just your creativity. The cost is always the computational performance.

Fig. – Often a single collider will completely fulfill your needs. It can also be easier to manage.

- Keep the 3D collider.kn5 as you made it (following the rules) for the vehicle body, and change the values in colliders.ini for the floor of the car. Parametric
ground colliders are not a replacement for the 3D collider mesh: both systems are required!

- The reference point of the values is the car’s CoG (center of gravity) as determined in the data files. Changing the model won’t alter the position of the
ground colliders.

381
11. ctrl_4ws.ini
This is a dedicated controller file. You can use it for both active and passive 4 Wheel Steering. Nissan GT-R R34, Mada RX-7, Porsche 918, Carrera S and
GT3 RS have different versions of this stuff.
[CONTROLLER_0]
INPUT=LATG ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX RPMS STEER_DEG
WHEEL_STEER_DEG LATG
COMBINATOR=ADD
LUT=(|-0.55=-0.0008|-0.3=0.0005|-0.1=0.0|0=0|0.1=0.0|0.3=-0.0005|0.55=0.0008|)
FILTER=0.99
UP_LIMIT=100
DOWN_LIMIT=-100

LITTLE EXPLANATION
- ctrl_4ws.ini can be used to simulate rear axle steering. It’s one of those features that has popped up a few times over the years but was usually ahead of its
time. Or at least ahead of the complexity required and the engineering cost to make it reliable. But that hasn’t stopped automakers from trying it. Over and
over and over.

Honda was one of the first to bring rear-steer to the market in the late ’80s. The four-wheel steering system was followed Nissan’s HICAS system but both
didn’t stick around. GM had Quadrasteer, which was offered on full-size trucks and 2500 series Suburbans in the mid-2000s. Porsche’s 928 had a passive
rear axle that could increase rear toe-in when braking, but that’s not exactly the same.

There are a few different effects from steering the rear wheels. Increased stability, improved maneuverability, a decreased turning radius. Oh, and more
steering parts to wear out and then fail. Especially if the manufacturer decides that it’s not going to keep offering the feature.

- Turn the rear wheels the opposite way as the front wheels and the car pivots around the center axis. The rear wheels don’t turn much, less than 15 degrees
in most cases and just 3-5 in others. It makes the wheelbase feel shorter. The Cadillac CT6, which is a very large car, trims its turning radius by a full three
feet with active rear steering.

Turn those back wheels at speed, though, and things get more interesting. Ever try and crank the wheel in reverse when you’re moving quickly? So at speed,
the rear wheels turn in the same direction as the front. That lets the vehicle almost crab walk over into the next lane. Instead of turning, you’re making a
diagonal movement. The effect is like making the wheelbase longer. Like turning a bus instead of a sports car. It’s a smoother movement, so the car feels
more stable as you make a lane change. If you’re towing, like in the pickups, the trailer gently follows. It actually reduces sway and makes it easier to control.

So how does it work? Basically, there is a small steering rack fitted to the rear axle. Since the wheels don’t turn very far, it can be much more compact than
what you’d find on the front wheels. From that there are tie rods that link to the rear hubs, and those rear hubs can pivot. It’s like a tiny version of the front
suspension layout, mounted in the back.

There’s no steering column leading to the back wheels either. The call to steering is done by computer. A sensor on the steering column measures what
you’re trying to do. It tells the computer, which also knows how quickly you’re moving. From there, the computer decides to either turn the rear wheels with
the fronts or the opposite. The speeds where the direction changes depend on the manufacturer and the type of vehicle. On a 911, for example, the switch
happens somewhere around 50 mph. Cadillac’s system changes the speed depending on which dynamic mode the vehicles is in.

Audi’s system works a bit differently. Instead of the smaller rear steering rack, each rear wheel has a small electric actuator. These take advantage of Audi’s
48-volt system. A moving link from the actuator to the hub toes each wheel in or out to steer the rear of the car. It’s the same basic idea, though. It moves
the rear wheels and either makes the vehicle turn tighter or change lanes more smoothly.

On heavy trucks and buses rear steering axles are VERY common nowadays.

382
11. damage.ini
The script that manages the VISUAL and/or MECHANICAL damage of your car. This has very little theoretic relation with physics, given that you can set at
which speed and acceleration a vehicle part gets visual and/or mechanical damage.
Be aware that this is not realistic at all, because there is not a simulation of deformations and damage. Everything is user-defined, so damage is more of an
artistic expression. With some reasoning and logic though you can make something quite good out of this. Look at the official cars for example.
[SCRATCHES]
MIN_SPEED=0 ; [km/h]
MAX_SPEED=20 ; [kmh]

[DAMAGE]
INITIAL_LEVEL=20

[DAMAGE_GLASS_FRONT]
MIN_SPEED=20 ; Minimum vehicle speed for the glass damage to appear (usually on the windscreen). [km/h]
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_REAR]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_LEFT]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_RIGHT]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_CENTER]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[OSCILLATIONS]
ENABLED=1

[VISUAL_OBJECT_0]
NAME=MOTORHOOD ; NAME OF THE NODE
STATIC_ROTATION_AXIS=-1,0,1 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=2.86 ; STATIC ROTATION ANGLE
MULT_G=0.1 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=FRONT ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=-1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=5 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,1 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

[VISUAL_OBJECT_1]
NAME=FRONT_BUMPER ; NAME OF THE NODE
STATIC_ROTATION_AXIS=-1,0,0.5 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=5.76 ; STATIC ROTATION ANGLE
MULT_G=0.1 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=FRONT ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=-1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=4 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,1 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

[VISUAL_OBJECT_2]
NAME=REAR_BUMPER ; NAME OF THE NODE
STATIC_ROTATION_AXIS=1,0,0 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=5.76 ; STATIC ROTATION ANGLE
MULT_G=0.01 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=REAR ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=5 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,0 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

LITTLE EXPLANATION
- The debug of damage zones can be done in ksEditor. (material)

- You can make things like the exhaust (or rear mirror) “jiggle” through damage.ini. Try something similar to what you find below - the important bits are
MIN_ and FULL_SPEED, as setting them both to -1 means the “damage” is on all the time:
[VISUAL_OBJECT_0]
NAME=Exhaust1
STATIC_ROTATION_ANGLE=0
MIN_SPEED=-1 ; three the most important values
FULL_SPEED=-1
ALLOWED_G=0,0,0
OSCILLATION_AXIS=0,-1,1 ; change this to choose axis
OSCILLATION_MAX_ANGLE=1 ; and this to change amplitude

Another example of a swinging object can be a keychain on the dash, like the Lancia Fulvia 1.6 HF mod has (Fig.).

383
Fig. – The swinging keychain of the Lancia Fulvia mod.

This is the code for that exact purpose:

[VISUAL_OBJECT_1]
NAME=keychain
STATIC_ROTATION_AXIS=0,0,0
STATIC_ROTATION_ANGLE=0
MULT_G=0.00001
DAMAGE_ZONE=FRONT
MIN_SPEED=-1
FULL_SPEED=-1
OSCILLATION_AXIS=-1,0,0
OSCILLATION_MIN_ANGLE=0
OSCILLATION_MAX_ANGLE=40
ALLOWED_G=-1,0,0

Be aware that it encounters a limitation of the AC engine, so it only swings to one side,
and quite slowly (may be adjusted with MULT_G).

To clarify some more, you don’t need a NULL for damageable wobbly parts, it’s just for
convenience. You can use the origin of the object’s mesh like in the keychain example
above.

Fig. shows how the origin was placed in the right spot for the keychain to oscillate
around the ring correctly.

Fig. – As you can see the origin is in the center of the ring.

CURIOSITIES AND AMENITIES

- Why a good simulator with a physically based damage model doesn’t exist out there?
The problem is not the manufacturers who don’t want to see their cars damaged, that one is mainly a Gran Turismo philosophy (which to me makes no
sense, as they could simply add an option to enable or disable damage). So much fuss over gasoline-sucking pieces of iron. But then ask Kazunori
Yamauchi, that’s more artistic direction than anything else.

The real trouble is the amount of calculations required to make a good damage model. Following the principle of realism, you don't want to simulate
sponges like in BeamNg, which reminds me a lot of Algodoo, a little program to play with physics.
You’d need to account for the strain resistance of the materials, the chassis deformation during the impact, the destruction of mechanical parts. All of this
requires a ton of research, data and computational power. Also, from the point of view of the graphic engine you would have to implement bones for your
meshes to let them interact with the physics. Just simulating the deformation of a small bolt or bracket can take up to several minutes with an engineering
software like Solidworks, designed to give you only the end result (Fig.), not an interactive environment.

384
Fig. – Just look at how many triangles you need to get an accurate result.

Imagine doing this in real-time. Not only that. Even if we had the CPU and GPU compute power needed, a complete damage model includes energy absorbing
zones made by the manufacturers with crash test results, so patented data, authorizations, etc. are required. If back in the day Kunos had added a sketchy
dynamic damage model, so not very realistic, people would've complained, so devs kept it as it was in the first place, basically textures. Maybe some day CSP
(or Kunos themselves?) will bring detachable meshes for cars and more complex particle effects (like bolts and small springs on the road), so at least you will
see some "shattering shards" on the track; that will be the compromise. Hood deformation effects are already there.
Not to mention the fact that once the car is destroyed, the race ends. Imagine the chaos in multiplayer. Realism kills fun here, and those who can enjoy
wrecking cars and seeing them burn are only a niche (luckily). I know I would have fun with crash tests, but that’s beyond the purpose of a racing simulator,
and in that case BeamNG is better.
I personally believe it’s good to not have an accurate damage model. It’s a sign of respect towards all the pilots who lost their life or had various accidents
during the many years of motorsport (Fig.).

Fig. – (Maybe too harsh. Replace image?)

385
12. dash_cam.ini
This config file is pretty simple, as it only sets the parameters for the position of dash cam of your vehicle. This camera is the one you can use to drive with
your hardware wheel in front of the screen, hiding the virtual one and the driver 3d model. It’s usually the second interior view activated when cycling
between the cameras with the F1 key on your keyboard.
[DASH_CAM]
POS=-0.00324544,1.05167,-0.958184 ; (x,y,z) x-/rightt; z+/forward
EXP=28 ; Exposure level.

13. digital_instruments.ini

If it wasn’t already obvious, this script controls the digital instrumentation of your vehicle: displays, timers, etc. You can also set the parameters for eventual
LEDs on the steering wheel (the ones that light up for RPMs near redline, often present on GT or GT3 sport cars).
Always delete the contents of this file at the beginning of a new project, because it always causes crashes, as often it looks for dummies or objects that are
likely not present on your model. (instead of a single script, let’s put example modules)
[FUEL_WARNING_0]
OBJECT_NAME=fuel_indicator_off
FUEL_SWITCH=8

[WATER_TEMP_0]
PREFIX=WATER_TAG_
START_TEMP=40
END_TEMP=110
LED_COUNT=12

[ITEM_0]
PARENT=DISPLAY_SPEED ; Name of the NULL, following the standard for digital instruments.
TYPE=SPEED ; Function of the instrument.

% ▲ List of all kinds of TYPE values; some are very useful for GT3 cars:

SPEED
RPM
CLOCK
AMBIENT_TEMP
GEAR
FUEL
FUEL_CONS
LAPTIME
PERF
RPM_GRAPH
TC_LEVEL
WATER_TEMP
PLACE_HOLDER

POSITION=0,-0.0075,0 ; Position relative to the parent object.

SIZE=0.013 ; Font size in meters.
COLOR=255,255,255 ; Color of the font in RGB (red, green, blue) format (it can also be R,G,B,A where A is the Alpha).
INTENSITY=2 ; Intensity of illumination.
FONT=e92_big ; Font of the display (for custom fonts).
VERSION=2 ; This is needed for the latest vanilla features (not documented); leave at 2.
ALIGN=CENTER ; Alignment of the text. Can be LEFT, CENTER, RIGHT.
UNITS=KMH ; Line for the SPEED unit displayed; input can be KMH [Km/h], MPH [miles/h] or SYSTEM (from AC options)

[ITEM_1]
PARENT=DISPLAY_RPM
TYPE=RPM
POSITION=0,-0.0075,0
SIZE=0.013
COLOR=255,255,255
INTENSITY=2
FONT=e92_big
VERSION=2
ALIGN=CENTER

% ▼ We can have a lot of instruments, so below we’ll keep only the differences between them and the lines of code that have the same functions will be
skipped. There are no missing lines compared to [ITEM_1].

[ITEM_2]
PARENT=DISPLAY_CLOCK
TYPE=CLOCK
[skipping lines similar to ITEM_1]

[ITEM_3]
PARENT=DISPLAY_TEMP
TYPE=AMBIENT_TEMP
[skipping lines similar to ITEM_1]

[ITEM_4]
PARENT=DISPLAY_TEMP
TYPE=PLACE_HOLDER
TEXT=@ ; Placeholder text for the temperature display.
[skipping lines similar to ITEM_1]

[ITEM_5]
PARENT=DISPLAY_DATA
TYPE=GEAR
N_TIME=0.3 ; Transition time between one gear number/letter and another. [s]

% ▲ Puts a delay on Neutral so it doesn't jump back to N between gears. Useful for modern cars where the gear change is shown seamlessly.

[skipping lines similar to ITEM_1]

[ITEM_6]
[ITEM_7]
[...] ; A vehicle can have as many [ITEMS] as necessary.

[KERS_INPUT_SERIE_0]
PREFIX=TAG_EMISSION_
START_INDEX=0
END_INDEX=15

[KERS_RECHARGE_SERIE_0] ; harvest series function

386
PREFIX=TAG_CHARGE_
START_INDEX=0
END_INDEX=13
NORM_MAX=0.001192

[SPEED_SERIE_0] ; series script for digital speed bars

PREFIX=TAG_SPEED_
START_SPEED=0
END_SPEED=350
LED_COUNT=35

[POWER_918_0] ; Porsche 918 Spyder-style full power usage series function

PREFIX=TAG_RPM_
START_TORQUE=0
END_TORQUE=980
LED_COUNT=44
FILTER=0.85

[LED_0]
OBJECT_NAME=LED_0
RPM_SWITCH=7400
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7400
BLINK_HZ=0

[LED_1]
OBJECT_NAME=LED_1
RPM_SWITCH=7600
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7600
BLINK_HZ=0

[LED_2]
OBJECT_NAME=LED_2
RPM_SWITCH=7800
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7800
BLINK_HZ=0

[LED_3]
[LED_4]
[...] ; A vehicle can have as many [LEDs] as necessary.

[FUEL_0]
OBJECT_NAME=FUEL_TAG_0
FUEL_SWITCH=1

[FUEL_1]
OBJECT_NAME=FUEL_TAG_1
FUEL_SWITCH=12

[FUEL_2]
OBJECT_NAME=FUEL_TAG_2
FUEL_SWITCH=24

[FUEL_3]
OBJECT_NAME=FUEL_TAG_3
FUEL_SWITCH=36

[FUEL_4]
OBJECT_NAME=FUEL_TAG_4
FUEL_SWITCH=48

[FUEL_5]
OBJECT_NAME=FUEL_TAG_5
FUEL_SWITCH=60

[FUEL_6]
OBJECT_NAME=FUEL_TAG_6
FUEL_SWITCH=70

[FUEL_7]
OBJECT_NAME=FUEL_TAG_7
FUEL_SWITCH=80

[FUEL_8]
OBJECT_NAME=FUEL_TAG_8
FUEL_SWITCH=90

[FUEL_9]
OBJECT_NAME=FUEL_TAG_9
FUEL_SWITCH=100

387
14. digital_panels.ini

This is the script you’ll have to create when working with digital panels.

Position
Use the following script to activate the function:
[FULLPOSITION_SERIES_0]
PREFIX=textName_ ; prefix of texture names located in your_car_folder/texture/display_panel.
POSITION=
PARENT=DUMMY ; parent dummy name.
START=0 ; postfix start.
END=9 ; postfix end.
DIGIT=1 ; set 1 for second digit, 10 for first digit.
WIDTH=30
HEIGHT=40
COLOR=255,255,255,255
INTENSITY=2

Push-to-Pass
Use the following script to activate the function:
[PUSH2PASS_SERIES_0]
PARENT=PANEL_P2P ; name of parent dummy.
POSITION=0.0615,-0.068,0
WIDTH=0.124
HEIGHT=0.137
TRIGGER=0
PREFIX=num_ ; prefix of texture names.
COLOR=255,255,255,255
INTENSITY=40.0
START=0 ; name postfix to start from
END=9 ; name postfix to end at
DIGIT=1 ; (=1 for second digit, =10 for first digit)
BLINK_HZ=5 ; blink rate when activated (=0 for no flashing)

Push-to-Pass status led

[PUSH2PASS_LED_0]
OBJECT_NAME=LED_P2P
EMISSIVE=0,0,800
DIFFUSE=0.35
INVERTED=0 ; for inverse function
BLINK_HZ=0 ; if higher than 0, it blinks

LITTLE EXPLANATION

- The digital panels’ colour is defined in digital_panels.ini.

- Known limitation: in replays, the P2P (Push-to-Pass) and displayed position status is not communicated, which is why the panels will show incorrect or
placeholder values.

388
15. driver3d.ini

This script manages the behaviour and the animations of the virtual driver model inside the car.
[MODEL]
NAME=driver_skidlid ; This value determines which driver model will be used (there are different models available).
POSITION=0,0,0 ; Position of the driver.

[STEER_ANIMATION]
NAME=steer.ksanim ; Determines which animation clip to use for the steering wheel.

% ▲ The default name is steer.ksanim and it makes the clip immediately recognizable, as widely used. It is recommended to use the same name for your
steer animation when exporting.

LOCK=360 ; Rotational limit of the steering animation. [degrees]

% ▲ It's just a value calibrated to match the driver animation, unrelated to physical steering lock. Changing it can only break the driver visuals. You
put here the steering lock of the driver animation file. If the animation does only 1 turn, you put here 360, if it does more turns you put 720 and so
on.

% ▲ If you want the animation to be correct, you have to make 100 frames for each direction of the steering wheel: frame 0 is 360 degrees left of center
frame 100, and frame 200 is 360 degrees right of frame 100. The full animation is actually a rotation of 720° from side to side.

[SHIFT_ANIMATION] ; Lines that manage the driver animations.

BLEND_TIME=100 ; Time needed to move the driver’s hand from the steer position to the first frame. [milliseconds]
POSITIVE_TIME=250 ; Time needed to move the hand from the first frame to the gear lever (forward anim.). [ms]
STATIC_TIME=102 ; Interval where the hand is still on the gear lever (Wait Time between forward & reverse anim.). [ms]
NEGATIVE_TIME=250 ; Time needed to move the hand from the gear lever back to the first frame (reverse anim.). [ms]
PRELOAD_RPM=5600 ; When the car’s engine reaches this regime the forward anim. is automatically played. [RPM]

% ▲ Preload time: plays the first half of the animation, actually shifting plays the second half, then it reverses through the whole thing (ping-pong
animation, for more info see par.)

INVERT_SHIFTING_HANDS=1 ; Set to =1 if the driver shifts with the left hand. =0 if he shifts with the left hand.

[HIDE_OBJECT_0] ; Change the ID number to add more objects to hide; SYNTAX: [HIDE_OBJECT_ID]; ID starting from zero.
NAME=helmet_sub1 ; Hides the specified mesh of the driver model when in cockpit view. In this case the helmet is hidden.

[HIDE_OBJECT_1]
NAME=DRIVER:GEO_Driver_FACE ; Another example: here the driver’s head is hidden.

% ▲ Note: The driver meshes may have different names if you use a custom driver model.

[HEAD_MOVEMENT] ; Parameters for the movement of the virtual driver’s head when subject to accelerations.
FILTER=0.150000 ; 0=no movement, do not use. Low values=high filter, high values=low filter

% ▲ Amount of filtering applied to the g acceleration values.

MAX_G=1.500000 ; Max G level allowed. G above this value will be clamped. [m/s^2]

% ▲ Maximum acceleration appliable to the driver’s head for the calculation of its movement. 1G = 9.81 m/s^2.

ROLL_MAX_DEG=-8 ; Head roll vs lateral G acceleration. Maximum rotation at the MAX_G lateral acceleration value. [deg]

% ▲ Maximum roll angle for the movement of the driver’s head.

PITCH_MAX_DEG=-7 ; Same as above (ROLL_MAX_DEG) but for head pitch vs longitudinal G (braking). [deg]
YAW_MAX_DEG=12 ; Same as above (ROLL_MAX_DEG and PITCH_MAX_DEG) for head yaw vs lateral G. [deg]

% ▲ The visual representation of the three angles is in Fig..

Fig. – For a better understanding of which angle is which, here you have all of them.

LITTLE EXPLANATION
- Here we have an alternative description of the parameters for the shifting animation:
[SHIFT_ANIMATION]
BLEND_TIME=140 ; Time it takes the driver's hand to reach from the wheel towards the shifter.
POSITIVE_TIME=400 ; Time it takes to grab the shifter and change into gear
STATIC_TIME=120 ; How long the driver keeps their hand on the shifter
NEGATIVE_TIME=400 ; Time it takes the driver's hand to let go of the shifter and start heading back towards the wheel
PRELOAD_RPM=7400 ; The driver will reach for the shifter after the engine has exceeded this specified engine RPM, or
take their hand off the shifter if you fall below this specified RPM.

Tweaking these parameters can really help achieve the realistic look of manual shifts.

FAQ
QUESTION [1]: What happens if I don’t include driver3d.ini in the data of my vehicle?
ANSWER: acs.exe crashes and you get this error (Fig.).

389
Fig. – Why did you ask?
QUESTION [2]: I want the shifting animation to be triggered by pressing my Fanatec clutch pedal, instead of the animation being tied to each car's high RPM
value.
ANSWER: It is not possible. The shift animation is triggered on gear change and there's no way for the game to predict it. The PRELOAD_RPM line is the only
thing controlling it.
If you don’t want to see the preload animation, set PRELOAD_RPM to some higher number. I would set it above the engine rev limit to turn the preloading
completely off, so that the driver will move his hand on the gear lever only when shifting happens.
At least AC has shifting animations, half of the other sims don't.

QUESTION [3]: Can I make and use my own driver model?

ANSWER: Yes, of course, but you will have to include it in your mod’s files for people to be able to use it. A vehicle with a custom-made driver model won’t
work if the model specified in the [MODEL] section of driver3d.ini does not exist in the AC files, specifically in this path: %root%\assettocorsa\content\driver

QUESTION [4]: Can I make vehicles with a hidden driver?

ANSWER: It is possible, probably with the [HIDE_OBJECT_ID] lines, but I suggest doing so only for really exotic vehicles (Fig.). If yours is a real-world
car, include it. People can always hide it if they don’t like it. It’s better to have more alternatives than less, right?

Fig. - Is this a joke? Most likely yes, and the only thing that remains visible is the head.

390
16. drivetrain.ini
This is the file that manages the parameters for the transmission and differential. It can have a huge influence on the car’s performance, top speed and
acceleration.
[HEADER]
VERSION=3 ; Version of the drivetrain that the engine will load. It does NOT represent the development version of
the car. Acceptable inputs are 1 through 3, with 3 being preferred as it includes latest features. Recommended input is 3.

[TRACTION]
TYPE=RWD ; Traction type of the vehicle. Acceptable values are RWD, FWD, AWD, AWD2.

[GEARS]
COUNT=4 ; Number of forward gears. Maximum amount is 10.

% ▲ After gear 8, the numbers won’t work anymore: gear 9 and 10 will be displayed as eLinear and eBezier by AC. After the 10th gear, the vehicle won’t
upshift, even if there are 11th or 12th or more gear ratios.

GEAR_R=-2.840 ; Gear ratio for the reverse with any possible overdrive, but without final gear. Input example: -3.382
GEAR_1=2.880 ; Forward gears ratios. must be equal to number of gears defined on COUNT
GEAR_2=1.91
GEAR_3=1.27
GEAR_4=1.00

“GEAR_1” through “GEAR_X” control the gear ratios for forward driving gears with any possible overdrive, but without final gear.

FINAL=3.27 ; Final gear ratio.

[DIFFERENTIAL]

% ▲▼ The rules for the differential are always required by AC to load, but not used (means still present) if the car has the AWD or AWD2 traction types.

POWER=0.012 ; differential lock under power. 1.0=100% lock - 0 0% lock

“POWER” controls the maximum lock % for the limited-slip differential in the acceleration direction. Inputs are in %, so that 50% = 0.50.

COAST=0.012 ; differential lock under coasting. 1.0=100% lock 0=0% lock

“COAST” controls the maximum lock % for the limited-slip differential in the deceleration direction. Inputs are in %, so that 50% = 0.50.

% ▲▲ A value of 1.0 in both POWER and COAST is an exception for a welded or spool-type differential where the wheels are coupled directly together with
no differential action. Use an input such as 0.999 for a “100%” clutchplate differential. Bear in mind also that real-world open differentials typically
have some effective lock %, perhaps from 3 to 10% depending on friction ie: more when turning. For open diffs it would be beneficial to increase lock
from 0.00 to 0.01 - 0.03 or so, to account for the internal friction of the system binding wheels together.

PRELOAD=12 ; Differential preload torque setting. [Nm]

% ▲ The preload is the minimum torque that is necessary to make the differential spin (due to internal friction). It can be measured via a torque wrench
if you remove the differential from the vehicle (Fig.).

Fig. –

Otherwise you can estimate it.

By the way is it

[GEARBOX]
CHANGE_UP_TIME=169 ; Mechanical upshift time. [ms]
CHANGE_DN_TIME=240 ; Mechanical downshift time. [ms]
AUTO_CUTOFF_TIME=170 ; Auto cutoff time for upshifts, set to 0 to disable. [ms]
SUPPORTS_SHIFTER=1 ; 1=Car supports shifter, 0=car supports only paddles
VALID_SHIFT_RPM_WINDOW=1200 ; range window additional to the precise rev matching rpm that permits gear engage.
CONTROLS_WINDOW_GAIN=0.6 ; multiplier for gas,brake,clutch pedals that permits gear engage on different rev matching rpm. the
lower the more difficult.
INERTIA=0.02 ; Gearbox inertia. By default value goes to 0.02 if not set. [kg*m^2]

[CLUTCH]
MAX_TORQUE=300

[AUTOCLUTCH]
UPSHIFT_PROFILE=NONE ; Name of the autoclutch profile for upshifts. NONE to disable autoclutch on shift up
DOWNSHIFT_PROFILE=DOWNSHIFT_PROFILE ; Same as above for downshifts
USE_ON_CHANGES=0 ; Use the autoclutch on gear shifts even when autoclutch is set to off. Values: 1, 0.

391
% ▲ Needed for cars with semiautomatic gearboxes.

MIN_RPM=900 ; Minimum rpm for autoclutch engadgement

MAX_RPM=4000 ; Maximum rpm for autoclutch engadgement
FORCED_ON=0 ; If set =1 disables manual clutch.

[UPSHIFT_PROFILE]
POINT_0=50 ; Time to reach fully depress clutch
POINT_1=110 ; Time to start releasing clutch
POINT_2=150 ; Time to reach fully released clutch

[DOWNSHIFT_PROFILE]
POINT_0=20 ; Time to reach fully depress clutch
POINT_1=320 ; Time to start releasing clutch
POINT_2=800 ; Time to reach fully released clutch

[AUTOBLIP]
ELECTRONIC=0 ; If =1 then it is a feature of the car and cannot be disabled
POINT_0=50 ; Time to reach full level
POINT_1=200 ; Time to start releasing gas
POINT_2=220 ; Time to reach 0 gas
LEVEL=0.95 ; Gas level to be reached

[DAMAGE]
RPM_WINDOW_K=100

[AUTO_SHIFTER]
UP=5000
DOWN=3800
SLIP_THRESHOLD=0.99 ; Slip ratio needed to shift up regardless of rpm.
GAS_CUTOFF_TIME=0.170

[DOWNSHIFT_PROTECTION] ; Automatic protection to prevent engine damage when downshifting too early or at high vehicle speed.
ACTIVE=1
DEBUG=0 ; Adds a line in the log for every missed downshift.
OVERREV=200 ; How many RPM over the limiter the car is allowed to go.
LOCK_N=0 ; Lock neutral (prevent it from engaging) unless the car is stationary.

[AWD]

% ▲▼ If you set the traction TYPE under [TRACTION] to AWD, the lines below must be present. [AWD] codes are required by AC even if you set [TRACTION] to
AWD2, but they are not used. Keep in mind that the rules under [DIFFERENTIAL] must always be included, whichever the traction type is.

FRONT_SHARE=50 ; AWD front mechanical split in full percentage values. For example 50% = 50. [0 - 100]

% ▲ Think of it as if the torque coming from the engine. You get out of the engine 100Nm. You set FRONT_SHARE=40. That means that 40Nm will go to the
front wheels and 60Nm to the rear wheels.

FRONT_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.

FRONT_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
FRONT_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.
CENTRE_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.
CENTRE_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
CENTRE_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.
REAR_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.
REAR_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
REAR_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.

% ▲ Like for [DIFFERENTIAL], here setting ~_DIFF_POWER and ~_DIFF_COAST to a value of 1.0 for any of the differentials is a special case in AC that
removes the diff and makes it a spool.

[AWD2]
FRONT_DIFF_POWER=0.002 ; same as “POWER” but for AWD2 type.
FRONT_DIFF_COAST=0.002 ; same as “COAST” but for AWD2 type.
FRONT_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD2 type.
CENTRE_RAMP_TORQUE=76.0 ; Ramp-up torque for Viscous center differential, per rad/s of differential speed between front and
rear axle. [Nm]
CENTRE_MAX_TORQUE=800.0 ; Maximum torque for Viscous center differential, at the wheels after gearing. [Nm]

% ▲ AWD2 has a viscous coupling based on wheel speed difference. And it can‘t provide preload.

% One may set “CENTRE_RAMP_TORQUE” and “CENTRE_MAX_TORQUE” to the same value when using ctrl_awd2.ini AWD2 center diff controller to control the “maximum
lock” of the center differential. Bear in mind that lower gears will offer a lower effective maximum lock % than higher gears due to greater amount of
torque available, which will result in center differential slip. Typical values are approximated to be 500 - 1500Nm~.

Bear in mind that AWD2 is only capable of 0/100 to 50/50 split, but not FWD biased.

REAR_DIFF_POWER=0.002 ; same as “POWER” but for AWD2 type.

REAR_DIFF_COAST=0.002 ; same as “COAST” but for AWD2 type.
REAR_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD2 type.

% ▲ Like for [DIFFERENTIAL] and for [AWD], here setting ~_DIFF_POWER and ~_DIFF_COAST to a value of 1.0 for any of the differentials is a special case in
AC that removes the diff and makes it a spool.

ABOUT RELATED FILES

Gear ratio files (.rto):
They are used for cars with multiple gear ratio options. The setup.ini will refer to them.

final.rto
The value you use in drivetrain.ini for the final gear ratio (FINAL) has to exist in final.rto.

ratios.rto
This file is only for in-game setup selection, normally you just need to write them into drivetrain.ini as ratios.

Controllers:
ctrl_single_lock.ini
This script controls the preload torque for a rear active differential on a RWD drivetrain (and front diff on FWD?? not sure).
Power and coast settings from drivetrain.ini are discarded (ignored) when the controller is used.
When ctrl_single_lock.ini is found in the vehicle data, the diff is set to have 0% power, coast and preload, and the controller is evaluated every step to
produce a lock value in Nm. Think of it as a dynamic preload.
392
[CONTROLLER_0]
INPUT=GEAR ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=ADD
LUT=gear_start.lut
FILTER=0.99
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_1]
INPUT=OVERSTEER_FACTOR
COMBINATOR=MULT
LUT=understeer_factor_vs_lock.lut
FILTER=0.98
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_2]
INPUT=GEAR
COMBINATOR=MULT
LUT=difflock_gear_mult.lut
FILTER=0.9
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_3]
INPUT=BRAKE
COMBINATOR=MULT
LUT=difflock_brake_mult.lut
FILTER=0.9
UP_LIMIT=10000
DOWN_LIMIT=0.0

The UNDERSTEER FACTOR

It's a large calculus equation that combines a large number of variables to determine the handling balance of the car.
The way it is calculated in AC is basically the slip angle of the front of the car minus the slip angle of the rear of the car. It gives you a positive number when
the car is oversteering, and a negative number when it is understeering. (Casillo 2015)

ctrl_awd_center_lock.ini
This file controls the centre differential preload torque, in [Nm] for the AWD drivetrain type.
Power and coast values in drivetrain.ini are ignored when the controller is used.
ctrl_awd2.ini
Obviously drivetrain TYPE must be AWD2 for this controller to work. Output is CENTRE_MAX_TORQUE, but the controller only sets the maximum value at any
moment. The actual value is still fundamentally controlled by CENTRE_RAMP_TORQUE.
And you can't actively control front and rear differentials. That’s the same reason why [AWD2] has no lines in setup.ini, while [AWD] has them.

LITTLE EXPLANATION
- Power/coast values are 0-100 in setup.ini but 0-1 in drivetrain.ini. Always remember this!
Example: setup.ini 50 = drivetrain.ini 0.5
Go figure out why; such are the mysteries of this simulator.
- If you don't understand what the fractions values under [GEARS] mean, those are the gear ratios. In the mechanical literature the gears for transmissions
and drivetrains are often referred to with the tooth counts on the actual gears, like 14/37 or 12:45 (Fig.); the ratio itself is the number of teeth on the input
gear (or cog), divided by the number of teeth on the output gear. Be careful when identifying them. The fractions are also used as descriptive labels, and the
real number that is also used by AC is the calculation of those, which you can put in the drivetrain.ini, final.rto and gears.rto files.
Example: 12/37 is 3.08

393
Fig. – (left) Main internal components of a transmission. (right) Various gears belonging to a Volkswagen Transporter T3. The ratio is clearly written on the box: 0,785 (28:22).

The same principle applies to the ratio of the differential, where for the cheapest and simplest types you just have two main spinning parts (Fig.).

Fig. – (left) Spool type differential assembly. (right) Ring and pinion gear.

- With all-wheel drive cars, the FRONT_SHARE value is important because not all permanent AWD cars are 50/50 front/rear (F/R).

- The original [AWD] code isn’t really appropriate for modern cars, it’s more for things like the Audi Quattro, with open center diff, symmetrical torque split; it
is portrayed by a mechanical 3-Lsd AWD like some Audis use.

- [AWD2] is just a better way to simulate AWD for cars that have asymmetrical torque split. It is portrayed by an RWD with clutch to the front and the
controllers determine how much torque the clutch provides (limited to 50% of total). [AWD2] caps out at 50% front. It basically starts with 100% torque on
the rear and can transfer up to 50% to the front.

- The main difference between [AWD] and [AWD2] is that [AWD] has a differential at the center, while [AWD2] has a clutch (a viscous center coupling).

- Always check whether the car mods you download from online websites do have AWD even if the real cars they represent shouldn’t. Some mod creators
add some little “fancy” traction (let’s say four wheel drive instead of two) to the cars to make them driveable, usually given the overall low quality of the
physics. This is technically cheating, but it’s likely to be so subtle that goes unnoticed to the untrained eye.

- Relationship between engine torque and wheel torque. As depicted in

the image above, the engine is the source of torque. The gearbox is
connected to the engine through the clutch (on manual transmissions)
or torque converter (on automatic transmissions).

In this case the engine torque Te is equal to the clutch/torque

converter torque Tc.
𝑇𝑇𝑐𝑐 = 𝑇𝑇𝑒𝑒 (2.2)
Furthermore, the engine torque is transmitted through the gearbox, where is multiplied with the gear ratio of the engaged gear ix and outputs the gearbox
torque Tg.
𝑇𝑇𝑔𝑔=𝑖𝑖𝑥𝑥 ∙ 𝑇𝑇𝑒𝑒 (2.3)
394
The propeller shaft is transmitting the torque to the rear axle, where is multiplied
with the final drive gear ratio i0. This gives the torque at the differential Td.
𝑇𝑇𝑑𝑑 = 𝑖𝑖0 ∙ 𝑇𝑇𝑔𝑔 (2.4)
If the vehicle is driven on a straight line, the torque at the differential is equally
split between the left wheel Tlw and the right wheel Trw.

𝑇𝑇𝑙𝑙𝑙𝑙 = 𝑇𝑇𝑟𝑟𝑟𝑟 =
𝑇𝑇𝑑𝑑
2
(2.5)

The sum of the left and right wheel torque gives the torque at the differential.
Replacing (2.2) in (2.3) in (2.4) gives the mathematical
expression of the wheel torque function of the engine torque, for a given gearbox
ratio ix and a final drive ratio i0.

(2.6)
𝑖𝑖𝑥𝑥 𝑖𝑖0 𝑇𝑇𝑒𝑒
𝑇𝑇𝑤𝑤 =
2

If we consider nw as the number of driving wheels, then the wheel torque

formula will have the general form of:

(2.7)
𝑖𝑖𝑥𝑥 𝑖𝑖0 𝑇𝑇𝑒𝑒
𝑇𝑇𝑤𝑤 =
𝑛𝑛𝑤𝑤

If the vehicle is rear wheel drive (RWD) or front wheel drive (FWD) then nw = 2, if the vehicle is four-wheel drive (4WD) or all-wheel drive (AWD) the nw =
4. If the vehicle is a motorcycle (who knows???) then nw = 1.
wip

- In the AC SDK there is the ksGearRatioEditor app (Fig.). This simple tool creates cogs for gear ratios. It is a solver, meaning that it generates possible
solutions.

Fig. – The ksGearRatioEditor solver with some examples. This OS has the comma as decimal character, pay attention to that.

Here's what to do, start with the RatioToGear tab. Insert a ratio you have, for example 3.65. Input the minimum and maximum cogs "available" and fill in the
acceptable error. The tool will generate all the possible options.

In the second tab GearToRatio, you can create similar results but for all the gears you might need instead of going through every single one, saving time.

Note: the tool has a problem with the decimal symbols (mark or comma). If your OS has the comma (,) as decimal character, use that. If you can, go to the
International settings of your operating system and change the decimal character to point. Do not mix commas with points! Use either one or the other,
depending on the standard present on your PC.
Pro tip: keep in mind that, based on the input parameters, there may not be always a solution, especially for very small Ratios, low Error parameters, or for very narrow Min-
Max ranges. For example, if Ratio = 0.05, Min = 7, Max = 70, Error = 0.05, there is only one solution. If you reduce the Error margin to 0.04 there are no solutions.
If you need for instance 3.751:1, it is hardly that you'll get exactly that with no error, so you give it a 1% chance to recalculate, then you'll get a lot of combinations, you
reduce that error margin, until 2-5 results are left, and you choose the one that is most accurate.

395
- About top fuel Dragsters: in AC there is not really any way of simulating a 6-plate clutch system with an automatic 6 speed gearbox.

CSP ADDITIONS
- Since CSP release 0.1.76 it’s possible to get additional clutch damage from high torque when shifting. New options are set in drivetrain.ini, next to the
vanilla damage option:
[DAMAGE] ; Vanilla section.
TORQUE_THRESHOLD= ; uses torque produced by the engine
TORQUE_DAMAGE_K= ; intensity multiplier, similar to existing DAMAGE_K
ENGINE_TORQUE_THRESHOLD= ; uses total drivetrain torque
ENGINE_TORQUE_DAMAGE_K=
CLUTCH_TORQUE_THRESHOLD= ; uses clutch torque
CLUTCH_TORQUE_DAMAGE_K=

The lines are simply added to the already existing [DAMAGE] section.

FAQ
QUESTION [1]: How would you model a torsen differential in AC?
ANSWER [1]: The answer is you don't. AC's diffs just don't work that way (they transfer a percent of input, instead of a percent of the other output, which
only models ramp style LSDs). Probably the closest you can get is setting it to the percent you want to go to the slower axle (eg. in a 5:1, it can be up to
85%). If you use that in combination with traction control you'll get the expected behaviour (of a car with torsen + TC) but if TC is off, there'll be too much
torque put on the wheel with traction.

17. drs.ini

Gyrtsd
[HEADER]
VERSION=2

[WING_3]
MODE=ANGLE

% ▲ ANGLE=uses the ANGLE value and not EFFECT, this angle will override any controller in the wing. EFFECT=Uses only the EFFECT value as a multiplier.

EFFECT=0.1 ; When in EFFECT mode, with DRS on the wing angle will be the current wing angle*EFFECT
ANGLE=10 ; When in ANGLE mode, this value will be set in the wing when DRS is on.

[DRS_ZONES]
IGNORE_ZONES=1 ; Boolean operator. Sets wether or not the DRS zones on the track shall be ignored. Inputs: 0, 1.

[DEACTIVATION]
LIMIT_G=0.5 ;

396
18. electronics.ini
This config file manages the behaviour of the various real-life electronic devices of the vehicle in our simulation: ABS (Anti-lock Braking System), TCS
(Traction Control System) and EDL (Electronic Differential Lock).
[ABS]
SLIP_RATIO_LIMIT=0.10 ; Slipratio limit before ABS engages.
CURVE=abs.lut ; Slipratio lookup table with different slipratio limits, in order to define ABS levels if present.

% ▲ Leave the value completely blank if you wish for a single level given by the SLIP_RATIO_LIMIT line above.

PRESENT=0 ; =1 if ABS is present on the car, =0 if not present.

% ▲ ABS always works if ABS assist is activated from the realism menu UI.

ACTIVE=0 ; =1 the car starts with ABS on (if present), =0 the car starts with ABS off (even if present).

% ▲ You can toggle this value on and off in-game with Ctrl+A.

RATE_HZ=100 ; ABS pulse frequency. It's better to insert the actual ABS pumps refresh rate, than the ECU and
sensors frequency

[TRACTION_CONTROL]
SLIP_RATIO_LIMIT=0.12 ; Slipratio limit before TC engages
CURVE=traction_control.lut ; Slipratio lookup table with different slipratio limits, in order to define TC levels if present.

% ▲ Leave the value completely blank if you wish for a single level given by the SLIP_RATIO_LIMIT line above. ctrl+T to toggle

PRESENT=0 ; 1 if present in car, 0 if not present (TC always work if TC assist is activated from realism menu UI)
ACTIVE=0 ; 1 will make the car start with TC active (if present), 0 will make the car start with TC inactive
(even if present). ctrl+T to toggle
RATE_HZ=100 ; TC pulse frequency. It's better to insert the actual TC pumps refresh rate, than the ECU and sensors
frequency
MIN_SPEED_KMH=40 ; Traction control is set automatically OFF under the min speed value in km/h even if selected as
assist by the user.

[EDL]
PRESENT=0 ; 1 if present in car, 0 if not present (TC always work if TC assist is activated from realism menu UI)
ACTIVE=0 ; 1 will make the car start with TC active (if present), 0 will make the car start with TC inactive
(even if present).
MAX_SPIN_POWER=0.8 ; Brake torque ramp on power. 0=no difference , 1=fast wheel twice the speed of slow wheel
MAX_SPIN_COAST=0.4 ; Brake torque ramp on coast. 0=no difference , 1=fast wheel twice the speed of slow wheel
BRAKE_TORQUE_POWER=50 ; Brake torque to apply to the fastest spinning wheel, on power
BRAKE_TORQUE_COAST=400 ; Brake torque to apply to the fastest spinning wheel, on coast
DEAD_ZONE_POWER=0.2 ; Dead zone for brake torque ramp on power
DEAD_ZONE_COAST=0.0 ; Dead zone for brake torque ramp on coast

LITTLE EXPLANATION
(is this a CSP feature?)
-How to make 4 channel ABS with electronics.ini:
[ABS_V2]
SLIP_RATIO_LIMIT=0.12
CURVE=
PRESENT=1
ACTIVE=1
RATE_HZ=250
CHANNELS=4

ABOUT RELATED FILES

LUTS
traction_control.lut
Example:
0|0.08
1|0.09
2|0.10
3|0.11
4|0.12
5|0.13
6|0.14
7|0.15
8|0.16

abs_control.lut
Example:
0|0.10
1|0.11
2|0.12
3|0.13
4|0.14
5|0.15
6|0.16
7|0.18

FAQ
QUESTION [1]: I have a car which is missing both ABS and TCS (Traction Control System). Now, I don't care about TCS, but I'd like to add the ABS. Do I
have to simply swap the electronics.ini file from a "donor" car?
ANSWER [1]: We’ll make it short: Yes, but if you want to keep ABS only, delete the TCS/EDL sections. At the same time don’t share Frankenstein mods, and
if you do, at least specify which features your customized version has or doesn’t have in the README.txt (see par.8.). Think as if you’re the end user. For
example, how would you feel when you found out that your beloved Audi Quattro mod is only 2WD? You’d feel disappointed, right? Let’s avoid bad
practices.

397
CUSTOM SHADERS PATCH – CSP ADDITIONS
Extended Physics has these lines in electronics.ini
[SPEED_LIMITER]
SPEED_KMH = 159, 161 ; min, max
RATE_HZ = 20

PHYSICS (for electronics.ini)

The ABS: Anti-lock Braking System

Braking stability

If both wheels of an axle lock (if ABS is not fitted), i.e. if they slide on the road, there is not just reduced friction in the longitudinal direction (Fig.), but also
lower friction in the lateral direction. If the rear axle locks, as shown in Fig., lateral forces FY,W,f will occur at the rolling wheels of the front axle, which will
intensify the problem, even in the case of a minor yawing effect, i.e. the condition is unstable.

KL

398
19. engine.ini
You can add parameters for the engine (or motor, whatever you call it) of your vehicle in this config file. Pretty useful, especially if you want to add turbos to
take off and land on the Moon.
[HEADER]
VERSION=1 ; VERSION controls the version of the script that AC will load. It does NOT represent the development
version of the car. Acceptable input is 1.

POWER_CURVE=torque.lut ; Defines the look-up table file (LUT) loaded for the torque curve.
COAST_CURVE=FROM_COAST_REF ; Controls the coast torque method.

% ▲ Defines 3 different options (coast reference, coast values for mathematical curve, coast curve file). Recommended input is FROM_COAST_REF.

[ENGINE_DATA]
ALTITUDE_SENSITIVITY=0.1 ; Sensitivity to altitude of the engine. Default value is 0.1. Deprecated, see CSP additions section.
INERTIA=0.165 ; Moment of inertia of the engine. A typical value is between 0.100 - 0.150. [kg*m^2]
MINIMUM=850 ; Engine idle rotations per minute. [rpm], [gg./min], [U/min], [tr/min], [об/мин]
LIMITER=6500 ; Engine rev limiter. Set to 0 = no limiter. [rpm]
LIMITER_HZ=20 ; Frequency of power cut when hitting LIMITER. [Hz]

% ▲ The maximum frequency that can be input is 333 Hz, due to Assetto Corsa’s physics engine clock (info at p.). Above that value the limiter won’t work.

DEFAULT_TURBO_ADJUSTMENT=0.8 ; Default turbo pressure amount if one or more turbos are cockpit adjustable. 0.5 = 50% boost.

[COAST_REF]
RPM=7000 ; Reference RPM for coasting torque.
TORQUE=50 ; Engine coasting torque (engine braking torque) value at rev number reference. [Nm]

% ▲ I've seen counter torque on some videos of dyno runs, you just have to watch carefully when they end a run and are coasting, to get some data. Plot
your own graph and input it into coast.lut. (works?)
% engine.ini has compression braking torque.

NON_LINEARITY=0 ; Coast engine brake from ZERO to TORQUE value at rpm with linear (0) to fully exponential (1)

[COAST_DATA] ; COAST0, COAST1 and COAST are unused legacy lines which must be included to load engine.ini properly.
COAST0=0
COAST1=0
COAST=0.0000015

[COAST_CURVE] ; Section which must be included to load engine.ini properly. Unknown if functional.
FILENAME=coast.lut ; Defines the LUT loaded for the coasting torque curve.

% ▲ Unknown if functional. Input may be invalid without an existing file; commonly coast.lut is used.

[THROTTLE_RESPONSE] ; Variable throttle response as a function of RPM.

RPM_REFERENCE=6000 ; Lowest engine RPM where “LUT” curve starts being in effect.
LUT=throttle_max.lut ; Filename of the second of the two possible LUT curves used by the throttle map (vanilla).

[TURBO_0] ; SYNTAX: [TURBO_ID]. Turbo identifier. ID starting from zero.

LAG_UP=0.995 ; Amount of filtering interpolation lag used while spinning up the turbo
LAG_DN=0.99 ; Amount of filtering interpolation lag for the turbo when spooling down the turbine.

% ▲ Turbo lag parameters define how responsive the turbocompressor is to the engine regime.

MAX_BOOST=1.40 ; Maximum theoretical boost pressure generated.

% ▲ This value is never exceeded; multiply the torque like T=T*(1.0 + boost), so a boost of 2 will give you 3 times the torque at a given rpm.

WASTEGATE=1.38 ; Max level of boost before the wastegate starts working. 0= no wastegate

% ▲ Controls the maximum allowed boost pressure. It is not the real-world wastegate spring pressure or anything similar, but a practical max pressure.

DISPLAY_MAX_BOOST=1.40 ; Boost pressure considered to be maximum by display apps.

REFERENCE_RPM=2300 ; The theoretical engine rev the turbo reaches MAX_BOOST at, with full throttle and no lag. [rpm]
GAMMA=2.5 ; Gamma function used for the turbo pressure build-up when applying throttle.

% ▲ Controls turbo spool speed, related to REFERENCE_RPM above. Lower gamma = more boost build-up at lower throttle amounts. Typical values are 1.5 -
5.0. This value has nothing to do with the torque equation.

COCKPIT_ADJUSTABLE=0 ; If the turbo boost is adjustable in-cockpit with number digits on keyboard; 0= off and 1= on.

[TURBO_1]
[TURBO_2]
[...]

% ▲ A vehicle can have as many turbos as necessary.

[BOV]
PRESSURE_THRESHOLD=0.5 ; the pressure on the air intake that the valve can take before opening, the pressure on the intake
depends on throttle, this is mostly used for fmod audio (is this deprecated?)

[DAMAGE]
TURBO_BOOST_THRESHOLD=1.2 ; Level of TOTAL boost before the engine starts taking damage.
TURBO_DAMAGE_K=5 ; Amount of damage per second when over TURBO_BOOST_THRESHOLD. Depends on (boost - threshold).
RPM_THRESHOLD=6700 ; RPM before the engine starts to take damage.
RPM_DAMAGE_K=1 ; Amount of damage per second when over RPM_TRESHOLD. Depends on (rpm-threshold).

LITTLE EXPLANATION
- Assetto Corsa is not an engine simulator: the way you get reasonable power curves is by typing reasonable torque curves into the engine look-up-table
based on real data.
- The torque LUT file referenced in the POWER_CURVE line defines with X-Y coordinates (specifically, input | output values) the torque curve of our car. Its
units are revolutions per minute [RPM] and torque at the wheels after drivetrain loss in [Nm].
Pro tip: the file is misnamed in the official vehicles, as it is always called power.lut; it should have been named torque.lut, but that is what we got from Kunos. And unfortunately,
modders kept copy-pasting the file from the templates without changing its name, which is actually defined within engine.ini (in the POWER_CURVE line). Let’s try to avoid
this trend that creates only misunderstandings and do things properly.

- Torque forms part of the basic specification of an engine: its power output is expressed as its torque multiplied by its rotational speed. Internal-combustion
engines produce useful torque only over a limited range of rotational speeds. The varying torque output can be measured over that range with a dynamometer,
which shows it as a torque curve.
Torque is often expressed in [Nm] (Newton * meter) or [kgm] (kilogram * meter); 1 kgm is equal to 9,81 Nm. Be aware that AC works with [Nm].

399
- Often the car you’ll be working on will have torque graphs available (Fig.). The ideal situation is having the graph of the torque at the wheels.

Fig. – A power and torque dynamometer graph. Notice how these are not SI units.

Sometimes though, due to manufacturer choices, or based on the data you will be able to find, you may only have a graph with the engine power ([bhp] or
[W]), or the power at the wheels ([hp] or [W]), like the one in Fig., thus you need to convert power into torque.
Now, in Fig. you can see a graph showing the power AT THE WHEELS expressed in horsepower [HP] on the Y axis, depending on the engine speed in [RPM]
(on the X axis). This is important: always pay attention to the units!

Fig. – These are actually three curves because each is for a different engine (Alfa Romeo). Let’s focus on one curve only. Notice how this is the power at the wheels (metric horsepower);
it means that once we calculate the torque curve from it we do not need to account for transmission losses due to friction: they are already included in the measurement.

If you have only the engine power as reference, not only you’ll need to convert it to engine torque, but you’ll have to calculate also the transmission loss to
obtain the graph of the torque at the wheels (which Assetto Corsa uses). We’ll see how later.
So how can we obtain the torque curve (at the wheels in this case) knowing the respective power graph? Physics give us this general formula:
𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 ∙ 2𝜋𝜋 ∙ 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 (1.6)
Which can also be written like this:
𝑃𝑃 = 𝜏𝜏 ∙ 2𝜋𝜋 ∙ 𝜔𝜔 (1.7)
where τ is torque and P is power. We can modify it a little, to obtain the torque of our rotating system from its power:

400
 𝑃𝑃
𝜏𝜏 = (1.8)
2𝜋𝜋∙𝜔𝜔

Now, it is important to input our data with the correct units, so here is the final torque equation we’re going to use the equation:
60∙𝑃𝑃[𝑊𝑊] 30∙𝑃𝑃[𝑊𝑊]
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 [𝑁𝑁𝑁𝑁] = 2𝜋𝜋∙ 𝜔𝜔[𝑅𝑅𝑅𝑅𝑅𝑅] = 𝜋𝜋∙ 𝜔𝜔[𝑅𝑅𝑅𝑅𝑅𝑅] (1.9)

Where [Nm] is the measure of torque and [W] (Watts, equal to energy per second, or Joule/second [J/s]) is the measure of power; the factor 60 depends on
the rotational speed ω, which is expressed in radiant/second [rad/s], while RPM uses 1 minute as time unit, so 1 RPM = 1 rotation per minute = 1
rotation/60 seconds; the number 60 of this little ratio has just moved to the numerator of the formula, thanks to math’s operations.
Now we can look again at the graph, to immediately find out that power here is not in Watts like in (1.9), but in horse power [Hp]. We like the metric
system, which AC uses, so we won’t change (1.9), instead we’ll convert any type of HP 63, imperial (mechanical) or metric, to Watts.
With the following formulas you can convert respectively imperial and metric Hp in Watts, which you will then input into (1.9):
𝑊𝑊 = 𝐻𝐻𝐻𝐻(𝐼𝐼) ∙ 745,699 (2.0)
𝑊𝑊 = 𝐻𝐻𝐻𝐻(𝑀𝑀) ∙ 735,5 (2.1)
We keep talking about different units and at this point you may be wondering why. You’ll encounter many types of power graphs, so to understand them we
need to distinguish power at the wheels from the engine power previously mentioned, which are similar concepts often confused.
In simpler words, what’s the difference between HP (power at the wheels) and BHP (engine power)?
Horsepower or Indicated power (HP), is simply the engine’s power, measured at the front/rear axle or at the wheels (Fig.). This is the power the whole vehicle
delivers when we drive.
Brake horsepower (BHP) is a measurement of the engine’s power taken at the flywheel or crankshaft without the engine losing power due to drivetrain and
gearbox resistance. This means that the bhp of an engine will always be higher than the hp. If you had to put it in a simple formula it would be something
like this:
𝑃𝑃𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 (𝑏𝑏ℎ𝑝𝑝) = 𝑃𝑃𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 (ℎ𝑝𝑝) + 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 (𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑)
After an engine model has been selected for a specific vehicle, it is tested to check how much power it delivers and how it performs (stress tests). The power
delivered by engine alone is calculated by a device called dynamometer. In the setup, special brakes or loads are applied along with sensors to the crankshaft
end to measure the torque at a certain RPM; look at Fig.right for example.
While performing the tests, torque and RPM are thus known in the above equations and so we can calculate power.
Since the power delivered by engine is calculated by applying brakes during testing, it is popularly called as brake horsepower.

Fig. – Simple visualization of how power at the engine and at the wheels are distinguished. Whenever you see them you have to immediately recall this image.

In Europe, the DIN 70020 standard tests the engine fitted with all ancillaries and exhaust system as used in the car. The older American standard by Society
of Automotive Engineers/SAE International, prior to 1972, (SAE gross horsepower, referred to as bhp) used an engine without alternator, water pump, and
other auxiliary components such as power steering pump, muffled exhaust system, etc., so the figures were higher than the European ones for the same
engine. The newer American standard (referred to as SAE Certified Power) tests an engine with all the auxiliary components. In the early 2000s SAE tightened
its horsepower rules to eliminate the opportunity for engine manufacturers to manipulate factors affecting performance such as how much oil was in the
crankcase, engine control system calibration, and whether an engine was tested with high octane fuel. In many cases, such can add up to a change in
horsepower ratings.
So there are various factors you need to recall when you search for an engine/vehicle power/torque graphs. As long as you want a car mod to be realistic.

63
The same conversion formulas (2.0) and (2.1) can be used for metric/imperial bhp. As far as the measurement unit goes, typically 1 hp = 1 bhp.

401
Fig. – How HP is measured (on the left) vs how BHP is measured (on the right).

Pro tip: the power graph you can see in Content Manager (with the red colour, see Fig. below) is the engine BHP calculated FROM the torque curve at the wheels, so that curve
won't necessarily match dyno graphs.

Fig. – Do not use Content Manager’s graphs as a reference point, they may be confusing (and especially wrong).

If you have the power curve (HP) of your vehicle, you can convert it directly to torque using in order (2.0) or (2.1) and (1.9), then input the values in torque.lut.
If you have the BHP curve of the engine instead, you’ll need to convert power to torque like before, but then you have to account for the loss due to mechanical
friction of the transmission to obtain the torque at the wheels; it depends mostly on the efficiency of the powertrain, and unless you have very specific data,
you can only estimate it. We’re also going to assume that there is no slip in the clutch or torque converter, the engine being mechanically linked to the wheels.
To convert actual engine power to wheel power, subtract 10-15% for road cars, 15-19% for race cars 64, and as much as 20-22% for vintage cars. But be wary
on manufacturer estimates for the transmissions, as they can be lower/higher than in reality.
Different gears do not have an impact on the torque curve (torque.lut), since the ratios are already accounted for in the drivetrain.ini config file. The only factor
that changes the torque in the LUT, as already mentioned, is the friction given by the transmission. In reality, torque differences can also exist given the fact
that you’re using different gear pairs, each with their own friction, weight and moment of inertia, but those are insignificant and can be ignored.
- Until now, we worked with imperial measurement units, [hp] and [bhp], but if you have dynamometer graphs with SI units, the distinction between engines
and wheels may be difficult, as you will work directly with watts [W] as power unit, whether the measurement was at the crankshaft or at the wheels (Fig.).

Fig. – As you can see, this engine power graph has SI units. If the sheets you find are almost blank, with no title or caption, good luck determining whether it is engine or wheel power.

64
Higher percentage of compensation? Yes, racing drivetrains are less efficient but more robust.

402
- As a side note, be careful with reading data at the ends of in the dyno graph; see Fig. , the massive jump in torque from 1500 to 2000 is very unusual
(read: likely incorrect) and could perhaps be caused by the throttle not being depressed fully within that interval.

Fig. - In this case, the given range is 1200~6500 RPM.

- Engine torque is also tied to throttle pedal input: at 0% pedal input AC ignores the throttle LUT and applies 0 torque. This is due to the artificial damping of
the cars when stopped (see pag.).
- If you want an estimation of engine inertia you should find flywheel weight and diameter and maybe clutch housing weight & diameter, since it’s linked to
the flywheel. Everything that rotates has an inertia, but those parts will be the greater component because they have both a considerable weight and gyration
radius.
- The RPM_TRESHOLD value sets the redline. It refers to the maximum engine speed at which an internal combustion engine or traction motor and its
components are designed to operate without causing damage to the components themselves or other parts of the engine. The redline of an engine depends
on various factors such as stroke, mass of the components, displacement, composition of components, and balance of components.
The word is also used as a verb, meaning to ride or drive an automotive vehicle above the redline. The actual term redline comes from the red bars that are
displayed on tachometers in cars starting at the rpm that denotes the redline for the specific engine (Fig.).

Fig. - Tachometers with redlines above 6000 RPM. From left to right: Porsche, Jaeger, Ferrari (Veglia).

Operating an engine in this area is known as redlining. Straying into and trespassing this area usually does not mean instant engine failure, but may increase
the chances of damaging the engine.

- Adding turbo compressors:

Turbos work by taking energy from the exhaust with an exhaust impeller and then transferring it to build pressure into the intake pipes with an impeller on
the intake side. This extra air increases the amount of power that your vehicle can produce.
But since it is quite a big area to build pressure into the intake pipes, it takes a little time to give you the power output you’re looking for. This lag time is
called turbo lag.
The only way to have a correct turbo curve, is to start with a turbo engine dynamometer sheet, and match that run (converting to torque) in torque.lut. You’d
think another way is to find the curve for a naturally aspirated engine (NA) and add whatever turbo you like, because reverse engineering the turbo curve with
just a dyno graph is not very fun; it’s easier but wrong: turbo works with pressure and influences torque. The two things have to be separated: the pressure is
a curve that you can either approximate (with the basic lines under the [TURBO] section) or plot into a separate LUT, while the torque generated is “baked”

403
into the engine torque. If you don't have the real-world pressure curve, just estimate it. If you have it, match it with the respective LUT in the controllers, then
adjust torque.lut according to the dyno graph.
Keep in mind that in AC, turbos are multipliers for the engine torque, because the formula is, at any given RPM:
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = (1 + 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵) ∙ 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝. 𝑙𝑙𝑙𝑙𝑙𝑙
Where Boost depends on MAX_BOOST, WASTEGATE, REFERENCE_RPM and GAMMA. Being a multiplier, Boost has no dimension. This formula
shows that when boost pressure is =1.0, torque is =2.0.
GAMMA is the turbo pressure sensitivity on the gas pedal. It makes the turbo boost build with more or less accelerator pedal input. An old laggy turbo will
need a high value so that you will have to press the gas pedal to the max to start building boost. Vice versa for a modern small inertia turbo.
The maximum generated boost at a given rpm is governed by the following relationship:
GAMMA
𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ∙ 𝑅𝑅𝑅𝑅𝑅𝑅
𝐵𝐵𝑚𝑚𝑚𝑚𝑚𝑚 = MAX_BOOST ∙ min �1, � � �
REFERENCE_RPM

So if you've got a 3100 rpm reference, if you are at 100% throttle 3100 rpm or 50% throttle 6200 rpm, you get full boost.
The minimum does seem to be present regardless of wastegate setting.
Pro tip: use the Car physics app to troubleshoot in-game boost pressure. See p. for more details.

In addition, AC’s turbo model is not really meaningful for free-revving, it only makes sense if torque is being applied to the tires.
% ▼ Turbo LAG_UP refers to the difference in time between when you press the accelerator and when the turbo kicks and starts delivering extra air to your
engine.
% ▼ Turbo LAG_DN refers to the difference in time between when the turbo is at full pressure and when the turbo reaches zero pressure while spinning down
(spool down time).
1.0 values for both LAG_UP and LAG_DN being fully filtered, 0.0 being unfiltered. Typical values are over 0.980 - 0.990, lag increases dramatically for
every 0.01 when nearing 1.0.

% LAG_DN and LAG_UP control how quickly the turbo boost spins up or down, using the formula (LAG_UP * previous boost + (1-LAG_UP) * next boost) every
frame. it uses LAG_UP if the max boost curve is higher than the current amount, LAG_DN if it's lower. Turbo lag has nothing to do with boost, it’s the
delay in pressure building. It has nothing to with the torque calculation.

You can set up a turbo so that it's only adjustable in setup, without the number 1-10 hotkeys, by setting COCKPIT_ADJUSTABLE=0 and adding turbo
entries in setup.ini.

- Adding superchargers:
A supercharger uses almost the same principles of a turbo; the difference is where the
energy to make it work comes from.
You see, while a turbo uses the pressure of the exhaust gases to spin its turbine, the
supercharger is belt-driven from the engine crankshaft, so it takes power directly from it.
As a consequence of this, superchargers just change the torque curve.
They deliver a decent power at lower RPMs, and have no spool time (lag), meaning you
enjoy the effects straight away (there’s a bit of lag actually, the spinning motion is not 1:1
exactly tied to throttle, but you can ignore it, especially if you don’t have a precise measure).

In AC you’re supposed to bake them into torque.lut, as Kunos did for example with the Lotus
Elise SC. If you have a supercharged vehicle dyno sheet just type the values into torque.lut. The turbo functions in engine.ini add turbo lag and wastegate
valves which superchargers do not have, although they have blowoff valves which change the off-throttle behaviour a bit, but there's not really anything to
do about that in AC.

If you want boost gauges to work on the dashboard of the car though, you can add a small “fictional” turbo, basically with zero boost (0.001bar for example)
and no lag, just for aesthetic purpose.

The problem of sound:

If you want to add more immersion thanks to your supercharger, bake its sound into the engine samples; otherwise tie the sound to the turbo Event of your
soundbank and add the “fictional” turbo in engine.ini, this way it should sound more realistic.

- The engine LIMITER:

Most modern cars have computer systems that prevent the engine from straying too far into the redline by cutting fuel flow through the fuel injectors/fuel rail
(in a direct-injected engine)/carburettor or by disabling the ignition system until the engine drops to a safer operating speed. This device is known as a rev-
limiter and is usually set to an RPM value at redline or a few hundred RPM above.
Most Electronic Control Units (ECUs) of automatic transmission cars will upshift before the engine hits the redline even with maximum acceleration (The
ECU in a sports car's automatic transmission will allow the engine to go nearer the redline or hit the redline before upshifting). If manual override is used,
the engine may go past redline for a brief amount of time before the ECU will cut power to pull it back or auto-upshift. When the car is in top gear and the
engine is in redline (due to high speed), the ECU will cut fuel to the engine, forcing it to decelerate until the engine begins operating below the redline at
which point it will release fuel back to the engine, allowing it to operate once again.

However, even with these electronic protection systems, a car is not prevented from redlining through inadvertent gear engagement. If a driver accidentally
selects a lower gear when trying to shift up or selects a lower gear than intended while shifting down (as in a motorbike sequential manual transmission), the
engine will be forced to rapidly rev-up to match the speed of the drivetrain. If this happens while the engine is at high RPMs, it may dramatically exceed the
redline. For example, if the operator is driving close to redline in 3rd gear and attempts to shift to 4th gear but unintentionally puts the car in 2nd by mistake,

404
the transmission will be spinning much faster than the engine, and when the clutch is released the engine's rpm will increase rapidly. It will lead to a rough
and very noticeable engine braking, and likely engine damage. This can actually happen in AC.

The limiter is well before you theoretically lose all torque, and in real life the engine will explode before that point anyway.

- What’s the relationship between throttle percentage (%) and output torque at any given rpm? In AC, it is calculated by default taking directly the values
inside torque.lut with a linear interpolation between them; however, you can change the relationship between accelerator pedal and engine (aka the shape of
the throttle curve) with throttle.lut.
About the [THROTTLE_RESPONSE] section: it’s a vanilla feature present since AC 1.15, dedicated to modders, that’s why it is not seen very often in
mods and official content. It is used for changing how the engine reacts to the gas pedal input, like modern ECUs with a different curve for starting from idle,
for low RPM, for high RPM, etc. The so-called Sport and Eco modes work by altering how the throttle works too.

But since in AC throttle is just a power percentage input, it is a simplified system. As already mentioned in the script descriptions, only a maximum of two
look-up-tables can be used: throttle.lut is the first, which you can directly put in the data files without referencing it in engine.ini; the second one, which you
can call however you like, must be referenced in the LUT line. The CSP mod changes this.

“Why are two tables available?” you may ask. You see, they are combined together to create different throttle response maps. throttle.lut will be used as base
curve from 0 RPM and above, while whichever second LUT you specify will be used from when the engine reaches the RPM_REFERENCE and below, with
a linear interpolation between the two LUTs until that value (Fig.).

For clarity purposes, let’s consider 6000 RPM our reference, thus let’s call a second table throttle_6000.lut. I recommend to follow a similar practice when
you will work with your files, distinguish them with the rev number to have an easier time, especially when making complex curves.

Fig. – Clarification of how LUTs are interpolated: the transition between the values is smooth, and at the extremes are found the exact values of the configured maps.

If say throttle.lut is 50|30, and the second map is 50|50, before the REFERENCE_RPM the throttle would be in between them, so 40% output. And of
course after it would be fully onto 50%.

You can check the log.txt file to see if the system is working - it will record if it is loading the .lut files. When you start the race session it also prints out a
whole 2d chart, beginning with "THROTTLE RESPONSE TABLE", showing a table of RPM vs gas values (every 1000 RPM, and that may be confusing).
Refer to p. for AC debug logs.
Pro tip: It shall be noted that throttle.lut may also be used alone, without the [THROTTLE_RESPONSE] section, to configure a simple throttle curve.
More importantly, you should be aware that if you’re playing AC with mouse or keyboard the throttle will always be at 100% whenever you click or press the gas button. So it
is more difficult to test properly the throttle response without a pedal controller, but you can still determine accurately the numbers in the LUTs via engine map curves (if you
can find them).

- If you really have time to waste or you’re just interested, you can try using the Lotus Engine Simulation software (Fig.), which you can find here for free:
https://www.lotusengineering.com/engineering-software.

Fig. – (top) A quick test I made with a four-cylinder engine. Not quite like Simulink, maybe more similar to Working Model 2D. There are panels with a ton of options, and animations.

I have yet to become familiar with this program, however it’s old-school and quite nice. Seems promising. It has also a data-checking wizard that lets you
know of eventual errors.

ABOUT RELATED FILES

Controllers:
405
ctrl_turbo0.ini
This config manages turbo controllers. It can be renamed based on how many turbos you have
[CONTROLLER_0]
INPUT=RPMS
COMBINATOR=ADD
LUT=(|0=0.525|7200=0.525|8500=0.47|)
FILTER=0.99
UP_LIMIT=10000
DOWN_LIMIT=0.0
ctrl_wastegate0.ini

LUTs:
torque.lut
This is the torque curve of our vehicle. The numbers on left are RPM, those ones on right are torque in [Nm] at the wheels, including any drivetrain losses.
Oh, and I should note, these values are before any turbos. The torque used in power.ini is effectively from a vehicle with N/A (Natural Aspirated) engine.
Turbines are to be added later.
Example: engine_example.lut
0|70
500|70
1000|70
1500|70
2000|113
2500|118
3000|128
3500|129
4000|114
4500|112
5000|110
5500|103
6000|100
6500|91

Pro tip: remember that in official vehicles and most mods this LUT is mistakenly called power.lut.

throttle.lut
This is the base throttle response curve. The numbers on the left are throttle % input, on the right you have torque % output. Example:
0|0
10|30
20|50
30|60
40|70
50|75
60|80
70|85
80|90
90|95
100|100

It works basically as a multiplier for the torque from torque.lut. Also, you do not need to specify all the percentages, since the values are interpolated, as
usual with LUTs. So do not put hundreds of values, it is not necessary.

It is the only LUT that doesn't need a reference in the config files. Why? Because it is already hardcoded in AC, see Fig.

Fig. – An extract, straight from the code of acs.exe. As you can see “throttle.lut” is already referenced.

If you want to use an additional throttle map for the [THROTTLE_RESPONSE] section of engine.ini, the file is identical, but it must be referenced.

COAST CURVE EXAMPLE

0: 6.818182
500: 2.272727
1000: -2.272727
1500: -6.818182
2000: -11.363636
2500: -15.909090
3000: -20.454544
3500: -25.000000
4000: -29.545454
4500: -34.090908
5000: -38.636364
5500: -43.181816
6000: -47.727272
6500: -52.272724
7000: -56.818180
7500: -61.363636
8000: -65.909088
8500: -70.454544
9000: -75.000000

(since COAST LUTS aren’t likely working in AC with all its bugs aaaaaah TUT, you can try using KERS, that one at least should work)

CSP ADDITIONS

406
- The ALTITUDE_SENSITIVITY of engine.ini is part of a function sadly not implemented well in vanilla AC; it won't affect turbos/engine as it should. It
does work, but at the same time it doesn’t; anything that's altitude sensitive does have code to handle it, it's just never told it's not 0 in vanilla. In fact, you
can't even set the track altitude, each map just has a certain fixed air pressure.
The principle behind altitude sensitivity is that going very high above the sea level, the air pressure reduces, along with its density, thus the engine has less
combustion agent to burn the fuel, and struggles more and more the higher you go, to the point that’s even difficult to breathe for humans and you need
oxygen 65. This is a phenomenon well known to mountaineers and climbers.
However, altitude effects have been implemented for a while for cars using extended physics brought by CSP. When you enable extended physics, the patch
will change the Assetto Corsa internal air density, which affects aero (already happens in vanilla) and engines (already happens in vanilla but it’s a bit better
with CSP), according to altitude. It is not used for cars without extended physics since it would cause online compatibility issues (read “cheating”).
To enable altitude sensitivity effects, it is necessary that the track has a new [ALTITUDE] section added to surfaces.ini (see pag.).
The elevation change alters the power of the engine. NA engines are pretty much proportional to air density, so the code just portrays that.
The ALTITUDE_SENSITIVITY line was not recycled by the mod because very often people put in totally random values for it, so many car mods would
have been totally broken (engine too sensitive if the line had a value of, say, 10).
Pro tip: there is a problem with electric cars: in real life electric motors are not affected by elevation change, so if you adopt extended physics you should add a small turbo to
compensate for the power loss at high altitudes. The better option however would be to avoid using extended physics.

- The patch adds new options for turbos, only available with extended physics: LUTs for the gas pedal and spin delay.

The following is an example of the vanilla section we learned previously, with the new lines (EXT_GAS_CURVE and EXT_SPIN_DELAY):
[TURBO_0]
LAG_DN=0.985
LAG_UP=0.9965
MAX_BOOST=1.0
WASTEGATE=0.58
DISPLAY_MAX_BOOST=0.58
REFERENCE_RPM=2500
GAMMA=4
COCKPIT_ADJUSTABLE=0
EXT_GAS_CURVE=(|0=0|0.3=0|1=1|)
EXT_SPIN_DELAY=0.2

In AC the gas pedal is used as a multiplier for turbo activation. With EXT_GAS_CURVE (which could also be a file name instead of inline LUTs), you can
remap that multiplier value, for example, stopping turbo from activating until pedal is pressed to at least 30% of its range. A somewhat similar effect could be
achieved in vanilla with the ctrl_turbo#.ini controller using INPUT=GAS, but a LUT allows to alter the value before gamma is applied. The default value (in
case you wanted to recreate the vanilla physics) is EXT_GAS_CURVE=(|0=0|1=1|).

As for EXT_SPIN_DELAY, it adds some sort of negative turbo pressure, extending the boost range. Engine would act as naturally aspirated (NA) until
turbo would spin beyond zero point. With EXT_SPIN_DELAY=1, if original turbo boost would equal 0.5, after altering, it’ll drop to 0, and would climb
from there. With EXT_SPIN_DELAY=0.5, it would be 0.33 (not very clear). Default value (again, for vanilla-style physics) is EXT_SPIN_DELAY=0.

- The usage of throttle response maps is changed, with more than two LUTs now available. This is done by adding a [MAP] section in engine.ini:
[MAP]
DEFAULT=0 ; Default map index.
MAP_0=engine_map0.lut ; File reference for the CSP throttle LUT (it is NOT like throttle.lut) in the car data.

% ▲▼ The number after MAP_ is the throttle map’s index. This is important for later, when working with setup.ini.

MAP_1=engine_map1.lut
MAP_2=engine_map2.lut
[...]

% ▲ A vehicle can have as many throttle maps as necessary.

The tables themselves here do not correspond to what you find in vanilla (throttle.lut): the values are still multiplying torque.lut, but they are RPM at the
input and torque multiplier (percentage in decimal number, so 1.1=110%) at the output, like this:
0|1
250|1.01
500|1.02
750|1.03
1000|1.04
1250|1.05
1500|1.06
1750|1.07
2000|1.08
2250|1.09
2500|1.1
2750|1.11
3000|1.12

It’s a much simpler approach compared to the vanilla [THROTTLE_RESPONSE] section. If you want to have a throttle map that leaves the original engine
power untouched, put ones at the outputs.

In Fig. you have a demonstration of what it is possible to achieve.

65
Hopefully this doesn’t happen when you drive in a simulator!

407
Fig. – How different ECU modes can be recreated thanks to CSP.

The engine throttle maps implemented with the mod can be managed from the setup screens too, editing setup.ini. Example:
[ENGINE_MAPS]
SHOW_CLICKS=0 ; The function is the vanilla one from the setup.ini script.
TAB=GENERIC ; The chosen tab for the engine map selection (in AC setup screens).
NAME=Engine Map ; Name of the engine maps group (you can use it as the name of the car’s ECU).
LUT=engine_map_setup.lut ; A look-up-table that specifies which are the single engine maps in the group.

% ▲ The format of the LUT is: name|index. It can also use the traditional system of indexing, just make sure your indexes don't go out of bounds of your
MAP_# entries. Example:

Standard|0
Tuned|1
Eco|2

POS_X=0.5 ; The function is the same as the vanilla one. Again, look at the setup.ini script.
POS_Y=3 ; Same as the line above.
HELP=NULL ; Same as the line above.

You can also associate a key binding to change them while driving (CTRL+E is the default binding).
Pro tip: I would advice to remove any vanilla throttle LUT if you choose the CSP method, it is not clear if they are overridden or they act on top of each other.

- This is important when working on physics: for mouse and keyboard users, CSP 1.70 introduced a new method of applying throttle: Forced throttle. See p.
of PART 1: AC USER MANUAL for more details.

FAQ
QUESTION [1]: There are no values that control the horsepower in engine.ini, only the torque.lut. I don't know how to modify it.
ANSWER [1]: You can’t define the power of an engine throughout all of its possible rotational regimes (RPM) with only one maximum value, you need
what’s called a “power curve”. If you want to modify it for an existing vehicle, you open the torque.lut Look-Up-Table with any text editor. But modifying any
number without any correlation between them will be an unrealistic mess.
Q [2]: I want to make a fully electric powertrain for a car but I'm having trouble understanding how electric motors work in AC.
A [2]: There’s not much to it. You can simulate electric motors with peak torque at 0 rpm, and adopt one drivetrain gear.

408
ENGINE PHYSICS
- To calculate fuel consumption, what one could try is the cylinder volume times revolutions per minute. Indeed, this gives the volume per minute of air-fuel
mix entering each cylinder of the engine. The point is that the air-fuel mix is not all fuel, and operates at varying pressure. Also, not all of it is burned in one
stroke. So no conclusion here.
In real life a motor’s fuel consumption is measured through experiments and recorded as a function of speed (RPM) and load (torque). It is called BSFC
(Brake-Specific Fuel Consumption), the rate of fuel flow mass rate [kg/s] divided by the effective output power produced [W]:
𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = [𝑘𝑘𝑘𝑘/𝐽𝐽]
𝑃𝑃𝑒𝑒
Engine power is the product between engine speed and torque. Therefore, we can express the BSFC function of engine speed and torque:
𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = [𝑘𝑘𝑘𝑘/𝐽𝐽] (yyyy)
𝜔𝜔𝑒𝑒 ∙𝑇𝑇𝑒𝑒

where 𝑇𝑇𝑒𝑒 is the effective (brake) engine torque 66 in [Nm] and 𝜔𝜔𝑒𝑒 is the engine speed in [rad/s].
Usually, the fuel mass flow rate is measured in [g/s], the engine power in [kW], which gives the brake specific fuel consumption in [g/kW·h]. Just multiply
the BSFC you get by 3600.

Engine torque can also be defined function of the mean effective pressure (MEP) of the engine.
𝑛𝑛𝑐𝑐 ∙𝑉𝑉𝑑𝑑 ∙𝑝𝑝𝑚𝑚𝑚𝑚
𝑇𝑇𝑒𝑒 = (cdnv)
2𝜋𝜋𝑛𝑛𝑟𝑟

where 𝑛𝑛𝑐𝑐 is the number of cylinders, 𝑉𝑉𝑑𝑑 is the cylinder displacement 67 [m3], 𝑝𝑝𝑚𝑚𝑚𝑚 is the mean effective pressure [Pa], 𝑛𝑛𝑟𝑟 is the number of crankshaft
rotations for a complete engine cycle (for 4-stroke engine 𝑛𝑛𝑟𝑟 = 2).
The MEP can be regarded as an average pressure in the cylinder for a complete engine cycle. By definition, mean effective pressure is the ratio between the
work and displacement:
𝑝𝑝𝑚𝑚𝑚𝑚 = 𝑊𝑊/𝑉𝑉𝑑𝑑
where W is the work performed in a complete engine cycle [J]. From equation () we can write the expression of the engine work as:
𝑊𝑊 = 𝑝𝑝𝑚𝑚𝑚𝑚 · 𝑉𝑉𝑑𝑑
There is also a direct relationship between the power of the engine and the work produced:
𝑊𝑊 = (𝑛𝑛𝑟𝑟 · 𝑃𝑃)/𝑛𝑛𝑒𝑒
where P is engine power [W], 𝑛𝑛𝑒𝑒 is the engine speed in [rps], aka rotations per second =RPM/60.
By making equation () equal to (), we get the expression of the mean effective pressure function of power and engine speed:
𝑝𝑝𝑚𝑚𝑚𝑚 = (𝑛𝑛𝑟𝑟 𝑃𝑃)/(𝑛𝑛𝑒𝑒 𝑉𝑉𝑑𝑑 )
Power can be written once again, as in (), as the product between torque and speed, so we get the expression of MEP, function of engine torque:

𝑃𝑃 = 𝜔𝜔𝑇𝑇 = 2𝜋𝜋𝑛𝑛𝑒𝑒 · 𝑇𝑇 ⇒ 𝑝𝑝𝑚𝑚𝑚𝑚 = (2𝜋𝜋𝑛𝑛𝑟𝑟 · 𝑇𝑇)/𝑉𝑉𝑑𝑑

As you can see, from expression (), the mean effective pressure is not influenced by the engine speed. Also, since the torque is divided by the engine
capacity, the mean effective pressure parameter can be used to compare internal combustion engines of different displacements.
For an engine with multiple cylinders we have to take into account the total volumetric capacity. We only have to multiply the volume of one cylinder with the
number of cylinders 𝑛𝑛𝑐𝑐 . The expression of mean effective pressure becomes:
𝑝𝑝𝑚𝑚𝑚𝑚 = (2𝜋𝜋𝑛𝑛𝑟𝑟 · 𝑇𝑇)/(𝑛𝑛𝑐𝑐 · 𝑉𝑉𝑉𝑉)
Mean effective pressure is used for initial engine design calculations, with engine torque and MEP as inputs, the engine designer can calculate what is the
required engine volumetric capacity. Remember that mean effective pressure is only a parameter to measure engine performance and does not reflect the
actual pressures inside an individual combustion chamber.
Be aware that there are different types of mean effective pressure:
• indicated mean effective pressure (IMEP) calculated with indicated power (work). This parameter does not take into account the efficiency of the engine.
• brake mean effective pressure (BMEP) calculated from the dynamometer power (torque). This is the actual output of the internal combustion engine, at
the crankshaft. BMEP takes into account the engine efficiency.
• friction mean effective pressure (FMEP) indicative of the mean effective pressure of the engine lost through friction and it’s the difference between
indicated mean effective pressure and brake mean effective pressure. FMEP = IMEP – BMEP
Now, replacing (cdnv) in (yyyy), we can write the formula of the brake specific fuel consumption function of the mean effective pressure of the engine:
2𝜋𝜋𝑛𝑛𝑟𝑟 𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = ∙ 3600 [𝑔𝑔/𝑘𝑘𝑘𝑘ℎ]
𝑛𝑛𝑐𝑐 𝑉𝑉𝑑𝑑 𝑝𝑝𝑚𝑚𝑚𝑚 𝜔𝜔𝑒𝑒

66
Brake engine torque is the torque measured at the crankshaft. Read p. and look at Fig. for clarification.
67
For one cylinder, the displaced volume is the product between the stroke of the piston and the area of the cylinder circumference.

409
The lower the brake specific fuel consumption, the more efficient the engine is. For spark ignition (gasoline engine) the BSFC is around 250 g/kWh and for
compression ignition (diesel) around 200 g/kWh.

BSFC plots are like topographic maps: small round shapes inside larger round shapes, with each shape having a constant BSFC value (isoline). And the
axes of the plot are speed and load.

Fig. – This graph adopts BMEP as you can see. The lowest BSFC is represented by an “island”, usually at medium engine speeds and high torque (load), close to peak full load torque.

Suppose that we’re looking for optimum fuel consumption. Then we need that plot, and we need to look at the smallest isoline inside all the other shapes.
Note that it is associated with a unique (x, y) combination.

In the end, is all this worth the effort? Probably not, at least for AC. Maybe the next title? At least you learned something.

410
20. ers.ini
This script allows the configuration of the ERS (Energy Recovery System) of your vehicle. It finds most of its applications on moder Formula cars and
prototypes. Hybrid commuters can make use of some features too.
[HEADER]
VERSION=1

[KINETIC] ; MGU-K configuration.

CHARGE_K=0.00014 ; Charge as function of brake torque (include engine) and rotation speed.
TORQUE_CURVE=kers_torque.lut ; File reference for the torque curve LUT in Nm/RPM.
COAST_CURVE=kers_torque_coast.lut ; Coast Torque curve Nm/RPM.
DISCHARGE_TIME=87000 ; Time to discharge the MGU-K or KERS, when used to deliver torque. [ms]
HAS_BUTTON_OVERRIDE=1 ; Boolean.
MAX_KJ_PER_LAP=10000000 ; Maximum energy discharge allowed per lap, given by race regulations. [kJ]
DEFAULT_CONTROLLER=0 ; Values: 0= 1=
BRAKE_REAR_CORRECTION=30 ; Torque removed from rear axle as function of kinetic recovery. [Nm]

[HEAT] ; MGU-H configuration.

CHARGE_K=0.002 ; Charge as function of turbo boost percentage.
TORQUE_PERC=10 ; % of torque the Heat is able to generate from the kinetic motor.

[COCKPIT_CONTROLS] ; Specify if the controls below should be available for cockpit operation.
RECOVERY=0 ; Boolean logic operator: 0=False, 1=True.
DELIVERY_PROFILE=1 ; “ “ “
MGU_H_MODE=0 ; “ “ “

LITTLE EXPLANATION
- First of all, what is an ERS system?
The power unit used in Formula 1 cars is hybrid; partly the “classic” combustion engine which we’re used to know, partly the ERS. The latter has been used
in some form or another since 2009.
All ERS are the same in terms of their basic concept: they allow the car to save energy that would otherwise be wasted, and use it when necessary. However,
with time the designs have changed a bit since.
The first ERS introduced to F1 was KERS (Kinetic Energy Recovery System), very well known to the public. It used either a flywheel or an electricity
generator with a battery to store the car's kinetic energy that would have otherwise been lost during braking, and supplemented the engine's power when
needed.
These days, Formula 1 cars are equipped with a different assembly, which essentially consists of four parts:
• Two electric motors, MGU-K (Motor Generator Unit – Kinetic) and MGU-H (Motor Generator Unit – Heat);
• An ECU (Electronic Control Unit) and an energy storage unit, consisting of a battery pack.

The motors are the heart of the contraption:

The MGU-K is connected to the crankshaft before the clutch, which exchanges mechanical power with the rear wheels. Under acceleration, it can deliver up
to 120 kW (about 160hp) with a maximum torque of 200Nm, with a spin limit of 50'000 rpm.
The regulations impose a limit of deliverable energy per revolution of 4MJ (as of 2020, check newer). The delivery of electric power is set through maps that
distribute electric power according to the gear used and speed.
When braking, on the other hand, the unit acts as a generator and derives electrical energy by dissipating mechanical energy from the crankshaft. It actually
takes energy from the rear wheels and converts it into electrical energy. The regulations again impose a limit on absorbable energy per lap of 2MJ.
The intensity of motor braking can be set from the pitbox and affects braking stability.
The MGU-H system consists of a control unit and an electric motor keyed directly to the axis of the engine turbine. This system limits the rotational speed of
the turbine by generating electricity that can be stored in batteries or can be used instantaneously by the MGU-K. When active, the MGU-K adds about an
extra 161 horsepower to the car's total power output. Its rotational speed is limited to 125'000rpm, and the regulations do not impose power generation
limits. The drivers can only use the MGU-K for a short amount of time each lap, however.
The MGU-H also functions as an engine by rotating the turbocharger even during deceleration. This system allows for nearly zero turbo lag, a problem that
plagued turbochargers in the 1980s.
Finally, we have the energy storage unit, which is made of batteries. The capacity of the batteries is 4MJ, and the ECU regulates energy delivery and
absorption.

- There is the possibility to change ctrl_ers mode with a button.

ABOUT RELATED FILES

LUTs:
Controllers:
ctrl_ers.ini
[HEADER]
NAME=Charging

[CONTROLLER_0]
COMBINATOR=ADD ; COMBINATOR MODE: ADD or MULT
INPUT=GAS ; Telemetry channel input.

% ▲ List of telemetry channel inputs (put at the beginning of controllers?) SLIPRATIO_MAX SLIPRATIO_AVG LONG LATG BRAKE0-1 GAS0-1 STEER-1+1 SPEEDKMH GEAR

LUT=ers0_gas.lut ; input data to kers delivery lookup table

FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1 ; kers delivery min limit (can be negative)

[CONTROLLER_1]

411
COMBINATOR=ADD ; COMBINATOR MODE: ADD or MULT
INPUT=BRAKE ; telemetry channel input.
LUT=ers0_brake.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1 ; kers delivery min limit (can be negative)

[CONTROLLER_2]
COMBINATOR=MULT ; COMBINATOR MODE: ADD or MULT
INPUT=SPEED_KMH ; telemetry channel input.
LUT=ers0_speed.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1

[CONTROLLER_3]
COMBINATOR=MULT ; COMBINATOR MODE: ADD or MULT
INPUT=GEAR ; telemetry channel input.
LUT=ers0_gear.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=0 ; kers delivery min limit (can be negative)

412
21. escmode.ini
This config sets the parameters for the camera that orbits 360° around the vehicle at the beginning and at the end of every session (in the setup/leaderboard
menu in pits or on the starting line) when you press F5 before driving. After you start driving, this camera movement is disabled and AC switches to the last
camera used in the previous sessions.
[SETTINGS]
POSITION=0,1.4,3 ; Position of the camera, referenced from the vehicle’s origin / CoG (center of gravity) in xyz. [m]
FOV=45 ; Field of View (FOV) angle of the camera. [deg]

LITTLE EXPLANATION
- At the beginning and end of every vanilla race session this camera enables automatically, whether you’re still on the track or you’re in pits (Fig.). The only
difference is that it stays still, looking at the vehicle side.

Fig. – REPLACE IMAGE

- If you press F7 you can enable the free camera, thus deactivating it temporarily, but doing this in the post-race screen is not very useful to look around
since the view is covered by the AC lap times GUI (Fig.).

Fig. – The camera in the vanilla session end screen is managed by escmode.ini.

413
22. extra_animations.ini
Additional animations can be configured with this script. Rotating objects can also be controlled here. This is the right place to add a simple spinning
movement to a fan. Bear in mind that everything is just visual, any moving or rotating object will not have any impact on the physics, independently from its
shape.
[ANIMATION_0]
FILE=extra_boot.ksanim
MIN=0
MAX=100

[ANIMATION_1]
FILE=extra_hood.ksanim
MIN=0
MAX=100

[ROTATING_OBJECT_0]
NAME=FAN ; Name of the dummy that rotates.
RPM=100 ; Rotational speed of the NULL. [rpm], [gg./min], [U/min], [tr/min], [об/мин]

% ▲ As there is no blurred texture, unlike for blurred rims, after a certain speed the rotation actually starts looking slower due to framerate, so keep
this value around 100.

AXIS=1,0,0 ; Axis of the rotation movement.

LITTLE EXPLANATION
- Properly set animations can be used in the vanilla Showrooms to open the trunk or the hood of the vehicle using numpad 4 and 5; this won’t be possible
during a race session. CM showrooms integrate the animations by activating them via checkboxes. Look at the Porsche 917/30 Spyder for an example of the
implementation of this feature.

Fig. –

414
23. flame_presets.ini
The lines of code below manage mainly the backfire animation and the colour of the flames of your vehicle. There are also other parameters. Flame types
It is suggested to read the explanation of the flames.ini for a better understanding of how flames work in AC. The two scripts are complementary when using
the latest version of the flame behaviour (v2).
[HEADER]
SIZE_MULT=1 ; Size multiplier of the total flame animation.

[PRESET_START_0] ; Starting backfire animation.

TRIGGER=0 ; Animation's frame trigger index.
OFFSET=0.0,0.0,0.02 ; Position of the flame texture.
SIZE=0.05 ; Size of the texture.
TYPE=0 ; 0 = F type texture (f2.dds), 1 = X type (x0.dds), 2 = L type (l3.dds)
RGB=200,150,150,0.5 ; RGB colour multipliers for the flame texture (Red, Green, Blue) + intensity value.

[PRESET_START_1]
TRIGGER=1
OFFSET=0.0,0.0,0.1
SIZE=0.1
TYPE=1
RGB=200,120,155,0.07

[PRESET_START_2]
TRIGGER=2
OFFSET=0.0,0.0,0.08
SIZE=0.07
TYPE=0
RGB=200,120,155,0.08

[PRESET_END_0] ; Ending backfire animation: TRIGGER is inverse because textures start already visible.
TRIGGER=4
OFFSET=0.0,0.0,0.02
SIZE=0.06
TYPE=1
RGB=90,190,150,0.1

[PRESET_END_1]
TRIGGER=2
OFFSET=0.0,0.0,0.06
SIZE=0.04
TYPE=1
RGB=120,120,55,0.07

[PRESET_END_2]
TRIGGER=0
OFFSET=0.0,0.0,0.1
SIZE=0.04
TYPE=2
RGB=120,50,55,0.05

[PRESET_LOOP_0] ; Looping animation (start always included).

TRIGGER=0
OFFSET=0.0,-0.01,0.18
SIZE=0.13
TYPE=1
RGB=150,50,28,0.1

[PRESET_LOOP_1]
TRIGGER=1
OFFSET=0.0,-0.04,0.26
SIZE=0.13
TYPE=1
RGB=100,50,28,0.06

[PRESET_LOOP_2]
TRIGGER=2
OFFSET=0.0,-0.06,0.35
SIZE=0.15
TYPE=2
RGB=100,50,28,0.05

[PRESET_FLASH_0] ; Flash animation : TRIGGER is inverse because textures start already visible.
TRIGGER=2
OFFSET=0.0,0.0,0.00
SIZE=0.04
TYPE=0
RGB=255,90,0,0.01

[PRESET_FLASH_1]
TRIGGER=1
OFFSET=0.0,0.0,0.03
SIZE=0.04
TYPE=0
RGB=255,90,0,0.006

[PRESET_FLASH_2]
TRIGGER=0
OFFSET=0.0,0.0,0.06
SIZE=0.06
TYPE=1
RGB=255,90,10,0.01

LITTLE EXPLANATION
- The full animation of backfire flames is made by the flame_presets.ini file. There are three stages in this anim:
• START
• LOOP
• END

Each one of these stages is made of one or more "frames": each frame has a trigger, color and type for the flame.
The TYPE is the texture group: every texture cycles in its own group.
-Two versions of flames exist in AC: v1 and v2. v1 is older.

415
If flame_presets.ini does not exist in your mod files (inside data.acd or the data folder), then the old flames (v1) will be used. v2 flames are enabled only if
this file is present.
-It is recommended to use v2 flames.
Keep in mind that with v2 the flame textures need to be .dds files.
-When using v1 the animation events are triggered by gas only if in normal mode (in a standard game session); they don’t work with the AC debug console
(see p.). Instead of setting the command with the console you can adjust every stage of the animation using the EDIT_STATE line of flames.ini to switch
stage.

CURIOSITIES AND AMENITIES

-So, in the real world, what defines the color of the flame?
The burning substance, the temperature, the 𝑂𝑂2 (oxygen) content... lots of things.

24. flames.ini
This config manages the flames for backfires. Leave it empty if your car doesn’t backfire. Keep in mind that what actually triggers the backfires’ sound is in
the parameters of the sounds.ini config.
It is suggested to read the explanation of the flames_presets.ini for a better understanding of how flames work in AC. The two scripts are complementary
when using the latest version of the flame behaviour (v2).
[HEADER]
EDIT_MODE=0 ; Deprecated in v2: use "set observeFlames 1" on the console.
INTENSITY=60.0 ; Deprecated in v2
EDIT_BIG=1 ; Useless (stated by Kunos)
EDIT_STATE=0 ; Debug: 0=no visible flame, 1=1st stage (start), 2=2nd stage (loop), 3=3rd stage (end), 4=flash flame
BURN_FUEL_MULT=10 ; Flame's lifetime: lower number = shorter lifetime.
FLASH_THRESHOLD=6 ; Threshold for the main flame. Value between 0 and 10. With the value=11 there are no main flames.

% ▲ The main flames appear only if the current gas/rpm/other stuff total is > of this threshold, if between 0 and 10. The main flame is the biggest
flame, with the prefix “x” on the textures in the flames folder.

% ▼ A car can have as many flames as required/needed. Make a car burning in flames.

[FLAME_0] ; Flame identifier. SYNTAX: [LOD_ID], ID starting from zero.

POSITION=0.830,0.22,-0.49 ; Position of the flame vector (x,y,z), related to the vehicle model origin. [meters]
DIRECTION=1,0,-1 ; Direction of the flame vector.
VSIZE_START=0.15 ; Deprecated in v2
VSIZE_END=0.10 ; Deprecated in v2
LSIZE=0.24 ; Deprecated in v2
IS_LEFT=1 ; Is the flame on the left or the right side of the car? 1=left side, 0=right side
SIZE_MULT=1 ;
GROUP=0 ; Group index of the flame (big exhausts need more flames to fill them).

[FLAME_1] ; Additional flames have the same lines of code as [FLAME_0].

POSITION=0.830,0.22,-0.49
DIRECTION=1,0,-1
VSIZE_START=0.15
VSIZE_END=0.10
LSIZE=0.24
IS_LEFT=1
SIZE_MULT=1
GROUP=0

[FLAME_2] ; A car can have as many flames as required.

[FLAME_3]
[FLAME_4]
[...]

LITTLE EXPLANATION
In order for the flames to work, their textures must be present in a dedicated subfolder called flames inside the texture folder of your FIN mod folder (about
it on pag.). There are flames textures of common use in AC, so you can copy them from another car and they will work; each official car usually doesn’t have
all of them: only some, or none, depending on the type of backfires it makes (or doesn’t make = no tex.). You can find all of them in the extra contents of
this manual.

The following are all the common flames textures you must use; they can be divided in different categories, based on their functions and letter prefix:
FLASH (hence the f prefix): TAIL (hence the l prefix; that’s an L): MAIN (every prefix except f and l):
• f2.dds • l3.dds • x0.dds
• f3.dds • l4.dds • x1.dds
• f4.dds • l6.dds • x5.dds
• f#.dds (additional numbers) • l#.dds (additional numbers) • x7.dds
• x8.dds
• x#.dds (additional numbers)
At least one texture from each of these three categories (FLASH, TAIL, MAIN) must be present to make the car work, unless flames.ini is empty or
flames_presets.ini does not exist. (must verify) Then I could have only three files inside the texture\flames folder.

òòèèòùòùàòD
• 1.png
• 2.png
• 7.png
• 8.png
You can also create and use your own own textures. Just drop them in the aforementioned path (your_car_mod\texture\flames) and use the correct prefix
and file format (.dds for v2 flames & ). [still need more info, may be wrong]

416
CSP ADDITIONS
The New flames brought by CSP ignore vanilla params.

FAQ
QUESTION [1]: I have all the parameters for the flames but they don’t appear in game. What can I do?
ANSWER [1]: Check if you added the flames textures to the texture folder inside the main archive of your mod. Otherwise check the sounds.ini lines dedicated to backfires.

Q [2]: Is there an easy way to adjust the flames positions after adding them to the script? I copied them from another car.
A [2]: Yes, there is. But first and foremost, after copy-pasting the lines of code for each flame in your flames.ini, always check that the numbers in the POSITION have
simple coordinates like 0,0,-1 or 0,1,0 or similar. This way you’ll always know where to look for your flames. Look at Fig. for a clearer explanation of this.
There are actually two methods to adjust the flames positions. They’re quite easy, and each has its pros and cons. Both of them require the car to be working in AC to some
extent, as you will have to look at the result of your edits in a game session.

METHOD 1: Using the AC console

This is the best method in my opinion, because it is very straightforward and almost everything happens in-game, so there’s no way you can get things wrong if you’re adjusting
them live, looking directly at the final result. It is also the first method that ever existed.
It involves the AC console, which you can find an explanation of at par. 6.1. Using the command set observeFlames 1 you can display any change in the flames config
live, during any practice or race session. You adjust the positions to your liking and you’re done. There’s almost nothing done by the machine, you’re the only one who’s
changing the damn numbers on the config file with the text editor. If you pay attention at what you’re doing, there’s a lower chance of errors happening.
This method is also useful when working with flame behaviour and flames_presets.ini, as you can directly give the car some gas and see how it responds.
The only problem of this procedure is that you may need a couple minutes to understand the XYZ directions, but after that your brain will adjust automatically and everything
should be fine. With small changes to the coordinates you will be able to obtain the position you like.
Estimated time to completion: 20’-30’ or more (with zero knowledge), 10’-15’ (after reading, with trial and error), 5’ (nerd)
Pros: Once done it’s done; few tools, low effort. Relax.
Cons: Getting used to orienting with coordinates can take some time.

METHOD 2: Using Content Manager showrooms

Few years ago, when CM didn’t exist, I would have told you to use the console, but now apparently you can do almost everything with this powerful tool. That’s not true and we
know it, otherwise this manual wouldn’t exist. But enough talk. With this method you will use the CM showrooms, which you can see in Fig..
You have to activate the Flames checkbox in the Physics section of the Car tab of the CM showroom GUI. That will make appear a red vector representing the flame position
and direction (Fig.).

Fig. – You can use simple coordinates if you don’t or have difficulty to see the vector in the 3D viewport. Then adjust the POSITION and DIRECTION values to your liking.

Opening the text editor and adjusting the position by hand (Fig.) is possible, but you can also hit the letter T on your keyboard to enable the built-in Edit mode. This way you
can move the vector along the axes or rotate it with some drag and click of the mouse. Then you can save the result (Fig.).

417
Fig. – All in all it’s pretty easy, but be careful.

The main problem of this method is that you can’t look at the final result. You can only edit the position and direction on screen. When working with flame_presets.ini and
flame behaviour, this procedure is not useful at all, so I suggest using method 1 if you want to do that.
Estimated time to completion: 10’-15’ or more (with zero knowledge), 5’ (after reading, with trial and error), 2’ (nerd)
Pros: Moving things with the mouse is easy. Your cat is happy.
Cons: You can’t do everything with it, and some mod tools are required.

418
25. fuel_cons.ini
This file is used by the AI to calculate the amount of fuel before the start of the race session, based on the vehicle’s fuel consumption. Without the
fuel_cons.ini the amount they have at the race start is pretty much random. They will still pit normally when their tank is empty though.
This config can be created with the AI developer app if it's missing, but you need to unpack data.acd or create a data folder if you want AC to be able to
write/edit this config with the app. Official vanilla cars do have this file by default of course.
[FUEL_EVAL]
KM_PER_LITER=1.324720 ; Average fuel consumption of the vehicle for AI opponents. [Km/L]

% ▲ How many kilometres the vehicle can travel in average with 1 litre of fuel.

LITTLE EXPLANATION
- [FUEL_EVAL] is a consumption estimate for km/L that will skew the AI pit strategy/starting fuel, so if you make it too high they can end up doing stuff like
having to pit on the last laps to refuel.

CURIOSITIES AND AMENITIES:

- It's kinda hit or miss with the ai in my experience. It is better if you start off in weekend mode, as they don't actually build a pit stop plan in quick race
mode so they end up retiring. Having a practice and/or qualification session before the race forces them to calculate fuel. Now then once they've done that
it's up to race length. The ai won't pit in a 20-lap race if their tank is filled enough for it, while the longer the race the higher the probability of them pitting.
Last but not least always check the AI's tire compound before the race (with the Race Fuel Monitor app) and use the same.
- We know that modded AC has become a jewel at handling, variety and eye candy, but it's still trapped in often very disappointing AI racing conditions. The
AI driving itself is actually nice, you just need to find the perfect skill/aggressiveness range for each car, but their pit strategies (or lack of) make the race too
linear specially if Formula racing is your thing.
While there's no definite clean/realistic solution to it, a workaround I've been doing with some degree of success (and a great degree of fun) is this:
Unpack the car data. I'd recommend backing up the car you're going to tamper with.
Then, simply go to car.ini and find the [FUEL] line. You'll see the lines corresponding to the default FUEL and the MAX_FUEL the car can take.
Now, start a race with the desired car being controlled by AI, and open the Race Fuel Monitor app. After a few laps, you'll see how much Fuel per lap (FxL)
they are spending.
What now? Imagine you are planning on a 53-lap race on a particular track, and the AI is burning 1.80 litres per lap. 53 * 1.80 = 95.4 is how much fuel
they'd need to complete the race in a full tank, and if the car tank holds more than that, very often the AI decides on not stopping at all, so only on absurdly
long races (For a Formula perspective that is) we'd see them pitting.
After some experimentation, I've found out that if you change the MAX_FUEL to somewhere between this non-stop race value (95.4) and its half (47.7), so
say, 70 litres, the AI is forced to choose a stopping strategy. Change the MAX_FUEL in car.ini however you like, and then repack the data (or leave the data
folder and delete the data.acd file).
And what's really nice about it is that they won't all choose the same strategy (again, open Race Fuel Monitor at the beginning of the race to see what they've
decided on), sometimes you'll see one-stoppers (with early or late pitting!) and even a few two-stoppers. Then you'll race with the AI over and under cutting
both you and each other, and you can at least play around a bit with pit strategy.
To enhance this effect, the Weekend mode is best, because in it the AI will use the practice session to establish how much fuel they are burning, and I see
way more variety than when they just estimate mathematically in the Race mode. I also think that forcing them to use soft tyres makes the race more varied.
Ideally, they would choose different tyres in race but that's not possible unless you clone the car and choose multiple defaults. This is achieved with Content
Manager and the method of Fake Cars (Fig.).

Fig. – In the About section of CM you can find the explanation of the method of Fake Cars, which you can use to tweak the AI behaviour. The underlying procedure, even if automatic,
is quite tricky and relatively heavy on the system, but can potentially achieve good results.

419
26. lights.ini
If your car has got headlights, you’ll definitely want to see them work! This *.ini file manages all the lights of your vehicle, bulbs, blinkers, LEDs, gauges,
buttons, cockpit instruments illumination, and more.
Don’t forget to detach the objects (meshes of the bulbs, reflectors, etc.) and link them to their respective dummies if they are located on moving objects (e.g.
on the steering wheel or on retractable lights).
[HEADER]
VERSION=3 ; Script version. Keep this value =3 to support latest functions

% ▼ Modern Formula cars can add to [HEADER] the following four lines for a rear ERS status flash light:

FLASHING_BLINK_TIME=0.15 ; Flash blink time length for pit light and flasher. [s]
FLASHING_REPEAT=8 ; Blink repeat for pit light and flasher
KERS_BLINKING=1 ; Add this line to enable KERS blinking (optional)
NO_LIGHT_SWITCH=1 ; Add this line to block lights from activating with the headlight key (optional)

% ▼ Add only these two lines to the [HEADER] if you want to enable the flash function for headlights and pitlane lights:

FLASHING_BLINK_TIME=0.15
FLASHING_REPEAT=8

[BRAKE_0] ; Brake light identifier. SYNTAX: [BRAKE_ID], ID starting from zero.

% ▼ Different functions and colours can be assigned to different meshes.

NAME=EXT_LIGHT_BRAKE_1 ; Name of the mesh to light up.

COLOR=450,30,0 ; RGB emissive value (RED, GREEN, BLUE) assigned when you press the brake pedal.

% ▲ The mesh is lit using HDR and there is no maximum limit of intensity. The values for the COLOR parameter are in RGB 0 to 1 range, so a value of 1
means the maximum value of the RGB scale (256). The values can go over 1 if more intensity is needed. As an example, a value of 240 is given to the
[LIGHT_0] section, in order to produce a strong glow.

% ▲ For a glowing brake light the recommended value for R (red) is between 150 and 850. For day racing lights, recommended values are between 40 and 100,
while for high beams, recommend values range from 250 to 800.

OFF_COLOR=0,0,0 ; RGB emissive value for position light when brakes are off; mandatory for BRAKE items in VERSION=3

% ▲ The line OFF_COLOR is the emissive value of the rear position light for cars where the same mesh is lit up when you turn the lights on and when you
brake.

[LIGHT_0] ; Light identifier. SYNTAX: [LIGHT_ID], ID starting from zero. For headlights and general purpose.
NAME=EXT_HEADLIGHT ; Name of the mesh to light up.
COLOR=240,240,240 ; RGB emissive value when the front light is on.
OFF_COLOR=25,25,25 ; Add this RGB emissive value for a day racing light (optional)
INTENSITY=1 ; add description

[LIGHT_1]
NAME=EXT_Emissive_Light_Endurance_1
COLOR=180,0,0
PITLINE=1 ; Add this value for pit lights: 1 means it flashes in pitlane.
KERS=1 ; ERS status flash light: 1 means it flashes when KERS harvest is active
SPECIAL=1 ; Add this value if pit light should not be turned on with light switch\key, switching it on only in
pits

[LIGHT_2]
NAME=EXT_Emissive_Flash_0
COLOR=3,10,0
FLASH=1 ; Add this value if the light is also a flasher; 1 means will flash when flash key is pressed

[LIGHT_GAUGE_0]

% ▲ The dashboard headlight indicator lights and the dashboard lighting are also controlled by lights.ini. The dashboard objects and any other objects
that light up in the interior must be detached and named according to the following convention: [LIGHT_GAUGE_ID] and [LIGHT_INTERIOR_ID]

NAME=clocks
COLOR=0.2,0.2,0.1

LITTLE EXPLANATION
- There are few limitations on light behaviour with lihts.ini:
• Pit light and flasher functions do not work on BRAKE items.
• When the OFF_COLOR line is present in a LIGHT item, blinking occurs between the two values.

CURIOSITIES AND AMENITIES

- The Audi R18 e-tron quattro 2014 has in its data several lights.ini scripts that have been discarded during development: lights_blue.ini, lights_red_blue.ini
and lights_white.ini. This is serious dedication, as they weren’t originally supposed to be found (due to official .acd encryption).

420
27. lods.ini
This script manages the transitions between the LODs (of the exteriors?) of the vehicle.
Little reminder: LODs are a set of simplified models that change in relation of the camera distance. This process is necessary in order to optimize the
framerate in the game. The LOD switching can be controlled via the following script, located in ~root/AssettoCorsa/content/cars/your_car_name/data.
Verify that the distance of LOD “out” value matches the “in” value of the next LOD, otherwise your car will disappear before the switch.
Be aware that you can create more than four LODs, as explained in chapter, but it’s neither mandatory nor necessary.

- LODs don’t have specific naming rules, neither in the folder nor in the lods.ini script, but distinguishing them with letters is super useful to make things
easier. You don’t need to replicate the examples shown in chapter 1, however you should use one of the following naming standards, being equivalent:
~_a.kn5; ~_A.kn5; ~_lod_a.kn5; ~_lod_A.kn5; ~_LOD_a.kn5; ~_LOD_A.kn5; ~a.kn5; ~A.kn5.
[COCKPIT_HR]
DISTANCE_SWITCH=6 ; Indicates the distance (in meters) when the cockpit_HR changes to the cockpit_LR (if present)

[DRIVER_HR]
DISTANCE_SWITCH=750 ; just wow. I keep finding new lines. I imagine [DRIVER_HR] require a DRIVER_HR dummy in the scene.

[LOD_0] ; LOD identifier. SYNTAX: [LOD_ID], ID starting from zero.

% ▲ First LOD (the most detailed one). Corresponds to LOD A.

FILE=abarth500.kn5
IN=0 ; The distance at which Lod A appears visible.
OUT=15 ; Indicates the distance (in meters) at which lod A exchanges with lod B (if present)

[LOD_1] ; Second LOD. Corresponds to LOD B

FILE=abarth500_B.kn5
IN=15 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=45 ; Indicates the distance (in meters) at which lod B exchanges with lod C (if present)

[LOD_2] ; Third LOD. Corresponds to LOD C

FILE=abarth500_C.kn5
IN=45 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=200 ; Indicates the distance (in meters) at which lod C exchanges with lod D (if present)

[LOD_3] ; Fourth LOD. Corresponds to LOD D

FILE=abarth500_D.kn5
IN=200 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=1500 ; Indicates the distance (in meters) at which lod D disappears from visual.

% ▼ Other LODs (not required, optional) added in this example. They follow the same syntax and use similar lines of code as the ones above. Adequate
FILE, IN and OUT values must be used in order to work properly. Vanilla content does not have more than the first four LODs (A, B, C, D).

[LOD_4]
[LOD_5]
[...]

28. mirrors.ini

This script manages mirrors. How?

[MIRROR_0] ; Mirror identifier. SYNTAX: [MIRROR_ID], ID starting from zero.
NAME=g_Door_L_SUB4 ; Name of the mesh that should act as a mirror.

[MIRROR_1]
NAME=g_Door_R_SUB2

[MIRROR_2]
NAME=GEO_Cockpit_SUB17

[MIRROR_3]
[MIRROR_4]
[...] ; A vehicle can have as many [MIRROR] as necessary.

421
29. proview_nodes.ini
This .ini is for Assetto Corsa Pro (feature available in vanilla AC as well, but meant for AC Pro).
It’s a view mode that can turn off / hide any object of the car which is being rendered. It’s the perspective you have in the stands with F1 cars, where there is
a car body in real life, so only the wheels are drawn on the screen (Fig.).

Fig. – Kunos software (a modified version of AC obviously), being used in the Evotek simulators.

Keep in mind that this works only for the two first person cameras in the cockpit, so you’ll see the car from outside views (Fig.). The script itself is basically
the tree of the hierarchy of all the objects (so meshes and NULLs) in the vehicle’s model.

Fig. – As you can see, the car is still visible in the exterior views.

422
To show only tyres (or only whatever you want) in a car:
1. Open with a text editor the options.ini file in your Assetto Corsa install folder: %root%\assettocorsa\system\cfg
2. This is the part of the script inside we care about:
[OPTIONS]
AUTOFLIP_RECOVERY=1
PROVIEW_MODE=0
RENDER_SPLINE=0
DISABLE_SHOW_MODE=0
IGNORE_RESULT_TELEPORT=0

3. Change PROVIEW_MODE=0 to PROVIEW_MODE=1. This enables the view mode, so every part of the car will be hidden. Note that you will have to change this back to
zero when you’ll desire to use the standard onboard view again.
4. Open proview_nodes.ini in the data folder of the car you want to modify (look at the FAQ of par. if you have data.acd) and edit the value of every element you want to see
when driving. Default is 0 (not visible). Change it to 1 and make it visible.
This script is also very useful if you want to reverse engineer mods, especially if you can’t or don’t want to unpack (decrypt) the models. The list is pretty
much identical to the Outliner in Blender and the Scene Explorer in 3DsMax.
The following example of proview_nodes.ini comes from the Ferrari 458 GT2 by Kunos. It is divided in two columns to save some space (and paper). The
colours refer to the NULLs of Chapter 2.
[NODES] ____LED_RPM_0=0
WHEEL_LF=0 ____LED_RPM_1=0
____RIM_BLUR_LF=0 ____LED_RPM_2=0
________polymsh_detached131=0 ____LED_RPM_3=0
____RIM_LF=0 ____LED_RPM_4=0
________Cerchione_Anteriore=0 ____LED_RPM_5=0
____TYRE_LF=0 ____LED_RPM_6=0
________g_Tyre_RF001=0 ____LED_RPM_7=0
WHEEL_RF=0 ____LED_RPM_8=0
____RIM_BLUR_RF=0 ____LED_RPM_9=0
________polymsh_detached133=0 ____LED_FUEL=0
____RIM_RF=0 ____GEO_cockpit_HR=0
________Cerchione_Anteriore1=0 ________Extra_Mirror=0
____TYRE_RF=0 COCKPIT_LR=0
________g_Tyre_RF4=0 ____STEER_LR=0
WHEEL_LR=0 ________GEO_Steer_LR=0
____RIM_BLUR_LR=0 ____GEO_cockpit_LR=0
________polymsh_detached132=0 DOOR_R=0
____RIM_LR=0 ____GEO_Door_R=0
________polymsh_detached129=0 ____DAMAGE_GLASS_RIGHT_2=0
____TYRE_LR=0 ________polymsh_extracted13=0
________g_Tyre_RF2=0 DOOR_L=0
WHEEL_RR=0 ____GEO_Door_L=0
____RIM_BLUR_RR=0 ____DAMAGE_GLASS_LEFT_2=0
________polymsh_detached134=0 ________polymsh_extracted14=0
____RIM_RR=0 WIPER=0
________polymsh_detached130=0 ____polymsh9=0
____TYRE_RR=0 ____WIPER1=0
________g_Tyre_RF3=0 ________polymsh_detached=0
SUSP_LF=0 DAMAGE_GLASS_RIGHT_1=0
____GEO_HUB1=0 ____polymsh_detached120=0
SUSP_RF=0 DAMAGE_GLASS_CENTER_2=0
____GEO_HUB=0 ____polymsh_detached119=0
SUSP_LR=0 DAMAGE_GLASS_REAR_1=0
____GEO_HUB2=0 ____polymsh_extracted9=0
SUSP_RR=0 DAMAGE_GLASS_LEFT_1=0
____GEO_HUB3=0 ____polymsh_detached121=0
DISC_LF=0 DAMAGE_GLASS_CENTER_1=0
____GEO_DISC_LF=0 ____polymsh_extracted11=0
DISC_RF=0 DAMAGE_GLASS_FRONT_1=0
____GEO_DISC_RF=0 ____polymsh_extracted12=0
DISC_LR=0 WING=0
____GEO_DISC_LR=0 ____GEO_RearWing=0
DISC_RR=0 GEO_BODY_Trasp=0
____GEO_DISC_RR=0 FRONT_LIGHTS=0
COCKPIT_HR=0 ____FRONT_LIGHT_2=0
____STEER_HR=0 ____FRONT_LIGHT_1=0
________GEO_STEER=0 ____FRONT_LIGHT_3=0
____________LED_0=0 REAR_LIGHTS=0
____________LED_1=0 ____REAR_LIGHT_REAR=0
____________LED_2=0 ____REAR_LIGHT_BRAKE=0
____________LED_3=0 ____REAR_LIGHT_BRAKE_CENTRAL=0
____________LED_4=0 FRONT_BUMPER=0
____________LED_5=0 ____GEO_FRONTBUMPER=0
____________LED_6=0 REAR_BUMPER=0
____________LED_7=0 ____GEO_REARBUMPER=0
____CINTURE_ON=0 ____LIGHT_RAIN=0
____CINTURE_OFF=0 MOTORHOOD=0
____DOOR_R1=0 ____GEO_Motorhood=0
________GEO_Door_R1=0 EXHAUST1=0
____DOOR_L1=0 EXHAUST2=0
________GEO_Door_L1=0 Mtore=0
____GEO_Vetro_interno=0 GEO_Body=0
____SHIFT=0 FLYCAM_L_0=0
________SHIFT2=0 FLYCAM_L_1=0
____________polymsh_detached1=0 FLYCAM_L_2=0
________polymsh_detached135=0 FLYCAM_L_3=0
____SHIFT1=0 FLYCAM_L_4=0
________polymsh_detached5=0 FLYCAM_L_5=0
____SHIFT3=0 FLYCAM_R_0=0
________SHIFT4=0 FLYCAM_R_1=0
____________polymsh_detached4=0 FLYCAM_R_2=0
________polymsh_detached2=0 FLYCAM_R_3=0
____DISPLAY_DATA=0 FLYCAM_R_4=0
____LED_LIGHTS=0

423
30. setup.ini
This configuration file lets you determine the values that can be changed in the setup GUIs right at the beginning of every session. It is one of the longest in
terms of text lines.
To avoid repetition and confusion, the example script below has been edited: some repeated lines are missing, and some sections have been reordered. For
reference, take a look at the setup.ini file of the official Ferrari SF70H by Kunos, or other Formula cars, which are the most complete in terms of features.
[DISPLAY_METHOD]
SHOW_CLICKS=1

[GEARS] ; Defines what kind of gearset can be used in setup.

USE_GEARSET=0 ; =0 gives access to various gears sliders. =1 Gives you prefixed compilations of gearboxes.

/////////////////////////////////////////////////////
;AERO
/////////////////////////////////////////////////////

[WING_1]
SHOW_CLICKS=0 ; 0 shows actual value. 1 Shows number of clicks needed depending step. 2 shows clicks starting from 0
TAB=AERO ; Tab to visualise.

% ▲ Keep consistent with default tabs otherwise ac will crash because of locales files errors.

NAME=Front left ; Name of setup component

MIN=0 ; Minimum permitted value, for wings is the angle. [deg] (this unit only for wings)
MAX=30 ; Maximum permitted value, for wings is the angle. [deg] (this unit only for wings)
STEP=1 ; Sets the amount changed by each click in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0 ; Position of the selector on the X axis. Values: 0=left, 0.5=middle, 1=right.

% ▲ Where the text shows up on the setup screen, in the X coordinates.

POS_Y=1 ; Position of the selector on the Y axis. Values from 0 to 8.

% ▲ Where the text shows up on the setup screen, in the Y coordinates.

% ▲+▲▲ The following picture (Fig.) shows the coordinates in the setup tabs.

HELP=HELP_FRONT_WING ; Tool tip help to show on title mouseover.

% ▲ Reference for AC to decide which of the quick tips should be displayed in the setup menu. The quick tips are predefined and the following:

hfigkjghklfghlhjolminònm

PITSTOP=2.5

% ▼ The lines similar or identical to [WING_1] will be skipped. There are no lines missing apart from those.

[WING_2]
NAME=Front right

[WING_3]
NAME=Rear wing
HELP=HELP_REAR_WING

/////////////////////////////////////////////////////
;TYRES
/////////////////////////////////////////////////////

[PRESSURE_LF]
SHOW_CLICKS=0
TAB=TYRES
NAME=Pressure LF
MIN=6 ; Minimum permitted value, for tires is the pressure. [bar] (this unit only for tires)
MAX=28 ; Minimum permitted value, for tires is the pressure. [bar] (this unit only for tires)
STEP=1 ; Sets the amount changed by each lick in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0
POS_Y=2
HELP=HELP_LF_PRESSURE

% ▼ The lines similar or identical to [PRESSURE_LF] will be skipped. There are no lines missing apart from those.

[PRESSURE_RF]
NAME=Pressure RF
HELP=HELP_RF_PRESSURE

[PRESSURE_LR]
NAME=Pressure LR
HELP=HELP_LR_PRESSURE

[PRESSURE_RR]
NAME=Pressure RR
HELP=HELP_RR_PRESSURE

/////////////////////////////////////////////////////
;SUSPENSION
/////////////////////////////////////////////////////

[SPRING_RATE_HF]
SHOW_CLICKS=2
TAB=SUSPENSIONS
NAME=Wheel rate HF
MIN=80
MAX=180
STEP=10 ; Sets the amount changed by each click in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0.5
POS_Y=3
HELP=HELP_HF_WHEELRATE

% ▼ The lines similar or identical to [SPRING_RATE_HF] will be skipped. There are no lines missing apart from those.

[SPRING_RATE_HR]
NAME=Wheel rate HR
HELP=HELP_HF_WHEELRATE

[SPRING_RATE_LF]
NAME=Wheel rate LF
HELP=HELP_LF_WHEELRATE

% ▼ The lines similar or identical to [SPRING_RATE_LF] will be skipped. There are no lines missing apart from those.

[SPRING_RATE_RF]
NAME=Wheel rate RF

424
HELP=HELP_RF_WHEELRATE

[SPRING_RATE_LR]
NAME=Wheel rate LR
HELP=HELP_LR_WHEELRATE

[SPRING_RATE_RR]
NAME=Wheel rate RR
HELP=HELP_RR_WHEELRATE

[ROD_LENGTH_LF]
SHOW_CLICKS=0
TAB=SUSPENSIONS
NAME=Height LF
MIN=100
MAX=500
STEP=10
POS_X=0
POS_Y=2
HELP=HELP_LF_RODLENGTH

% ▼ The lines similar or identical to [ROD_LENGTH_LF] will be skipped. There are no lines missing apart from those.

[ROD_LENGTH_RF]
NAME=Height RF
HELP=HELP_RF_RODLENGTH

[ROD_LENGTH_LR]
NAME=Height LR
HELP=HELP_LR_RODLENGTH

[ROD_LENGTH_RR]
NAME=Height RR
HELP=HELP_RR_RODLENGTH

[ARB_FRONT]
SHOW_CLICKS=2
TAB=SUSPENSIONS
NAME=ARB Front
MIN=30000
MAX=100000
STEP=2000
POS_X=0.5
POS_Y=0
HELP=HELP_FRONT_ARB

% ▼ The lines similar or identical to [ARB_FRONT] will be skipped. There are no lines missing apart from those.

[ARB_REAR]
NAME=ARB Rear
HELP=HELP_REAR_ARB

/////////////////////////////////////////////////////
;SUSPENSION ADVANCED
/////////////////////////////////////////////////////

[BUMP_STOP_RATE_LF]
SHOW_CLICKS=0
TAB=SUSPENSION ADV.
NAME=Packer rate
MIN=150
MAX=250
STEP=5
POS_X=0
POS_Y=0
HELP=HELP_LF_BUMP_STOP_RATE

% ▼ The lines similar or identical to [BUMP_STOP_RATE_LF] will be skipped. There are no lines missing apart from those.

[BUMP_STOP_RATE_RF]
HELP=HELP_RF_BUMP_STOP_RATE

[BUMP_STOP_RATE_LR]
HELP=HELP_LR_BUMP_STOP_RATE

[BUMP_STOP_RATE_RR]
HELP=HELP_RR_BUMP_STOP_RATE

[PACKER_RANGE_LF]
SHOW_CLICKS=0
TAB=SUSPENSION ADV.
NAME=Travel range
MIN=20
MAX=80
STEP=1
POS_X=0
POS_Y=1
HELP=HELP_LF_TRAVEL_RANGE

% ▼ The lines similar or identical to [PACKER_RANGE_LF] will be skipped. There are no lines missing apart from those.

[PACKER_RANGE_RF]
HELP=HELP_RF_TRAVEL_RANGE

[PACKER_RANGE_LR]
HELP=HELP_LR_TRAVEL_RANGE

[PACKER_RANGE_RR]
HELP=HELP_RR_TRAVEL_RANGE

/////////////////////////////////////////////////////
;ALIGNMENT
/////////////////////////////////////////////////////

[CAMBER_LF]
SHOW_CLICKS=0
TAB=ALIGNMENT
NAME=CAMBER_LF
MIN=-3.6 ; degrees
MAX=1
STEP=1
POS_X=0
POS_Y=0
HELP=HELP_LF_CAMBER

% ▼ The lines similar or identical to [CAMBER_LF] will be skipped. There are no lines missing apart from those.

425
[CAMBER_RF]
NAME=CAMBER_RF
HELP=HELP_RF_CAMBER

[CAMBER_LR]
NAME=CAMBER_LR
HELP=HELP_LR_CAMBER

[CAMBER_RR]
NAME=CAMBER_RR
HELP=HELP_RR_CAMBER

[TOE_OUT_LF]
SHOW_CLICKS=2
TAB=ALIGNMENT
NAME=Toe LF
MIN=0
MAX=100
STEP=1
POS_X=0
POS_Y=1
HELP=HELP_LF_TOE

% ▼ The lines similar or identical to [TOE_OUT_LF] will be skipped. There are no lines missing apart from those.

[TOE_OUT_RF]
NAME=Toe RF
HELP=HELP_RF_TOE

[TOE_OUT_LR]
NAME=Toe LR
HELP=HELP_LR_TOE

[TOE_OUT_RR]
NAME=Toe RR
HELP=HELP_RR_TOE

/////////////////////////////////////////////////////
;DAMPERS LF ; Left Front wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_LF]
SHOW_CLICKS=2
TAB=DAMPERS
NAME=Bump
MIN=1000
MAX=5560
STEP=190
POS_X=0
POS_Y=0
HELP=HELP_LF_DAMPER_BUMP

% ▼ The lines similar or identical to [DAMP_BUMP_LF] will be skipped. There are no lines missing apart from those.

[DAMP_FAST_BUMP_LF]
NAME=FST Bump
HELP=HELP_LF_DAMPER_FBUMP

[DAMP_REBOUND_LF]
NAME=Rebound
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LF]
NAME=FST Rebound
HELP=HELP_LF_DAMPER_FREBOUND

% ▼ For all other damper types, the lines similar or identical to every section of the DAMPERS LF above will be skipped. There are no lines missing apart
from those.

/////////////////////////////////////////////////////
;DAMPERS RF ; Right Front wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_RF]
HELP=HELP_RF_DAMPER_BUMP

[DAMP_FAST_BUMP_RF]
HELP=HELP_RF_DAMPER_FBUMP

[DAMP_REBOUND_RF]
HELP=HELP_RF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RF]
HELP=HELP_RF_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS LR ; Left Rear wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_LR]
HELP=HELP_LR_DAMPER_BUMP

[DAMP_FAST_BUMP_LR]
HELP=HELP_LR_DAMPER_FBUMP

[DAMP_REBOUND_LR]
HELP=HELP_LR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LR]
HELP=HELP_LR_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS RR ; Right Rear wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_RR]
HELP=HELP_RR_DAMPER_BUMP

[DAMP_FAST_BUMP_RR]
HELP=HELP_RR_DAMPER_FBUMP

[DAMP_REBOUND_RR]
HELP=HELP_RR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RR]
HELP=HELP_RR_DAMPER_FREBOUND

/////////////////////////////////////////////////////

426
;DAMPERS HF ; Heave Front dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HF]
TAB=HEAVE DAMPERS
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_REBOUND

/////////////////////////////////////////////////////
;DAMPERS HR ; Heave Rear dampers
/////////////////////////////////////////////////////

[DAMP_BUMP_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HR]
TAB=HEAVE DAMPERS
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_REBOUND

/////////////////////////////////////////////////////
;DRIVETRAIN
/////////////////////////////////////////////////////

% ▲▼ If you’re using the AWD traction type in drivetrain.ini, the lines under [AWD_FRONT_TORQUE_DISTRIBUTION], [FRONT_DIFF_POWER], [FRONT_DIFF_COAST],
[FRONT_DIFF_PRELOAD], [CENTER_DIFF_POWER], [CENTER_DIFF_COAST], [CENTER_DIFF_PRELOAD], [REAR_DIFF_POWER], [REAR_DIFF_COAST] and [REAR_DIFF_PRELOAD] can be
added under the ;DRIVETRAIN setup tab.

% For the AWD2 traction type, the code does not allow any regulations, so you won’t have to add the lines below to setup.ini. Basically you can’t edit an
AWD2 setup.

[AWD_FRONT_TORQUE_DISTRIBUTION]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Distribution
MIN=0
MAX=100

% ▲ Front Torque Distribution is wrong coded and you have to put value between 0 and 1, not 0 to 100.

STEP=1
POS_X=0.5
POS_Y=-0.5
HELP=

[FRONT_DIFF_POWER]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Power
MIN=0
MAX=100
STEP=5
POS_X=0
POS_Y=1.5
HELP=HELP_DIFF_POWER

[FRONT_DIFF_COAST]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Coast
MIN=0
MAX=100
STEP=5
POS_X=1
POS_Y=1.5
HELP=HELP_DIFF_COAST

[FRONT_DIFF_PRELOAD]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front preload
MIN=0
MAX=100
STEP=5
POS_X=0.5
POS_Y=2.5
HELP=HELP_DIFF_PRELOAD

% ▼ The lines similar or identical to [FRONT_DIFF_POWER], [FRONT_DIFF_COAST] and [FRONT_DIFF_PRELOAD] will be skipped. There are no lines missing apart
from those.

[CENTER_DIFF_POWER]
NAME=Center Power
POS_X=0
POS_Y=4.5

[CENTER_DIFF_COAST]
NAME=Center Coast
POS_X=1
POS_Y=4.5

[CENTER_DIFF_PRELOAD]
NAME=Center preload
POS_X=0.5
POS_Y=5.5

[REAR_DIFF_POWER]
NAME=Rear Power
POS_X=0

427
POS_Y=7.5

[REAR_DIFF_COAST]
NAME=Rear Coast
POS_X=1
POS_Y=7.5

[REAR_DIFF_PRELOAD]
NAME=Rear preload
POS_X=0.5
POS_Y=8.5

/////////////////////////////////////////////////////
;GEARS
/////////////////////////////////////////////////////

[FINAL_GEAR_RATIO]
RATIOS = final.rto
NAME = Final Gear Ratio
POS_X = 0.5
POS_Y = 2.5
HELP = HELP_REAR_GEAR

/////////////////////////////////////////////////////
;GENERIC
/////////////////////////////////////////////////////

[FUEL]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Fuel
MIN=5
MAX=133
STEP=1
POS_X=0.5
POS_Y=0
HELP=HELP_FUEL

[FRONT_BIAS]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Brake Bias
MIN=52
MAX=68
STEP=1
POS_X=0.5
POS_Y=1
HELP=HELP_BRAKE_BIAS

[BRAKE_POWER_MULT]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Brake power
MIN=80
MAX=100
STEP=1
POS_X=0.5
POS_Y=2
HELP=HELP_BRAKE_POWER_MULT

LITTLE EXPLANATION
- If a parameter in your setup.ini does not have the correct range, it will overrule the other data files and limit the default value(s) of the physics.
For example, if your default camber on your front wheel is -3° (given from suspensions.ini) but your setup.ini range is from -2 to -1, then the default camber
in-game won't exceed -2°.
Another case: if setup.ini says that springs have a 200˙000-300˙000 N/m range, while suspensions.ini has a value of 50,000 N/m, then AC will use
200˙000-300˙000 N/m.
Basically if you have a range of adjustment in the setup script, the real-time simulated value will always fall within it, no matter if it’s a larger or thinner interval.
So always double check and verify that your setup.ini has the correct range of values to fit the default physics values.
When creating a new vehicle, the best option is to clear out setup.ini of everything but camber, toe, fuel and tires. Tweak the car via the other data files, and
fill in this config file as the last step after everything else is done.
It is also possible to create a premade setup file that you paste every time when you’re working with your mods, with really wide ranges, that way you're not
being constrained by anything, but can still make very quick changes early on.
- In general, with few exceptions, you can add anything from the data files to setup.ini. (needs more research)

ABOUT RELATED FILES

ai_default.ini
This is an extra config file that can be created by copying the setup.ini of the specific car inside the following path:
C:\Users\Your_User_Name\Documents\Assetto Corsa\setups\your_car_name\specific_track_name.
It allows you to force virtual opponents (AIs) to use a predefined setup for the races. The file is looked up by AC for offline sessions only.
You can also create it inside the GUI of a race session, by saving a new setup as “AI_default”. If it already exists (normally it shouldn’t), just overwrite it.
This functionality however is limited to aerodynamics, suspensions (e.g. ride height) and gear ratios, and there are some bugs. For some reason the AIs
disregard the eventual gear ratios (if you have multiple gearsets). Moreover, as already explained for ai.ini, virtual opponents pick their own tire compounds
and fuel, and sadly this file has no influence on that.
Also, it is track-specific, as you might have guessed from the folder path. This way the function is sadly not useful to adjust the AI for a specific race condition,
pit stop strategies, etc.
The following is an example of use case for this script:
Speedways can be geared and winged for over 400 kph whilst Short ovals can be below 300 kph.

428
This large difference means the use of ai_default.ini as a saved setup is unavoidable, however the AI won't use the gear ratios from that file and also lose the
ability to change the final gear ratio to an appropriate one.
In setup.ini toggle USE_GEARSET=1. Design a generic gearset or more, that the player can use; design a fine grained choice of Final Drive ratios for the
player to use.
In drivetrain.ini use 9 really close ratios and a final drive ratio, ensure these do not share any value with any ratio available to the player.
The AI won't use the player's gearset, as none of the values match, so defaults to the values in drivetrain.ini. On track it now has more gears to work with,
hopefully allowing it to run at any speed.
In the example above the AI would only use 9th gear at say Michigan but would only ever get into 5th or 6th at Milwaukee.
Works 'perfectly' in the above example or in Karts with only one gear.
Problems:
-The gears used may not reflect real gear ratios.
-Nine gears in the setup GUI is displayed somewhat messed up (more than six doesn't seem to fit).

429
31. sounds.ini
For technical reasons and easier management, some sound events (par. 7.) get external interaction with this script, which lets you adjust the volume of
certain sounds of your car, and configures also some backfire params. One of the most important parameters here is the POSITION of the engine. It must
correspond to the actual vehicle configuration, so that the sound source is placed correctly on the car by the audio engine.
[SKIDS] ; Section dedicated to tire skid/squeal sound.

% ▲ The whole [SKID] section is deprecated and is not needed anymore.

ENTRY_POINT=0.45 ; Related to the tyre load. Values [0 – 1.0]

% ▲ Lowering the value will make the skid sound audible even with a minimum tyre load.

MIX_VOLUME=0.7 ; Global sample volume of tire squeal sound. Values [0 – 1.0]

PITCH_BASE=0.42 ; Deprecated
PITCH_GAIN=0.13 ; Deprecated

[WIND] ; Section dedicated to wind sound

SPEED_GAIN_0=0 ; Volume increase for every kmh
SPEED_GAIN_1=0.000045 ; Volume increase for squared kmh
VOLUME_GAIN=0.9 ; Maximum volume reached by the wind (DO NOT EXCEEED 1.0)
PITCH_REFERENCE=50 ; Reference speed for speed variation. [Km/h]
PITCH_GAIN=0.3 ; Pitching gain for speed variation

[TYRE_ROLLING]
SPEED_GAIN_0=0.0025
SPEED_GAIN_1=0.0
VOLUME_GAIN=0.88
PITCH_REFERENCE=50
PITCH_GAIN=0.25

[BACKFIRE] ; Section dedicated to backfire parameters. Influences when backfires happen, not only the sound.
MAXGAS=0.4 ; Backfires are not played if input gas is > maxgas. Values [0 – 1.0]
MINRPM=9000 ; Minimum rotational regime of the engine at which backfires happen. [RPM]
MAXRPM=15000 ; Maximum rotational regime of the engine at which backfires happen. [RPM]

% ▲▲ MINRPM and MAXRPM represent the engine RPM range within which the backfires are audible.

TRIGGERGAS=0.8 ; Trigger point for backfires, related to throttle input. Values [0 – 1.0]
VOLUME_IN=1.0
VOLUME_OUT=1.0
VOLUME_SCALE_OUT=8

[BODY_WORK]
MIN=0.4
GAIN=1

[GEAR_EXT]
DISTANCE_SCALE=9

[ENGINE] ; Section dedicated to the engine sound emitter position.

% ▲▼ Optional. If this section is not present, the engine sound emitter is on the CoG of the vehicle. It is recommended to add these lines in your script
and input a correct value.

POSITION=rear ; Position of the engine sound relative to the car’s configuration. Available options: front, rear.

CURIOSITIES AND AMENITIES

You may find obsolete sections in the sound configs of old mods or official cars by Kunos. An example is in the Nissan Skyline GTR R34 V-Spec, because
there is this part:
[TURBO]
WAV=turbo.wav ; The presence of this line indicates that this is an obsolete section. It can be deleted/ignored.
REF_PITCH=1.2
PITCH_GAIN=0.2
VOLUME=0
MIN_VOLUME=0
MAX_VOLUME_AT=3
DISTANCE_SCALE=2.0
VELOCITY_GAIN=0.0

% ▲ As a consequence, the entire [TURBO] section can be deleted/ignored as obsolete.

[TURBO_BOW]
WAV=turbo.wav ; The presence of this line indicates that this is an obsolete section. It can be deleted/ignored.
FULL_GAS_LIMIT=2.5
ZERO_GAS_LIMIT=0.7
REF_PITCH=1.2
PITCH_GAIN=0.2
VOLUME=0
MIN_VOLUME=0
MAX_VOLUME_AT=3
DISTANCE_SCALE=2.0

% ▲ As a consequence, the entire [TURBO_BOW] section can be deleted/ignored as obsolete.

Whenever there are filenames in sounds.ini, it means that the sections come from a period in time located before AC adopted the FMOD audio engine, and
thus employed directly the audio samples. Those lines of code can be deleted. Another relic of the development past of our simulator.

430
32. suspensions.ini
This config sets most of the parameters for the sprung and unsprung masses, such as the placement of the suspension linkages, the stiffness of springs and
dampers, the graphical offsets (you can set spacers for the wheels) and more. In this example Double Wishbone suspensions will be used, while other
possible designs will be explained in the continuation.
[HEADER]
VERSION=4 ; Version of the suspensions code that the physics engine will load.

% ▲ Each version introduces new and more accurate features. Input is a number, from 1 to 4, with 1 being the oldest and 4 including the latest features.

% ▲ VERSION=2 adds the progressive wheelrate and other parameters. =3 and =4 add features too and are required for the live axle. Again, the recommended
input is 4, use it to avoid confusion.

[BASIC]
WHEELBASE=2.6441 ; Longitudinal distance between the front and rear axle (how far apart they are). [m]
CG_LOCATION=0.585 ; Distribution of the sprung mass over the wheels. Input is percent, for example 50% = 0.50.

% ▲ This value is NOT the total car CG. The total CG is calculated from the fuel tank position and weight (described in the values under [FUEL] and
[FUELTANK] in car.ini) and the ride height.

% For a basic drawing of what the WHEELBASE and CG_LOCATION values do, look at Fig. in the LITTLE EXPLANATION section.

[ARB] ; Anti-Roll-Bar. (explanation)

FRONT=100 ; Stiffness of the front ARB, measured at the wheel. [N/m]
REAR=100 ; Stiffness of the rear ARB, measured at the wheel. [N/m]

[FRONT]
TYPE=DWB ; The suspension type used. Inputs are DWB, STRUT, ML.
BASEY=0.014 ; The height that is 0 for all suspension components. [m]
RIM_OFFSET=0 ; Wheel offset. [m]

% ▲ Effectively, it adds the amount to the X coordinates of the suspension linkages, on each side of the car.
Take care to adjust TRACK in suspensions.ini after adjusting RIM_OFFSET if the intention is to “change wheels”. As in, to know how much you should
increase your track, divide RIM_OFFSET by 2.
Not required, but it simplifies suspension creation, as you can use one set of coordinates with multiple wheels.

TRACK=1.335 ; Track width (from 3D placement of the pivot of the 3d model of a wheel). [m]

% ▲ Lateral dimension between the left and right tire contact patch, when the camber angle is 0 degrees and the suspension is at design height.
% When you go measure track on your car, you measure from center of tire, to center of tire.

ROD_LENGTH=0.055 ; Push rod length in meters. Positive raises ride height, Negative lowers ride height. [m]

% ▲ This is an offset value. Before using it, set properly the car's weight, the springrates, and some other stuff, and then adjust ROD_LENGTH so the car
sits at the right height. If the actual suspension attachment points aren't where you want them, that's what BASEY or the car.ini visual offset is for.

HUB_MASS=54 ; Portion of the unsprung mass for one corner. Includes the wheel and tire weight. [Kg]

% ▲ With the AXLE suspension type, the unsprung mass is for both wheels. Take care to include the actual unsprung distribution, as parts of the assembly
are shared with the sprung mass, such as struts and driveshafts.
You can check the unsprung masses in the Car Engineer App.

% NOTE: STRUT suspension types convert per-corner 20% of HUB_MASS as a sprung mass, placed probably between STRUT_TYRE and STRUT_CAR. Additionally, 20%
of original HUB_MASS per corner is added as sprung mass at the sprung CG. You must enter a higher HUB_MASS value for STRUT to attain intended values.
Example: 40kg per corner = 40 / 0.80 = 50 HUB_MASS.

% ▼ Coordinates of the suspension attaching points:

STRUT_CAR=0.12, 0.3, -0.0

STRUT_TYRE=0.1,-0.10,0.0
WBCAR_BOTTOM_FRONT=0.35,-0.09,0.32 ; Bottom front car side wishbone attach point.
WBCAR_BOTTOM_REAR=0.35,-0.1,-0.37 ; Bottom rear car side wishbone attach point.
WBTYRE_BOTTOM=0.1,-0.10,0.0 ; Bottom tyre side wishbone attach point.
WBCAR_STEER=0.667,-0.175,-0.16 ; Steering rod car side attach point.
WBTYRE_STEER=0.135,-0.175,-0.11 ; Steering rod tyre side attach point.
TOE_OUT=0.0000 ; Setup toe angle, expressed as the length of the steering arm. [m]

% ▲ It is the lateral displacement of the tie rod. Currently not functional for TYPE=AXLE.

STATIC_CAMBER=2.35 ; Wheel static camber angle for setup. The actual camber is relative to suspension geometry and
movement. check values in game. [deg]

% ▲ Keep in mind that camber adjustment will not move TYRE suspension points, it simply pivots the wheel. Currently not functional for AXLE.

SPRING_RATE=32000 ; Wheelrate of a single corner spring on that axle; the value is shared for left and right. [N/m]

% ▲ This is the wheel rate stiffness. Do not use the spring value. This parameter has to be calculated.

NOTE: STRUT suspension types apply a pseudo-motion ratio to the SPRING_RATE, approximately equivalent to Actual Motion Ratio * SPRING_RATE. The “motion
ratio” is kinematically solved. Actual SPRING_RATE can be checked via referring to SUSTRVL in apps.
Example: 0.90 * 20000 = 18000.

PROGRESSIVE_SPRING_RATE=1 ; Progressive WHEELRATE. Can and commonly should be paired with SPRING_RATE. [N/m/m].

% ▲ For progressive springs, you should also have a linear springrate component.

BUMP_STOP_RATE=580 ; WHEELRATE of the PACKER_RANGE and BUMPSTOP_UP/DN. [N/m]

% ▲ Bear in mind that STRUT and AXLE suspensions currently have a hardcoded ~500000 N/m rate for the BUMPSTOP entries.

BUMPSTOP_UP=0.13112 ; Vertical movement of the wheel, until impacting the bump rubber. [m]
BUMPSTOP_DN=0.0526 ; Wheel travel, until impacting the internal bump stopper of the damper, which resists droop. [m]
PACKER_RANGE=0.162 ; Position of the packer along the suspension travel. [m]

% ▲ Gap to bumpstop from the ROD_LENGTH point of the suspension. The formula is susp travel + intended gap to packer from the intended height. For
example 0.100 + 0.030 = 0.130, resulting in a 30mm packer gap if your static spring deflection is 100mm.

Total travel minus packer range equals packer thickness.

100mm - 80mm = 20mm.

So if you have 100mm of total travel and want a 20mm packer, then you set PACKER_RANGE=0.080 and the rest 20mm of the travel will be the packer. If you
have no packer, you set PACKER_RANGE as the total travel, and there will be no packer.

(old description) Total suspension movement range, before hitting packers

But actually, what are packers?

such as a plastic packer for racecars, or rubber bumpstop for roadcars

DAMP_BUMP=26800 ; Wheel damping rate for bump travel when the wheel is travelling slower than the
DAMP_FAST_BUMPTHRESHOLD value. [N/m/s]

431
DAMP_FAST_BUMP=1 ; Wheel damping rate for bump travel when the wheel is travelling faster than the
DAMP_FAST_BUMPTHRESHOLD value. [N/m/s]

DAMP_FAST_BUMPTHRESHOLD=1 ; Transition point, or “knee” for the bump damping to change from SLOW to FAST. [m/s]

DAMP_REBOUND=4650 ; Wheel damping rate for rebound travel when the wheel is traveling slower than the
DAMP_FAST_REBOUNDTHRESHOLD value. [N/m/s]

DAMP_FAST_REBOUND=1 ; Wheel damping rate for rebound travel when the wheel is traveling faster than the
DAMP_FAST_REBOUNDTHRESHOLD value. [N/m/s]

DAMP_FAST_REBOUNDTHRESHOLD=1 ; Transition point, or “knee” for the rebound damping to change from SLOW to FAST. [m/s]

BUMP_STOP_PROGRESSIVE=0 ; It works the same as PROGRESSIVE_SPRING_RATE but for the packers/bumpstops.

[HEAVE_FRONT] ; Section dedicated to heave springs (third elements).

ROD_LENGTH=0.015 ; heave (3rd spring) push rod length in meters. positive raises ride height, negative lowers it.
SPRING_RATE=166000 ; 3rd spring wheel rate stiffness in Nm. Do not use spring value but calculate wheel rate
PROGRESSIVE_SPRING_RATE=0 ; 3rd spring progressive spring rate in N/m/m
BUMP_STOP_RATE=165000 ; 3rd spring bump stop spring rate
BUMPSTOP_UP=0.035 ; meters to upper bumpstop from the 0 design of the suspension
BUMPSTOP_DN=0.035 ; meters to bottom bumpstop from the 0 design of the suspension
PACKER_RANGE=0.045 ; Total suspension movement range, before hitting packers
DAMP_BUMP=8276 ; Damper wheel rate stifness in N sec/m in compression
DAMP_FAST_BUMP=2262 ; Damper wheel rate stiffness in N sec/m in fast speed compression
DAMP_FAST_BUMPTHRESHOLD=0.028 ; Damper bump slow/fast threshold in seconds
DAMP_REBOUND=8680 ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND=4365 ; Damper wheel rate stiffness in N sec/m in fast speed rebound
DAMP_FAST_REBOUNDTHRESHOLD=0.040 ; Damper rebound slow/fast threshold in seconds

[REAR] ; Similar parameters as seen for [FRONT], with additions for the specific suspension type.
TYPE=DWB ; For the rear AXLE and ML types can be used, as well as DWB and STRUT.
BASEY=0.03
RIM_OFFSET=0
TRACK=1.2
ROD_LENGTH=0.054
HUB_MASS=146

% ▼ In this example the rear has more linkages than the front.

WBCAR_TOP_FRONT=0.28, 0.01, 0.72 ; Top front car side wishbone attach point.
WBCAR_TOP_REAR=0.30, 0.06, -0.01 ; Top rear car side wishbone attach point.
WBCAR_BOTTOM_FRONT=0.33, -0.20, 0.77 ; Bottom front car side wishbone attach point.
WBCAR_BOTTOM_REAR=0.47, -0.232, -0.01 ; Bottom rear car side wishbone attach point.
WBTYRE_TOP=0.14, 0.10, 0.01 ; Top tyre side wishbone attach point.
WBTYRE_BOTTOM=0.15, -0.20, 0.0015
WBCAR_STEER=0.47,-0.232, 0.10
WBTYRE_STEER=0.15,-0.220, 0.10

% ▲ The rear "_STEER" is a tie-rod and in typical suspension geometry is coplanar with one of the wishbones - so it looks like a rectangle instead of a
triangle, and you can just code it in as such.

TOE_OUT=0.00000
STATIC_CAMBER=0.0
SPRING_RATE=368
PROGRESSIVE_SPRING_RATE=0
BUMP_STOP_RATE=64000
BUMPSTOP_UP=0.1565
BUMPSTOP_DN=0.0601
PACKER_RANGE=0.1814
DAMP_BUMP=3150
DAMP_FAST_BUMP=1
DAMP_FAST_BUMPTHRESHOLD=1
DAMP_REBOUND=3155
DAMP_FAST_REBOUND=1
DAMP_FAST_REBOUNDTHRESHOLD=1
BUMP_STOP_PROGRESSIVE=50000 ; Adds the progressive rate on top of the base bumpstop rate. Requires CSP’s progressive rate fix.

[GRAPHICS_OFFSETS] ; Offsets for graphic adjustment of the suspension. They don’t affect physics.

% ▼ The following parameters can be used to make corrections on the visuals of the vehicle. Keep in mind that if you move the graphics, the physics won’t
change, for example moving the wheels outwards (or inwards) graphically, the car will behave as if it still had its wheels on the inside (or outside).
That is why these parameters should be avoided and kept to zero, unless you know what you’re doing. A correct positioning of the empties for wheels and
suspensions in your model is recommended from the beginning.

WHEEL_LF=-0.0 ; Left front offset of the wheel positioning in the x axis (width). + is left - is right movement
SUSP_LF=-0.1012 ; Left front offset of the suspension positioning in the x axis (width). + is left - is right movement
WHEEL_RF=0.0 ; As above for RF, LR and RR.
SUSP_RF=0.1018
WHEEL_LR=0.0
SUSP_LR=-0.462
WHEEL_RR=-0.0
SUSP_RR=0.462

% ▲ If you want to add fictional spacers for specific rims, you can make a copy of this file and change the offsets here. Always remember to keep backups
if you’re working on your own mods or someone else’s.

[DAMAGE] ; This section is for suspension damage, and influences both front and rear.
MIN_VELOCITY=60 ; Minimum velocity to start taking damage.
GAIN=0.00045 ; Amount of steer rod deflection for impact kmh.
MAX_DAMAGE=0.6 ; Maximum amount of steer rod deflection allowed.
DEBUG_LOG=1 ; Activates damage debug in the log.

LITTLE EXPLANATION
- Coupled to the tire is an unsprung mass element (which usually consists of the rim, the brake discs and calipers, the springs, suspension arms and shock
absorbers), which attaches to a sprung mass element (the car body) via a spring-and-damper system.
The location of the tire in relation to the sprung mass element is accomplished via several suspension TYPE options, mainly DWB, STRUT, AXLE, ML.
- Suspensions in Assetto Corsa are kinematically solved, which means that you must input in coordinates for joint locations and the program will generate
behaviour from them.
- When working on suspensions in-game you should use a variety of test tracks, most of which are in the attachments of this manual, including the
Suspensions Test Track by @chuky500, which you can find also here: https://www.racedepartment.com/downloads/suspensions-test-track.6770
- Assetto Corsa is currently a hard-body simulation, which means that the chassis does not deflect or introduce its own springrate onto any elements. The
suspension links have a specified, very stiff, currently fixed springrate and are able to deflect somewhat, but you should not consider suspension
elastokinematics (for example the deflection of soft rubber elements like slide bushings on the joints of control arms in the suspension geometry) to be a
significant theme of Assetto Corsa’s simulation. Simple controllers for a rear wheel steering system and active stabilizer bars are also available.

432
- Note that many modern roadcar suspension geometries incorporate elastokinematics into their design, which is currently not a feature of Assetto Corsa.
- The location of suspension links is accomplished for each wheel via the three-dimensional reference system 𝑲𝑲2𝑖𝑖 of Assetto Corsa, with origin 𝐎𝐎2𝑖𝑖
determined by the WHEEL_# dummies in the vehicle 3D model (see pag.).
Pro tip: (important for later) the suspension points should be built where they are when the car is sitting at its design height, which refers to the location when ROD_LENGTH
equals SUSTRVL (more details in the next paragraphs).

The suspension coordinates are relative to the wheel’s center of rotation, meaning that a position of (0, 0, 0) would be positioned in the middle of the
wheel, basically at the center of the touch point between HUB and RIM (Fig.).

Fig. – An example of a rear suspension linkage for a Lamborghini Gallardo. You can clearly see where the origin 𝐎𝐎2𝑖𝑖 = (0,0,0)𝑖𝑖 of the coordinates is.

It’s important to remember that since suspension components follow the reference system 𝑲𝑲2𝑖𝑖 :
• Positive values on x refer to positioning towards the car center, while negative values refer to positioning away from the car center.
• Positive values on y refer to positioning above the wheel center, while negative values refer to positioning below the wheel center.
• Positive values on z refer to positioning in front of the wheel center, while negative values refer to positioning behind the wheel center.

Pro tip: the AXLE suspension type references the points from the center of the axle instead of the center of the wheel.

- Let’s discuss first the parts of suspensions.ini that deal with weight distribution, moments of inertia and center of gravity.
After working with MOIs and the sprung mass inertia box estimations, what you have left is the setup of the CG height. (total to sprung CGH conversion)
That’s where the BASEY value here comes into play. It is the vertical distance of the CG from the center of the wheel, referenced from the suspension design
height. It is the CG height (CGH) for the sprung masses. It can be thought of as the position of the connection between suspension and chassis.
A negative BASEY produces a positive CGH. The formula for each end of the car (front/rear) is RADIUS – BASEY, and the RADIUS value comes from
tyres.ini. For example, if the CG is 0.4m up from ground and the wheels of one axle are 0.3m radius, BASEY is -0.1m since it has to go down 0.1 from 0.4m
to get to that axle. Thus, you can see BASEY as a vertical vector going downwards from the geodetic elevation of the CG to the center of the wheels of one
specific axle (either front or rear). Bear in mind that the loaded tire radius should be used for accuracy.
The values of BASEY between the front and rear axles may be different, due to variations in suspension designs and tire size. It is a quite common practice
from vehicle manufacturers to employ multiple types of systems, to either reduce the costs 68 or solve technical issues (improving the handling). That’s why
the actual formula of the CG height for the entire sprung mass is:
(𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 + 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵) + (𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 + 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵)[𝑚𝑚]
𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐶𝐶𝐶𝐶 ℎ𝑒𝑒𝑒𝑒𝑒𝑒ℎ𝑡𝑡 (𝐶𝐶𝐶𝐶𝐶𝐶) =
𝐶𝐶𝐶𝐶_𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 [%]

Pro tip: the process for setting up BASEY correctly is:

1. Find plausible CG height for the sprung mass.
2. Ensure that -BASEY + RADIUS (tire loaded radius) is exactly equal to that number for front and rear suspensions. You accomplish this by going in-game and checking
that the CGH matches up with the Car Physics app.
3. Never edit BASEY again (unless you change your CGH, then repeat the process).
Typically all vehicles should have identical BASEY values for front and rear suspensions, as there is only one CG for the whole mass. The idea of BASEY being different front
to back is not supported by reality, as the values are both measuring the same thing, the CGH, without chassis flex anyway. Unless you have tires with different radii, then you
have to account for that and the numbers will be forcibly not identical.
Remember that as you change the BASEY value, your whole model will also visually move. You must add in a graphical offset (see car.ini) to keep the visual side correct.

68
An example is the adoption of leaf springs for the rear axle and double wishbone / McPherson struts for the front wheels.

433
Look at Fig. below for a simplified visualization of the BASEY value.

Fig. - WHEELBASE says how far apart the axles are. BASEY says how far down from the “red line” through the CG the axles are. CG_LOCATION is the weight distribution, that
says how the WHEELBASE is split up between front and rear, so a higher number means more wheelbase behind the CG.

- General features of suspensions portrayed by AC:

Usually suspensions share some basic components, like springs, dampers, bump stoppers, upper and lower arms. All of them are parametrized in AC within
the suspensions.ini script. For a quick visualization of the most important values, see Fig. below.

Fig. – PACKER_RANGE and the suspension travel (sustrvl=static spring deflection) move when you change ROD_LENGTH. If you modify the ride height by editing ROD_LENGTH
and you want the PACKER_RANGE to not move, you have to change it by the same amount.

Design height (or zero) is just the coordinate numbers in the .ini; when ROD_LENGTH=static deflection, the simulated height is at the design height (because
ROD_LENGTH is offsetting the springs deflecting under load and lifting the suspension back to the design height).
ROD_LENGTH can be adjusted in-game, while CGH cannot, so use it to move the suspension, adjusting the ride height, which then also moves the model
because it is connected to the suspension. (unsure if correct)

The formula for ROD_LENGTH should be static deflection + offset from “0 point” (measurement point) of suspension.

A ROD_LENGTH value which matches up with the suspension travel value will result in the suspension loading in at the design height, or the height that
the coordinate points for the arms are inputted in and all of the lines are referenced from. Suspension travel is the amount of static spring deflection for that
wheel, from now on referred to as suspension travel or “susp travel”. Negative being compression, from now on referred to as “bump”, and more positive
being extension, from now on referred to as “rebound”.
What is the push rod?
434
You change ride height by altering the rod length. ROD_LENGTH modifies the height of the car but it does NOT affect the actual suspension travel (to affect
the suspension travel you need to change the BUMPSTOP_UP and DOWN and the PACKER_RANGE values). Especially on race cars you don't want to change
ride height by altering the spring stiffness or preload. Specifically preload "is Satan", as said by a race engineer, so everybody stays away from it. You set the
rod length up and down and you modify the ride height while keeping your spring rates identical, which obviously is what you want to have correct handling
predictions in a proper race car.
- What are the bump stoppers (bumpstops) referenced by BUMPSTOP_UP, BUMPSTOP_DN and BUMP_STOP_RATE?
They are typically elastic components (usually made of hard synthetic rubber/plastic) which prevent hard metal-to-metal impacts when the suspensions reach
the extreme of their travel during a bump, hence the name. Without them, when you take huge bumps, you would very quickly damage the vehicle chassis,
the suspension arms and the axles. There are mainly two locations where the stoppers can be: on the upper and on the lower part of the suspension. Typically
only one stopper is needed per corner (Fig.).

Fig. – Rear axle with bump stop bushings highlighted.

You may ask: what happens during rebound travel? The extension of the wheel downwards is limited by the linkages or by the springs themselves. But if the
car is mid-air you won’t care that much about the suspensions, your problem will be the aerodynamics.

Fig. - leaf spring suspension with a pretty huge stopper.

Depending on the design, some are secured inside the space occupied by the spring, or in line with the piston rods of the shock absorbers, adding an extra
level of absorption when the shocks reach their limit, or simply between frame and axle, absorbing energy before the axle gets a chance to slam into the frame.
Alternatively stoppers can be placed above the lower arm (Fig. ). In AC, the up bumpstops are considered as the rubber stops mounted to the chassis, not on
the damper shaft. The down stoppers represent the end of the piston stroke inside the shock absorber, which resists droop. Most of the time it is not possible
to consider the BUMPSTOP_DN as a spring, so its elastic constant value must be set very high, to portray an infinitely stiff spring (= hard stop).
Pro tip: keep in mind that real-life bumpstops are progressive in rate and become very stiff fairly quickly, but are somewhat soft initially, so they’re good for controlling the
suspension travel without making the car overly stiff. They also have a little bit of damping, a very small percent compared to their spring rate. In AC the stoppers are linear
instead, unless you set the BUMP_STOP_PROGRESSIVE line to 1. However, this vanilla feature is buggy and doesn’t work properly. There is a correction brought by the
CSP mod which makes it work correctly, the progressive spring rates fix.

435
Packer is the actual "bumpstop" or packer springs

Fig. -

Various shapes can be employed, depending on the requirements. However, it shall be noted that bumpstops don’t need to be made out of rubber. They can
be adjustable hydraulic devices too. These are mostly employed in racing and tuned vehicles. In Fig. below you have a couple examples.

% ▲ BUMPSTOP_UP and BUMPSTOP_DN set the suspension travel in meters referenced from the neutral point (the design height). That’s the distance
above/below the wheel centre at which the spring rate will change from the SPRING_RATE to SPRING_RATE + BUMP_STOP_RATE. They should commonly be placed
farther than PACKER_RANGE.

As an example, if we set BUMPSTOP_UP to 0.1, the wheel can move upwards 100mm from the original wheel centre position, with respect to the car sprung
mass.

So if your suspension has 50mm of movement up and 50mm movement down, it'd be:

BUMPSTOP_UP=0.050
BUMPSTOP_DN=0.050

The total travel is 100mm, because it's 50mm allowed up and 50mm allowed down. 0.000 is not a coordinate in space: it just means there is no travel in that
direction.

% There are no general rules for setting these: use data that you find. At worst, learn enough to be able to estimate from pictures or just seeing the car
drive. Usually, the DN value is higher than the UP, but it can vary of course.

- Heave springs (HEAVE_FRONT)

They are a decoupled solution from conventional springs. The only deflect under vertical loads, which mainly are downforce and transitions under braking or
acceleration.
In the real world you can use them to adjust ride heights, minding the aerodynamic balance of the car (check heights in telemetry and use the aero
calculator to see where you want to be at that point of the track).
Ideally, you'd want stiff heave springs to keep ride height constant, but usually, you want a different height in corners and straights, to optimize the aero.
I'll give you an interesting example: with the Dallara P217 LMP2, if you are saving fuel, you'd rather want softer front heave springs, because your brakings
are smoother. But if you are braking late and hard, you'll want it stiffer so that the front doesn't drive too much.
Softer heave springs give more grip during heavy weight transitions to that end of the car. The sacrifice is less aero in higher speed corners.
Like always, the best is to test it and make your own understanding of it for the track and car.
A zero spring rate heave spring with a bumpstop doesn’t do anything. Just set it to 1 Nm, the code disables the heave spring if spring rate == 0. 1 Nm is
basically nothing.

436
Note: rear heave springs appear to get ignored when the front is not DWB: in such a condition, the AC log will print the following message:
IGNORING HEAVE SPRING BECAUSE SUSPENSION 0 IS NOT DOUBLE WISHBONE

- What if the car has a rake angle (Fig.)? If you have got the correct suspension measurements you don't need any corrections for the rake. Remember the
measurements have as a reference point the center of the hub, and the height of the center of the hub from the terrain is only relative to the tyre radius.
You can have the body at any rake and position you like, independently of the suspensions. Open the car.ini file and change:
GRAPHICS_OFFSET=value,value,value
GRAPHICS_PITCH_ROTATION=value

Fig. - Delta CGh axle= Z axle from CG *tan(Rake angle in radians). As a result, change the BASEY to match in the editor the value of CoG height front and rear.

- A guide to vanilla suspension types:

The designs available in AC by default are DWB (Double Wishbone), STRUT (McPherson strut), AXLE (for the rear axles) and ML (Multilink).
DWB is good for 90% of the applications, and STRUT is a bit better for, yeah, struts. But AXLE is pretty sub-optimal and ML is buggy. Let’s analyse each
type now.
DWB suspension
With the Double Wishbones you can simulate almost all the independent suspensions out there. The multi-point suspensions are made this way because of
lack of space in the actual real cars. The engineers want to create specific wheel movements but they don't have space in the chassis to make the wishbones
as long as they like, so they use multiple arms. In a sim you have infinite space so you could get the exact same wheel movements by using DWB that are
as long as the real multipoint suspension arms extension and tangents.
Acceptable replications of trailing and semi-trailing arm, swing-axle, multilink and other uncommon or antiquated geometries may be accomplished to a good
degree of accuracy when enabling the TORQUE_MODE_EX=2 fix (CSP addition). It can also replicate MacPherson Strut layouts to reasonable accuracy if there
is need to use some DWB2 features with it.
The example car in Fig. uses DWB.

437
 O20

Fig. – The front suspension layout of the Tatuus FA01 by Kunos (picture taken from the left side of the car).

Looks like this when you get the susp app working, minus all the labels. In blue is the origin O2𝑖𝑖 of the suspension reference system 𝐾𝐾2𝑖𝑖 .
The end points should be in the same place as the ball joints on the car.
For a rear suspension, the link created with WBCAR_STEER and WBTYRE_STEER becomes a tie-rod instead of a steering arm, and in typical suspension
geometry is coplanar with one of the wishbones - so it looks like a rectangle instead of a triangle, and you can just code it in as such. The tie rod is VERY
important.
The code for this suspension requires specifically the following lines:
TYPE=DWB
WBCAR_TOP_FRONT=
WBCAR_TOP_REAR=
WBCAR_BOTTOM_FRONT=
WBCAR_BOTTOM_REAR=
WBTYRE_TOP=
WBTYRE_BOTTOM=
WBCAR_STEER=
WBTYRE_STEER=

438
STRUT suspension
Looks like this:

Note that STRUT_TYRE and WBTYRE_BOTTOM are in the same place here - I believe that in general you want the STRUT purple line to be in the direction
the strut compresses & rotates around, and it's possible that in all real suspension designs, it does line up this way.
To switch to strut suspension, set
TYPE=STRUT
And, in place of WBCAR_TOP_ (front, rear, tyre) you have
STRUT_CAR=
STRUT_TYRE=

In STRUT the bumpstops, up and down, use a 500k Nm rate, hardcoded.

ML suspension
The ML (multilink) is still an independent suspension, just more flexible. It lets you define 4 links anywhere + tierod, by using the JOINT#_CAR and
JOINT#_TYRE, for # from 0 to 4. It does not work for front wheels, it’s not steerable.
Also, it requires the bumpstops and the packers to be set properly in the setup.ini file, otherwise they won’t work. PACKER_RANGE is not functional unless
inputted into setup.ini. Packers will always default to the MIN value.
There are some bugs with alignment not always setting correctly when first loading into the game. It also sets toe to random values sometimes in setup.
Kinematically it seems to work fine though. ML produces more or less correct suspension curves.
You can use DWB to solve the issues with the ML type, but you’ll want/need to use kinematic software to make such a conversion.
DWB is ML with welded outboard joints. The inside links are constrained.
The suggestion is to not use this type of suspension, you can however graph curves with it and use those to help in building a DWB version.
The code for this suspension requires specifically the following lines:
[REAR]
TYPE=ML
JOINT0_CAR=0.3534, 0.12674, 0.0800
JOINT0_TYRE=0.15369, 0.14219, -0.0400
JOINT1_CAR=0.3934, 0.13274, -0.0800
JOINT1_TYRE=0.15369, 0.14219, -0.0400
JOINT2_CAR=0.2498, -0.07777, 0.4000
JOINT2_TYRE=0.17184, -0.11425, -0.0625
JOINT3_CAR=0.42926, -0.10782, -0.0700
JOINT3_TYRE=0.07957, -0.11445, -0.0600
JOINT4_CAR=0.30933, 0.01046, 0.2200
JOINT4_TYRE=0.097911, 0.01257, 0.1600

AXLE suspension
For AXLE suspensions, real-world geometries may be inputted. However bear in mind that the links are very stiff. A link count of 5 links is likely to bind. It
is advisable to match the kinematics with a 4-link setup if possible. If the upper arms are not laterally separated very much between _AXLE and _CAR
points, you may combine them into one arm and not suffer any kinematic downside. Bear in mind that PACKER_RANGE is not functional for AXLE.
Pro tip: the reference point for the AXLE joints is the center of the live axle. This is valid only for this suspension type.

The code for this suspension requires specifically the following section to be added (this example comes from the official Maserati 250F by Kunos):

439
[AXLE] ; Add this section only if you’re using the AXLE suspension TYPE.
LINK_COUNT=4 ; Number of TOTAL suspension links used in AXLE suspensions, referenced by TYPE in [REAR].

% ▲ Due to high stiffness of suspension links, an input of 5 is not recommended and 3 or 4 should be used instead. 5 results in frequent, unintended
binding of the suspension assembly.

LEAF_SPRING_LAT_K=880000 ; Lateral coefficient for leaf springs; controls the lateral resistance springrate of the axle.
TORQUE_REACTION=-0.2 ; Torque reaction of AXLE suspensions.
ATTACH_REL_POS=0.729 ; “motion ratio” for the corner springs and dampers for AXLE suspensions.

% ▲ It causes a change in wheelrate when the suspension rolls. The formula is Length between links / TRACK. For example 1.500 / 2.400 = 0.625

J0_CAR=0.4188,-0.072,0.541 ; Attachment point of the bottom left arm on the car.

J0_AXLE=0.438,-0.082, -0.031 ; tyre bottom left arm.
J1_CAR=-0.4188,-0.072,0.541 ; car bottom right arm.
J1_AXLE=-0.438,-0.082, -0.031 ; tyre bottom right arm.
J2_CAR=0.4188,0.080,0.541 ; car top right arm.
J2_AXLE=0.438,0.076, 0.031 ; tyre top right arm.
J3_CAR=-0.4188,0.080,0.541 ; car top right arm.
J3_AXLE=-0.438,0.076, 0.031 ; tyre top right arm.
J4_CAR=0.572171,0.00,0 ; car top right arm.
J4_AXLE=-0.572171,0.00,0 ; tyre top right arm.

% ▲ These lines are the coordinates of the suspension linkages for the AXLE suspension type. Again, keep in mind that the reference point is the center
of the live axle. They may be excluded depending on the value of the LINK_COUNT line below. For example you can exclude J4 if you use LINK_COUNT=4, since
the first index is zero.

- To start off, use the in-game Suspensions app (see par.) to analyse the positions of links and become comfortable with viewing the assemblies.

- The best way to learn the suspension is to enable the dev app and hit Backspace, this brings up an ingame representation where you can check the parts
are where you want them.

- What's the best way to make a swing axle suspension on AC? Use a double wishbone, but move all the on-car mounts onto the axis it swings around.

- As the physics creator you must also specify stiffness rates for the corner springs, the stabilizer bars, the corner spring dampers, the packers, bump and
rebound rubbers, heave springs and any possible future additions.

- The vanilla PROGRESSIVE_RATE for springs has got a bug. In the solver calculations, rate needs to get divided by 2, but in vanilla it doesn’t happen. CSP
brings a fix for this, adding the following section to suspensions.ini:
[_EXTENSION]
FIX_PROGRESSIVE_RATE=1

Obviously it doesn’t correct anything if you don’t have the mod installed.

- You can't change camber or toe in a live axle, at least not back in the days unless you hammer it. Mustang teams would hammer the rear axle to bend it a
bit and gain a tiny bit of toe... but AC doesn't simulate this.

- About Anti-Roll Bars: you have to consider that AC does not consider the torsional rigidity of the chassis so the ARB is applied to an infinitely rigid chassis
and is not representative of the real one. You should instead calculate the real roll angle and then adapt the ARBs to get it in game. If you want to do some
kinematic calculations, I can tell you that usual roll angle values at 1 G for passenger cars starts from 6 or 7 for small economic cars, passes through 4 or 5
for medium class and goes to 2.5 or 3 for sport cars. Those values are an average between front and rear, usually much of the stiffness is on the front so if
you want to use 4° you can set 3.5° front and 4.5° rear.

ksSusEditor, a basic suspension geometry viewer which is compatible with DWB and STRUT layouts. AXLE is buggy.

- How to create a suspension geometry in AC

When enough relevant information to somewhat form a car has been gathered, you can move on to making the suspension geometry.
Laser scans of the coordinates is one of the best resources, so are CAD models from the manufacturer. High-definition schematics of the suspension in
orthogonal views are also useful. A basic method is to determine a pixel size from a known dimension, like the brake disc diameter, then measure the
amount of pixels from the center of the wheel or another reference point and convert it into a metric value. For example if you know that 2px equals 1mm,
you will calculate 1 / 2 = 0.5mm per px. That is your constant which you use to multiply your pixel measurements with.

440
At worst, a photo-reference method may be used to create suspension geometries. With more sophisticated photo-matching methods, somewhat good
results can be attained. It is advisable however to at the very least find some known angles or dimensions to anchor the new data to. Do not expect too
much accuracy out of this method unless you happen to find extremely right-angles of the assembly. Pay great attention to what position the assembly is in;
fully drooped, without a car mass, with a full load on it etc. Strive to design the geometry at the design height of your choosing, usually the position the
geometry is in without any occupants or fuel loading it, but with the load of the car on it.

Ultimately, precision to the hundredth of a degree is not necessary, especially on road-going vehicles equipped with rubber bushings that deflect from
forces (Precisely measuring such a geometry may prove challenging to begin with if the components are worn) but you should take care to keep outputs
within acceptable limits. I try to stay within at least 0.1deg accuracy for angles in any given suspension position, but laser scans have produced larger
deviation than that in practice for some aspects. Given insufficient data and a choice needing to be made, try to find a solution that produces the least
compromise to the car behavior as possible.

When building the front geometry, match the STEER_LOCK and STEER_RATIO values in car.ini to the real-world values and ensure that your geometry is
accurate. Adjust LINEAR_STEER_ROD_RATIO until you are within the specifications for steering angles. Even laser-scanned roadcar geometries may barely
fall within the specifications, and modified cars at a different suspension height or with geometry modifications will likely differ from the idealized wheel
angles. Don’t put too much importance on matching the spec exactly, specifically for the inside wheel (The spec is often +- several degrees for a reason) but
an accurate geometry should nonetheless provide closely matched angles. More complicated geometries such as Multilink strut setups or the Super Strut
layout may somewhat require a compromise in steering angles to maintain more important characteristics.

Note that many modern roadcar suspension geometries incorporate elastokinematics into their design which is currently not a feature of Assetto Corsa.
ctrl_4ws.ini may be used to hack in some rear-wheel steering effects for a loose replication of some compliance steer, but most of the time such effects can
be ignored without significant issues. Note also that subframe location is fixed and will not deflect due to bushing stiffness either. Hence effects like wheel
hop are not particularly present.

Combination suspension types such as Z-axle as present in the E36/E46 (Fig.) and Out-of-wheel DWB with swan-neck and separated steering axis such as
in the Skyline GT-R are also possible to be replicated to reasonable accuracy if using DWB.

441
Fig. –

Pay great attention to the nature of the joints and how they behave. In some cases, some creative placement of links may be needed to more accurately
match behavior. Try to acquire real-world curves for the suspension to inform the design process. Remember that laterally locating an entire A-arm without
changing its dimensions or inclination will not significantly change the curves in most cases, but may allow closer matching of the Steering Axis Inclination
and Scrub radius.

When beginning geometry building, the first thing you should determine is the most suitable TYPE to be used. Commonly DWB is most capable, but
MacPherson, Chapman and other struts should be usually done via STRUT. Completely solidly coupled rear geometries may be created with AXLE, but
beware that beam-axles are NOT completely solidly coupled and may be best served by a DWB implementation using the rear ARB to produce coupling
similar to the torsional stiffness of the beam-axle. Trailing arms are best suited to be made via DWB. Multilink geometries with a short-arm long-arm
arrangement are also best suited to be made via DWB. A good understanding of DWB suspension will allow a reasonable implementation of many
suspension types. When building geometries, remember to place the suspension points inside of the actual balljoint and slide joint center. The geometric
angle of the arm section is not relevant. Search for images of cutouts of balljoints and bushings to get a better idea.

When building ML geometries, the process will be highly specific to the exact type and arrangement of arms and generally some kind of compromise must
be made. A simple explanation would be that the aim is to match the dynamic rotation centers and swing arm lengths as best as possible. It is
recommended to first build the geometry with ML layout to verify its characteristics, then build a DWB version for better compatibility and less bugs.

Many ML geometries separate a set of arms, or all arms, to attain curves which are physically difficult or impossible to attain with DWB due to physical or
kinematic constraints. In some cases you may want to place a TYRE joint at the intersection point of the separated arms’ axis (Fig.) and move the relevant
arms towards the new center while maintaining real swing-arm lengths, although that is not always possible as there is not necessarily any point in space
where intersection happens. In that case it may be beneficial to focus on the swing-arm lengths and angles. If the vertical separation of the separated TYRE
points is very high, a delicate compromise by changing Y and X of TYRE and perhaps CAR points may need to be found. Take care that arm angles in roll
do not become strange, despite seemingly matching centers when at design height.

Fig. - Example of what is meant by finding the intersection point of arm axis. Beware that it is a 3D location and cannot be accurately discerned from a limited amount of images. The
geometry in the picture is from the Honda S14 rear suspension.
When building typical Trailing or Semi-trailing arm geometries, the DWB layout should be used. You should locate the CAR side points and weld the upper
and lower wishbone CAR points to the true joint locations. Do not weld the TYRE points, I suggest adequate separation on height for upper and lower
balljoints. The amount of separation should not be relevant to the kinematics, but an ample amount of separation may perhaps assist in avoiding some
unintended forces. The center point of the TYRE points should be the wheel center on Y; the apparent angle of the trailing arm assembly is not relevant, only
the geometric angle. The toe arm should be placed along the instant axis ie: WBCAR_STEER on the inboard CAR joint and WBTYRE_STEER on the
outboard CAR joint. Beware that in older CSP versions telemetry and UI shows erroneous camber and toe values for suspensions with caster gain, typically
toe-out when actual curve is toe-in. Use external software to confirm.

442
Auto Union type C: Trailing arm front suspension is just parallel A-arms, only the pivots are oriented front/rear rather than inside/outside. Make the base of
the A-arms very narrow, though that shouldn't matter in terms of game geometry.

Swing arm rear suspension are A-arms with a common chassis pivot at the u-joint.

The wrong antisquat is a big issue for weird use of DWB, the game actually has an internal fix for it but you can only access it with the shader patch (needs
setting a variable that's not in any ini)

Front suspension's same as a Beetle I think? torsion spring trailing arms? Doesn't really do anything crazy. You'd be close enough just making it regular
DWB with equal length arms.

(wip)
CSP ADDITIONS
- The mod brings alternative ways of applying torque to DWB-only or DWB & STRUT suspensions. It’s the fix for a Kunos bug that caused inaccuracies with
anti-effects (anti-squat, etc.) geometry. The following section shall be added to suspensions.ini.
[_EXTENSION]
TORQUE_MODE_EX=2 ; Values: 0 is default, 1 is broken, 2 recommended and should be physically accurate.

% ▲ EX=2 calculates the internal forces pointing to the contact patch instead of the wheel center (vanilla AC), so it's like real case.

In reality these lines enable a feature created by the developers that never made it to the final AC release due to its incompleteness and to other fixes that it
would have required to work.

- CSP brings a fix for a bug in the progressive springs and bumpstops: rates needed to get divided by 2 in the calculations, which doesn’t happen in vanilla.
[_EXTENSION]
FIX_PROGRESSIVE_RATE=1

CURIOSITIES AND AMENITIES

- suspension_graphics.ini
This file is an old config, left from early development, where the linkages were defined in a different way. It can be deleted, as it’s unused by AC; it will only
generate an error message in the command console, as the objects it’s searching for do not exist anymore in the vehicle 3D model (Fig.).

Fig. – The error displayed in the AC Console when starting a session.

It has already been deleted in many cars. There is still one with text in the Lotus 98T data files:
[CONNECTION_0]
SRC_OBJECT=CAR_BODY
TARGET_OBJECT=Braccetto_L
DST_OBJECT=WHEEL_LF
SRC_POINT=0.35 , 0.47, 1.12
DST_POINT=-0.18,0.18,0

[CONNECTION_1]
SRC_OBJECT=CAR_BODY
TARGET_OBJECT=Braccetto_R
DST_OBJECT=WHEEL_RF
SRC_POINT=-0.35 , 0.47, 1.12
DST_POINT=0.18,0.18,0

FAQ
QUESTION [1]: I need help with the HUB_MASS line: how much does a F1 tire+rim weigh?
ANSWER [1]: Look at Fig. . It’s self-explanatory.

443
Fig. -
PHYSICS (for suspensions.ini)
Wheels
Curious as it might sound, wheels are not really part of the suspension, except as tyre carriers, and in some areas of racing a poseur's delight. Leaving aside
wood and cast iron, variations on the theme of a circle keep a mini-industry successfully in business in steel and alloy, spoked pressed, cast, one piece, in
two halves and multi-section permitting variable offsets. This latter type gives the designer some elbow room in varying both the track and other clearances
if desperate.
In suspension terms, wheels are nonetheless the vital link between the geometry and the tyre contact patch, and as such have to have all those old virtues -
lightness, strength and reliability.

TYPES OF SUSPENSIONS

At this point we can separate different suspension types, making them fall into one of these main categories:
• Dependent
• Independent
• Semi-independent

What’s the difference?

These terms refer to the ability of opposite wheels to move independently of each other. A dependent suspension normally has a beam (a simple 'cart' axle)
or a (driven) live axle that holds wheels parallel to each other and perpendicular to the axle. When the camber of one wheel changes, the camber of the
opposite wheel changes in the same way (by convention, on one side, this is a positive change in the camber, and on the other side, this a negative
change).
In an independent suspension instead, the wheels move independently, hence the name, and the camber of one wheel does not affect the other.

444
Fig. -

We will talk about semi-dependent suspensions later on.

We will also highlight which systems are used more or less frequently, depending on whether they’re on the front or on the rear end of the vehicle.

DEPENDENT SUSPENSIONS

Dependent systems may be differentiated by the system of linkages used to locate them, both longitudinally and transversely. Often, both functions are
combined in a set of linkages.

Examples of location linkages include:

• Satchell link
• Panhard rod
• Watt's linkage
• WOBLink
• Mumford linkage
• Leaf springs used for location (transverse or longitudinal):
Fully elliptical springs usually need supplementary location links, and are no longer in common use
Longitudinal semi-elliptical springs used to be common, and are still used in heavy-duty trucks and aircraft. They have the advantage, that the spring rate can easily be
made progressive (non-linear).
A single transverse leaf spring for both front wheels and/or both back wheels, supporting solid axles, was used by Ford Motor Company, before and soon after World
War II, even on expensive models. It had the advantages of simplicity and low unsprung weight (compared to other solid-axle designs).

INDEPENDENT SUSPENSIONS

The variety of independent systems is greater, and includes:

• Swing axle
• Sliding pillar
• MacPherson strut/Chapman strut
• Upper and lower A-arm (double wishbone)
• Multi-link suspension
• Semi-trailing arm suspension
• Swinging arm
• Transverse leaf springs when used as a suspension link, or four-quarter elliptics on one end of a car are similar to wishbones in geometry, but are more compliant.
Examples are the front of the original Fiat 500, then Panhard Dyna Z, and the early examples of Peugeot 403, and the backs of AC Ace and AC Aceca.

TYPES OF SPRINGS
What are live axles and dead axles, and their role in an automobile?

What is the camber angle of a wheel?

Camber angle is the angle between the plane of the wheel and the vertical line from the ground. There are 3 types of camber angle: it is described as
positive when the top of the wheel leans outward, negative when the top of the wheel leans inward, and neutral or zero camber, when the top is aligned with
the contact point of the tire, so that the wheel axis is parallel to ground. Camber angle alters the handling characteristics of a suspension system.

445
• Positive camber is the most rarely used setting of the three camber settings. This is a specialised setting used in a few forms of motorsport, for example it was common in
F1 cars from 1920s to 1960s-1970s. This is because if the suspension was soft the nose of the vehicles could drop under heavy braking, thus giving much less camber
into hard corners, and without power steering turning the wheel took a fair bit of strength, that’s why the steering wheel was so large to be able to get leverage, and the
positive camber helped quite a bit too. It guarantees a smaller contact patch on straights, and therefore less rolling resistance. Under braking and through corners, the
weight transfer allows for more tyre on the track and more grip.
Usually it is seen on road cars only if there is damage to the suspension components. It is most commonly used in heavy load applications such as trucks where when the
vehicle is empty, the tyres have positive camber so that when the vehicle is at its normal operating load the tyres then settle to a neutral camber position due to the
camber gain of the system.
• Negative camber: In general, it improves handling when cornering. This works when a car is cornering, the lateral load transfer through the body causes the vehicle to roll.
When the car encounters roll, it raises the inside contact patch of the outside wheel. This reduces overall grip. If the camber is set to negative then it has a smaller contact
patch when it has zero roll but engages full contact patch as it corners rolling onto the full contact patch.
• Neutral camber angle is used in applications where hard cornering is not common, such as road cars, drag racing, off – roading. When a tyre is in its neutral position, the
full tyre contact patch is in full contact with the ground during zero roll situations. This is useful for acceleration purposes as it allows the entire contact patch of the tyre to
be run at optimum slip angle to generate as much dynamic grip as possible for better acceleration and stability.

FAQ

QUESTION [1]: About suspension failure (Fig.).

446
33. tyres.ini
With this script you can set all the parameters for the tires of your car. This is the most important part of our simulation, as it represents the base of every
interaction of the automobile with the tarmac. Don’t be surprised if modifying the values alters completely the vehicle’s behaviour – that’s something you
should expect at this point. Too grippy or too slippery tires will be unrealistic for a stock vehicle, but what we truly need to know are the specifications of the
tire we’re going to simulate; in the absence of such data, we can only estimate; we’ll see how to proceed in the following pages.
[HEADER]
VERSION=10 ; Version of the tire code that the physics engine will load. The suggested input is 10.

% ▲ Use VERSION=10 and do not care at all about what the older tire models did. They’re just outdated, and if you see a mod with a different number (to
be valid it must be 2 < n < 10, but some numbers may be skipped), it means that the tire code wasn’t updated and needs to be edited or replaced.

% To be fair, older tire models are quite good, but they don’t include a lot of features that the newer do, so they’re less accurate when trying to
represent a real-world tire, and more prone to bugs.

[COMPOUND_DEFAULT]
INDEX=1 ; Defines which tire is loaded in the setup by default.

% ▲ The first tire set is entry 0, while the second is 1 and so on. Bear in mind that currently, default pressure for the tire is loaded only from index
0 regardless of what is selected.

[VIRTUALKM]
USE_LOAD=1 ; Boolean. Whether to use load or not in wear calculations (0= no, 1= yes). The recommended input is 1.

% ▲ The normal load of the tire ceased to be considered in the wear calculation after a certain tire model iteration. This parameter adds it back (as it
should be).

[EXPLOSION]
TEMPERATURE=200 ; Temperature the tire should pop/explode at; feature introduced with AC 1.10. [°C]

% ▲ While tire internal structures do deteriorate at around 200°C, temperatures of 450°C and beyond have been observed for the surface and close to
surface layers. It is better to bias high than low, due to the relative simplicity of heat interactions compared to reality, the average temperature of
the tire may rise quite high compared to what it perhaps would be in the inner surfaces of the tire when for example drifting or doing other extreme
temperature generating activity with complex rubber behavior.

[ADDITIONAL1]
BLANKETS_TEMP=50 ; Tire blankets temperature, used if blankets are enabled in the session configuration options.
PRESSURE_TEMPERATURE_GAIN=0.1 ; Pressure vs temperature gain.
CAMBER_TEMP_SPREAD_K=1.4 ; Camber spread tweak value. AC default is 1.4, higher numbers = more spread.

[FRONT] ; SYNTAX: Add ” _X” for every further compound. Example: FRONT_1 for the 2nd tire set in the index.
NAME=Nurburgring ; Display name of the tire in the setup screen.

% ▲ Uppercase and lowercase letters may be used alongside numbers, but some special symbols may not display correctly.

SHORT_NAME=V ; Display name of the tire compound in the leaderboard.

% ▲ Standard inputs are:

ST ; Street
SV ; Street 90s (ST90s, 1990s-2000s street tires)
SM ; Semislicks
US ; Slick Ultra Soft
SS ; Slick Super Soft
S ; Slick Soft (also Soft GP70)
M ; Slick Medium
H ; Slick Hard (also Hard GP70)
SH ; Slick Super Hard
HR ; Hypercar road
I ; Hypercar Trofeo
V ; Vintage (GP67; 1950s-60s vintage Grand Prix and street tires)
V70 ; Vintage GT70 (1970s GT tires)
V78 ; Vintage 78 (1978 Porsche 935 Moby Dick only)
E ; ECO
Q ; Qualifying (Lotus 98T only)

% You can find the prefixes also in the ks_tyres.ini script in the assettocorsa/server/manager folder. You can see how same prefixes can be used for
different types of tires. You should choose a prefix that makes sense, however anything can be input.

% ▲ It is currently recommended to stay to standard inputs if possible, so that auto-guessed (automatically generated) cphys (CSP) rain behaviour will
work correctly. CSP’s code is going to automatically turn tires of cars without extended physics into rain tires based on their short names. Cars with
extended physics active (in car.ini) will have to be completed with specific rain tires instead.

% ▲ AC servers can be set to not allow some tyre compounds.

WIDTH=0.135 ; Tire width for graphics effects (defines skid marks width). [m]

% ▲ Doesn’t affect physics but the visual representation of the wheel 3D model in the suspensions app and skid marks. When in doubt, input tire section
width.
% The vanilla AC’s tire model has got only one contact point with the ground, which is represented by a single vector. WIDTH doesn’t matter.

RADIUS=0.356 ; Unloaded tire radius at nominal inflation. Should match the tire radius of the 3D model. [m]

% ▲ Remember that tires’ size may differ from the datasheets. RADIUS does not directly affect the physical characteristics of the tire, such as stiffness
or flex, but it has an immediate impact on the car’s gearing (bigger wheels will make you go faster, but require more torque to be spun).

RIM_RADIUS=0.294 ; Rim radius. Add 1 inch more than nominal (1 inch = 2.54 cm = 0.0254 m). [m]

% ▲ This value is the radius of the rim, used for ground collisions when tires explode. It does not influence physical characteristics such as stiffness
or flex. Use the outer diameter of the rim, not the nominal one. KS suggestion is to add one inch to the wheel radius spec, as the wheel diameter is
measured from barrel to barrel, but there is some additional lip distance. For example, an 18" rim may actually be 19” or 20" in outer diameter.

ANGULAR_INERTIA=2.82 ; Angular inertia of rim + tire + brake disc assembly and transmission axis if present. [kg∙m^2]

% ▲ Includes any other rotating unsprung masses on a specific suspension.

DAMP=550 ; Damping rate of the tire at nominal load and inflation. Values usually vary from 200 to 1400. [N/m/s]
RATE=278800 ; Vertical spring rate of tires. [N/m]

% ▲ This is the vertical spring rate of the tire at nominal load and at the inflation pressure specified in PRESSURE_STATIC. If you change your
PRESSURE_STATIC but wish to maintain the same spring rate, adjust RATE while respecting PRESSURE_SPRING_GAIN.

% ▼ The functions DY0, DY1, DX0 and DX1 below are outdated load sensitivity values, obsolete from tire model V5 onward. They have to be included for
tyres.ini to load properly, but do not have any impact on the physics of the currently recommended version (v10).

DY0=1.9270 ; Lateral force. Unused since tire model V5 - still likely required for loading.
DY1=-0.220 ; Lateral load sensitivity. “ “ “ “ “ “
DX0=1.9770 ; Longitudinal force. “ “ “ “ “ “
DX1=-0.239 ; Longitudinal load sensitivity. “ “ “ “ “
WEAR_CURVE=wcurve_conti.lut ; Tyre wear lookup table filename to call.

447
% ▲ Specifies the look-up table to be used for wear characteristics. Works on "virtual Km" that are added depending on the slipangle/ratio and
temperature. The format is vkm | grip percent multipler, in whole numbers. The LUT must be included in the data folder. Example : tire_example_wear.lut
Example LUT format:
0 |100
30 |90

SPEED_SENSITIVITY=0.004979 ; Speed sensitivity value (higher the value, the greater slip velocity's effect on tire grip).

%▲ controls the mechanical and chemical speed sensitivity of the tire. Good value is generally around 0.002.
force/(speed_sensitivity * ((sin(slip_angle_rad) * m/s)^2+(cos(slip_angle_rad) * m/s * slip_ratio)^2)^(0.5) + 1.0)
OR
1/( total tire slip in m/s * speed_sensitivity + 1)

RELAXATION_LENGTH=0.2792 ; Delay function for lateral loads. [m]

% ▲ Slip angle is instantaneous, so you need a delay function to represent the contact point’s movement, hence relaxation length exists. It’s the only
time-based physics effect. It's a "lag" in the tire response, that acts as a distance-based filter. In other words, it can be seen as the time it takes
for the side loads to build up after you turn a tire. It is also described as “the distance that a tire rolls before the lateral force builds up to 63%
of its steady-state value” (Wikipedia). One interesting fact about relaxation length is that camber is not influenced by it (and AC models this
correctly), so camber variation produce an instantaneous force while slip variations need space in order to build up... the space is controlled by the
relaxation length parameter.

ROLLING_RESISTANCE_0=11 ; Rolling resistance constant component (rolling resistance force = (ROLLING_RESISTANCE_0 +

ROLLING_RESISTANCE_1 * V^2 ) * normal force / 1000

ROLLING_RESISTANCE_1=0.000561 ; Rolling resistance velocity (squared) component - see above

% ▲is the squared velocity parameter used in RR calculations.

pgain=1+(PRESSURE_IDEAL / current_pressure - 1) * PRESSURE_RR_GAIN RR=(ROLLING_RESISTANCE_0 + ROLLING_RESISTANCE_1 * V^2) * pgain Divide by 1000
Load Curve Helper has a solver.

ROLLING_RESISTANCE_SLIP=3680 ; Rolling resistance slip angle component. Kunos-size values not recommended. Minimum of zero, maximum
of 1000 recommended and correlated via telemetry.

% ▲ Controls rolling resistance gain from tire slip. Typical values in KS tires are observed to be 20~ times too high. Decent value for Cphys is around
800~, perhaps lower for vanilla such as 300~.

% ▲ The rolling resistance of a tyre raises when the tyre generates slip and friction. This is the typical behaviour that you can even hear on onboard
cameras (or your car if you ever pushed on track), when on a given turn, at maximum throttle aperture the engine loses rpm because it can't overcome the
friction of the tyres.
When the tyre goes over the peak slip angle or slip ratio, the rolling resistance plateau and stops raising.

FLEX=0.01492 ; Tire profile flex. Unused since v5 model, required anyway for loading.

% ▲ Increasing the number increases the flex, along with the added slipangle with load.
This is an outdated tire profile flex input. This value is not used since V5 anymore; it must be included for the tire code to load, but is otherwise
unused. Just leave it in tyres.ini anyway to avoid warnings/errors while loading. The functionality has been replaced by the FLEX_GAIN value.

CAMBER_GAIN=0.075 ; Camber gain value as slipangle additive. Default value is =0. (or =1?)

% ▲ Amount of camber thrust. It is a slip angle shift from camber angle. A typical value is 0.100.

% The formula that calculates the slipangle additive is the following:

Slip additive = CAMBER_GAIN * sin(camber angle)

Where sin(x) is the well-known mathematic trigonometric function. You can obtain this value with any scientific calculator, knowing the camber angle.

Now, what is camber thrust?

Camber thrust is a lateral force which is developed due to the camber angle of the wheel. Like any other lateral force, it is generated due to the
deformation of the contact patch tread of the tires.

DCAMBER_0=0 ; First parameter used by formula-based camber sensitivity.

DCAMBER_1=-4 ; Second parameter used by formula-based camber sensitivity.

FRICTION_LIMIT_ANGLE=10.5 ; Optimal slip angle of the tire at FZ0. An indication of slipangle peak. [deg]

% ▲ It is the peak lateral slip angle at nominal values to attain maximum grip. Due to AC tyre model complexity, this is not an exact number. Put all the
values first, then check the actual slipangle with the in-game TYRES Dev App and modify accordingly. It interacts with many parameters such as load and
should be built for the FZ0 you have chosen. Thus choosing a wise FZ0 is also necessary.

XMU=0.20 ; Outdated friction parameter.

% ▲ Since VERSION=5 this value is not used in the calculations anymore. It must be included for the tire code to load, but is otherwise unused.

PRESSURE_STATIC=32 ; Static (cold) pressure. Always try to use the default manufacturer recommendation. [psi]

% ▲ The actual cold pressure will vary based on temperature conditions. RATE is referenced from this pressure.

PRESSURE_SPRING_GAIN=3580 ; Springrate gain due to a pressure increase of one unit, from the PRESSURE_STATIC inflation. [N/m]
PRESSURE_FLEX_GAIN=0.5 ; FLEX gain due to a pressure increase of one unit.

% ▲ controls the flex gain of the tire from the PRESSURE_IDEAL value for every one psi. Typical KS values are backwards, and input should be negative.
Tires typically gain compliance with higher pressure. NEEDS MORE DOCUMENTATION.

PRESSURE_RR_GAIN=1.0 ; INCREASE IN RR RESISTENCE per psi

% ▲ controls the RR gain of the tire from the PRESSURE_IDEAL value for every one psi. NEEDS MORE DOCUMENTATION.

PRESSURE_D_GAIN=0.0055 ; Loss of tyre footprint with pressure rise.

% ▲ controls the grip loss for every one psi under and above PRESSURE_IDEAL. For example a value of 0.004 means a loss of 0.4% DY and DX for every one
psi deviating from optimal pressure.

PRESSURE_IDEAL=40 ; Ideal (optimal) pressure for grip. [psi]

FZ0=1107 ; The reference load. [N]

It's the load at which some of the values indicated are true, it's used as a reference point for DX_REF and DY_REF.
Fz is in the car physics app named ""load"".
(But FZ0, if it's areasonable value, is not so important stated that the other affected parameters are changed accordingly. You can use, for example,
FZ0=1000 and put DY_REF to 1.7 or FZ0=3000 and DY to 1.2…)"

% is the reference load for much of the tire behaviour, and the load where values are referenced from. Avoid very low or high values. Tire behavior is
relatively nonlinear, so data attained at a load of 1000N might not apply at all at a load of 10000N. Aim for a good average in respect to the car
conditions. Safe values when using custom tire load curves are around 3000 to 6000. The input is in Newtons.

LS_EXPX=0.86 ; The exponent used in the formula

% ▲ longitudinal load sensitivity exponential parameter used by Kunos-formula-based load sensitivity. LS_EXPX=0 means EXTREMELY linear load sensitivity,
which doesn’t happen in real tires, so avoid that value.

LS_EXPY=0.67 ; The exponent used in the formula

% ▲ lateral load sensitivity exponential parameter used by Kunos-formula-based load sensitivity. LS_EXPY=1.0 means no load sensitivity.

DX_REF=1.22 ; The D level at FZ0. The REF just indicates the grip at FZ0 (which is just the load reference).

% ▲ reference mu for the longitudinal load sensitivity formula, referenced from the FZ0 value.

448
DY_REF=1.22 ; The D level at FZ0. The REF just indicates the grip at FZ0 (which is just the load reference).

% ▲ reference mu for the lateral load sensitivity formula, referenced from the FZ0 value.

% ▲ Formula based load sensitivity should be avoided as it isn’t capable enough to produce faithful grip characteristics.

% ▼ Lut based load sensitivity: the lookup table is better when trying to match a real tire data.

In this case a simple lookup table is used for the parameters DY_CURVE and DX_CURVE. The lookup table can be "inline" ex.:
DY_CURVE=(0=3.0|1500=2.613|3000=1.680|4500=1.447|6000=1.257|12000=1.100)

or referencing an external file:

DY_CURVE=external_curve_file.lut

with the typical AC lut file format of KEY|VALUE

At runtime the lookup table is smoothly interpolated (thus you are not required to insert dozen of values)
Note that the 0 value is required in order avoid crazy numbers at very low loads due to the cubic spline interpolation.

DY_CURVE=tyres_dyF.lut ; Specifies the LUT used by LUT based lateral load sensitivity.

% ▲ Load values should be spaced evenly to avoid dangerous smoothing conditions. The LUT input is load in N and the output is the mu coefficient.

Example: example_tire_195_55_15_lateral.lut
Example LUT format:

0|1.275
3000|1.10
6000|0.95

DX_CURVE=tyres_dxF.lut ; Same as DY_CURVE, except for longitudinal load sensitivity.

DCAMBER_LUT=tyres_camber.lut ; Specifies the LUT used for LUT based camber sensitivity.

% Example : tire_example_camber.lut. Lut input is angle in degrees and output is grip in percent. Example LUT format :

-1|1.04
0|1
1|0.975

DCAMBER_LUT_SMOOTH=1 ; Toggles smoothing for DCAMBER_LUT on or off, with 0 being off and 1 being on.

% extended
DX_CAMBER_REF=3 ; reference angle (in degrees) - must not be zero
DX_CAMBER_MULT=0.98 ; grip multiplier at reference angle

COMBINED_FACTOR=2.20
COMBINED_FACTOR_1=0.4

% ▲ Controls the combined lateral + longitudinal slip grip gain. Modern tires have been observed to not lose lateral grip when some longitudinal stress
is applied. A value of 2.0 is standard ie: traction “circle”, while values above 2.0 will square it out, providing more grip in combined situations. Real
tires appear to have somewhat high values, perhaps around 2.1 to 2.3, but this information is subject to change. It is possibly down to individual tire
characteristics.

FLEX_GAIN=0.122 ; Parameter that influences the amount of flex of the tyre.

The formula are proprietary (KS) and will not be published however the value will roughly approximate a "widening" of the value at which the tyre reaches
max grip as function of load.
The parameter express the amount of slip added to the reference slip angle when load is twice FZ0. Example.
Let's say a tyre has a FRICTION_LIMIT_ANGLE of 10 deg, FZo=2000 N, and a FLEX_GAIN of 0.5 then the max slip angle will be: 10 deg @ 2000N 10 * (1 + 0.5)
= 15 deg @ 4000N
Bigger flex = the lateral force peaks at higher slip angles at increased loads. Values at a few loads are exposed in AC log.txt"

% parameter in the contact patch flex equations. It cannot be compared to real-world values as the interactivity is high within the tire model. It is
additive to the slip angle. The author is unaware of the specific formula(s) used by the engine. An approximation would be that FLEX_GAIN gets added to
FRICTION_LIMIT_ANGLE when load is 2*FZ0, however this is not completely truthful. The log outputs relevant information for determining the practical
effects. The effect appears to be somewhat linear. Typical values for radial tires appear to be around 0.0500 to 0.1200. Most radial tires perhaps end up
around 0.0700 to 0.1000. KS values are somewhat non-compliant compared to current understanding.

FALLOFF_LEVEL=0.90 ; Lowest grip limit past grip peak (related to peak, so 0.9 is 90% of max grip).

% ▲ Recommended to use around 0.7-0.8 for most tires. Input is in percent, so 80% = 0.8.

% Adjusts the grip the tire will produce when slipping at infinite SR (slip ratio). In vanilla, falloff curve is shared between lateral and longitudinal,
while in real tires lateral dropoff is much lower than longitudinal.

FALLOFF_SPEED=1 ; The speed of grip drop-off after reaching the peak slip angle.

% ▲ In other words, it can be seen as how much time the tire takes to come to falloff level. It is a sort of gamma that defines the curve from the peak
(=1) to the FALLOFF_LEVEL (=0.9 for example); =2 was the standard till v6 tyres, =1 is linear so the tyre is "easier", higher numbers make the transition
sharper. In conjunction with the value of 0.7-0.8 for FALLOFF_LEVEL, values of 1-3 for FALLOFF_SPEED are recommended.

CX_MULT=0.976 ; It controls the cornering stiffness of the longitudinal part of the tyre force generation.

% ▲ Adjusts the optimal slipratio longitudinally. A value lower than 1.0 will make the longitudinal part less aggressive, a value of 1.0 will make it
exactly like the lateral, and higher than 1.0 values will make it stiffer. Values below 1.0 are not typically recommended because tires are typically
stiffer longitudinally than laterally. While this is interesting, the most important effect of this value is in the way longitudinal and lateral forces
are combined into a resultant force. Sadly data on combined forces is pretty rare so there isn't a "correct value" to suggest here.

Lower values of CX_MULT will create a tyre that feels more responsive to throttle/brake application. In other words, there will be more loss in lateral
friction when longitudinal friction is applied. Higher values will do the exact opposite by creating a tyre that is pointier and more composed. It's a
parameter that really has huge effects on the final car behaviour.

The formula for the longitudinal slipratio is:

Vanilla: tan(slip_angle_opt) / CX_MULT

Cphys: sin(slip_angle_opt) / CX_MULT

RADIUS_ANGULAR_K=0.082 ; This is the tyre radius increase as function of rotation speed.

It is a simple linear relationship where the dynamic tyre radius is: dynamic_radius = radius + (RADIUS_ANGULAR_K * abs(tyre_rotation) / 1000) Here
RADIUS_ANGULAR_K is in mm/rad/s and tyre rotation is rad/s, hence the division to convert to meters for the radius. Typical values for racing tires are
around 0.01

% is an input in the formula for tire radius growth in millimeters from angular speed. Formula: RADIUS_ANGULAR_K * angularVelocity in rad/s.

BRAKE_DX_MOD=0 ; % additive to longitudinal grip under braking. It's a DX multiplier apparently (1 + BRAKE_DX_MOD).

Positive values will make the tyres better on braking than accelerations, and the opposite is true ... but usually tyres generate more slip on
acceleration than braking so using positive value is the way to go."
% controls how much more longitudinal grip the tire has in braking compared to acceleration. Formula is (1+BRAKE_DX_MOD)*D. For example, a value of 0.02
will provide +2% D when braking, and a value of -0.02 will provide -2% D when braking. Typical values for real tires seem to be around -0.02, but it is
an argued topic. It is possibly down to individual tire characteristics.

[REAR]
[...] ; same as the FRONT tires, skipping everything.

449
[THERMAL_FRONT] ; SYNTAX: Add ” _X” for every further compound. Example: THERMAL_FRONT_1 for the 2nd tire set in the
index.
SURFACE_TRANSFER=0.017 ; How fast external sources heat the tyre tread touching the asphalt: Values 0-1
PATCH_TRANSFER=0.00027 ; How fast heat transfers from one tyre location to the other: Values 0-1
CORE_TRANSFER=0.00406 ; How fast heat transfers from tyre to inner air and back
INTERNAL_CORE_TRANSFER=0.00093 ; How fast rolling K transmits to core

This value is used to control how the heat generated by rolling (function of ROLLING_K , tyre angular velocity, load, pressure) transfer to the tyre
core. Example value: 0.004

FRICTION_K=0.03950 ; Quantity of slip becoming heat (generated by lateral sliding).

ROLLING_K=0.19 ; rolling resistance heat (generated by rolling driving straight).
SURFACE_ROLLING_K=0.75 ; Like ROLLING_K but dedicated to surfaces.

Prior to V6 the ROLLING_K value was used to generate heat as function of rolling both for Core and Surface, from V6, ROLLING_K is used for Core and
SURFACE_ROLLING_K is used for Surface.

PERFORMANCE_CURVE=tcurve_conti.lut ; File to use for temperature/grip relation

GRAIN_GAMMA=1.2 ; Gamma for the curve grain vs slip. higher number makes grain more influenced by slip
GRAIN_GAIN=0.6 ; Gain for graining.

How much gain raises with slip and temperature difference- 100 value = slipangle*(1+grain%)

BLISTER_GAMMA=1.2 ; Gamma for the curve blistering vs slip. higher number makes blistering more influenced by slip
BLISTER_GAIN=0.6 ; Gain for blistering.

How much blistering raises with slip and temperature difference. Think blistering more as heat cycles. 100 value = 20% less grip

COOL_FACTOR=0.860 ; Speed up surface cooling as function of the square of the car speed. Example value: 1.5

[THERMAL_REAR]
[...] ; same as the FRONT thermals, skipping everything.

% ▼ Below are the section headers for an optional second set of tires. Everything will be skipped as identical to the first set. Other sets of tires can
be added following the correct numeration. In order to avoid confusion, do not to give identical names to different sets.

[FRONT_1] ; next set of front tires.

[REAR_1] ; next set of rear tires.

[THERMAL_FRONT_1] ; thermal model of the front tires.

[THERMAL_REAR_1] ; thermal model of the rear tires.

LITTLE EXPLANATION
- The vanilla tire has got a single contact point with the driveable surface, determined by the vector with the origin at the center of the tire radial dimension
(simply its RADIUS, see tires.ini) and with the end touching ground (Fig.).

Fig. – In-game visualization of the tire contact point. Remember, even if tires.ini has a profile width, it’s for visual skidmarks only. All the interactions between the car and the road happen
only on the location of the point C. The green wireframe cylinders you can see with the Suspensions app, here displayed, are not physical (refer to the WIDTH line).

The tire has a spring and damping rate, it can also wear and manifest a thermal behaviour, which can be expanded with the use of Custom Shaders Patch.
Being a single spot, the dimensions of the tire have no real meaning, and only the compound affects the grip directly. If for example you want to make tires
wider, you need to modify the compound parameters to increase grip, to simulate more width (though I imagine the effect of wider tyres to be quite subtle).
- The question of the 1 contact point vs 5 contact points. Having driven on a true 5d flex model, I can tell you that adding more contact points would make
very, very little difference (and that's on a car that'd be incredibly sensitive to it). Again, the biggest thing is the data input. If the numbers you're using for
your tires are not really correct (especially if, for example, you're using the KS load sensitivity formula instead of a custom Look-Up-Table), that will do a lot
more to change the driving experience than any of the things you can discuss.

Something that a 5- (or more) point(s) tire model can fix is the errors in the collision of the tire with bumps: in Fig. we have an example of the wheel going
right through the curbside (Highlands track) in vanilla AC. This problem is mitigated by the CSP mod, which recently has brought also a new tire model with
more contact points.

450
Fig. – This problem is due to the single contact point: being at the center of the tire width, if it is still touching the road and is not on the curb, the wheel will fall through. See p.

- Since you’re probably at the beginning, until you acquire more experience, you may want to adopt for your car one of the vanilla tire compounds; at this
point let’s talk about them.
On Oct 23, 2017, Stefano Casillo from Kunos stated:
“We do not have any direct relationship with tyre manufacturers. We get data from either car manufacturers, teams, public literature and so on. I truly wish the reality of
things was that we could pick and choose between different manufacturers and models but that's just daydreaming and simply shows how detached you are from the process
of working on race simulators. Which totally is fine, considering that you do not.”
Regarding temperatures, the ranges are not perfect intervals but a min-max range instead, in which you might not be able to notice the difference in grip.
Temperatures also vary quite widely from straight to inside a turn, so optimally you need a tire that stays at the lower end of the optimum temperature just
before the braking zone and at the higher end of the optimum temperature at the exit of the turn. That isn’t easy to obtain.
In AC going outside the optimum range doesn't mean the car will become undriveable. This characteristic is a double sword. You might think the tires (and
the vehicle) are fine, but you're not driving on the optimum grip, so you may lose time on the lap without understanding why. There's a lot to be discovered
and explored within the AC tire model.
Another hint: as in real life, use more camber to heat faster a part of the tyre tread and then this dissipate to the rest of the tire. More camber, more heat,
less camber, less heat.
The following are the characteristics of the compounds you can find in vanilla AC (taken directly from the official Kunos FAQ).

Road legal tyres:

Street and semislicks are road legal compounds, used on the road. They wear out slightly. Their main problem is overheating, but after you have overheated them, you can
wait to cool down and then start stressing them again. They can give similar grip even after lots of kilometres. Eventually though they will wear and lose grip totally.
Optimal temperatures
• Street tyres: 75°C - 85°C; still easy under and over those temps. Very easy to overheat after some laps, especially on fast corners.
• Semislicks: 75°C - 100°C; a bit less grip under that and overheat quite faster over that. They have more grip of course and can resist more fast laps, but do not like much abuse and drifting.
They wear gradually and lose grip km after km.

GT2 slicks:
The main difference of the GT2 cars is that manufacturers are actively developing tyres during the season and bring different compounds on the various tracks. The AC
developers can't of course simulate specific compounds for specific tracks, but they offer 5 different ones.
Optimal temperatures
• SuperSoft: 90-105°C; they don't like to be driven under or over that range. They wear out very fast.
• Soft: 90-105°C; like Supersofts. They wear out fast.
• Medium: 85°C-105°C; Supersofts over their range. They wear out in a linear, gradual way.
• Hard: 80-100°C; a tiny bit easier than Supersofts outside their range but nothing too radical. They wear just a tiny bit after the initial laps and then stay quite stable for a long time until they
start to lose lots of grip.
• SuperHard: 80-100°C; like Hard. They wear a tiny bit and stay stable for many laps until they let go.

GT3 slicks:
The biggest difference between GT2 and GT3 cars are their tires. GT3 tires are fixed for the whole season and the organization decides what tyres the car have to use. Kunos
provided 3 compounds that are not equivalent to their GT2 counterparts (worse).
Optimal temperatures
• Softs: 80-110°C; wear VERY fast. We've been told that they were actually used only for a couple of times in qualifying.
• Mediums: 75-105°C; wear linearly and predictably. An all-around tyre.
• Hard: 70-100°C; wear a tiny bit after a couple of laps and stay stable for a long stint. Not great grip but they are predictable and can be used in a wide variety of tracks and temperatures. Often
"forced" by regulations on cars.

Hypercars Trofeo slicks (Pagani Zonda R and Ferrari 599XX):

They’re a bit worse parents of the GT3 tires. Let's say a generation behind. Rest of their characteristics is very similar to the GT3 tyres. They are not remotely close to street
legal tyres. Don't confuse the name with real-world Pirelli Trofeo tires; in AC they are used to emulate the cut slicks on the Pagani and were extended to other cars.

Vintage F1 67 tires:
AC provides just one compound for such tyres, although during that period (1960-70s) there were actually different compounds. As a matter of fact, there is documentation
reporting that Jim Clark chose the tyre that permitted him to slide more for the race at Monza. Unfortunately, there is not enough data for the compounds so Ks stick with just
one compound. If anybody has more info regarding the matter, I'd be happy to discuss with it.
Optimal temperatures
Range 50-90°C; the tyres are good at low temps, and can withstand overheating pretty well. The tyre wear is gradual, you can expect to do a full race without problems, except if you overdrive and
overheat them too much.

451
- Assetto Corsa uses a simplified brush tire model 69, which (from v5 onward) allows two methods of configuration for the relationships between the input
parameters (mainly load and slip, called load sensitivity):
• the first one adopts an empiric-based exponential formula (the so-called “Kunos tire formula”);
• the second one is look-up table (LUT) based system.
The formula-based is the system that Kunos’ official cars usually employ. It works with an exponential formula that derives from the observation of how the
contact patch varies as function of load influencing the pressure at contact patch, which influences grip.
The formula “seems to be able to match real tyres with a reasonable accuracy and has a solid physics reasoning behind it” 70. Three parameters from tyres.ini
are used:
• FZ0: the reference load.
• LS_EXPY (and LS_EXPX): the exponent(s) used in the formula.
• DY_REF (and DX_REF): the D level at FZ0.

The values are then used this way: a "MULT" parameter is calculated,
𝐷𝐷𝐷𝐷_𝑅𝑅𝑅𝑅𝑅𝑅∙𝐹𝐹𝐹𝐹0
𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = MULT = (DY_REF*FZ0) / FZ0^LS_EXPY
(𝐹𝐹𝐹𝐹0)𝐿𝐿𝐿𝐿_𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸

then, at runtime, the D value as function of load (Fz) is the calculated as:
D = Fz^LS_EXPY * MULT / Fz

The look-up table system is better when trying to match a real tire data. In this case a simple LUT is used for the parameters DY_CURVE and DX_CURVE.

Pro tip: The LUT can be "inline", so written directly in tyres.ini, for example:
DY_CURVE=(0=3.0|1500=2.613|3000=1.680|4500=1.447|6000=1.257|12000=1.100)

or you can reference an external file like this:

DY_CURVE=external_curve_file.lut

You can see other examples in the script at page .

with the typical AC lut file format of KEY|VALUE

At runtime the lookup table is smoothly interpolated (thus you are not required to insert dozen of values).

Note that the 0 value is required in order avoid crazy numbers at very low loads due to the cubic spline interpolation.

- The formula for formula-based camber sensitivity is:

D(camberRAD)/D = 1/(1 + DCAMBER_0 * camberRAD - DCAMBER_1 * camberRAD^2)

It can also be written like this:

1
𝐶𝐶𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 = (3.5)
1+(𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_0 ∙ 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐)−[𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_1 ∙ (𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐)2 ]

Where camberRAD is the absolute value of the camber angle in radians.

If you want to use the grip% and peak angle method:

DCAMBER_0= -2*grip%/((grip%+1)*peakangle)
DCAMBER_1= -grip%/((grip%+1)*peakangle^2)

Which can look like this:

−2∙𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈% −𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_0 = 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_1 = (3.6)
[(𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%+1)∙𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑] [(𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%+1)∙𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑2
Where

peakangle: the peak camber angle in Radian = DCAMBER_0/(2*DCAMBER_1)

grip%: the grip increase at the peakangle (like 5%) = (4*DCAMBER_1/(4*DCAMBER_1+DCAMBER_0²))-1

For example: If you want 7% more grip at a peak angle of -3.8°:

DCAMBER_0= -2*0.07/((0.07+1)*-0.0663)= 1.973

DCAMBER_1= -0.07/((0.07+1)*(-0.0663)^2)= -14.873

The -3.8° angle in degrees has been converted in radians (-3.8° = -0.0663 rad).

If you have experience from the classic Pacejka or RFactor tire model, you need to think in a slightly different way. In AC the model is so dynamic that creating a
simple load/slip curve would not cut it. It is not the curve that defines the tyre characteristics, but the rest of the values that define a dynamic curve and characteristics.
(Aristotelis Vasilakos, 2014)

69
“Simplified”, as it is a brush with only one bristle (or contact point).
70
As stated by Stefano Casillo. It represents a good choice when real-world data (e.g., telemetry, tire testing, etc.) is not available, recommended to use if you’re starting with your first project(s).

452
 Due to the limited amount of available tire data and even less actually representational and usable tire data, unfortunately in most cases many parameters in tires must
be decided based on trends or guesses and not actual empiric data for the specific application. Luckily reasonable tires can be created by following trends, and applications
can even be created to automatically create various reasonable tire parameters from relatively few inputs. Narrowing down the likely range for acceptable parameters and
establishing some generalized trends, a method can be developed for creating simulation tires which provides acceptable results with minimal guesswork. However, one
should exercise great caution when analysing tire data or trends. Real tire characteristics are relatively nonlinear and interactive, with relationships existing that are not
present in Assetto Corsa, such as optimal pressure not being a strict constant in real tires. Pay great attention to the testing method as well, not every method produces as
realistic results as others. Tire data is not absolute and true in all cases.
Assetto Corsa’s tire model has one main benefit over many other real-time simulation models, namely that the number of inputs is relatively low but the behaviour
generated is quite dynamic and appropriate in most situations. For example, rFactor doesn't have features like relaxation length.
You do not directly input physical characteristics like dimensions of the sidewall, or softness of the rubber or whatever such as in some other tire models. There is a
large degree of interactivity within the tire behaviour and complex situations can be generated from relatively few inputs resulting in relatively high telemetry correlation of
car handling.
A tire model such as Pacejka would require look-up tables and inputs for several more parameters, for many of which there is no data publicly available. (Arch, 2023,
p. 17)

- "Flex" in simulation tire models is a garbage word. In real life, you have 4 main types of flex: vertical, lateral, longitudinal, and torsional. Vertical is easy
and pretty much every sim does it in a way that's acceptable. The other three aren't as easy, but that's fine because they don't really matter. In a semi-
empirical model like AC (and pretty much every other sim), you use slip velocities to generate forces. If you delay these forces with respect to the distance
the tire travels, you can replicate flex. That's what RELAXATION_LENGTH is for. That parameter wouldn't be there if you had lateral + longitudinal +
torsion flex, because those are the things that contribute to it existing. It's a stand-in for "3d" flex that does as good of a job as you'd almost ever need,
being that your tire model is going to have WAY more error from your data input than its fundamental code.

But on the other hand, lateral tire deformation has to be entirely made up, because AC doesn't try to model it, as it only offers relaxation length. And
strangely, the RELAXATION_LENGTH parameter doesn't end up being anything like the actual relaxation length simulated, it's like...1/3. Typical AC values
range around 0.07 to 0.12 per Kunos recommendation; thus it is not comparable to real-world values, which have been found to be between 0.12 and 0.45
meters, with higher values corresponding to higher velocities and heavier loads. The value is pretty directly linked to the sidewall stiffness of the tire, but it
cannot be measured at steady state. How this feature works is still unclear.

- The elephant in the room: tire wear.

I'll start with some things you have to keep in mind regarding tyre wear in AC.
1. The USE_LOAD line under the [VIRTUALKM] section essentially toggles wear effects based on load and vkms, which stands for "virtual kilometres", a special unit in
Assetto Corsa that defines the distance a tire is travelling while slipping, overheating, underheating, overloading and a ton of other values which mean the tire is under
stress, even by the smallest amount. Obviously if you're drifting the vkms will rise very quickly, while if you're driving straight or cruising normally, they will increase very
slowly. So the smoother the driving style, the less the tire gets vkms, and thus wear.
2. Tires in this simulator don't really wear out meaningfully, you just get different traction from how long you've driven on them. Interpret "how long" as a distance traveled,
or rather, slipped. There is essentially no wear or heat simulation, nor realistic "heat cycles".
3. Vehicles are set up with tyre wear luts (look-up-tables), which contain data (you can create wear curves) with the following syntax: vKm | traction % (or grip%). So at the
input you have vKm, at the output you have simply the grip percentage. So you can just bake heat cycling + slip and rolling wear into the curve.
With the luts you can make a tire wear less or more with the same vkm. You only need to change the input | output relationships in the lut. In your case you want to increase
the wear? You have to decrease the traction % at the output for each vKm in the LUT.
Below here there is an example of a tyre wear look-up-table.

The inputs and outputs are separated by the | symbol as you can see (I already mentioned this at the beginning). For more examples open an official Kunos car and look at
the data. Usually wear LUTs with more than three lines are kind of wasted. The reason why three values are exactly what you need is that you need a point any time the wear
rate changes. With 3 points there's the wear on a new tire, then the wear once it's scrubbed, then the wear at fully worn.
You can add however many points you want but you need at most 6 or so, 3 are ideal and recommended if you just want a break-in, peak and dropoff for the wear curve.
Also, try to evenly space them. Look at the official content for reference.
In the tyres.ini script you can find all the lines where to reference these LUTs and there are also some multipliers to adjust the behaviour. (add more details)

4. Tyre wear is never really off, it just goes really really slowly even when it's set to "off" from the realism options in the Race preparation.
5. Camber doesn’t affect tyre wear in vanilla AC. This however is not very important, because physical wear is less important than chemical for peak grip.
6. In order to work with wear, I recommend to use the Sidekick app, as it reads the tyre wear LUT directly, so you can configure what "0% wear" actually is. Other debug
apps (included official ones) display wrong values.
7. Be aware that the tyre wear of the virtual AI opponents is much lower than the player's. Assetto Corsa has got many bugs regarding them. There are some mod projects
trying to fix them but they're still in development.

- Now, about tire explosion.

In AC the tire explodes (it's an optional setting for each car) based on a temperature threshold, if you look in the tyres.ini script you'll find the [EXPLOSION]
value for this, but from my understanding it is not what normally you would want to achieve. There isn't a parameter to make them directly rip due to wear.
The temperature however is influenced by wear (but not in a realistic way). Heating behaviour in Assetto is not very good at all.

453
- Heat is probably the weakest part about vanilla tires indeed. Most content has very incorrect rate of heating and manner of heating; there are no interactions
between brake temps and tire temps (and the brake heat is consequently not worth using). So you simply can't use the same tire heating strategies, or even
the same logic as in real life for vanilla AC. If you're going for performance, forget the real world completely and just optimize it within the simulation.
With CSP this changes, because a completely new, more accurate thermal model is introduced. Then it is possible to implement quite realistic tire and brake
heating and have them work. But many vanilla parameters are still required, so you can’t forget about tyres.ini.
- AC always assumes that every car has 4 tires and runs code only for those ones. That's very hardcoded. Vehicles with two, three, five or more wheels
aren’t possible without hacks that almost defy the physics (and maybe some special CSP-mod sauce too).
- In tyres.ini you can configure multiple sets of tires. You can add them below the first one. Just make sure you type in the needed .lut files and use the right
numbering. Each set should come with correct radius/width of the tires, but may result in the visual meshes to sink or hover on the ground. This problem
can be overcome with the CSP mod, otherwise it's probably fine to just leave a shared radius.
- Since the tire's modeled as a spring vertically, doing a more complicated collision mesh wouldn’t be very easy.
- Changing the spring rate (the RATE value) won't directly change grip in AC (there's no real contact patch simulation). You need to adjust DY_REF and
DX_REF (lateral and longitudinal grip coefficients at reference load) to directly adjust grip. The V5 Tires thread on the official forum (in the physics modding
section) has the equations to calculate grip at a given load.

ABOUT RELATED FILES

LUTs:

tyre_compound_wear_f.lut / tyre_compound_wear_r.lut

The physics engine applies a linear interpolation to the values, same as every other LUT (except camber).

CURIOSITIES AND AMENITIES

- ac_tyres.ini
This script is an old version of tyres.ini. You can find it in the Ferrari 458 GT2 data and in other cars. I’m just going to copy it below (formatted in columns),
because there is no information available about this file anywhere online. It’s just a relic of Kunos development, don’t be scared if you find it in the data files.
[FRONT_0] [REAR_0] [FRONT_1] [REAR_1]
NAME=Front tyre NAME=Rear tyre NAME=Front tyre NAME=Rear tyre
SHORT_NAME=S SHORT_NAME=S SHORT_NAME=SS SHORT_NAME=SS
WIDTH=0.300 WIDTH=0.310 WIDTH=0.300 WIDTH=0.310
RADIUS=0.325 RADIUS=0.355 RADIUS=0.325 RADIUS=0.355
RIM=0.2413 RIM=0.2413 RIM=0.2413 RIM=0.2413
SOFTNESS=1.7 SOFTNESS=1.7 SOFTNESS=1.7 SOFTNESS=1.7
SIDE_STIFFNESS=0.5 SIDE_STIFFNESS=0.7 SIDE_STIFFNESS=0.5 SIDE_STIFFNESS=0.7

Of course it can be deleted.

- There are mods that don't show any tire model reference in the loading screen (vanilla). Those are pre version v5. Tire model info was not included in the
loading screen (or tire.ini?) before v5.

- In the early days of the more accurate v10 tires, some people started complaining because they preferred the v5 model, which was simpler. What an
attitude… keep on comparing games…

CSP ADDITIONS
NEW TIRE MODEL with multiple contact points.

FAQ
QUESTION [1]: Can I use tires from another car for my mod?
ANSWER [1]: Yes, if you take the sets from the official content. Avoid swapping tires from another mod, as they may have been altered to make cars with the
worst handling driveable, being low-quality and low-effort. And the numbers may be completely invented. These are examples of bad practices. With
telemetry you can learn to recognize them. Tire sets made by Kunos are not bad at all, despite whatever people may say.

Q [2]: How do I update the tires of an old car mod? I'm trying to fix a broken mod. Currently it is on version 3. I want to update it to v10.
A [2]: As already explained in the parameter descriptions, the tire version in the [HEADER] indicates the properties of the tires, not really the version of the
file. This is because each VERSION number introduces different features that determine the accuracy of the behaviour based on real data. This means, for
example, that v10 tires are more faithful than v3, v5 or v7 tires, but they need also more values, being less simplified. That’s the “problem”. Tires cannot
really be updated, they have to be replaced with counterparts that produce a similar behaviour, or with brand new, well-made ones. Put your brain to good
use. And by the way, avoid CM’s automatic tyre machine, which relies on black magic.

Q [3]: We have a question about matching a real-life tire to AC tire:

“I'm modeling my real-life track car in AC, and the tire compound is somewhere between the vanilla Semislick and the Trofeo Medium Slick. The tire is a 255/40/17.
I have real life AIM data at a track that exists in AC. Assuming my vehicle model and track model is reasonably accurate, Is there any way I can adjust the global lateral/longitudinal
grip factor, and use telemetry to match the tire compound to the real tire?”

454
A [3]: All of the parameters pertaining to tires in Assetto Corsa are within the tyres.ini file and the corresponding LUTs. If there are any other parameters related
to tyres, we do not have a way to access them (for example, you can’t change the equations of the Kunos-formula-based tires). It's going to take a lot of trial
and error. Even the lead developer of AC, Stefano Casillo, refers to tire creation as a "black art". But we will shed some light on it. I have a torch with me.
Trying to match the grip of your real-world tire is going to be hard enough, but don't forget about the thermal properties. How they heat up and cool down
and spread that heat throughout the surface is equally important.
I would use one of the vanilla compounds that feels similar to the real car, and play with the values.
With telemetry, using lateral and longitudinal G (acceleration), you can try to match it as closely as possible by adjusting the DX_REF and DY_REF values
and obtain something like Fig..

Fig. – The top graph is speed, 2nd graph is Lat G, 3rd graph is Lon G. The red traces are the telemetry data from a Honda S2000 in real life. Blue traces are AC on the same track. This
was achieved by an enthusiast with no professional engineering background; while noting the skill demonstrated by this modder, one can still do better.

Q [4]: Why is it difficult to model drift cars in AC?

A [4]: It's near impossible to get data on extreme slip angles for tires, real world tests rarely pass 10-15 degrees, sure you can by observation realize that
drifting exists, but since it's "known" that it's not the fastest driving style, there's less effort to figure out what happens. I think partly it's because the tyre's
dynamic in too many variables at larger slip angles - you have heat moving around, rubber literally melting off the surface, etc. - it makes running consistent
tests more difficult.

Q [5]: How can I find real-life tire specifications?

A [5]: All tyres and rims are standardized to guarantee interchangeability, i.e. to guarantee the possibility of using tyres from different manufacturers but with
the same designation on one vehicle and to restrict the variety of tyre types worldwide. So when you find the definition of one of the standards, you can define
generic characteristics of tires that follow it. Just look at what’s written on the tire itself. I know, there are tires without specs printed or engraved on them; we’ll
talk about those later.
Within Europe, standardization is carried out by the European Tyre and Rim Technical Organization or ETRTO, which specifies the following:
• tire and rim dimensions;
• the code for tire type and size;
• the load index and speed symbol.
Passenger car tyres are governed by UNO regulation ECE-R 30, commercial vehicles by R 54, spare wheels by R 64, and type approval of tyres on the vehicle
by EC directive 92/23/EC.

In the USA the Department of Transportation (or DOT, see item in Fig.) is responsible for the safety standards. The standards relevant there are:
• Standard 109 Passenger cars
• Standard 119 Motor vehicles other than passenger cars.
The Tire and Rim Association, or TRA for short, is responsible for standardization in the US.
In Australia, binding information is published by the Federal Office of Road Safety, Australian Motor Vehicle Certification Board.
ARD 23 Australian Design Rule 23/01: Passenger car tyres is the applicable standard.
In Germany the DIN Standards (Deutsches Institut für Normung) and the WdK Guidelines (Wirtschaftsverband der Deutschen Kautschukindustrie Postfach
900360, D-60443, Frankfurt am Main) are responsible for specifying tyre data. All bodies recognize the publications of these two organizations.

455
At the international level, the ISO (International Organization for Standardization) also works in the field of tyre standardization and ISO Standards are
translated into many languages.
The most important information on the tire sidewall is the size number, indicated by 2 (Fig. ). To see the format of the size number, here is an example
explained:
P 215 / 60 R 15 96 H
P: Tire type. The first letter indicates the proper type of car that the tire is made for. P stands for passenger car. The first letter can also be ST for special trailer, T for temporary,
and LT for light truck.
215: Tire width. This three-number code is the width of the unloaded tire from sidewall to sidewall measured in [mm].
60: Aspect ratio. This two-number code is the ratio of the tire section height ℎ𝑡𝑡 to tire width 𝑤𝑤𝑡𝑡 , expressed as a percentage. Aspect ratio is shown by
ℎ𝑡𝑡
𝑠𝑠𝑡𝑡 = ∙ 100
𝑤𝑤𝑡𝑡
Generally speaking, tire aspect ratios range from 35, for race car tires, to 75 for tires used on utility vehicles.
R: Tire construction type. The letter R indicates that the tire has a radial construction. It may also be B for bias belt or bias ply, and D for diagonal.
15: Rim/bead diameter. This is a number in [in] to indicate diameter of the rim that the tire is designed to fit on. Typically rims are referred to with their size in inches, even in
countries which adopted SI units. That’s weird, it happens for screens and televisions too.
96: Load rate or load index. Many tires come with a service description at the end of the tire size. The service description is made of a two-digit number (load index) and a
letter (speed rating). The load index is a representation of the maximum load each tire is designed to support. It is generally valid for speeds under 210 km/h (≈130 mph).
If the load index is not indicated on the tire, then a tire with a size number such as 255/50R17 100V may also be numbered by 255/50V R17.
H: Speed rate. Indicates the maximum speed that the tire can sustain for a ten-minute endurance without breaking down. This was very useful for those guys from Bugatti
trying to go at 400 km/h.
Race tire markings
Race cars employed quite different tires than nomal vehicles. Sometimes you’ll have to understand what the numbers and units refer to, based on the context.
Size markings like 280/675-18, show nominal tread width [mm], overall tyre diameter [mm] and bead diameter [in]. Note that all dimensions are taken from
an inflated tire under unloaded conditions. For post historic tyres, the markings (e.g. 600/1200-15) are nominal section height, section width and bead
diameter in inches.
Certain rules call for maximum overall width to include rims.
With this you should be able to understand the various tire catalogues and product labels out there (Fig.).

Fig. – (left) Label of a Pirelli Cinturato P7 pneumatic. (right) Extract from a Goodyear tire catalogue.

Regarding the INFLATION PRESSURE CONVERSION:

PSI to BAR: divide by 14.5 (14.50377)
BAR to PSI: multiply by 14.5 (14.50377)

Regarding tire weight.

The average weight of a tire for passenger cars is 10-12 kg. The weight of a tire for light trucks is 14-16 kg, and the average weight of commercial truck tires
is 135-180 kg.

456
Fig. T.-1 - Explanation of the marking on the sidewall of a tyre manufactured by Pneumatiques Kléber SA.
Legal and industry standard markings on the sidewalls of tyres according to: FMVSS and CIR 104 | UTQG (USA) | CSA Standard (Canada) | ADR 23B (Australia) | ECE–R30 (Europe)
1 Manufacturer (brand or commercial name)
1a Product name
2 Size marking: 195 = nominal tyre width in mm; 60 = height–width ratio (60%); R = radial type; 14 = rim diameter in inches
3 Type of tire construction, here tubeless tire
4 Trade code
5 Country of manufacture
6 Load capacity index (LI)
7 Maximum load capacity for the USA
8 Tread: under the tread are 6 plies carcass rayon, 2 plies steel belt, 2 plies nylon). Sidewall: the substructure consists of 2 plies rayon
9 Maximum allowed tyre inflation pressure for the USA
10, 11, 12 USA: manufacturer’s guarantee of compliance with the Uniform Tire Quality Grade (UTQG) which specifies: 10 tread wear: relative life expectancy compared with US-specific standard
test values
11 Traction: A, B, C = braking performance on wet surfaces
12 Temperature resistance: A, B or C = temperature resistance at higher test stand speeds; C fulfills the legal requirement in the USA
13 Europe type approval mark and number. E 4 = tyre fulfils the European ECE R30 value requirements; 4 = country in which approval was carried out (4 = The Netherlands)
14 identity number according to ECE R-30
15 DOT = tyre fulfils the requirements according to FMVSS 109 (DOT = U.S. Department of Transportation)
16 Manufacturer’s code: CU = factory (Continental); L2 = tyre size; AXCT = model; 127 = date of manufacture: production week 12, 1987

Q [6]: How do I calculate tire data from the specifications seen in QUESTION [5]?
A [6]: Here are some examples.
Calculating tire diameter and radius.
We are able to calculate the overall diameter of a tire using the tire size numbers. By multiplying the tire width and the aspect ratio, we get the tire height. As an example, we
use tire number P 235/75R15.
hT = 235 × 75% = 176.25mm ≈ 6.94 in
Then, we add twice the tire height hT to the rim diameter to determine the tire’s unloaded diameter D = 2R and radius R.

457
D = 2× 6.94 + 15 = 28.88 in ≈ 733.8mm
R = D/2 = 366.9mm
Height of a tire based on tire numbers.
A tire has the size number P 215/60R15 96H. The aspect ratio 60 means the height of the tire is equal to 60% of the tire width. To calculate the tire height in [mm], we
should multiply the first number (215) by the second number (60) and divide by 100. ℎ𝑡𝑡 = 215 ∙ 60/100 = 129 𝑚𝑚𝑚𝑚. This is the tire height from rim to tread.
Weight of a car and load index of its tire.
For a car that weighs 2 tons = 2000 kg, we need a tire with a load index higher than 84. This is because we have about 500 kg per tire and it is in a load index of 84.

458
PHYSICS (for tyres.ini)
This part will be pretty heavy and comprehensive, as the tires are crucial functional elements for the transmission of longitudinal, lateral and vertical forces
between the vehicle and road. They’re the most important part of the whole simulation.
For now, grip is what our business is all about. Grip comes from tires, period. The racing driver’s best friend is the tire, followed closely by the sponsor.

1.0 - Wheels and tires

All road vehicles have wheels and almost all of them have wheels with pneumatic tires. Wheels have been around for many centuries, but only with the
invention and enhancement of the pneumatic tire it has been possible to conceive fast and comfortable road vehicles.
A tire is an advanced engineering product made of rubber and a series of synthetic materials cooked together. Fiber, textile, and steel cords are some of the
components that go into the tire’s inner liner, body plies, bead bundle, belts, sidewalls, and tread. Figure illustrates a sample of tire interior components and
their arrangement.

Fig. ** - (left) Illustration of a sample radial tire interior components and arrangement. (right) Radial design of passenger car tyres in speed category T; the number of layers and the
materials are indicated on the sidewall (see Fig.). The components are: 1-Running tread, 2-Steel belt, 3-Edge protection for the belt, made of rayon or nylon, 4-Sidewall, 5-Substructure
with two layers, 6-Cap, 7-Inner lining, 8-Flipper, 9-Bead profile, 10-Core profile, 11-Bead core

The main components of a tire are explained below:

• Bead or bead bundle is a loop of high strength steel cable coated with rubber. It gives the tire the strength it needs to stay seated on the wheel rim and to transfer the tire
forces to the rim.
• Inner layers are made up of different fabrics, called plies. The most common ply fabric is polyester cord. The top layers are also called cap plies.
• Cap plies are polyesteric fabric that help hold everything in place. Cap plies are not found on all tires; they are mostly used on tires with higher speed ratings to help all
the components stay in place at high speeds.
• An inner liner is a specially compounded rubber that forms the inside of a tubeless tire. It inhibits loss of air pressure.
• Belts or belt buffers are one or more rubber-coated layers of steel, polyester, nylon, Kevlar or other materials running circumferentially around the tire under the tread.
They are designed to reinforce body plies to hold the tread flat on the road and make the best contact with the road. Belts reduce squirm to improve tread wear and resist
damage from impacts and penetration.
• The carcass or body plies are the main part in supporting the tension forces generated by tire air pressure. The carcass is made of rubber-coated steel or other high
strength cords tied to bead bundles. The cords in a radial tire, as shown in Fig. left, run perpendicular to the tread. But we will discuss the tire types in more detail later.
The plies are coated with rubber to help them bond with the other components and to seal in the air.
A tire’s strength is often described by the number of carcass plies. Most car tires have two carcass plies. By comparison, large commercial jetliners often have tires with
30 or more carcass plies.
The sidewall provides lateral stability for the tire, protects the body plies, and helps to keep the air from escaping from the tire. It may contain additional
components to help increase the lateral stability.
The tread is the portion of the tire that comes in contact with the road. Tread designs vary widely depending on the specific purpose of the tire. The tread is
made from a mixture of different kinds of natural and synthetic rubbers. The outer perimeter of a tire is also called the crown.
The tread groove is the space or area between two tread rows or blocks. The tread groove gives the tire traction and is especially useful during rain or snow
and while driving on mud or offroad.

Fig.T.0 illustrates a cross section view of a tire on a rim to show the dimension parameters that are used to standard tires.

459
Fig. t.0 - Cross section of a tire on a rim that shows tire height and width.

The section height, tire height, or simply height, hT, is a number that must be added to the rim radius to make the wheel radius. The section width, or tire
width, wT, is the widest dimension of a tire when it is not loaded.
Tires are required to have certain information printed on the tire sidewall. Fig.T.-1 illustrates a side view of a sample tire to show the important information
printed on a tire sidewall.
The main features of any tire are its flexibility and low mass, which allow for the contact with the road to be maintained even on uneven surfaces. Moreover,
the rubber ensures high grip. These features arise from the highly composite structure of tires: a carcass of flexible, yet almost inextensible cords encased in
a matrix of soft rubber, all inflated with air 71. Provided the (flexible) tire is properly inflated, it can exchange along the bead relevant actions with the (rigid)
rim. Traction, braking, steering and load support are the net result.
It should be appreciated that the effect of air pressure is to increase the structural stiffness of the tire, not to support directly the rim. How a tire carries a
vertical load Fz if properly inflated is better explained in Fig. t1. In the lower part the radial cords encased in the sidewalls undergo a reduction of tension
because they no longer have to balance the air pressure pa acting on the contact patch. The net result is that the total upward pull of the cords on the bead
exceeds that of the downward pull by an amount equal to the vertical load Fz.

71
Only in competitions it is worthwhile to employ special (and secret) gas mixtures instead of air. The use of nitrogen, as often recommended, is in fact completely equivalent to air, except for the
cost.

460
Fig. t.1 - How a tire carries a vertical load if properly inflated.
The contact patch, tireprint or footprint, of the tire is the area of the tread in contact with the road. This is the area that transmits forces between the tire and
the road via pressure and friction. To truly understand some of the peculiarities of tire mechanics it is necessary to get some insights on what happens in the
contact patch.
Handling of road vehicles is strongly affected by the mechanical behaviour of the wheels with tires, that is by the relationship between the kinematics of the
rigid rim and the force exerted by the road.
The following paragraphs are devoted to the analysis of experimental tests. The and development of simple, yet significant, tire models will be done later.

461
1.1 - The tire as a vehicle component
A wheel with tire is barely a wheel, in the sense that it behaves quite differently from a rigid wheel 72. This is a key point to really understand the mechanics
of wheels with tires.
For instance, a rigid wheel touches the (flat) road at one contact point C, whereas a tire has a fairly large contact patch. Pure rolling of a rigid wheel is a clear
kinematic concept, but, without further discussion, it is not obvious whether an analogous concept is even meaningful for a tire. Therefore, we have to be
careful in stating as clearly as possible the concepts needed to study the mechanics of wheels with tires.
Moreover, the analysis of tire mechanics will be developed with no direct reference to the dynamics of the vehicle. This may sound a bit odd, but it is not.
The goal here is to describe the relationship between the motion and position of the rim and the force exchanged with the road through the contact patch:
rim kinematics ⇐⇒ force and moment
Once this description has been obtained and understood, then it can be employed as one of the fundamental components in the development of suitable
models for vehicle dynamics, but this is the subject of other chapters.
Three basic components play an active role in tire mechanics:
1. The rim, which is assumed to be a rigid body;
2. The flexible carcass of the inflated tire;
3. The contact patch between the tire and the road.

1.2 - Tire compounds

During World War II, supplies of natural rubber from Asia became difficult to come by, so chemical engineers in the U.S. and Russia came up with synthetic
rubber made from crude oil. Their products fulfilled wartime needs for rubber until rubber-tree supplies resumed after the war. During the 1950s, chemists
improved the formulas for synthetic rubber, and by the mid-1960s synthetic materials outpaced natural rubber in tires.
Today’s tubeless tires are a composite of up to 200 different chemicals. Each part of the tire — casing, sidewalls and tread — is manufactured to specific
performance criteria, using a variety of natural and synthetic rubber compounds. Racing tires are very different from passenger tires, which are very different
from truck tires. Various chemical formulations allow for tradeoffs among tire properties, such as resistance to aging, heat and wear, as well as the critical
aspect of traction.
During the 1950s, chemical engineers discovered that they could extend the life of tires by adding chemicals to slow the aging process. Ozone, a highly
reactive form of oxygen, is created as a byproduct of automobile exhaust. When ozone contacts rubber, it creates tiny cracks by breaking chemical bonds in
the long-chain molecules that give rubber its flexibility and resilience. The cracks grow larger and larger with more ozone exposure.
Compounds that capture ozone before it can break rubber’s chemical bonds proved to be a godsend in saving rubber from deterioration. A closely related
group of chemicals, the para-phenylene-diamines, proved especially effective at grabbing ozone when added to rubber. Such chemicals include 6PPD, the
most commonly used in tires today, as well as IPPD and DPPD.
Small amounts of these additives (0.5 to 2 percent) in rubber can inhibit ozone degradation by migrating to the surface of the tire, where they form a
microscopic film. Experts still debate whether the tire is better protected by the micro-film layer or by the rapid reaction between ozone and PPD, but both
come into play.
In any case, tiny bits of rubber eventually fly off onto the roadway and wash into streams. These bits of rubber carry with them a new chemical never added
to tires and apparently overlooked when studying the toxicity of tire-related compounds. This chemical is the mysterious, highly toxic compound believed
responsible for the deaths of many coho salmon. It’s called 6PPD-quinone, as quinone is a chemical group bearing oxygen atoms picked up during the
rapid reaction between 6PPD and ozone.

72
A rigid wheel is essentially an axisymmetric convex rigid surface. The typical rigid wheel is a toroid. Imagine a donut.

462
2.0 - Road-to-wheel contact
In this paragraph we will present some theoretical models useful for identifying the forces that are exchanged in the wheel-road contact.
2.1 – Coulomb’s model

Rim position and motion

For simplicity, the road is assumed to have a hard and flat surface, like a geometric plane. This is a good model for any road with high quality asphalt
paving, since the texture of the road surface is not relevant for the definition of the rim kinematics (while it highly affects grip).
The rim R is assumed to be a rigid body 73, and hence, in principle, it has six degrees of freedom (it can move along three directions and rotate in other
three). However, only two degrees of freedom are really relevant for the rim position, because the road is flat and the wheel rim is axisymmetric.

Let Q be a point on the rim axis 𝑦𝑦𝑐𝑐 (Fig.). Typically, although not strictly necessary, a sort of midpoint is taken. The position of the rim with respect to the
flat road depends only on the height h of Q and on the camber angle γ (i.e., the inclination) of the rim axis 𝑦𝑦𝑐𝑐 . More precisely, h is the distance of Q from
the road plane and γ is the angle between the rim axis and the road plane.

Fig. t.2 - Wheel with tire: nomenclature and reference system.

Sometimes, the distance h is called loaded tire radius. The word “radius” may be misleading. There is no circle with radius h.
Now, we can address how to describe the rim velocity field 74.
The rim, being a rigid body, has a well defined angular velocity Ω. Therefore, the velocity of any point P of the (space moving with the) rim is given by the
equation
𝑽𝑽𝑃𝑃 = 𝑽𝑽𝑸𝑸 + 𝛀𝛀 × 𝑄𝑄𝑄𝑄 (5342)

where 𝑽𝑽𝑸𝑸 is the velocity of Q and QP is the vector connecting Q to P. The three components of 𝑽𝑽𝑸𝑸 and the three components of Ω are, e.g., the six
parameters which completely determine the rim velocity field.

Reference system
A moving reference system Sw = (x, y, z; O) is depicted in Fig.t.2. It is defined in a fairly intuitive way. The y-axis is the intersection between a vertical
plane containing the rim axis 𝑦𝑦𝑐𝑐 and the road plane. The x-axis is given by the intersection of the road plane with a plane containing Q and normal to 𝑦𝑦𝑐𝑐 .
The intersection between axes x and y defines the origin O as a point on the road. The z-axis is vertical, that is perpendicular to the road, with the positive
direction upward 75. The unit vectors marking the positive directions are (i, j, k), as shown in Fig. t.2.
An observation is in order here. The directions (i, j, k) have a physical meaning, in the sense that they clearly mark some of the peculiar features of the rim
with respect to the road. As a matter of fact, k is perpendicular to the road, i is perpendicular to both k and the rim axis 𝐣𝐣𝑐𝑐 , j follows accordingly. However,
the position of the Cartesian axes (x, y, z) is arbitrary, since there is no physical reason to select a point as the origin O. This is an aspect whose
implications are often underestimated.
The selected point O is often called center of the footprint, or center of the wheel.

Rim Kinematics
The moving reference system Sw = (x, y, z; O) allows a more precise description of the rim kinematics. On the other hand, a reference system Sf = (xf, yf,
zf; Of) fixed to the road is not very useful in this context.

Let jc be the direction of the rim spindle axis 𝑦𝑦𝑐𝑐

𝐣𝐣𝑐𝑐 = 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝐣𝐣 + 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝐤𝐤 (ko2)

73
In physics, a rigid body (also known as a rigid object) is a solid body in which deformation is zero or so small it can be neglected. The distance between any two given points on a rigid body
remains constant in time regardless of external forces or moments exerted on it. A rigid body is usually considered as a continuous distribution of mass.
74
Which can be thought of at each instant in time as a collection of vectors, one for each point in space, whose direction and magnitude describes the direction and magnitude of the velocity of
the object at that point. The distribution of velocities is described by the vector function v (x, y, z, t). This represents the velocity of the object at the point with (x, y, z) coordinates at the instant t
and is called velocity vector field.
75
Sw is the system recommended by ISO (International Organization for Standardization).

463
where the camber angle γ of Fig.t.2 is positive. The total rim angular velocity Ω is

𝛀𝛀 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜃𝜃 ′ 𝐣𝐣𝑐𝑐 + 𝜁𝜁 ′ 𝐤𝐤 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜔𝜔𝑐𝑐 𝐣𝐣𝑐𝑐 + 𝜔𝜔𝑧𝑧 𝐤𝐤 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜔𝜔𝑐𝑐 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝐣𝐣 + (𝜔𝜔𝑐𝑐 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 + 𝜔𝜔𝑧𝑧 )𝐤𝐤 = Ω𝑥𝑥 𝐢𝐢 + Ω𝑦𝑦 𝐣𝐣 + Ω𝑧𝑧 𝐤𝐤

where γ’ is the time derivative of the camber angle, 𝜃𝜃 ′ = 𝜔𝜔𝑐𝑐 is the angular velocity of the rim about its spindle axis, and 𝜁𝜁 ′ = 𝜔𝜔𝑐𝑐 is the yaw rate, that is
the angular velocity of the reference system Sw.

It is worth noting that there are two distinct contributions to the spin velocity Ω𝑧𝑧 𝐤𝐤 of the rim 76, a camber contribution ωc sin γ and a yaw rate contribution
ωz:
Ω𝑧𝑧 = 𝜔𝜔𝑐𝑐 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 + 𝜔𝜔𝑧𝑧

Therefore, as will be shown in Fig., the same value of Ω𝑧𝑧 can be the result of different operating conditions for the tire, depending on the amount of the
camber angle γ and of the yaw rate 𝜔𝜔𝑧𝑧 .

By definition, the position vector OQ (Fig.) is

𝑂𝑂𝑂𝑂 = ℎ(−𝑡𝑡𝑡𝑡𝑡𝑡 𝛾𝛾𝐣𝐣 + 𝐤𝐤) (A43Q)

This expression can be differentiated with respect to time to obtain

𝛾𝛾 ′
𝑽𝑽𝑸𝑸 − 𝑽𝑽𝑶𝑶 = ℎ′ (−𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐣𝐣 + 𝐤𝐤) + ℎ �𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 − 𝐣𝐣� =
𝑐𝑐𝑐𝑐𝑐𝑐 2 𝛾𝛾
𝛾𝛾
= ℎ𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 − �ℎ′ 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 + ℎ � 𝐣𝐣 + ℎ′𝐤𝐤
𝑐𝑐𝑐𝑐𝑐𝑐 2 𝛾𝛾

since dj/dt = −𝜔𝜔𝑧𝑧 i. Even in steady-state conditions, that is h’ = γ’ = 0, we have 𝑉𝑉𝑄𝑄 = 𝑉𝑉𝑂𝑂 + ℎ𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 and hence the velocities of points Q and O
are not exactly the same, unless also γ = 0. The camber angle γ is usually very small in cars, but may be quite large in motorcycles (up to 60 deg).

The velocity Vo = VO of point O has, in general, longitudinal and lateral components (Fig. t.2)
𝑽𝑽𝑜𝑜 = 𝑽𝑽O = 𝑉𝑉𝑜𝑜𝑥𝑥 𝐢𝐢 + 𝑉𝑉𝑜𝑜𝑦𝑦 𝐣𝐣

As already stated, the selection of point O is arbitrary, although quite reasonable. Therefore, the velocities 𝑉𝑉𝑂𝑂𝑥𝑥 and 𝑉𝑉𝑂𝑂𝑦𝑦 do not have much of a physical
meaning. A different choice for the point O would provide different values for the very same motion. However, a wheel with tire is expected to have
longitudinal velocities much higher than lateral ones. that is |α| < 12°, as will be discussed with reference to Fig.

Summing up, the position of the rigid rim R with respect to the flat road is completely determined by the following six degrees of freedom:

• h(t) distance of point Q from the road (often, improperly, called loaded radius);
• γ(t) camber angle;
• θ(t) rotation of the rim about its axis yc;
• xf (t) first coordinate of point O with respect to Sf;
• yf (t) second coordinate of point O with respect to Sf;
• ζ(t) yaw angle of the rim.

However, owing to the circular shape of rim and the flatness of the road, the kinematics of the rigid rim R are also fully described by the following six
functions of time:

• h(t) distance of point Q from the road;

• γ(t) camber angle;
• ωc (t) angular velocity of the rim about its axis yc;
• 𝑉𝑉𝑜𝑜𝑥𝑥 (t) longitudinal speed of O;
• 𝑉𝑉𝑂𝑂𝑦𝑦 (t) lateral speed of O;
• ωz (t) yaw rate of the moving reference system Sw.

The rim is in steady-state conditions if all these six quantities are constant in time. However, this is not sufficient for the wheel with tire to be in a stationary
state. The flexible carcass and tire treads could still be under transient conditions.

Now, there is an observation whose practical effects are very important. If we are interested only in the truly kinematic (geometric) features of the rim motion,
we can drop the number of required functions from six to five:
𝑉𝑉𝑂𝑂𝑥𝑥 𝑉𝑉𝑂𝑂𝑦𝑦 𝜔𝜔𝜔𝜔
h, γ, , , (xh)
𝜔𝜔𝜔𝜔 𝜔𝜔𝜔𝜔 𝜔𝜔𝜔𝜔

Essentially, we are looking at the relative values of speeds, as if their magnitude were of no relevance at all. This is what is commonly done in vehicle
dynamics, as we will see soon. Again, we emphasize that a vehicle engineer should be aware of what he/she is doing.

76
In the SAE terminology, it is 𝜔𝜔𝑐𝑐 𝒋𝒋𝑐𝑐 that is called spin velocity.

464
Carcass features

The tire carcass C is a highly composite and complex structure. Here we look at the tire as a vehicle component and therefore it suffices to say that the
inflated carcass, with its flexible sidewalls, is moderately compliant in all directions (Fig. t.1).
The external belt (Fig. Xi) is also flexible along the radial axis, but quite inextensible transversally (i.e. when you take a bump it deforms mostly in a vertical
direction rather than any other longitudinal direction). For instance, its circumferential length is not very much affected by the vertical load acting on the tire.
The belt is covered with tread blocks whose elastic deformation and grip features highly affect the mechanical behaviour of the wheel with tire.
Basically, the carcass can be seen as a nonlinear elastic structure with small hysteresis due to rate-dependent energy losses. It is assumed here that the
carcass and the belt have negligible inertia, in the sense that the inertial effects are small in comparison with other causes of deformation. This is quite
correct if the road is flat and the wheel motion is not “too fast”.

Contact patch
Tires are made from rubber, that is elastomeric materials to which they owe a large part of their grip capacity. Grip implies contact between two surfaces: one
is the tire surface and the other is the road surface.
The contact patch (or footprint) P is the region where the tire is in contact with the road surface. In Fig. t.2 the contact patch is schematically shown as a
single region. However, most tires have a tread pattern, with lugs and voids, and hence the contact patch is the union of many small regions (Fig.).

Fig. - Typical contact patch (if α = γ = 0) with tread pattern.

It should be emphasized that the shape and size of the contact patch, and also its position with respect to the reference system, depend on the tire operating
conditions.

Grip depends, among other things, on the type of road surface, its roughness, and whether it is wet or not. More precisely, grip comes basically from road
roughness effects and molecular adhesion.
Road roughness effects, also known as indentation, require small bumps measuring a few microns to a few millimetres (Fig.), which dig into the surface of
the rubber.

Fig. - Road roughness description.

On the other hand, molecular adhesion necessitates direct contact between the rubber and the road surface, i.e. the road must be dry.

Two main features of road surface geometry must be examined and assessed when considering tire grip, as shown in Fig.:

Macroroughness: this is the name given to the road surface texture when the distance between two consecutive rough spots is between 100 microns and 10
millimetres. This degree of roughness contributes to indentation, and to the drainage and storage of water. The load bearing surface, which depends on road
macroroughness, must also be considered since it determines local pressures in the contact patch.

Microroughness: this is the name given to the road surface texture when the distance between two consecutive rough spots is between 1 and 100 microns.
It is this degree of roughness which is mainly responsible for tire grip via the road roughness effects. Microroughness is related to the surface roughness of
the aggregates and sands used in the composition of the road surface.

Footprint force
Any set of forces or distributed load is statically equivalent to a force-couple system at a given (arbitrary) point O. Therefore, regardless of the degree of
roughness of the road, the distributed normal and tangential loads in the footprint yield a resultant force F and a resultant couple vector MO

465
wip

The resultant couple MO is simply the moment about the point O, but any other point could be selected. Therefore it has no particular physical meaning.
However, if O is somewhere within the contact patch, the magnitude |MO| is expected to be quite “small” for the wheel with tire to resemble a rigid wheel.
Traditionally, the components of F and MO have the following names:
Fx longitudinal force;
Fy lateral force;
Fz vertical load or normal force;
Mx overturning moment;
My rolling resistance moment;
Mz self-aligning torque, called vertical moment here.
WIP

Grip, traction and everything in between

The ability of an automobile tyre to ‘grip’ the road and avoid skidding is ultimately dependent upon the events in the tyre-road interface.
This paragraph will describe some of the variables to be aware of in tyre performance, and it provides a ‘state of the art’ review of the friction processes
involved.
Considerable uncertainty exists concerning the importance of tyre-road traction (or friction). Intuitively most users of vehicles would endorse high friction on
the simple ground that it would increase safety. However, there has not yet been a complete study of driver-vehicle-environment system effectiveness to
determine how high friction should be. It is known that in many accidents a high tyre-road friction would not have reduced the severity of the consequences.
In many other instances high friction might have been useful, but only if the driver had been trained to handle his vehicle during extreme manoeuvring. Few
operators are experienced in vehicle manoeuvres involving accelerations in excess of 0.3 g.

The industry has been under some pressure to specify the limits and abilities of their product in a manner that is meaningful to the general public.
Unfortunately, the tire is a very complex structure and its role in the dynamics of vehicle handling is only slowly becoming understood. However, the more
difficult problem is to describe properly true behaviour over the wide range of operating conditions of tires. Some of these conditions will be discussed in
connection with the results of the skid resistance tests described in the following paragraphs. Many devices have been built to measure the traction ability of
a tire.
Usually, when the results of such test programmes are used to try to predict the behaviour of a vehicle equipped with the tyres tested, poor correlation is
found. Apparently the discrepancy lies in the fact that with full scale vehicles, many more dynamic quantities are at work than in the test devices. The tyre is
a deformable body and it bears a fraction of the weight of the vehicle that varies with time. Roads are never perfectly smooth, vehicles never proceed in a
straight line, and with every pitch, roll and bounce of the vehicle a great number of dynamic states is imposed upon the tyre.
As a result, the tyre could appear to produce a higher or a lower friction in a full-scale vehicle test than in a carefully controlled test with a single tyre.
An extreme analogy of the tyre is a pogo stick. To ask what is the average friction between the tyre and the road is somewhat equivalent to inquiring
as to the average friction between the pogo stick and the pavement.

The skid resistance measurement of tyres

There is a great interest in data on the tractive coefficient for a particular tyre on a particular road. However, complete data are difficult and expensive to
obtain. Measuring a single value is not a useful exercise because tyre traction varies in an unpredictable manner with speed, amount of water on the road
and many other factors. Illustrative data are given here for two conditions of tyre behaviour.
First, it is known that average locked wheel sliding forces vary with speed on virtually all but the roughest road surface textures.
According to the Coulomb Law, a friction coefficient S of a perfectly elastic body such as steel is determined by the load and the friction force of the body,
and the value of a friction coefficient cannot exceed 1.
However, an object such as elastomer (which a tire is) becomes deformed when an external force is applied. Thus, to describe the mechanism of this
process is far more complicated. The mechanism needs to be analysed in a totally different way on the texture of the road surface with which elastomer
contacts.
As shown in formula (X**/), the friction coefficient of elastomer is determined by adding three coefficients such as an adhesion friction coefficient of a
molecular interaction between the road surface and elastomer, a friction coefficient of a hysteresis on deformations of elastomer, and a friction coefficient of
the cohesion due to wear or tear.

𝜇𝜇𝑡𝑡𝑡𝑡𝑡𝑡 = 𝜇𝜇𝑎𝑎 + 𝜇𝜇ℎ + 𝜇𝜇𝑐𝑐 (X**/)

where 𝜇𝜇𝑡𝑡𝑡𝑡𝑡𝑡 is the total (overall) coefficient, 𝜇𝜇𝑎𝑎 is the adhesion mu, 𝜇𝜇ℎ is the hysteresis mu and 𝜇𝜇𝑐𝑐 is the cohesion mu.
Here, the adhesion, which is a friction mechanism of polymer interactions between surfaces of the tread rubber and the road surface, determines friction
characteristics on the smooth and dry road surface as shown in Fig.. The grip especially on the icy or snowy road surfaces depends on the friction
mechanism.

Typical data are shown in Fig. for tractive coefficient (equivalent to friction coefficient) over a range of initial vehicle speeds.

466
Fig. - Tractive coefficient (tractive force/vehicle weight) over a range of vehicle speeds for all tyres on dry roads, and for good and bald tyres on wet roads.

Data are shown for ‘dry’ and for wet roads for two states of wear of the tyre. Note the great difference in performance of ‘dry’ versus wet roads. Also note that
the amount of tread determines the speed at which very little tractive force is available for vehicle control. The condition on wet road where very low friction
coefficient occurs is often referred to as hydroplaning (or aquaplaning).

The braking force of a tyre varies with its speed of rotation relative to the speed of rotation of a freely rotating tyre. For example, if a vehicle is proceeding at
60 km/h and if one tyre on that vehicle is rotating at a speed consistent with a vehicle speed of 54 km/h that tyre is said to be ‘slipping’ 10%, or S=0,10.
During normal braking of a vehicle, most of the tyres are slipping to some extent, of the order of 5% or less. In fact, a braking force cannot be generated
without such slip. A freely rolling tyre has S=0 and a locked wheel has S=1.

The tractive coefficient in braking over this full slip range is shown in Fig. (Byrdsong 1968) for wet and dry concrete at 30 mile h-l.

Fig. – The mu, μ, the drag force (friction) coefficient of the tire, plotted against slip ratio on both wet and dry surfaces.

Tire designs

Tires are divided in two classes: radial and non-radial, depending on the angle between carcass metallic cords and the tire-plane. Each type of tire
construction has its own set of characteristics that are the key to its performance.
The most important difference in the dynamics of radial and non-radial tires is their different ground sticking behaviour when a lateral force is applied on the
wheel. This is shown in Fig..

467
Fig. - Ground-sticking behaviour of radial and non-radial tires in the presence of a lateral force.

The radial tire, shown in Fig. (a), flexes mostly in the sidewall and keeps the tread flat on the road. The bias-ply tire, shown in Fig. (b) has less contact with
the road as both tread and sidewalls distort under a lateral load. The radial arrangement of carcass in a radial tire allows the tread and sidewall act
independently. The sidewall flexes more easily under the weight of the vehicle. So, more vertical deflection is achieved with radial tires. As the sidewall
flexes under the load, the belts hold the tread firmly and evenly on the ground and reduces tread scrub. In a cornering maneuver, the independent action of
the tread and sidewalls keeps the tread flat on the road. This allows the tire to hold its path. Radial tires are the preferred tire in most applications today.
The cross arrangement of carcass in bias-ply tires allows it act as a unit. When the sidewalls deflect or bend under load, the tread squeezes in and distorts.
This distortion affects the tireprint and decrease traction. Because of the bias-ply inherent construction, sidewall strength is less than that of a radial tire’s
construction and cornering is less effective.

Radial ply tyres

The radial ply tire consists of two bead cores joined together radially (hence the name) via the carcass with reinforcing steel cable belts that are assembled
in parallel and run side to side, from one bead to another at an angle of 90° to the circumferential centerline of the tire (Fig.). A belt of cords provides the
necessary stiffness (Fig. X), whereas the external part of the tyre consists of the tread and sidewall and the interior of the inner lining, which ensures the tyre
is hermetically sealed (Fig. ).

Fig. - Substructure of a radial tyre. The threads have a bias angle between 88° and Fig. Xi - The belt of the radial tyre sits on the substructure. The threads are at angles
90°. of between 15° and 25° to the plane of the tyre centre.

This makes the tire more flexible radially, which reduces rolling resistance and improves cornering capability. Fig. shows the interior structure and the
carcass arrangement of a radial tire.

In passenger car tyres, the carcass is made of rayon or nylon, the belt of steel cord or a combination of steel, rayon or nylon cord, and the core exclusively
of steel. Due to the predominance of steel as the material for the belt, these tyres are also known as ‘steel radial tyres’. The materials used are indicated on
the sidewall (Fig., points 7 and 8). In commercial vehicle designs this is particularly important and the carcass may also consist of steel.

The stiff belt causes longitudinal oscillation, which has to be kept away from the body by wheel suspensions with a defined longitudinal compliance,
otherwise this would cause an unpleasant droning noise in the body, when on cobbles and poor road surfaces at speeds of less than 80 km/h. The only
other disadvantage is the greater susceptibility of the thinner sidewalls of the tyres to damage compared with diagonal ply tyres. The advantages over cross-
ply tyres, which are especially important for today’s passenger cars and commercial vehicles, are:

• significantly higher mileage

• greater load capacity at lower component weight
• lower rolling resistance
• better aquaplaning properties
• better wet-braking behaviour
• transferable, greater lateral forces at the same tyre pressure
• greater ride comfort when travelling at high speeds on motorways and trunk roads.

468
Diagonal ply tyres

The non-radial tires are also called bias-ply and cross-ply tires. The plies are layered diagonal from one bead to the other bead at about a 30° angle,
although any other angles may also be applied. One ply is set on a bias in one direction as succeeding plies are set alternately in opposing directions as they
cross each other. The ends of the plies are wrapped around the bead wires, anchoring them to the rim of the wheel. Fig. shows the interior structure and the
carcass arrangement of a non-radial tire.

Fig. - Example of a non-radial tire’s interior components and arrangement.

In industrialized countries, cross-ply tyres are no longer used on passenger cars, either as original tyres or as replacement tyres, unlike areas with very poor
roads where the less vulnerable sidewall has certain advantages. The same is true of commercial vehicles and vehicles that tow trailers, and here too radial
tyres have swept the board because of their many advantages. Nowadays, cross-ply tyres are used only for:

• temporary use (emergency) spare tyres for passenger cars (due to the low durability requirements at speeds up to 80 or 100 km/h);
• motorcycles (due to the inclination of the wheels against the lateral force);
• racing cars (due to the lower moment of inertia);
• agricultural vehicles (which do not reach high speeds).

Cross-ply tyres consist of the substructure (also known as the tyre carcass, Fig.) which, as the ‘supporting framework’ has at least two layers of rubberized
cord fibres, which have a zenith or bias angle of between 20° and 40° to the centre plane of the tyre (Fig.).

Fig. - Design of a diagonal ply tubeless car tyre with a normal drop rim and pressed-in inflating valve.

469
Fig. - The diagonal ply tyre has crossed-bias layers; the zenith angle was 30° to 40° for passenger cars. The 4 PR design should have two layers in each direction. Smaller
angles can be found in racing cars. Rolling resistance, lateral and suspension stiffness are significantly determined by the zenith angle.

Rayon (an artificial silk cord), nylon or even steel cord may be used, depending on the strength requirements. At the tyre feet the ends of the layers are
wrapped around the core of the tyre bead on both sides; two wire rings, together with the folded ends of the plies, form the bead. This represents the
frictional connection to the rim. The bead must thus provide the permanent seat and transfer drive-off and braking moments to the tyre. On tubeless tyres it
must also provide the airtight seal.
The running tread, which is applied to the outer diameter of the substructure, provides the contact to the road and is profiled. Some tyres also have an
intermediate structure over the carcass as reinforcement.
At the side, the running tread blends into the shoulder, which connects to the sidewall (also known as the side rubber), and is a layer that protects the
substructure. This layer and the shoulders consist of different rubber blends from the running tread because they are barely subjected to wear; they are
simply deformed when the tyre rolls. This is known as flexing. Protective mouldings on the sides are designed to prevent the tyre from being damaged
through contact with kerbstones.
There are also GG grooves, which make it possible to see that the tyre is seated properly on the rim flange. Cross-ply design and maximum authorized
speed are indicated in the tyre marking by a dash (or a letter, Fig.) between the letters for width and rim diameter (both in inches) and a ‘PR’ (ply rating)
suffix. This ply rating refers to the carcass strength and simply indicates the possible number of plies (Fig. 2.5).
The marking convention is:

5.60-15/4 PR (VW rear-engine passenger car, tyres authorized up to 150 km/h)

7.00-14/8 PR (VW Transporter, tyres authorized up to 150 km/h)
9.00-20/14 PR (reinforced design for a commercial vehicle)

and on the temporary use spare wheel of the VW Golf, which requires a tyre pressure of pT = 4.2 bar and may only be driven at speeds up to 80 km/h (F
symbol)

T 105/70 D 14 38 F
(WIP)

Tubeless or tubed

In passenger cars, the tubeless tyre has almost completely ousted the tubed tyre.

The main reasons are that the tubeless tyre is easier and faster to fit, plus the inner lining is able to self-seal small incisions in the tyre.

In tubeless tyres the inner lining performs the function of the tube, i.e. it prevents air escaping from the tyre. As it forms a unit with the carcass and (unlike
the tube) is not under tensional stress, if the tyre is damaged the incision does not increase in size, and this avoids rapidly causing loss of pressure and
failure of the tyre. The use of tubeless tyres is linked to two conditions:

• safety contour on the rim

• its air-tightness.

Because this is not yet guaranteed worldwide, tubed tyres continue to be fitted in some countries. When choosing the tube, attention should be paid to
ensuring the correct type for the tyre. If the tube is too big it will crease, and if it is too small it will be overstretched, both of which reduce durability. In order
to avoid confusion, the tyres carry the following marking on the sidewall:

• tubeless (Fig. point 3)

• tubed or tube type.

Valves are needed for inflating the tyre and maintaining the required pressure. Various designs are available for tubeless and tubed tyres (Fig and ). The
most widely used valve is the so-called ‘snap-in valve’. It comprises a metal foot valve body vulcanized into a rubber sheath, which provides the seal in the
rim hole (Fig. 2.20). The functionality is achieved by a valve insert, while a cap closes the valve and protects it against ingress of dirt.

470
At high speeds, the valve can be subjected to bending stress and loss of air can occur. Hub caps and support areas on alloy wheels can help to alleviate this
(see Fig. and Section in R).

Height-to-width ratio

The height-to-width ratio H/W – also known as the ‘profile’ (high or low) – influences the tyre properties and affects how much space the wheel requires (Fig.
2.8).

As shown in Fig. 2.9, the narrower tyres with a H/W ratio = 0.70 have a reduced tread and therefore good aquaplaning behaviour (Fig. 2.35).
Wide designs make it possible to have a larger diameter rim and bigger brake discs (Fig. 2.10) and can also transmit higher lateral and longitudinal forces.

W is the cross-sectional width of the new tyre (Fig. 2.11); the height H can easily be calculated from the rim diameter given in inches and the outside
diameter of the tyre ODT. The values ODT and W are to be taken from the new tyre

(WIP)

Lateral and longitudinal slip

(wip)

Tyre load capacities and inflation pressures

The authorized axle loads mV, f,max and mV,r,max (see Section 5.3.5), and the maximum speed vmax of the vehicle, determine the minimum tyre pressure.
However, the required tyre pressure may be higher to achieve optimum vehicle handling (see also Section 2.10.3.5 and Fig. 2.44).

Tire wear

Each tyre compound has an optimal range of operation. When in this range, the tread provides the most adhesion. Cold tyres are not as adhesive. This is why
it is not uncommon to see even experienced drivers spin the car out, when they get aggressive with the throttle pedal, as they exit the pits on cold, new tyres.
Overheated tyres perform about as well as cold ones. The softer compounds operate in higher temperature ranges, and the harder ones a bit cooler. And the
softer tyres get up to operating temperature more quickly, but they also tend to overheat more easily. On the other hand, the harder tyres may not get up to
operating temperature at all, unless driven at an adequate speed. The medium compound tyres usually take a lap or two, before they reach their optimum
temperature.
The front tyres heat up rapidly, during corner-entry braking. And once on the straights, they cool down quickly, because they do not generate thrust forces
and because they are exposed to the airstream, especially on open-wheel cars. So, when braking hard at the end of a very long straight, realise that your front
tyre temperatures maybe below optimum.
The rear tyres heat up during acceleration, and they remain warm while travelling on the straights, since they must continually generate thrust. The only time
they may have a chance to cool down somewhat is when the rear wheels unload during braking. This difference in temperature profiles may create an imbalance
in traction between the front and the rear, when braking hard. Moreover, the brakes, especially the fronts, would also have cooled, while flying down a long
straight. Hence, a long straight that ends in a sharp corner can be tricky to get right, especially if the braking zone is on a downslope.

Driving the car much too aggressively can heat the tyres beyond their design limit, and damage their treads permanently. Aggressive driving rubs the tyre
tread against the carcass of the tyre, as well as the surface of the track. The excessive heat generated by this double whammy boils the rubber, and causes
air bubbles to form inside the tread. These bubbles expand with the rising tread temperature. A bubbling tread becomes uneven, so the wheel begins to
vibrate. Eventually, the tread gets too hot, and these air bubbles burst. When they blow, they take with them chunks of rubber, leaving behind a ruined tread
dotted with large pits. This condition is called blistering.
When the tyres overheat and start to blister, a wide, dark stripe forms on the tread, longitudinally. On an open-wheeler, the driver can not only feel, but also
see, the onset of blistering. He can see from the cockpit the dark stripes beginning to form on the front tyres. But by then, there is not much the driver could
do, but to plan for a pit stop. The lack of traction and the vibrations confirm that blistering is afoot. When faced with an overheating problem during the race,
the only option the driver has is to tone down the aggression, or return to the pit for a new set of tyres. Both options are undesirable. So, learn to save your
tyres by driving smoothly. And remember that softer compounds are more susceptible to blistering. Rain tyres are designed to heat up, even if the track is
cold and wet. As such, when the rain lightens up and the racing line begins to dry, rain tyres quickly overheat. In that case, driving over pools of water on the
track will cool down the tyres, thereby stretching them for a few more laps until the return of the rain or the return to the pit. But since AC does not model
wet weather, this bit of information is merely for your edification. The opposite problem of overheating is when the tyres will not heat up, because the car is
not driven fast enough. Tyres are too cold, so they do not provide a sufficient amount of grip, and without grip it is difficult to drive fast, so the tyres cannot
heat up. However, a driver with superior car-control skills can go fast enough in a twitchy car, so his tyres get up to temperature more quickly, and hence he
goes faster, all other factors being the same. Yes, life is unfair. Aggressively sliding the car about on cold tyres in hope of heating them up, however, may
create a bigger problem. Aggressive driving can twist the cold tyre beyond its slip angle design limit, before it has had a chance to warm up to the operating
temperature. This causes thin, parallel striations to form on the tread, longitudinally, due to the top layer of the rubber peeling away in thin strips, as the
rolling tread scrubs sideways against the track. These striations reduce the tyre’s traction capacity, making the car slide around more, thereby worsening the
problem. This phenomenon is called graining, because the parallel striations on the tread resemble wood grains. If allowed to progress, graining can destroy
the tread, permanently. But by backing off for a few laps to let the grainy top layer of the tread scrub off, the tyres may recover their traction capacities. Here
471
is a quick summary. Graining occurs on cold tyres. It makes the car feel slippery. Graining is temporary, and it will pass if the driver takes timely action by
toning down aggressive driving, until the tyres come up to operating temperature. Blistering occurs on hot tyres. It not only makes the car feel slippery, it
also vibrates the car. The deep pits on the tread caused by blistering permanently destroy that part of the tread. To encourage the cold tyres to heat up
quickly, the wheels can be installed in a pronounced negative camber, so that their tops are tilted inward. This forces the inside shoulder of the tyre treads to
be used more than the outside shoulders, thereby heating up the inner portions more quickly. The heat then propagates to the rest of the tyre tread. This
approach is not the best use of the tyres, however. A cambered wheel’s tyre has smaller contact patch area, so it generates less traction. And severe
cambering wears out the inside shoulder more quickly, thus shortening the tyres’ service life. Before the cars line up on the grid for a race start, they go
slowly round the track once, to conduct a final system check. During this installation lap, drivers briskly weave their cars about on the track. This side-to-side
movement rubs the tyres against the track, and heats them up in preparation for the launch. Drag racers have a different pre-race ritual, called the burnout,
which achieves the same effect: they spin their rear tyres, before lining up for the start.

472
Computational tire models

In vehicle dynamics, a tire model is a type of multibody simulation used to simulate the behavior of tires. In current vehicle simulator models, the tire model
is the weakest and most difficult part to simulate.

Why should we take a look at computational tire models? The answer is that we can look at a specific model and to Assetto Corsa’s one, compare them,
make our tire LUTs with it, see how they behave in AC and get realistic results, interpreting them while knowing that simulation tire models follow the
industry standard. This can actually lead to an amateur/enthusiast professional-grade production of tire behaviour for our simulator.

Introduction to simulation software and tire models

In recent years, there has been a tremendous push towards the simulation of complex systems. This, coupled with the growing desire by automotive
manufacturers to push the limits, has created an industry devoted specifically to automotive dynamic behaviour. In this industry, tires play a large role in the
actions of the vehicle. As such, the accurate modeling of said tires is critically important in obtaining accurate results. With the number of varying models out
there, it is typically a difficult decision. Tire models can be classified on their accuracy and complexity, in a spectrum that goes from more simple empirical
models to more complex physical models that are theoretically grounded.

Empirical models include Hans B. Pacejka's Magic Formula, while physically based models include brush models (although they are still quite simplified),
and more complex and detailed physical models include RMOD-K, FTire and Hankook.
Brush models were very popular in the 1960s and '70s, after which Pacejka's models became widespread for many applications.

Fully physics-based tire models have been typically too computational expensive to be run in realtime driving simulations. For example, to since CDTire/3D,
a physics-based tire model, cannot be run in realtime, for realtime applications typically an equivalent semi-empirical "magic formula" type of model, called
CDTire/Realtime, is derived from it through experiments and a regression algorithm.

In 2016, a slightly less accurate version of FTire, a physics-based tire model, was adapted to be run in real time. This realtime version of FTire was shown in
2018 to run on a 2,7 GHz 12 Core Intel Xeon E5 (2014, 22nm process, about $2000), with 900 contact road/contact patch elements, a sample frequency of
4.0 kHz including thermal and wear simulation.

The typical tire model sampling rate used in automotive simulators is 1 kHz. However, running at higher frequencies, like 2 kHz, might mitigate lowered
numerical stability in some scenarios, and might increase the model accuracy in frequency domain above about 250 Hz.

In January 2020 Cosin scientific software showcased that they were able to run their physical tire model FTire in realtime with rFpro.

Classification of the most important tire models by purpose:

Driving dynamics models

• Brush model (Dugoff, Fancher and Segel, 1970)
• Hohenheim tire model (physical approach)
• Pacejka Magic Formula Tire (Bakker, Nyborg and Pacejka, 1987)
• TameTire (semi-physical approach)
• TMeasy (semi-physical approach)
• Stretched string tire model (Fiala 1954)

Comfort models
• BRIT (Brush and Ring Tire)
• CDTire (Comfort and Durability Tire)
• Ctire (Comfort tire)
• Dtire (Dynamical Nonlinear Spatial Tire Model)
• FTire (Flexible Structure Tire Model)
• RMOD-K (Comfort and Durability Tire)
• SWIFT (Short Wavelength Intermediate Frequency Tire) (Besselink, Pacejka, Schmeitz, & Jansen, 2005)

This paragraph should help clarify the strengths and weaknesses of the major ones.

The software used to conduct these tests is Adams. Adams is one of the leading multibody dynamics simulation software. There is a module within the
software called Adams/Car which specifically handles vehicle dynamics. Within Adams/Car there are specific protocols that handle tire solutions. These
protocols utilize various models that have been created, or at least incorporated into the software, by the software’s manufacturer, MSC.
In February 2017, the company was acquired by Swedish technology company Hexagon AB. It operates as an independent subsidiary.

This software can be obtained from MSC’s website (http://www.mscsoftware.com) in both student and professional forms. The student version can be
obtained for free (with software limitations) after student standing has been confirmed, or the full version can be obtained at sizable cost, but there are
discounts for professors.

It is also necessary to have a computer capable of running the software. Exact requirements can be found on MSC’s website. The computer utilized during
these tests was a custom-made workstation specializing in demanding processing. It features 3 terabytes of hard drives, 16 gigabytes of RAM, and a 3.7 GHz
quad core processor.

The simulated vehicle used was a template provided by MSC software employees. It was not created under the direction of MSC but more as a side project
to help students who participate in Formula SAE to get started using Adams/Car in a reasonable amount of time.
473
The tire models used by Adams described herein include the PAC2002, PACTIME, PAC ’89, PAC ’94, 521, UA-Gim, and FTire. The first 4 of which use the
same basic approach but with slight variances. The 521 and UA-Gim models use a relatively more simplistic approach, and the FTire model utilizes a
completely different approach than any of these. The PAC models all work on the basic premise of research that was developed using what’s called the
“Magic Formula.” This is basically a curve fit that can be used to solve for things such as the forces and moments acting on the tire. The forces and moments
are the most important aspects that need to be modeled due to their impact on the vehicle performance.

Since these models vary significantly in their performance and applicability, MSC had provided a reference table designed to help decide which model to
use. That one is not the chart below. This new table was modified to reflect the findings of a study by Andrew R. Wheeler (University of Arkansas,
Fayetteville, Computational Tire Models and their Effectiveness).

MSC Software originally stated the best overall tire model was the PAC2002. Based off the findings stated within the study, this is not true. They are even
aware of the inaccuracy of the Pacejka models at low speeds, yet indicate in their table that it is best to use at these speeds. Such incongruities roused
suspicion initially. Once it was found out that the creator of the PAC models is MSC, it was clear that there may have been some bias.

MD Adams Event / Maneuver Adams / Handling Tire

PAC2002 PAC-TIME PAC89 PAC94 FTire 5.2.1 UA Tire
Stand still and start 2 2 1 1 2 3 2
Parking (standing steering effort) 3 0 0 0 3 0 0
Standing on tilt table 3 3 3 3 3 3 3
Steady state cornering 2 3 1 1 3 1 2
Handling Lane change 2 3 2 2 3 1 2
ABS braking distance 3 2 2 2 3 1 2
Braking/power-off in a turn 3 3 1 1 2 1 1
Vehicle roll-over 3 1 1 1 3 1 1
On-line scaling tire properties 3 0 0 0 1 0 0
ABS braking control 2 1 1 1 3 1 1
Shimmy 2 1 1 1 3 1 2
Chassis Steering system vibrations 2 1 1 1 3 1 1
Control Real-time 2 2 2 2 0 2 2
Chassis control systems > 8 Hz 2 0 0 0 3 0 0
Chassis control with ride 0 0 0 0 3 0 0

Based on the aforementioned research, it is contended that the FTire model consistently outperforms the PAC2002 model. Every test conducted resulted in
the FTire model being at or very near the average of all the results.

One complication that arouse during the initial stages of this research was how to determine the validity of the tests. Because there is no true result that can
be obtained via computation, the approach taken to determine the effectiveness of each model was to compare each individual result with the mean of all of
the results. Greater deviation from the mean would therefore imply a less effective model for that given test.
Several complications were encountered during the tests. The software used, Adams/Car by MSC Software, proved to be somewhat temperamental.
Sometimes simulations would run perfectly fine. The same simulation would try to be ran again with no changes and an error would occur. Sometimes,
certain models refused to run on certain courses. This is not due to incompatibility with the models and road, but to software inconsistencies. Examples of
this include the UA-Gim tire model not running properly on the skidpad test, but being the only one to provide realistic results on the fish-hook maneuver.

PAC2002 Tire Model

The PAC2002 Tire Model is the industry standard when it comes to computational tire/force interaction.
It is based off a book by a renowned vehicle system dynamics and tire dynamics Professor emeritus at Deft University of Technology in Deft, Netherlands
named Hans Pacejka. Over the past two decades, Pacejka has been designing tire models that have little to no physical basis or structure of the formulas
chosen. Because of this, they are commonly referred to as the “magic formula” models. During the solving process, each tire is characterized by 15-20
different coefficients that represent different forces exerted on the tire’s contact patch. Most of these can be seen in Fig.

474
Fig. - Basic notation for the road/wheel interaction. Directions shown are positive.

Generally speaking, a Magic Formula (MF) tire model describes the tire behaviour for roads with surface roughness of up to 8 Hz.
This characterizes most roads and makes the model applicable for situations including:
• Cornering at steady-state
• Single-lane change
• Braking (including split-mu and ABS)
• Most turning maneuvers
• Other common maneuvers on applicable roads

For vehicles with camber angles (𝛾𝛾) less than 15°, the PAC2002 tire model has also proven to be valid.
In pure slip conditions (cornering with a free rolling tire), both the longitudinal force, 𝐹𝐹𝐹𝐹, as a function of longitudinal slip, 𝜅𝜅, and the lateral force, 𝐹𝐹𝐹𝐹, as a
function of the lateral slip, 𝛼𝛼, have a similar sine-arctangent shape that can be represented by the general equation:

𝑌𝑌(𝑥𝑥) = 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 {𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶[𝐵𝐵𝐵𝐵 − 𝐸𝐸(𝐵𝐵𝐵𝐵 − 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎(𝐵𝐵𝐵𝐵)]}} (XXX)

where B, C, D, and E are constants obtained from curve fittings and 𝑌𝑌(𝑥𝑥) is either of the aforementioned forces with their respective independent variable.

The characteristic curves for these can be seen in Fig..

Fig. - Characteristic Curves for Fx and Fy under pure slip conditions.

Since this is by no means a regularly seen curve, a little more in-depth look at it is necessary. The coefficients in the MF each affect the curve in different
ways. The way the curve changes will directly change the force or moment being solved for. Fig. illustrates how these changes interact.

Fig. - The Parameters of the MF Explained.

Equation (XXX) is the standard form of the Magic Formula. It can be applied to more than just the aforementioned forces. Its other primary use is that of
solving for the moments acting on the tire in all 3 directions.

475
The movements of the vehicle are a direct result of the road forces on the tires. These forces are directly dependent on not only the tire’s properties, but also
the road’s properties. In this model, the tire is assumed to act as a parallel spring with damper (both linear) in the radial direction with a single point of
contact.
(WIP)

PAC-TIME Tire Model

The PAC-TIME model is a new version of the PAC2002 model. The only modification made is in the equations for the aligning moment 𝑀𝑀𝑀𝑀 and side force
𝐹𝐹𝐹𝐹.
(WIP)

’89 and ’94 Pacejka Tire Models

The ’89 and 94’ Pacejka models are also in the magic formula family. They are the older versions of the PAC2002 model. While the PAC2002 model has
been kept up to date, the ’89 and ’94 models have been mostly abandoned. They are still applicable and relatively accurate; so much so that they are still
included in the Adams/Tire software due to their continued use in the industry.
(WIP)

521-Tire Model

The 521-Tire Model is one of the simpler models in Adams. It utilizes only a handful of parameters and experimental data. One of the primary benefits of this
model is its flexibility. It can solve for the moments and slip forces using two different methods. These methods are the Equation Method and the
Interpolation Method. The Equation Method utilizes a set of generalized equations based off research done in the 1990s while the Interpolation Method uses
an AKIMA spline to calculate the forces and moments relative to the camber, slip, or vertical load. The basic notation of this can be seen in Fig.

Fig. - Directional vectors of the 521-Tire model.

MSC states that this model has been superseded by newer tire models and recommends the use of these other models for more accurate work. They state
that this model is only included for backwards compatibility.

UA-Gim-Tire Model

The University of Arizona Tire Model, abbreviated UA-Gim tire model, was developed based off the research of Dr. Gwangun Gim. His thesis, Vehicle
Dynamic Simulation with a Comprehensive Model for Pneumatic Tires, originally published in 1988, prompted MSC to create a computational tire model in
their Adams software. The model calculates the forces and moments at the contact point as a function of the tire’s kinematic states. One of the new concepts
presented by Dr. Gim was that of the Friction Circle.
Seen in Fig., it limits the total friction achieved by the wheel/ground interface but allows for different values of the longitudinal and lateral friction. For
example, if 𝜇𝜇𝜇𝜇 is at its limit (greatest braking or acceleration in the longitudinal direction without slippage) then no lateral forces can occur without resulting
in slip.

Fig. – The Friction Circle.

476
FTire Model

The final model to be discussed is the FTire Model. The FTire, or Flexible Ring Tire Model, varies significantly from most other models. No form of the
magic formula is used. It relies almost exclusively on analytical means to solve problems using classical mechanical and thermodynamic approaches.
Instead of using lengthy pre-processing of the road data, it simply resolves road data as it is defined. This allows the model to be used as a more effective
means for analysing ride comfort and modeling the reactions on harsher terrain. An example of a harsh ride comfort simulation can be seen in Fig..

Fig. - Harsh terrain capabilities of FTire.

This model was created and is kept up to date by Cosin Scientific Software. MSC Software incorporates its solving capabilities into Adams.

The approach taken by the FTire model is similar to finite element analysis. The belt of the tire is described as a ring with elasticity and stiffness properties. It
is broken up into subsections and given degrees of freedom for movement. They are connected to each other by what can be represented by a spring (Fig.).

Fig. - FTire bending stiffness representation.

These connections are used to represent the tire’s bending stiffness. A similar approach is used for torsion and lateral bending. Because of the complexity of
this model’s approach, it takes a significantly longer time to simulate. It is also suggested by the manufacturers to use a minimum of 1000 steps per
second for the integrator. This is due to the high resolution of the model and the way it was developed to deal with tire vibration and road irregularities.

(WIP)

PAC 96 tire model used by netKar Pro.

477
34. wing_animations.ini
This config file can be used to add animations for the active wings of the vehicle. It can also be re-purposed for other parts. The movement can be managed
thanks to the controllers present in aero.ini.
[HEADER]
VERSION=2

[ANIMATION_0] ; Wing animation identifier. SYNTAX: [ANIMATION_ID], ID starting from zero.

WING=3
TIME=0
FILE=WING_L.ksanim ; Specifies which animation file to use for the specific wing.
MIN=0
MAX=80
NEXT=1
SPEED=4
INVERTED=0

% ▼ As you can see below, not all the parameters are required, it depends on the result you want to get.

[ANIMATION_1]
WING=4
FILE=WING_R.ksanim
MIN=0
MAX=50

[ANIMATION_2]
[ANIMATION_3]
[...] ; A vehicle can have as many [ANIMATION] as necessary.

LITTLE EXPLANATION
- To add the movement of the air intake butterfly valve opening and closing when the throttle is pressed (Fig.), create the animation for it (simple rotation
around the throttle blades axis with just two keyframes should be fine), then export it the same way you would any other animation like doors or wipers
(@Stereo 's add-on makes it way easier).

Fig. -

Subsequently add a wing element in aero.ini and its [ANIMATION] in wing_animations.ini, with the respective WING number. You can link the movement
to throttle actuation with a controller in the aero.ini file.

478
CHAPTER 12 – ADJUSTMENTS DURING / AFTER A RACE SESSION
This chapter is dedicated to everything you can do within a race session to observe, check and debug any desired or undesired behaviour of your vehicle.

12.1 – AC DEBUG CONSOLE COMMANDS (LIVE FIX)

Lights (front, rear, brakes), flames, digital instruments, display panels and the ground collider can be adjusted with real time in-game feedback, using the
built-in debug console commands.

Press the HOME button on your keyboard to open the AC command window (Fig. 7.0). Please note that with CSP comes an option to deactivate the console,
so if you can’t open it, check the Custom Shaders Patch settings.

Fig. 7.0 - The AC debug console.

Type after the set command one of the functions below to enter edit mode, where AC will display real-time any adjustments in the data files.
• set observeLights [value] ; enables edit mode for lights.ini
• set observeFlames [value] ; enables edit mode for flames.ini
• set observeDigital [value] ; enables edit mode for digital_instruments.ini
• set observePanel [value] ; enables edit mode for digital_panels.ini
• set editBoxes [value] ; enables edit mode for colliders.ini

% ▲ [value] can be 1 (AC will read the new values in the config files) or 0 (AC won’t read the changes in the scripts; this is the default value).

The commands and functions are case sensitive.

When [value] is set to 1 (Fig. 7.1), any change to the lines of code in the respective config file will appear in the game real-time. For example, if you edit
the colour of headlights in lights.ini, with the set observeLights command you will see the colour change in-game.

Fig. 7.1 - Just type the number directly after the command, you don’t need brackets or other symbols.

The set command is multi-purpose however, and can also be used with this syntax: set [var] [value] and the following variables (case-sensitive!):
• set axisMode
• set sunHeading
• set sunPitch
• set hideGroove
• set hideHead
• set headRoll
• set headPitch
• set headYaw
• set headMaxG
• set headFilter
• set lodDebug ; Shows info on screen for which vehicle LOD is currently active and its coordinates. [Boolean]

479
• set debugDamage
• set steerAssist
• set FUEL_STEP ; Overrides the same parameter in analog_instruments.ini for debug purposes.
• set FUEL_ZERO
• set FUEL_MIN
• set RPM_STEP
• set RPM_ZERO
• set SPEED_STEP
• set SPEED_ZERO
• set wATER_STEP
• set WATER_ZERO
• set WATER_MIN
• set debugDirt
• set exposure
• set editCMesh
• set restrictor
• set fov
• set aniso
• set driverEye.x
• set driverEye.y
• set driverEye.z
• set graphicsOffset.x ;
• set graphicsOffset.y ;
• set graphicsOffset.z ;
• set graphicsPitchRotation
• set bias0
• set bias1
• set bias2
• set ffMult
• set maxLayer
• set AUTOFLIP_RECOVERY
• set DISABLE_SHOW_MODE
• set PROVIEW_MODE
• set RENDER_SPLINE
• set aiSteerGain
• set aiPush
• set aiLookAhead
• set aiLookAheadSpeed
• set freeCamFov
• set freeCamDof
• set freeCamDofFocus
• set freeCamExp
• set freeF5 ; The F5 camera is movable with the mouse and arrow keys, but still attached to the vehicle. [Boolean]
• set minExposure
• set mirrorpos.x
• set mirrorpos.y
• set mirrorpos.z
• set shadowBias
• set hdrHPLevel
• set hdrBloomLevel
• set hdrBloomBaseLevel
• set bodyDamageLevel0 ; Specify the amount of damage for the front bumper (if damage.ini is properly set). It is cumulative.
• set bodyDamageLevel1
• set bodyDamageLevel2
• set bodyDamageLevel3
• set bodyDamageLevel4
• set engineDamageLevel

In the variables above the [value] parameter will often work as a Boolean (0=false, 1=true) like in Fig. 7.1, but there are exceptions, where you will be
allowed to input numbers.

Remember that the changes done from the console are not saved: the commands are mostly for debug purpose, so they can help you finding correct
parameters which you’ll have to remember or write down on a piece of paper; try for example the ’set RPM_STEP 10’ command and look at what the
gauge on the car dash does.

Other commands are the following:

• getSteerAssist ; Returns the current steer assist setting.
• refresh_instruments ; No parameters needed.
• testCrash ; Initiates an AC session crash for testing purposes.
• saveff ; Saves the current ffMult value in car.ini
• rSsA ; Resets the Steam Achievements.
• help ; Displays the available commands in the console. Can be used to list other functions (e.g. set help).

Pro tip: some people may want to use a shader injection tool called Reshade; just avoid binding the HOME key to the opening of its shaders’ configuration window, because
the AC console will open every time and it will be annoying, unless you use CSP and deactivated it in the mod’s settings.

Are there any other commands? Yes, in the code there are PLUGIN functions, but Kunos didn’t reveal nor document them.

what is acnotify.py?

480
12.2 - AC DEBUG LOGS (wip)
- Python has its own log: py_log.txt
- race.ini and race_out.json are printed in log.
- Go to %ROOT%/system/cfg/assetto_corsa.ini, change WARNING_AS_ERRORS=1. With this setting, the game will always crash for the smallest errors and
write down the errors towards the end of the user Documents/logs/log.ini file.

12.3 – APPS
What are apps in Assetto Corsa?
Apps are part of the UI and HUD in any race session of our simulator. When you start a session, move your mouse to the RIGHT SIDE of the screen to reveal
the list of all the awesome APPS the game has to offer. Simply click on the respective icons to open them.
You are free to move them anywhere on the display. Even on a different monitor, if you have a double or triple-screen setup. They can be fixed in place and
closed whenever you want (Fig. 7.2). The interface becomes quite modular.

Fig. 7.2 – AC makes no compromises in terms of customization.

You can choose from a multitude of apps that display a variety of information. Exactly how much and how detailed that info should be, is up to you.
Assetto Corsa has a completely moddable interface, you can change any icon quite easily indeed. Some mods recreate the look of other games, like Gran
Turismo or Forza, or even the graphics of the official F1 leaderboards. If you want a fresh experience, you just need to search a bit in the world of AC mods.
Keep in mind that apps have always been fps-hungry. Since the early days of AC opening apps has always had an impact on the rendering performance.
That’s part of the reason why the main apps are really clean and sometimes quite spartan, but they do their job well.
We can divide apps in two categories: basic, mostly useful while driving as Head-Up display (HUD), and developer apps, very useful while making mods, as
debug tools.

12.3.1 - BASIC APPS AND HUD

This paragraph is dedicated to basic apps, the ones that the common user usually sees during his normal driving routine. The info these apps give is simplified
and mostly in the form of a graphic visualization output, because if you aren’t a skilled driver and you just want to have fun, you don’t need detailed specs (for
example, you just need to know that the accelerator pedal is working, not its percentage).
The following are the most important basic apps you will find:
1. Essentials
2. Gears
3. Pedals
4. Track map
5. Onboard settings
6. Graphic stats
7. Render stats
8. k

Let’s take a look at each one of them, analysing each parameter displayed.
1. Essentials

2. Gears

Simple, yet very nicely made and quite fancy.

481
 White arc: RPM
Red arc: Turbo boost
Blue arc:
Green arc:
Yellow arc:
Center number: Selected gear
Lower number: Current speed + unit (kmh/mph)

Fig. -
3. Pedals

Blue indicator: Clutch pedal input

Red indicator: Brake pedal input
Green indicator: Throttle pedal input +
Grey indicator: FFB (Force Feedback)

Fig. - Be sure to set your FFB gain in such a way, that it doesn't “clip”, so the bar not to turn red the majority of the time.

4. Track map

track_map.jpg

Look at the map while exiting the pitlane or returning onto the track from an off-road.

5. Onboard settings

Adjust your seating/view position, FoV and pitch. These settings will be saved individually by car. You may raise your seating position to improve your view
out of Formula cars.

You can't save car.ini and Dash for cars with encrypted data folder like the Kunos McLaren in your screenshot. Those two buttons are supposed to be used
when making cars (and don't usually show up with data not being editable).

Does it save the view position on a per car basis? Yes, if you use that app it applies changes only to the car you're in.

482
6. Graphics stats
Parameters:

UPD:
REND:
HUD:
PHYS:
CPU:
AUDIO:
DIFF:

7. Render stats
APP for physics

DIP and B.Size are the most relevant numbers to tell if you have roughly the right object size (dip is total # objects,
b.size is their average polycount) TRI tells you how much is actually getting rendered, splitting up objects and
setting LOD distances appropriately brings that down.

PHY is the percent of a physics frame (3ms) it takes for the cpu to finish calculating physics.

PHY_LATE is number of frames that finished calculating after the real time they were supposed to be done... if it's a
temporary spike it'll just add 1, it'll be counting up if your game can't run at 100% speed.

Time of day
timeofday.jpg
Time of day does advance in SP and does not in MP (as of 15.08.14)

12.3.2 - DEVELOPER APPS

These are the most powerful tools you can get from any game session. A lot of data is displayed on these utilities, so don’t miss them, because they’re usually
hidden from commoners and nerds. You’ll have to enable them if you want the benefits of their power. How is it done?

Go into the AC install folder: %root%\assettocorsa\system\cfg and open assetto_corsa.ini with a text editor, then find and edit the following value:
[AC_APPS]
ENABLE_DEV_APPS=0 ; Enables/disables developer apps; =1 to enable, =0 to disable (default value).

About the root folder at par. 2.3 of the AC User Guide at the beginning of this manual.

The following are the most important dev apps you’ll have to use:

1. AI app
2. Camera editor
3. Car physics
4. Graphics stats
5. Setup debug
6. Suspensions
7. Tyre debug
8. Tyre tester
9. Wings app

Let’s take a look at each one of them.

483
AI app
The AI app (Fig.) is very useful to configure the artificial intelligence parameters of the single vehicles, but it’s fundamental for the creation of track AI splines
and testing the virtual opponents in general.
Normalized Pos:
Target Steer Distance:
Points count:
Interpolation Mode:
Outside offset:
Gas Brake Target
IS grid on:
Prj RPM:
Distance from target:
BASE:
NCM:
DTNC:

Graphs:

Start recording:
Start pits:
Save cons:
LAT_OFF: Lateral offset
XX1: Speed the AI wants to brake at. [km/h] XX2: Current speed of the AI. [km/h]
XX3:
D: stands for distance. It represents how many meters are left before hitting the XX1 speed.
If the D value is positive before a corner, the AI managed to brake faster (earlier) than it “thought”, so you
have to do is bring up the Brake hint.
Magic:
CP:
aiPush:
Steer LA:
Steer gain:
Aero hint:
RPM gear up:
Gear down %:
Brake hint:
Tyre hint:
Save AI:
- Trail hint is missing from the app. In a video of development by Stefano Casillo we see eight boxes in the lower part of the app, not seven. Why was it
removed?

- While the car is in self-driving mode (enabled with Ctrl+C in any session except practice), it is possible to edit many of the ai.ini parameters directly live in-
game. When the AI has the control of your car, it runs at 100% strength, so it’s got no oscillation in the hint levels. That’s why the self-driving AI is not identical
to the opponent cars’ one, which can't be put on the player’s car.
- If the AI goes too wide in a corner, the brake hint or the TRAIL_HINT (the latter in the ai.ini) may be too high. Usually 30 is a good starting point for
every car. Move them from there.

Pro tip: when working on the car-specific AI parameters, be conservative: there is no point in spending too much time trying to optimize one track. The fact that the system
works well on one map doesn’t mean that it will translate well on other circuits or other conditions (e.g., temperatures).

484
Camera editor

Fig. – car with packed data.acd

Edit vehicle cameras with the app

-save dash only appears if you unpack data

485
Car physics
Parameters:

SM: Tyre compound short name as in tyres.ini (in this example, Slick Medium).
CGH: sprung mass CG (center of gravity) height from ground (GH = ground height) in meters [m];
DY F: tire grip level (front of the vehicle)
DY R: tire grip level (rear of the vehicle)
LD0: current vertical load Fz for tire LF in Newtons [N]
LD1: current vertical load Fz for tire RF in Newtons [N]
LD2: current vertical load Fz for tire LR in Newtons [N]
LD3: current vertical load Fz for tire RR in Newtons [N]
DISTR: Weight distribution of the car as a percentage on the front axle.
SA LF:
SA LR:
AVEL_Y:
GLAT: lateral acceleration in Gs: [G]
GLON: longitudinal acceleration in Gs: [G]
DI: dynamic index of the vehicle; inertia related
DSPEED:
BOOST: turbo boost pressure in psi?
VKM F: slip distance in kilometres (front of the vehicle); slipping laterally will add more vkm than slipping longitudinally
when traveling forward
VKM R: slip distance in kilometres (rear of the vehicle); same as VKM F
AP: air pressure (you can do all of your aerodynamic calculations and evaluations with this value)
ELIFE:
BOV: turbo blow off valve
DYN_TRK: current grip level on track in percent (0.963 means a grip of 96.3% and so on)
BOOST: turbo boost pressure (again?)
GRAIN F: Front tires graining
GRAIN R: Rear tires graining
BLISTER F: Front tires blistering
BLISTER R: Rear tires blistering
FLAT L: Tire LF flat-spotting
FLAT R: Tire RF flat-spotting
KERS:
KERS_KJ:
CONS: fuel consumption of the vehicle for AI calculations, saved by AI app (save fuel cons button)
NCP:
RPM: rotational regime of the vehicle’s engine in [RPM], rotations per minute
FSPEED:

486
Setup debug

AIR PRESSURE #: Single tire pressure in [bar]; 0 is, 1 is, 2 is, 3 is

camberRAD #:

camberDEG #:

accG:
engineRPM:
limiterRPM:
isEngineLimiterOn:
steer:
gas:
brake:
clutch:
gear:
cgHeight:
worldPosition:
velocity:
Tyre Comp.:
lapTime:
lastLap:
bestLap:
lapCount:
performanceMeter:
FUEL:

AEROMAP:

ROD LENGTH #:

GEARS #: Gear ratios of the vehicle, user-defined in drivetrain.ini or through

transmission-related files (.rto); affected by setup choices.

FINAL RATIO: Final gear ratio, user-defined in drivetrain.ini or through

transmission-related files (.rto); affected by setup choices.

wheelAngularSpeed #:

slipAngle #:

slipRatio #:

load #:

tyreDirtyLevel #:

suspensionTravel #:

ndSlip #:

487
Suspensions app

Coordinates

GRAPHS (four corners): Slip angle; if violet line is perpendicular = none.

SA: Slip angle. STR: Steering angle, zero is neutral. [deg]

SR: Slip ratio. CASTER: Front wheels castor angle. [deg]
C: Camber angle relative to the road surface. [deg] KPI: King Pin Inclination. [deg]
T: Toe angle. SCRUB: Scrub radius. [mm]
Yellow/red bars: Slip ratio/angle graphs for each wheel (red=100% slip).
If you stop pressing the gas and brake pedals, they'll all even out.
If your car is RWD for example, there will almost always be more slip ratio on the rear than the
front - it is normal.
Tire visualizer (red=hot): Tire temperatures are plotted on a 3x12 array for each tire; the top row is
inner, bottom row is outer, and it goes around the radius of the tire.

IMO [ℕ1 ℕ2 ℕ3]: Instantaneous Inner / Middle / Outer tire temperatures. Race car engineers
measure temps in these zones across the tread.
I: Vertical load on the tire
P: Instantaneous tire pressure. [psi]
CP: Contact point

Vertical white graph: Rear bumpsteer. It is toe gain on bump and rebound.

Fig. –

- Keyboard shortcuts:
• Numpad 1-4 keys toggles the wheels' physics locations (vs. graphics locations.): 1 is WHEEL_LF, 2 is WHEEL_RF, 3 is WHEEL_LR, 4 is WHEEL_RR.
• Pressing backspace on your keyboard toggles the suspension linkage visualization ON/OFF.
• Pressing Ctrl (left/right) or Alt Gr on your keyboard toggles the

- Front wheels on a racing car are typically installed with a pronounced negative camber. The front camber counteracts the front suspensions’ tendency to tilt
the top of the outside-front wheel outward, in response to corner-entry load transfer. If the car is not set up properly and hence cannot be driven hard through
the corners, the outside edge of the front tyres will not be used as much. The inside edges will accordingly be hotter. Hence, the IMO temps are a crude but
effective way to diagnose poor setups, and sometimes poor driving techniques as well.

At lower tiers of racing, the engineers have no real-time telemetry data of the car’s performance parameters; the only information they possess when setting
up the car are the tyre temperatures and the driver’s feedback about the car behaviour. The engineers obtain tyre temperatures by sticking a probe into the
tyre tread at inner, middle, and outer areas. The engineers sometimes employ the same probe on the driver forcibly to extract feedback, when the driver is not
forthcoming with the information upon his return to the pit.
Pro tip: do not use the Suspensions app during replays, as the physics are not calculated. If you were to do this inadvertently, you might encounter situations similar to what
you can see in Fig. below.

Fig. - Phantom axle, detached from the car and refusing to follow it when the cameras roll. The app sticks to the most recent frame that was simulated.

488
Tyre debug

Fig. -

Tyre tester

Fig. -

489
Wings app
Here's a screen of the Wing App in action with the Mercedes AMG GT3 (Fig.). I chose that as I know the GT3 class is very popular, and it has a widely used
setup (body, front, rear wings and diffuser, some other cars have many more or less, but this is quite common and easy to understand).
I'll start from the left column on top.

NAME: Name of the wing, as specified in aero.ini. With the app open, you can see the wings that these refer to
displayed as green rectangles (or red if it’s a fin, I think).
AOA: That is angle of attack, basically the angle of the wing is relative to the air. Usually the body is a positive, but
can be a negative under heavy braking, depending on the car. This is live, so although your rear ring may be set
at 10 degrees, it could well be 9.5 degrees or 11 degrees, depending on the cars current position and rake angle.
GH: Ground Height, so height in [mm] of the element relative to ground. Very useful for noting when the front
wing or diffuser might start to stall. The front splitter and the rear diffuser perform differently depending on the
height.
CL: Coefficient of lift (or downforce) times wing area. It represents the lift or downforce you are producing real
time for each wing. Use this to help decide how much wing angle you want (along with CD). This number is pulled
from the aero files and will vary live, depending on angle and height for splitter and rear wing/diffuser. If the wing
stalls the number will drastically decrease.
CD: Coefficient of drag times wing area. Same as lift but it's drag force. Useful for knowing if the wing changes
you make are efficient (i.e., you get a good amount of downforce against drag). You might find that the very high
wing settings only add drag, not downforce, so keep an eye out.
°: Angle of the wing in degrees. This is just the static angle, so is not affected by the live pitch of the car.
YAW: The yaw angle of each wing relative to the air. Not super useful, but since most wings are affected by yaw
angle (they become less efficient), you can monitor this, though I've never been in a situation where this was
necessary.

Fig. – The Wings app.

On the bottom row AC will do the sum of all the CL and CD of the wings; put those in your formulas that will include element width, car speed and air density
and then you will know the total lift and drag in kgs of force. It also gives you the forces repartition (aero balance) between front and rear axle in %.
TOT CL: This is the total Coefficient of Lift taking into account all wings. Very useful for getting a quick and easy picture of how much downforce you have.
@ XX% front: This is your Aero Balance, very handy for setting the car up. The percentage shows ratio of generated downforce (how much of the total downforce is pushing
down the front axle). Generally you want this to match your weight distribution (that’s at least a good starting point). For most cars this is fine anywhere between 40% and 50%.
The real center of pressure is a little bit less (3-4% rearwards) because the drags of the aero elements increase rear tyre load and reduce front tyre load (squat).
Note: drag forces do have an impact on wheel loads, only the app does not include them in lift repartition %.
TOT CD: This is the total Coefficient of Drag taking into account all wings. Very useful for getting a quick and easy picture of how much drag you have.
EFF: The aero efficiency: lift divided by drag =CL/CD. The higher the better, as it means you have more downforce per quantity of drag. On some tracks (like Monaco) you can
sort of forget this and go for maximum drag, but it’s important for most tracks. A lift to drag ratio of 7 is not reasonable for any car. Modern LMP1 cars max out at around 4.9,
GT2 cars around 3, F1 cars around 2.9.
TOT(KG) DOWNF: This is your actual amount of downforce in KG - though its not as easy or useful to read at the CL because it changes with speed. Only really useful for
modding, if you have data that states a certain amount of DF at X speed, otherwise just use the CL.
TOT(KG) DRAG: This is your actual amount of drag in KG - though its not as easy or useful to read at the CD because it changes with speed. Only really useful for modding, if
you have data that states a certain amount of Drag at X speed, otherwise just use the CD.
- The drag/lift values (CD & CL) you see at the AERO app are total values. The drag/lift coefficients of the car are multiplied by the frontal area (CdA & ClA).
That’s one thing to note as you try to compare the CD in the wings app to the drag figures you may see published.
The frontal area of modern cars is around 2 (small variations make a difference) and that's why you may think that in AC all the CD values are x2. But you
are wrong. As a litmus test, for example:
In the aereo.ini you can have a wing with the following specs: And you'll need a wing_body_AOA_CD.lut:
NAME=BODY -10|1
CHORD=1 0|0.31
SPAN=1.81 2|0.32
POSITION=0,0.23,0 5|0.34
LUT_AOA_CL=wing_body_AOA_CL.lut 8|0.36
LUT_GH_CL= 10|0.38
CL_GAIN=1.0 12|0.50
LUT_AOA_CD=wing_body_AOA_CD.lut 14|0.51
LUT_GH_CD= 16|0.53
CD_GAIN=1.0 20|1.00
ANGLE=0

This way your CD at 0 angle will be 0.31; multiply this by the frontal area: CHORD ∙ SPAN = 1.81; multiply the CD with frontal area: 1.81∙0.31 = 0.56,
so 0.56 is the number you will see in the Wings app in-game and it is the total drag.
Pro tip: the two main things to watch and maximize on Kunos aero cars is the FRONT CL and DIFFUSER CL. They will always grow as the car gets lower and lower up to a
point they will drop sharply when GH gets too small. The goal is to keep these two elements near their maximum CL as much as possible.
In AC a common thing in GT cars is that if you lower the front too much you may lose your front downforce when you hit the brakes hard at the end of a straight.
Such thing generally does not happen in real life, only for certain designs but not for conventional splitters (at least not until you reach much lower heights than in AC, where
they seem to stall at 3 cm from the ground). Finetuning ride height is one of the things the app helps a lot with.

490
12.3.3 - FAQ
QUESTION [1]: How do you guys use the apps for physics debug? I mean do they work in replays or do you glimpse them while driving? And if while
driving, is it necessary to really push the car to get correct readings?
ANSWER [1]: Hey, these are two questions in one. Slow down, kid.
Some guys can concentrate on the live readings while driving but for the people (like me) who can't there's the telemetry dump that can be opened with
RaceStudio.

1. Make sure you have set DEBUG_PHYSICS=1 under [TELEMETRY] in Steam\steamapps\common\assettocorsa\system\cfg\assetto_corsa.ini so you have all
telemetry channels in the telemetry dump file.
2. Download RaceStudio, open RS2 Analysis and import telemetry_dump.act from your user Documents\Assetto Corsa\aim using import Assetto Corsa file.
3. Now you can choose the aero channels you want and it will plot a nice curve for the laps you have selected.

Alternatively, you can use Motec for live telemetry, but we will talk about it in the next Paragraph. And if you dont trust the apps, simply check telemetry.

Finishing with the second part of the question, there is no need to be pushing 100% while driving. For example, regarding the Wings app, the wings’ height
won't change much if you are 5-10 km/h off your normal speeds. No need to constantly monitor it either. Fast corners and hardest braking zone of the track
are the spots where you want to be glancing at it.

491
12.4 – TELEMETRY
Due to the difficulty to gain real life racing experience, many sim-racers have little to zero knowledge about what is needed to improve their own
performance on the track. Studying and reading are never a foolish thing, and racing and sim-racing are not exceptions.

One of the best ways to analyse and understand whether your own and your vehicle’s behaviour is good or not is the same used by all kinds of racing
teams: telemetry.

,.bkvjhdhfgd yeeeeeahh

Fig. – The telemetry interface of the MoTeC i2 Pro software with data taken directly from an AC race session.

12.4.1 – WHAT IS TELEMETRY

The level of technology that today's motorsport world has reached means that engineers, technicians, drivers, insiders and even fans are increasingly talking
about telemetry. All the data that a racing car is able to generate on the track is meticulously analysed by professionals to find those precious tenths of a
second that make the difference between winning a race... and finishing behind your opponent.

All of this, of course, has also become an integral part of the world of sim-racing, where the quest for performance is now closely linked not only to driving
precision, but also to the meticulousness with which the data collected from a training session on the (virtual) track is studied and interpreted. At this point,
therefore, curiosity reigns supreme: what is telemetry really? How does it work? What is its history?

Let's start this new journey by answering the first question: what is telemetry?

In a nutshell, this term identifies a system capable of collecting remotely a whole series of data (physical quantities) on a racing car that track engineers then
analyse in detail. This ranges from speed to the G-force experienced between corners and acceleration, from the travel of the gas and brake pedals to the
temperature of each individual tyre, from the steering angle to the presence of oversteer or understeer in a given part of the circuit.

The stopwatch can be considered the first rudimental form of telemetry: you’re measuring the time taken to complete each lap on a circuit.

The purposes of telemetry are multiple: on the one hand, the data collected during a track session serves to constantly monitor the various parameters of the
car in order to consolidate the reliability of its components. On the other hand, telemetry is used as a valuable tool to analyse in detail the performance of the
car-driver system from lap to lap, or to compare the performance of a driver with an opponent or, more frequently, with his teammate.

Generally speaking, telemetry is used in every series that makes up the world of motorsport: from karts (in a simplified way) to GT, from prototype categories
to single-seaters... and, of course, Formula 1.

Over the course of time, the top championship series has always been used as a testing ground for various mechanical, electronic and aerodynamic
solutions that have subsequently found their way into other series or the automotive world. Just think, for example, of traction control or, more recently,
energy recovery under braking, today the cornerstone of the most important electric and hybrid cars.

492
Telemetry, in this case, has not been outdone: it was introduced in Formula 1 towards the end of the 1980s and since then has been developed hand in
hand with electronic driving aid systems, permitted and then banned several times over the course of the various seasons. Its use was initially mono-
directional and the sole responsibility of the driver, who could make certain adjustments (such as braking distribution or engine power level) via the 'knobs'
and 'selectors' on the steering wheel.

Then, at the beginning of the 2000s, the FIA allowed the use of bi-directional telemetry: instead of the driver, at that time it was the engineers from the pits
who controlled the various parameters of the single-seater, varying what was most needed depending on the situation on the track. In this way the driver
could concentrate solely on driving, having at his disposal a car that, theoretically, was practically perfect in every sector of the track.

Just as happened in 1993 with Alain Prost's Williams-Renault FW15C and later in 1994 with Michael Schumacher's Benetton-Renault B194, which were
challenged for all those electronic aids that gave them a considerable advantage over their rivals, in 2003 the Federation backtracked and banned bi-
directional telemetry, once again bringing into focus the importance of the driver as the sole protagonist of his own performance on the track.

Today, telemetry, therefore, has become a very powerful tool with which Formula 1 teams keep an eye on what is happening on their single-seaters, sending
all the relevant communications to the driver on what to change on the wheel in order to be competitive in every corner and sector of a circuit.

12.4.2 – HOW DOES TELEMETRY WORK

Always taking the top series as a reference, each Formula 1 car is equipped with a special data collection unit, which is connected to a series of sensors
located on the various components of the car itself: engine/power unit, tyres, gearbox, suspension, pedals, front and rear wing and many others.

On each lap of the track, such a car is able to collect up to 35 megabytes of data through its sensors, totalling around 30 gigabytes of information over the
course of a single race weekend. The sensors, specifically, analyse various physical parameters of the single-seater in real time, which are then transmitted
to the control unit which, in turn, sends them to the track engineers' computers via the antenna positioned on the front nose, or using the various
transmitters located in specific parts of each circuit on the calendar.

At this point, the pit wall has received all the data in question in real time, suitably encrypted and ready to be analysed. (one of) The software used to
interpret them is currently developed and supplied by McLaren Applied Technologies and is called ATLAS, which stands for Advanced Telemetry Linked
Acquisition System (Fig.).

Fig. – The ATLAS Express software in all of its glory.

On a practical level, this programme looks very much like an Excel worksheet, containing a series of tables and graphs showing the parameters collected by
the sensors on the single-seater.

493
But what are the parameters that the engineers of an F1 team are constantly analysing on a single-seater? Through ATLAS, the values that are kept under
observation approach a thousand and require up to a hundred people, either directly on the track or 'remotely', to monitor them effectively and efficiently.
This is, of course, a choice, because it would be impossible to monitor, moment by moment and during the entire race weekend, all the parameters of such
a racing car.

Usually the telemetry parameters are obtained through a very precise sampling frequency: those of the transmission, for example, are obtained at a cyclic
rate of 200 Hz, so the data is acquired two hundred times per second. In the case of unusual vibrations that may lead to possible malfunctions, however, the
frequency is increased to 10 kHz in order to achieve even higher sampling accuracy.

The most common parameters that are monitored through telemetry systems are as follows:

• Speed
• Engine revs
• Steering angle
• Brake pressure (front and rear)
• Braking distribution
• Throttle use
• Engaged gear
• Level of understeer/oversteer
• Inflation pressure of each individual tyre
• Operating temperature of each individual tyre (inner, outer and middle)
• Lateral and longitudinal G-force
• Hydraulic system pressure
• Internal engine temperature
• Engine mapping (ERS)
• Aerodynamic load (downforce)
• Number of revolutions
• Fuel load
• Delta last lap
• Use of DRS
• Wind incidence (speed and direction)
• Plank load cell: any contact of the wooden skid on the bottom of the car with the ground

On every Formula 1 race weekend, therefore, a single-seater is constantly monitored in all its parts: specific engineers study a specific component and
communicate any anomalies and useful information to the track engineer in order to improve performance on the track. In all of this, however, the difference
is still the driver's job: he too has the ATLAS software at his disposal and can present his requests and feelings to his engineer, so that he can solve, for
example, understeer in a corner or perfect the car's entry in another part of the circuit.

The gyroscopes, accelerometers and all the sensors with which a racing car is equipped, in fact, are only able to detect data, but are not currently capable of
assessing whether what they have acquired is a parameter that goes in the direction of maximum lap performance or not. The values for understeer and
oversteer, for example, are an end in themselves and cannot simultaneously communicate whether these effects contribute to the correct handling of the car
on the track.

This evaluation is the task first of the engineers, then of the track engineer and, finally, of the driver, the true protagonist of this system who, with his
feedback, will be able to indicate to his technician the sensation perceived in that specific part of the circuit. His contribution, therefore, is still decisive not
only in Formula 1, but in general throughout the world of motorsport. As well as in that of sim-racing, which today offers specific tools to be able to
meticulously analyse the most important parameters of one's favourite car, especially within AC.

12.4.3 - REAL LIFE VS SIMULATED TELEMETRY

Race car data acquisition used to be limited to well-funded teams in high-profile championships. Nowadays, the cost of electronics has decreased
dramatically, making them available to everyone. But the cost of any data acquisition system is a waste of money if the recorded data is not interpreted
correctly.

Whether measuring the performance of a Formula One vehicle or a road-legal street car on the local drag strip, the dynamics of vehicles and their drivers
remain nearly the same. Almost identical analysis techniques apply.

In the real-word, the sensing and measuring of information happens at some remote location and then that information is transmitted to a central or host
location. There, it can be monitored and used to control a process at the remote site (Fig.).

494
Fig. – This is the block schematic of a basic real-world telemetry system. In a simulator (in our case AC), both ends are at the same place.

Purpose and function(s) of each of building-block or element of the system shown in Fig. are briefly described below:

1. Transducer or Sensor: Converts the physical variable to be telemetered (that is, the measurand) into an electrical quantity. This quantity in most cases
is either an electrical parameter (variable resistance, inductance or capacitance) or an electrical signal (voltage or current).
2. Signal Conditioner #1: Converts the electrical output (which may or may not be a signal, as explained above) of the transducer (or sensor) into an
electrical signal compatible with the next element, i.e. the transmitter. The incompatibility could be either in the form (such as parameter versus signal,
voltage versus current, analog versus digital, etc) or in the magnitude of the signal (that is, it is too weak to be used by the next element).
3. Transmitter: Its purpose is to transmit the information signal (a signal containing information, i.e. a signal which is a function of the value of the
measurand) coming from the signal conditioner #1 using a suitable carrier signal to the receiving end. It may perform one or more of the following
functions:
• Modulation: Modulation of a carrier signal by the information signal.
• Amplification: As and if required for the purpose of transmission.
• Signal Conversion: As and if required for the purpose of transmission. For example, voltage to current conversion, or analog to digital
conversion, or electrical signal to radio wave conversion, or electrical signal to optical beam conversion, depending on the nature of the carrier
signal and the signal transmission medium.
• Multiplexing: If more than one physical variables need to be telemetered simultaneously from the same location, then one of the following
multiplexing techniques is used: time-division multiplexing (TDM), frequency-division multiplexing (FDM), and wavelength-division multiplexing
(WDM).
• Signal Transmission Medium: It is the medium or link that connects the sending or transmitting end to the receiving end, over which the
transmitter can transmit its output signal to the receiver. Broadly, there are three signal transmission media in use: copper wires, radio link, and
optical fibre.
4. Receiver: Its purpose is to receive the signal(s) coming from the transmitter (located at the sending end of the telemetry system) via the signal
transmission medium and recover the information from the same. It may perform one or more of the following functions:
• Amplification: Amplification of the received signal as and if required for the purpose of further processing.
• Demodulation: Demodulation of the received signal to recover information signal. The demodulation process has to be complementary of the
modulation performed by the transmitter.
• Reverse Signal Conversion: This conversion is generally the reverse of the conversion performed by the transmitter. Thus the receiver is required
to perform current to voltage conversion, or digital to analog conversion, or radio wave to electrical signal conversion, or optical beam to
electrical signal conversion, depending on the nature of the carrier signal and the signal transmission medium.
• De-multiplexing: It refers to the process of segregating or separating various information signals so that they can be delivered to their respective
end devices. The process in the receiver has to be essentially the reverse of the multiplexing carried out by the transmitter.
5. Signal Conditioner #2: Processes the receiver output as necessary to make it suitable to drive the given end device
6. End Device: The element is so called because it appears at the end of the system. Depending on the purpose of the telemetry in the given application,
the end device may be performing one of the following functions:
• Analog Indication: Analog indication of the value of the measurand through the deflection of a pointer on a scale. The device used is very often a
permanent magnet moving coil (PMMC) meter.
• Digital Display: Digital display of the value of the measurand on LEDs, LCD, monitor screen etc.
• Digital Storage: Storage of the digital value of the measurand in electronic or optical storage device for a later use.
• Data Processing: The digital values of the mesurand may be given to a data processor, such as a microprocessor, digital signal processor or
computer, for analysis etc.

495
Various mediums or methods of transmitting data from one site to another have been used. Data radio provides a wireless method for transmitting the
information. Telemetry using radio waves or wireless offers several distinct advantages over other transmission methods. Some of these advantages are:

• No transmission lines to be cut or broken

• Faster response time
• Lower cost compared to leased lines
• Ease of use in remote areas where it is not practical or possible to use wire or coaxial cables
• Easy relocation
• Functional over a wide range of operating conditions
• Properly designed radio links can provide low cost, effective and flexible data gathering systems that operate for many years with very little
maintenance.

At the remote site, a sensor or sensors are typically the data source. The output of the sensor(s) is converted to digital data by a small computer device or
RTU (Remote Terminal Unit). The RTU is interfaced to a modem device that converts the digital data into an analog signal that can be transmitted over the
air. The radio transmitter then transmits the signal to the host site radio receiver. Now the process is reversed. The modem takes the analog signal received
and converts it back to a digital form that can be processed by the data recovery equipment.

In a typical application, the base or host site requests data from the remote site(s). The base transmits a request to the remote unit telling it to send its data.
The base reverts to a receive mode and awaits the transmission from the remote site. After the remote sends its data, it goes back to a receive mode waiting
for further instructions to come from the base. Once the base receives the remote site information, it may send additional instructions to that site or continue
on to request data from the next remote site. This polling process continues until all the remotes in the system have sent their data.

Telemetry radio systems are normally configured as a fixed base station that obtains information from another fixed station at a remote site. The FCC has
allocated certain frequencies that can be used for fixed operation. There are certain frequencies available in the VHF band (150-174 MHz), UHF band (450-
470 MHz) and 900 MHz band (928-960 MHz) for this type of operation.

WIP

Our main advantage using sims is that we ignore completely FM signals and the testing/troubleshooting of sensors in the different parts of the vehicle.

WIP

12.4.4 - THE IN-GAME AC TELEMETRY

We’re going into the details of what the simulation world offers: the current technology allows us to use a professional software tool like MoTeC i2 Pro,
which has also been used for years in real motorsport series. However, to begin understanding the graphs that characterise telemetry, let’s analyse two laps
on the Imola circuit (Fig.) with the Ferrari F2004, on the AC interface.

Fig. – Personally I love this circuit. It was really dangerous back in the 80s and 90s though, especially the first curves, which over time have been split into three corners, especially
after many deaths of pilots and the infamous 1994 Grand Prix, where Roland Ratzenberger and Ayrton Senna died (and that changed the motorsport world forever).

In our simulator’s GUI there is a simplified version of the telemetry graphs that we will be analysing soon with MoTeC (Fig.). This tool, although basic, will
allow us to interpret the values provided by the most important parameters of our vehicle, including the pressure we exerted on the brake pedal, the use of
the accelerator and the speed we maintained.
496
Fig. – The basic telemetry interface incorporated in the AC UI.

The analysis of speed

Let’s begin our analysis with the fundamental parameter that underlies telemetry systems: the speed that our Ferrari reached during the two laps, bearing in
mind that the vehicle in question had the basic setup, except for the seventh gear (one step longer), fuel at minimum and Medium tires.

Past the initial straight we are faced with the first challenge of the Imola circuit: the Tamburello variant. Here our reference is the 100-meter sign, which
imposes a strong braking during which we’re going to downshift four gears. The maximum speed reached in the best lap (in RED) and slowest lap (in
WHITE) is 319 km/h, which can be seen by placing the mouse pointer just before the moment when we hit the brakes (Fig. A). Then the speed decreases
dramatically and rises again near the Villeneuve variant.

Fig. -

497
On entry we reached 293 km/h in each hotlap, and, as can be seen from the graph, our speed remained similar on both laps even at Tosa, the Imola hairpin
bend: near its braking point there was a slight 3 km/h gap in favour of the slower lap (Fig. B), due to the fact that we braked more gently and with less
intensity than on our fastest lap.

The first major difference that consistently influenced the 305-thousandths delta between the two laps, however, we found as we exited Piratella, the drop-off
that then leads towards Acque Minerali. On our best lap we braked harder and released the brakes earlier than on our second attempt, which allowed us to
project into the next part of the track with a speed of 203 km/h (Fig. C).

On the lap marked in white, however, the exit speed is 195 km/h, almost ten less: this gap significantly affected our performance at Acque Minerali, where
on entry we reached 291 km/h vs 288 on the slower lap (Fig. D).

Also different was the exit from the second corner of Acque Minerali, 125 km/h vs 121, as well as the braking at the Variante Alta, where the performance
gap between the two laps materialized in 2 km/h (Fig. E). The last sector, on the other hand, showed no particular differences, despite a quite different use of
accelerator and brake between the two laps.

The analysis of the brake pedal

Let's move on to analyse the use of the brakes: looking at the screenshot below, we can see that on our best lap we maximized the potential of our F2004's
pedal in the first corner, pressing hard and then gradually releasing the pressure by taking advantage of the "trail braking" technique. In the slowest lap, on
the other hand, we had an initial uncertainty and then reached 85% braking force relatively late: this affected the exit from Tamburello, because if we pay
attention, we can see that the red line, related to our hotlap, first reaches the exit speed (equal to 152 km/h) and then resumes in the direction of the
Villeneuve variant (Fig. A).

Fig. -

At the Villeneuve variant our best performance is marked by 30% braking on entry compared to 19% on the second lap (Fig. B) and 44% braking on the
change of direction (compared to 31% on the second lap), leading towards Tosa (Fig. C). At the hairpin we basically repeated the same script as in the first
variant: on entry we reached 70% braking power in our best hotlap, which we then gradually released by taking advantage of trail braking. In the second
hotlap, however, there is a step from 28% braking power to 67% (Fig. D), which was reached late in the first lap: this caused a delay when it was time to
take the throttle back in hand, resulting in a widening of the ideal trajectory in the next straight towards Piratella.

It is at Acque Minerali, however, that we notice a marked difference in the use of the brake pedal: on our best lap we got to the right pressure of 42% right
away, while on our slowest one we "messed up" on entry and then too gradually (and inevitably late) got to an even lower pressure of 36% (Fig. E), then
rose noticeably to 44% when, on our other attempt, we were already letting off the brakes and letting our Ferrari slide (Fig. F).

Very similar was our behaviour at the braking of the Variante Alta: on both laps we pressed the brake pedal to 70%, and then gradually released it so that the
single-seater entered the change of direction firmly. At Rivazza, on the contrary, we got on the brakes early in our worst hotlap, with 70% pressure (Fig. G);
In our hotlap, on the other hand, we disconnected later and with a slightly higher intensity of 76 percent.

498
The analysis of the accelerator pedal
It only remains for us to go over the use of the gas pedal, mainly when exiting the various corners that distinguish the Imola Autodrome. At Tamburello,
because of the mistake made on the second flying lap, we were back on the throttle late, with an intensity of 48%: at this point, however, we were already at
66% of the pedal in our best attempt (Fig. A).

Fig. -

At the Tosa braking, then, another gap can be seen: on our best lap we released the throttle early, at 26% versus 64% on our worst attempt (Fig. B). Having
"messed around" with the brake, however, did not help us come out strong enough towards Piratella, where another big difference can be seen. The higher
speed maintained in this section of the track allowed us to get on the gas pedal sooner, with a 78% better throttle pressure on our hotlap than the 26% we
experienced in our second attempt (Fig. C).

At Acque Minerali we notice another difference in our use of the throttle: the red line shows an early release of the relevant pedal, which we then recalled
briefly before attaching to the brakes. If we look at the white line, on the other hand, we can see that we "held down" longer (albeit slightly) and released the
pedal more firmly ... only to make a mistake in going for the right brake pedal pressure. So the behaviour we kept on our best lap rewarded us: even on the
exit to the Variante Alta, where we were able to accelerate more effectively since we were on the gas already at 72% vs the absolute zero of our worst attempt
(Fig. D).

The last point to emphasize is what happened at the Rivazza braking: in our best hotlap we arrived on the brakes later, maintaining maximum throttle travel
for a longer time than in our worst hotlap. Here, in fact, we released the pedal earlier (30% intensity) to anticipate braking, but this did not allow us to gain
anything once we passed under the checkered flag (Fig. E).

Conclusions
We have come to the end of this installment: we have seen what is offered by the software present in Assetto Corsa, which provides us with a very basic but,
at the same time, important analysis to understand the fundamentals of telemetry systems. The graphs we studied show lines that oscillate up and down and
can be observed simply by hovering over them with the mouse pointer. This way we discover the value of a given parameter at that precise point on the
track, which can be compared at the same time with another value belonging to a second lap taken as a cue to compare our performance.

The comparison between one hotlap and another represents the ultimate purpose of telemetry in terms of performance: we can figure out at what point and
with what braking pressure it is most appropriate to break off on corner entry, and then identify the best time and level of intensity to get back on the gas on
exit. In addition to this, telemetry provides us with the indispensable speed graph, with which we can note the most important differences between one of
our launched laps and our best attempt ever between the curbs.

Putting together everything good that was done in our two hotlaps we would get the "perfect lap" on the Imola Autodrome, again keeping in mind the
conditions we used to perform this test. Because the goal of telemetry, after all, is just that: to go in search of the best possible result, taking into account
even individual thousandths of a second. In the next paragraph, the work we did with AC will take a different and more professional turn: it's time to move
onto the ACTI and MoTec!

499
12.4.5 – THE AC TELEMETRY INTERFACE (ACTI)
ACTI is a standalone client that together with an in-game app allows live access to and recording of Assetto Corsa telemetry data. Some of its key features
are:

• Record telemetry data in Motec i2 compatible log files (i2 v1.0.21.30 currently supported).
• View live telemetry data in user-configurable workspaces.
• Remote telemetry access (recording / viewing live data from a friend / teammate located anywhere in the world while they are on track).
• Easy in-game control over telemetry acquisition.

The complete ACTI tool package can be found right here. Included in the package are:

• The acti client.

• The in-game acti trigger control app.
• Motec i2 installer.
• Sample Motec i2 Project based on the data channels currently available from Assetto Corsa.

JKHLKJH

WIP

12.4.6 - IN-DEPTH ANALYSIS OF TELEMETRY DATA (WIP)

Much of the workload for the data acquisition engineer consists of comparative analysis. Comparing data from different laps or runs with previously collected
data reveals the effect of setup changes or driver performance. Most data analysis packages offer similar techniques for comparing different data sets. This
paragraph covers these techniques and provides a basic interpretation of the patterns showing up in the sensor signals most often used.

Obviously some of the real-word details you’ll see here aren’t present in AC, since there aren’t actual “sensors” in a simulation. However they may be
interesting, especially for curious people.

1 - Lap Markers and Segment Times

Performance analysis usually begins with figuring out where on the track time is gained or lost before actual events are investigated. A quick way to assess
this is to investigate lap segment times.
Lap times are determined by the analysis software measuring the time it takes for the car to pass the lap beacon. This beacon represents the location on the
track where a lap ends and the next one begins. It can be an infrared pulse logged by the data system or a manually entered beacon point in the data. Most
data analysis packages offer the option of placing additional virtual beacons around the track at certain distances from the start/finish beacon. Lap segment
times are determined by measuring the elapsed time between two consecutive beacons. Placement of these beacons depends on what needs to be analyzed.

Engine performance can be evaluated best on a straight track segment where the car is accelerating. Corners can be defined as separate segments, but the
corner itself can also be divided into entry, apex, and exit to investigate cornering performance.

WIP

Great care should be taken in placing importance on the theoretical fastest lap because a slower time in one segment can result in a faster time in the next.
The driver may take a driving line through one corner that is faster in the particular corner but compromises speed in the next one. Missing braking points
also can cause inconsistent segment times.

The confidence level of this performance indicator also depends on the location of the segment beacons. Segment times in areas bordered by beacons
placed at the apex of a corner are more sensitive to inconsistencies than those bordered by beacons placed at the middle of a straight.

The fastest rolling lap is the lap time achieved between beacons that are not necessarily at the end of a lap—an indication of the performance potential when
there is heavy traffic on the track. It is a lap time the driver actually achieves.

WIP

Another issue that requires attention when calculating the theoretical fastest lap is thenumber of track segments. The more track segments incorporated, the
faster the ideal lap is. There must be an optimum number of segments that provide a realistic theoretical fastest lap. Sound judgment is necessary here, both
in choosing the right number of segments and having confidence in this performance indicator.

2 - Comparing Laps

500
The most powerful tool in any data acquisition software package is overlaying and comparing different laps. Most analyses performed on race car data are
comparative. When something is changed on the car, comparing a run to previous ones indicates the difference of that change.

By overlaying two traces as a function of distance, the performance of the vehicle and the driver can be compared at the same point on the track. Overlaying
against time does not bring any meaningful conclusions because events at the same time probably happen at other locations, and the traces tend to diverge
over the length of the lap.

WIP

3 - Track Mapping

Track maps are graphical representations of the location at which logged data was recorded. It is a helpful software feature for lap navigation and a visual aid
for drivers and engineers that can be used while analysing the data. To draw a track map, three signals should be present: wheel speed, lateral acceleration,
and a lap beacon. Wheel speed integration gives the covered distance; combined with lateral acceleration, the heading of the vehicle can be calculated. The
lap beacon indicates the start and finish point of the lap. This technique is called inertial mapping.

It is, however, just a graphical representation of the racetrack and has its limitations.

4 - The beginner’s data logging

Any data logging system intended for the analysis of race car and driver performance should log at least the six basic signals: engine RPM, vehicle speed,
throttle position, steering angle, and lateral and longitudinal acceleration. These signals already contain a vast amount of information to analyse. Even in a
state-of-the-art data acquisition package with numerous sensors, these six signals remain the most important and most used data resource for the engineer.
The next logical step is to add suspensions to the system. In this section, the traces created by these sensor signals are explored and a feel for reading the
graphs developed.

4.1 - Logging Engine RPM

Engine RPM often is recorded from a magnetic sensor placed near a teethed trigger wheel on the engine’s crankshaft. This sensor counts the pulses
generated by this trigger wheel and converts them into the number of crankshaft revolutions per unit of time.

4.2 - Logging Vehicle Speed

The speed trace is the results graph. It is the best way to conclude if a change on the car or in driving style produced any result. This is the reason why
most analysis work is done with the speed graph as a reference. It is also the easiest trace to use for track navigation. Because this graph represents a
typical layout of each track (indicating corners between acceleration and deceleration zones) and the signal is used so much in analysis work, an
experienced data engineer looks more closely at the speed trace rather than at a track map to find a location on the track.

4.3 - Logging Throttle Position

The throttle position signal measures what the driver is doing with his right foot on the accelerator pedal. Throttle position usually is expressed as a
percentage, with zero percent meaning the driver is completely off the accelerator pedal and 100% equaling full throttle.

4.4 - Logging Steering Angle

As with throttle position, steering angle is a driver activity channel. It records the angle at which the steering wheel is turned and, just like throttle position, is
an invaluable diagnostic tool. Steering angle can be expressed as degrees turned by the steering wheel, spindle, or rim, as well as steering rack travel in
millimeters.

4.5 - Logging Lateral Acceleration

Lateral g-force is the channel logged as the acceleration perpendicular to the car’s centerline, and strictly speaking it measures cornering force. This channel
usually is displayed in units of g-forces (1 G = 9.81 m/s2).

4.6 - Logging Longitudinal Acceleration

Longitudinal g-force is the acceleration logged along an axis parallel to the car’s centerline (i.e., perpendicular to the lateral g-force). It is basically the
acceleration created by the engine’s power or the deceleration due to application of the brakes. A positive value is used for acceleration. For deceleration, the
sign for the longitudinal g-force is negative.

Longitudinal acceleration displayed with lateral g-forces in an X-Y graph forms the popular traction circle, a useful visualization technique illustrating how the
potential of the tires is used.

WIP

4.7 - Logging Suspension Travel

501
The six basic signals covered in the previous sections already give the engineer a significant amount of information about chassis and driver performance.
Equipping the vehicle with four suspension travel sensors helps in further diagnosing vehicle dynamics. Because suspension travel is used extensively in
the following chapters in mathematical channels, a review of basic properties of the signal is needed.

Suspension movement typically is measured as shock absorber displacement. With this signal, a sign convention and a short explanation of nomenclature is
necessary. (move it to suspensions.ini?) All ingoing shock travel from static ride height is considered positive. When the wheel goes up relative to the
chassis, the sensor signal has a positive sign. This motion is called bump. The opposite is true for all outgoing shock travel from static ride height. This is
called droop (Fig.). Shock absorber specialists use the names bump and rebound, but this actually refers to the gradient of the sensor signal. A positive
gradient (ingoing shock travel, regardless of static position) is called bump travel, while a negative gradient (outgoing shock travel, regardless of static
position) is referred to as rebound travel.

Fig. -

There are two different categories of suspension movement:

1. Low-speed movement
This includes the suspension movement in response to chassis attitude changes due to weight transfer (pitch and roll) and to the varying aerodynamic
loads at different speeds.

2. High-speed movement
The suspension movement induced by road irregularities and curbs takes place at a higher frequency than the low-speed movement.
Remember that suspension travel is being measured here, not wheel travel (Fig.).

Fig. - Suspension travel versus wheel travel.

When the motion ratio of the suspension is known, wheel travel can be calculated from the suspension travel signal using equation ()
∆𝑥𝑥𝑤𝑤
𝑀𝑀𝑀𝑀 =
∆𝑥𝑥𝑠𝑠

where MR = motion ratio, ∆𝑥𝑥𝑤𝑤 = wheel movement, ∆𝑥𝑥𝑠𝑠 = suspension movement.

WIP

502