AN A&M POOR MAN’S PRODUCTION PRESENTS

the
ASSETTO CORSA MODDING
MANUAL 3.0 by A&M
1
WRITTEN BY
A&M

CONTENT BY
A&M, Kunos developers & OTHERS

(credits at the end)

AN A&M POOR MAN’S PRODUCTION

Edition 0.27 pre-alpha Revision H

2022 | 2023

© 2023 A&M. All rights reserved.

2
 To all Modders and Kunos developers

I hope AC2 will be compatible with the AC engine, the official content, the mods and the amazing projects users and communities brought to this simulator.
Imagine driving the Bizzarrini GT 5300, the true heir of the Ferrari 250 GTO, on the 1970 Le Mans, in a physics engine with an improved tyre model, dynamic weather, more realistic damage with glass shards and
metal chips, oil on the track, exploding tyres and vehicles with more than four wheels.
I’m not interested in a career path with driving licences and shiny trophies. I want to feel the thin, rubbery line of death. Modders raised the bar pretty high with AC, which now already looks like a gorgeous next-
gen title, even though it was born to be a simulator, not a game, always remember that.
Obviously AC will always be the best game I’ve ever played.
A&M
3
Preface

This manual is meant to be read in its entirety, more like a book than a “guide”, even if it aspires to become the latter. I think that whenever
you’re doing something in your life you should be aware of the full picture, otherwise your objective is missing. We tend to forget that every
part is connected to the others, and that’s where this work of mine comes in handy. It’s a collection (mind me the word) of information, well
organized, or at least organized the best way I could think of. But it follows a path, hopefully as linear as possible. The beginning will be (or
seem) simple, and going further and further our magnifying lens will be more and more focused on the details that the common user ignores
and doesn’t need.

I also wouldn’t recommend printing this text, as to make the huge amount of info fit into a smaller number of pages I often used very small
fonts, which would become unreadable on a piece of paper. My suggestion is to read it like an ebook, on your PC or your tablet, where you
can zoom the pages to your liking.

The main purpose of this document is to revise and expand the old “car Pipeline 2.0 ” made by Kunos, the creators of the Assetto Corsa
simulator, for a better clarification and explanation of all the procedures needed to make car and track mods for AC (latest release 1.16.4,
Ultimate Edition) from scratch, or with a conversion.

A brand-new track creation guide, with some help, will be produced for the first time. Also, a brief game user manual is being written and
expanded. I really hope this will be, if not the best, at least the most complete and organic guide to AC and its modding ever made.

I know that the popular AC Custom Shaders Patch mod exists. But I don’t know if I will include it. Being that project currently under
development it would be a bit difficult to keep track of everything. I might change my mind about this.

If you have any suggestion, find errors or have extra content that can be added, contact me with this email:
assettocorsathemanual@gmail.com (for serious purposes only), or comment under this resource on the main website:
https://assettocorsathemanual.blogspot.com/

This project is currently in a WIP (Work-In-Progress) state, therefore it’s subject to changes. Any image, sentence, or paragraph is being
added, written down, revised, expanded or shortened, corrected and sometimes deleted, just like pencil on sheets of paper.
Highlighted text consists of reminders for me, or parts that are going to be modified soon; please don’t judge the micro-chaos of the
document. Do not rely too much on the cross-references to pages, sections, chapters, or paragraphs, in many cases they may be wrong or in
the process of being written!

I’d like to quote the following message here:

“Because my books are self-published, I am the researcher, the author, the proofreader, the editor, the typesetter, the illustrator, and the
publisher. To add to my struggles, English is not my mother tongue. As such, grammatical, typographical, and other forms of errors may seep
in, at places. For that, I apologise ahead of time. It is difficult to insert new text into a book this size, without also injecting minor editorial
errors, here and there. In order to reduce the entropy, I re-edit the entire text, regularly. But if you do find errors, drop me a line. […]

I do not write books like this one to make a living; I make my living by other means, so that I could have the spare time to write such books.
And I write not because I believe I have some special knowledge to impart, but because I enjoy sharing with others what little I know. […]
Teaching gives me the opportunity to probe deeper into the subjects and to fill holes in my own understanding thereof. And sharing ideas and
knowledge invigorates me. So, there you have it.” – Amen Zwa, Going Nowhere Fast in Assetto Corsa

Yours,

A&M

4
 HOW TO READ THIS MANUAL

You don’t have to teach us how to read.

I know, but when I was a high school student and even before, whenever I read a textbook I used to take notes, underline the most important parts to
remember them the day after, when I’d have had the test, which was always too late. But that’s enough about me, times change.

If you don’t take notes, someone else has to do the work for you, to make things easier (and to guarantee that you pass your exams). That’s why I adopted a
system to organize and highlight ideas, keywords and concepts. I find it quite efficient and effective, especially if you give yourself enough time to read the
entire work.

First of all, this book is split in four parts: PART 1 is a general manual about Assetto Corsa, PART 2 is about the creation of cars, PART 3 is about tracks,
PART 4 is CLASSIFIED. It’s truly simple. I might add more of them, but that is at my discretion.

Second, each PART is divided into Chapters. They’re numbered, and they constitute for the reader the logical handrail to follow. There is no doubt about it;
if you skip a Chapter, you will not be able to move forward and you will be stuck there, unless it consists of things you already know. This is because they
don’t represent only steps in a process, but more so in that they are interdependent.

Third, every Chapter has got several main Paragraphs. Sometimes you can follow them, sometimes you don’t need to. Their purpose is to introduce,
contextualize and define more specific information handled within them. They’ve got numbers too so you don’t get lost.

Finally, you have the little ones, the Paragraphs. Keep an eye on them, they can get quite beefy. Important stuff, stuff you shouldn’t ignore, stuff you forgot,
stuff you hid from yourself: there’s plenty here.

And what about paragraphs without numbers? Can I say those exist because I can’t really justify the use of four digits to enumerate them? To be fair, once
you start reading a Paragraph, everything should have the same importance. So their purpose is only to make things more clean, fresh, “cool”, like everyone
would their manuals to be like. I’m joking, however they’re not pointless.

Following this structure, you will often find colours, underlined or bold text. Let’s discover their meaning:

 A bold, dark blue colour text is adopted for file paths and folders (in the field of computer science), for example: %root%\assettocorsa\_CommonRedist
 Filenames will usually be red italic text. Example: suspensions.ini
 If there is something really important, you will see red bold text. If there is a key word, it will be black, to make it more visible:

“ The AC engine does not support 2 OBJECTS with the same NAME in the same model ”.

The colours will be inverted if the whole sentence is less important, but we want the key word to be highlighted anyway:

“ In order to have a working car mod, this folder and its contents are REQUIRED ”.

 Bold text of any colour is also used to distinguish the various items in particularly long lists of things. You can already see examples in the GLOSSARY.
 When you encounter magenta italic text it means that’s my personal, biased comment. After all, this book should be fun to some extent, right?
 Every picture (figure) in this manual is numbered (aside from covers and photo albums), following this example: Fig. 1.2. This will be its cross-reference
too. There will always be captions under the images, no matter how short and concise.
 Scattered throughout the document there are little Pro tips: their function is to
 Often you will find sections with the title FAQ. This stands for Frequently Asked Questions. Here you will get answers to questions you may have. They’re
VERY useful.
 asasf

Makes you a better person, doesn’t it?

WIP

5
 ABBREVIATIONS - GLOSSARY
These definitions are simplified and will give you only a general understanding of what we’re talking about.

AC: Stands for Assetto Corsa, your racing simulator.

Active Suspension: Electronic-controlled method of automatically pitching the suspension for specific track bends or terrains (the latter for road vehicles).

Aerodynamics: The study of forces that come into play when the car has picked up speed, due to air.

Angle of Slip: The angle between the direction of the wheels (front and rear) and the direction of travel of the vehicle.

Anti-Roll Bar (ARB): Forms part of the suspension assembly and helps to support the car when cornering, by resisting the tendency for the body to roll.

Apex or Clipping Point: The nearest point a car gets to the inside of a curve in an ideal racing line.

API: An Application Programming Interface is a way for two or more computer programs to communicate with each other. It is a type of software interface,
offering a service to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API
specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the
implementation.

In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to
each other. It is not intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into the software. An
API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of
these parts is said to call that portion of the API. The calls that make up the API are also known as subroutines, methods, requests, or endpoints. An API
specification defines these calls, meaning that it explains how to use or implement them.

One purpose of APIs is to hide the internal details of how a system works, exposing only those parts a programmer will find useful and keeping them
consistent even if the internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing
interoperability among many systems.

The term API is often used to refer to web APIs, which allow communication between computers that are joined by the internet. There are also APIs for
programming languages, software libraries, computer operating systems, and computer hardware.

Balance: The degree to which a car has understeer or oversteer in a corner.

Brake Balance: The bias of braking power between the front and rear tyres.

Braking Distance: The distance between the point where braking starts and ends.

Bug (software) / Buggy / Debugging: It is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an
incorrect or unexpected result, or to behave in unintended ways. It can be caused by a particular asset (in AC for example cars and tracks).

Bugs in software can arise from mistakes made in interpreting users' requirements, planning a program's design, writing its source code, and from
interaction with humans, hardware and programs, such as operating systems or libraries.

A program with many, or serious, bugs is often described as buggy.

The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the
computer, or causing damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls
in order to obtain unauthorized privileges. Some software bugs have been linked to disasters.

The process of finding and correcting bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs.

Bump Damper: An energy absorbing device, fitted between the wheel and car body, which resists upward movement by the wheel.

Camber: Slight upward curve to the centre of race track.

Camber Angle: Camber angle is designed to make a tyre work as effectively as possible when a car is going through a corner. Negative camber is applied
so that when fully stressed a tyre will be as close to perpendicular as possible.

Castor Angle: Castor gives greater responsiveness and stability to the front wheels. The larger the castor angle, the heavier the steering and more stable the
front end.

Centre of Gravity (CG or CoG): The position within the car around which all the mass is gathered. The lower the centre of gravity, the greater the downforce.

CG: Computer graphics deals with generating images with the aid of computers. Today, computer graphics is a core technology in digital photography, film,
video games, cell phone and computer display, and many specialized applications. A great deal of specialized hardware and software has been developed,
with the displays of most devices being driven by computer graphics hardware. It is a vast and recently developed area of computer science. The phrase

6
was coined in 1960 by computer graphics researchers Verne Hudson and William Fetter of Boeing. It is often abbreviated as CG, or typically in the context
of film as computer generated imagery (CGI). The non-artistic aspects of computer graphics are the subject of computer science research.

Some topics in computer graphics include user interface design, sprite graphics, rendering, ray tracing, geometry processing, computer animation, vector
graphics, 3D modeling, shaders, GPU design, implicit surfaces, visualization, scientific computing, image processing, computational photography, scientific
visualization, computational geometry and computer vision, among others. The overall methodology depends heavily on the underlying sciences of
geometry, optics, physics, and perception.

Computer graphics is responsible for displaying art and image data effectively and meaningfully to the consumer. It is also used for processing image data
received from the physical world, such as photo and video content. Computer graphics development has had a significant impact on many types of media
and has revolutionized animation, movies, advertising, video games, in general.

Chicane: A sharp bend that reduces speeds by forcing drivers to drive through in single file.

CM: Content Manager - A 3rd party launcher for Assetto Corsa by Ilja Jusupov (aka x4fab) which you need for an easier modding. The free (Lite) version is
all you need, but if you want some more tools you can buy the Full version for a small price. We will avoid most of the times (if not always) the vanilla AC
launcher (AssettoCorsa.exe), because it takes a lot of time to load, it is not efficient at managing the game contents and it doesn’t let you edit any of them.
Plus a ton of options are missing (especially for mods).

CPU: A Central Processing Unit, also called central processor, main processor or just processor, is the electronic circuitry that executes instructions
comprising a computer program. The CPU performs basic arithmetic, logic, controlling, and input/output (I/O) operations specified by the instructions in the
program. The form, design, and implementation of CPUs have changed over time, but their fundamental operation remains almost unchanged. Principal
components of a CPU include the arithmetic–logic unit (ALU) that performs arithmetic and logic operations, processor registers that supply operands to the
ALU and store the results of ALU operations, and a control unit that orchestrates the fetching (from memory), decoding and execution of instructions by
directing the coordinated operations of the ALU, registers and other components. Most modern CPUs are implemented on integrated circuit (IC)
microprocessors, with one or more CPUs on a single IC chip. Microprocessor chips with multiple CPUs are multi-core processors.

CSP: Custom Shaders Patch, also known as Shaders Patch or Custom Shaders, it’s a mod by x4fab (aka Ilja Jusupov) that brings a major overhaul of the
AC graphics and enables things such as and rain, more than 1 light source, dynamic weather, among other advanced graphics and physics options. The
mod is meant to work on the latest AC release, 1.16.4.

DLC: Downloadable Content is additional content created for an already released video game, distributed through the Internet by the game's publisher. It
can either be added for no extra cost or it can be a form of video game monetization, enabling the publisher to gain additional revenue from a title after it
has been purchased, often using some type of microtransaction system.

DLC can range from cosmetic content, such as skins, to new in-game content such as characters, levels, modes, and larger expansions that may contain a
mix of such content as a continuation of the base game.

While the Dreamcast was the first home console to support DLC (albeit in a limited form due to hardware and internet connection limitations), Microsoft's
Xbox console and Xbox Live platform helped to popularize the concept. Since the seventh generation of video game consoles, DLC has been a prevalent
feature of most major video game platforms with internet connectivity.

Since the popularization of microtransactions in online distribution platforms such as Steam, the term DLC has become a synonymous for any form of paid
content in video games, regardless of whether or not they constitute the download of new content. Furthermore, this led to the creation of the oxymoronic
term "on-disc DLC" for content included on the game's original files, but locked behind a paywall.

In the case of AC, DLCs are addons made and sold by Kunos on Steam. If you own the Assetto Corsa Ultimate Edition (1.16.4), you will automatically own
all of them.

Damper: Forms part of the suspension system and absorbs the energy that is produced when the spring is compressing or extending. Damper force
increases with speed (heave, roll and pitch velocity).

DirectX / Direct3D: Microsoft DirectX is a collection of APIs for handling tasks related to multimedia, especially game programming and video, on Microsoft
platforms. Originally, the names began with "Direct", such as Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound, and so forth. The name DirectX
was coined as a shorthand term and soon became the name of the collection. When Microsoft later set out to develop a gaming console, the X was used as
the basis of the name Xbox to indicate that the console was based on DirectX technology. The pattern has been continued for Windows APIs such as
Direct2D and DirectWrite.

Direct3D (the 3D graphics API within DirectX) is widely used in the development of video games for Microsoft Windows and the Xbox line of consoles.
Direct3D is also used by other software applications for visualization and graphics tasks such as CAD/CAM engineering. As Direct3D is the most widely
publicized component of DirectX, it is common to see the names "DirectX" and "Direct3D" used interchangeably.

Downforce: The force which pushes the car downward allowing the vehicle to grip the road surface.

Drag: Resistance to forward motion of the car. Can be caused by aerodynamic resistance or mechanical resistance.

Electronic Control Box: Contains, among other information, the Driver aids software and settings, (traction control, active suspension etc.). The Electronic
Control Boxes are frequently inspected by the FIA following a race to test for illegal driving aids being used by constructors.
7
Extension (*.*): kjlj

Here we have some of the most common extensions you may find while modding or reading this manual:

3ds 3D model format used by Autodesk 3D Studio Max lut Assetto Corsa Look-Up-Table, plain text format
7z compressed archive created with 7-zip m4a
acd Assetto Corsa data file mid, midi
ai Assetto Corsa AI (artificial intelligence) file for offline opponents mp3
bank Files created by FMOD containing audio and events for games mp4
csv plain text, comma-separated values file (common with MS Excel) mpeg, mpg digital video file format standardized by the Moving Picture Experts Group
dds raster image saved in the DirectDraw Surface (DDS) container format msi MS-Windows installer package file
dll dynamic-link library, set of procedures executed by a Windows program pdf Adobe Portable Document Format, typically read-only documents
doc, docx png digital raster image similar to JPG but with lossless compression and transparency
exe executable programs in MS-Windows, either applications or installers psd native format used to save files in Adobe Photoshop
fbx rar compressed archive created with WinRar
gif 3D model saved in the Autodesk Filmbox format, often used in games rtf text files including extra info about font style, formatting, images, etc.
htm, html rto Assetto Corsa gear ratio file
ini configuration file used by Windows programs to initialize program settings tmp temporary backup, cache, or other data file created automatically by a software
iso optical disc (i.e, DVD) file format containing an exact copy of the data txt document that contains plain text
jar Java archive (JAR) format, which utilizes Zip-compression vob
jpg, jpeg digital raster image format that features lossy compression wav digital audio file in the WAVE format, storing waveform data
json simple data structures in the JavaScript Object Notation format wma
kn5 Assetto Corsa 3D Object format xls, xlsx
knh zip
ksanim Assetto Corsa animation file (read-only)
log log generated by various programs (here AC) to track system events

FFB: Force Feedback. When referring to sim racing, force feedback is a feature within certain wheels that try to simulate the feel of a real car by making the
wheel react with force and resistance. When driving a real car, the driver can get a sense of the vehicle's grip, any bumps or curbs hit, the feeling of the
road, etc. by using all their senses. For example, you know you hit a pothole because your body can feel the car as it goes through it. But in the virtual
world, there's no real way of feeling that. As a result, a force feedback wheel can react to appeal to your sense of touch and give you more awareness of the
virtual car. A force feedback wheel will, for example, give counter-resistance when turning into a tight corner at high speeds, shake and rumble when your
virtual car hits a curb, goes off-road, hits gravel or sand among many other things for example. All of this is done to not only increase realism and
immersion but most importantly give essential cues to the driver which would otherwise be impossible to feel.

FIA: Federation Internationale de l’Automobile. The motor racing sport’s governing body.

FPS (display): The frame rate (expressed in frames per second) is the frequency (rate) at which consecutive images (frames) are captured, rendered or
displayed. Very simply it is the number of frames you see every second.

The term applies equally to film and video cameras, computer graphics, and motion capture systems. Frame rate may also be called the frame frequency,
and be expressed in hertz. Frame rate in electronic camera specifications may refer to the maximal possible rate, where, in practice, other settings (such as
exposure time) may reduce the frequency to a lower number.

The human visual system can process 10 to 12 images per second and perceive them individually, while higher rates are perceived as motion.

A sufficiently high frame rate on a racing simulator is essential for a smooth, life-like driving experience. A low frame rate interferes with your ability to
control the car smoothly, and thus destroys your sense of immersion. Here is why. When driving a car in real life, your brain is the controller, your body is
the sensor and actuator, the steering wheel and the pedals are the control inputs, and the car is the system under control. Your limbs exert control forces
on the steering wheel and the pedals. Your eyes, your inner ears and your whole body sense the resultant movements of the car. Your brain uses this
feedback information from the sensory organs, and determines the new forces your limbs should exert on the controls.

Similarly, when driving on a simulator, your eyes see a frame that shows the car’s instantaneous location and orientation, your brain computes the new
control forces based on what your eyes saw, your limbs apply these forces to the controller, the simulator moves the car to a new location and orientation in
accordance with the new control inputs, the graphics card generates another frame that reflects the new location and orientation, and the entire feedback
process repeats.

If the frame rate drops well below 30 fps and the transition between two adjacent frames becomes perceptible, your visual feedback system will be thrown
out of kilter. The frame update delay causes your eyes to continue to see the old location and orientation of the car, even after your limbs have exerted the
new control forces. In the real world, the brain is not used to work with delayed feedback, so it misconstrues the lagging visual update as having exerted
insufficient amounts of control forces. Consequently, it commands your limbs to apply more forces. The car has now turned more than necessary. When the
delayed, new frame finally appears, it shows the over corrected new location and orientation of the car. Through the eyes, your brain senses the over-
correction error, and immediately applies a new counter correction. The frame delay, again, fools the brain into making another over correction, but this time
in the opposite direction. The car is now going out of control, weaving left and right.

So, without achieving an adequate frame rate, you cannot drive in a simulator. Usually for games, using the same hardware, a lower rendering quality yields
a higher frame rate, and a higher image quality a lower frame rate.

8
GPU: A Graphic Processing Unit is a specialized electronic circuit designed to rapidly manipulate and alter memory to accelerate the creation of images in a
frame buffer intended for output to a display device. GPUs are used in embedded systems, mobile phones, personal computers, workstations, and game
consoles. Modern GPUs are very efficient at manipulating computer graphics and image processing. Their highly parallel structure makes them more
efficient than general-purpose central processing units (CPUs) for algorithms that process large blocks of data in parallel. In a personal computer, a GPU
can be present on a video card or embedded on the motherboard. In certain CPUs, they are embedded on the CPU die.

Getting a Tow: Another term for slipstreaming, gaining speed by sitting behind a rival car prior to overtaking.

Ground Effect: The car has an underbody shaped like an inverted wing which almost sucked the car on to the track and gave tremendous grip. This wing is
also called diffuser.

GUI: The Graphical User Interface (GUI) is a form of user interface that allows users to interact with electronic devices through graphical icons and audio
indicator such as primary notation, instead of text-based UIs, typed command labels or text navigation. GUIs were introduced in reaction to the perceived
steep learning curve of command-line interfaces (CLIs), which require commands to be typed on a computer keyboard. The actions in a GUI are usually
performed through direct manipulation of the graphical elements. A series of elements conforming a visual language have evolved to represent information
stored in computers. This makes it easier for people to work with and use computer software. The most common combination of such elements in GUIs is
the windows, icons, text fields, canvases, menus, pointer, especially in personal computers.

HUD: What is a HUD (Heads-Up Display)? It is any transparent display that presents
data without requiring users to look away from their usual viewpoints. The origin of the
name stems from a pilot being able to view information with the head positioned "up"
and looking forward, instead of angled down looking at lower instruments (Fig.). A HUD
also has the advantage that the pilot's eyes do not need to refocus to view the outside
after looking at the optically nearer instruments.

In video gaming, the HUD (heads-up display) or status bar is the method by which
information is visually relayed to the player as part of a game's user interface. While the
information that is displayed on the HUD depends greatly on the game, there are many
features that players recognize across many games. Most of them are static onscreen so
that they stay visible during gameplay.

KP 2.0: The Kunos pipeline 2.0 is a brief official guide of 76 pages on how to make car mods for Assetto Corsa. It is an update of the Kunos pipeline 1.03,
with corrections due to the development stages of AC. The focus is on visuals. It is based on 2015 hardware standards, and some aspects are even older.
Many procedures are not explained, some are not even mentioned and most are overlooked. A copy of the KP 2.0 is present as a PDF file in every
installation of the simulator, under the %root%\assettocorsa\sdk\dev\car_pipeline_2.0rev folder. It’s an outdated document, but a lot of the instructions are
still used to this day and have been corrected and incorporated in this very manual.

KS: Kunos Simulazioni S.R.L., the Italian software house that developed AC.

ksEditor: Small program useful to convert .fbx models to AC .kn5 models. Also called SDK Editor, AC SDK, AC Editor, Kunos Editor.

Launcher (game software): It is a program (almost always used in games) that manages the graphic interface when you are not in a real-time session of the
game. You can usually consider any loading screen part of a launcher. Sometimes launchers are part of the game itself, sometimes they aren’t. Talking
about AC, we can say that the vanilla launcher is AssettoCorsa.exe in the installation folder. It lets you prepare the race, in fact when you select your car,
track, opponents etc. it writes on the race.ini file in the assettocorsa\cfg folder. Then you could technically close AC and open acs.exe. This is basically the
game engine, and it can work without any launcher if you feed it with the correct config file. This flexibility lets you make alternative launchers.

Logged data chart: Graphical method of displaying information which has been recorded during a lap. Also known as Performance Analysis, it is a form of
telemetry.

Mod, modding, modder: Modding is a slang expression derived from the English verb "to modify". The term “mod” refers to modification of hardware,
software, or anything else, to perform a function not originally intended by the designer, or to achieve bespoke specification or appearance. The term is
used in relation to computer games, particularly in regard to creating new or altered content and sharing that via the web. It may be applied to the
overclocking of computers in order to increase the frequency at which the CPU operates. Case modding is a popular activity amongst many computer
enthusiasts which involves the customization of a computer case or the installation of water-cooling technology. In connection with automobiles, modding
can connote engine tuning, remapping of a vehicle's engine control unit or customization of the coachwork.

Modding may sometimes infringe the legal rights of the copyright owner. Some nations have laws prohibiting modding and accuse modders of attempting
to overcome copy protection schemes. In the United States, the DMCA has set up stiff penalties for mods that violate the rights of intellectual property
owners. However it is also worthy of note that some other European countries have not interpreted the legal issues in the same way. In Italy a judge threw
out a Sony case saying it was up to owners of a console what they did with it. Similarly in Spain, mod chips have been ruled as legal despite the EU
copyright legislation.

Types of modding:

9
There are two different ways of running unsigned code on a game console. One is through soft modding (modifying software, normally using a softmod) to
allow the user to change data contained on its hard drive in the case of the Xbox. Another type of modding, known as hard modding, is done by modifying
the hardware, such as components connected to the Hypervisor in order to run exploits to the BIOS of the console or to run unsigned code and games.
This form of 'modding' (more correctly termed as hacking), while not as popular as softmodding, is mostly done as it is able to 'run' many different types of
software. Soft modding is more popular because of its ease of installation and its relatively low price (it can even be done for free with the right tools).

Another type of console modding is about appearances, much like computer case modification. Which includes, adding lights, cutting the game system
case, to fit hardware and/or expose the internal systems. Cooling is a large part of console hard 'modding'.

Some companies actively encourage modding of their products. In cases such as TiVo and Google, there has been an informal agreement between the
modders and the company in which the modders agree not to do anything that destroys the company's business model and the company agrees to support
the community by providing technical specifications and information. Assetto Corsa was intended and designed as a moddable simulator from the
beginning.

The softmods in games can be as simple as altering the mechanics of a weapon in a first-person shooter, or as complex as turning one game into an
entirely different one (this happened a lot especially with classic Doom and old DOS games). The latter is known as a total conversion.

The modder (though it is more grammatically accurate to use the word modifier; not to be confused with the slang that stands for moderator, typical of
social platforms) is the person that actually produces mods. These people are usually technically inclined and they deliberately modify games (or anything
else) to their advantage (i.e. someone who cheats by altering the game code because he is too much of a newbie) or for fun. Most of the time they do
anything out of passion, and what pushes them is the satisfaction of making things work the way they want. It’s very rare that their hobby becomes a job,
and I have yet to hear that someone hired a modder. If you win a contest, maybe. While modding isn’t a guarantee you’ll land a job in the games industry,
it’s a great way to discover your passion for game development, and refine your skills – all while bolstering your résumé and building a portfolio of work.
Mods build skills because they are using tools similar (or sometimes exactly the same) to the ones that the game developers use. This can be invaluable in
both improving your skills and learning what gamers like.

OEM (automotive parts): An Original Equipment Manufacturer is generally perceived as a company that produces non-aftermarket parts and equipment that
may be marketed by another manufacturer. When referring to auto parts, the term refers to the manufacturer of the original equipment, that is, the parts
assembled and installed during the construction of a new vehicle. In contrast, aftermarket parts are those made by companies other than the OEM, which
might be installed as replacements after the car comes out of the factory. For example, if Ford used Autolite spark plugs, Exide batteries, Bosch fuel
injectors, and Ford's own engine blocks and heads when building a car, then car restorers and collectors consider those to be the OEM parts. Other-brand
parts would be considered aftermarket, such as Champion spark plugs, DieHard batteries, Kinsler fuel injectors, and BMP engine blocks and heads. Many
auto parts manufacturers sell parts through multiple channels, for example to car makers for installation during new-vehicle construction, to car makers for
resale as automaker-branded replacement parts, and through general merchandising supply chains. Any given brand of part can be OEM on some vehicle
models and aftermarket on others.

Outbrake: To brake very late into a corner when dicing with a rival car.

Oversteer: Oversteer is characterised by the rear end of the car losing grip, giving the car a tendency to spin.

Packers: Packers form part of the suspension assembly and adjust the position at which the bump rubbers become loaded.

Paddock: The parking area behind the pits where all the equipment, trucks and spare cars are kept by the teams.

PP Filter (PPFX): The term post-processing is used in the video/film business for quality-improvement image processing (specifically digital image
processing) methods used in video playback devices, video playing software and transcoding software. It is also commonly used in real-time 3D rendering
such as in video games to add additional effects.

Instead of rendering 3D objects directly to the display, the scene is first rendered to a buffer in the memory of the video card. Pixel shaders and optionally
vertex shaders are then used to apply post-processing filters to the image buffer before displaying it to the screen. Some post-processing effects also
require multiple-passes, gamma inputs, vertex manipulation, and depth buffer access. Post-processing allows effects to be used that require awareness of
the entire image (since normally each 3D object is rendered in isolation). Such effects include:

Ambient occlusion (HBAO, Screen space ambient occlusion (SSAO, reflections), etc. Dynamic contrast
Anaglyph Crepuscular rays
Anti-aliasing (FXAA, AGAA, SMAA, MLAA, custom methods -not sample-size AA like Digital camera light compensation
MSAA and SSAA) Dithering (including subpixel)
Bloom Eye adaptation
Blur (depth of field, motion blur, smart) Film grain
Bloodlust effect (red vignetting with particles, etc.) Filmic scene tone mapping
Bokeh Fog/mist
Bump mapping Gamma correction
Cel shading Global illumination
Chromatic aberration Glow
Color correction Grayscale
Color grading Haze (depth, heat)
Contrast adjustment High-dynamic-range rendering

10
Image distortion Screen rotation
Infrared Shading (ink, paint, sketch)
Lens flare (cubic lens distortion flare, pseudo lens flare) Shadow mapping
Light scattering Sepia tone
Nightvision Sharpen/unsharpen (texture unsharp mask, LumaSharpen, sharpen, sharpen complex
Outlines 1/2, adaptive-sharpen)
Particle effects Sobel operator
Pixel vibrance Split screen
Point light attenuation Upscaling (xBR, Super xBR, SuperRes)
Posterization and deposterization Texture filtering (point, linear, bilinear, trilinear, anisotropic, etc.)
Scanline Vignette
Screen borders

Rebound damper: An energy absorbing device fitted between wheel and car body which resists downward movement by the wheel.

Refuelling: Refuelling is an essential part of race strategy. The less fuel a car holds, the faster it can travel, but this will result in the need for more time-
consuming pit stops to refuel.

Responsive handling: The car responds quickly to steering, acceleration and braking inputs from the driver, allowing very accurate manoeuvres.

Rev limiter: A device which limits the RPM of the engine to a preset value. This is used in the pit lane to keep the car speed within the pit lane speed limit.

Ride height: The height of the car floor, above the ground, measured from the wheels.

Rumble Strip: The bobbly, coloured strip on the edge of the track which serves as a warning to the driver to transgress no further.

Run Off Track: A stretch of track close to a dangerous section of the circuit, that gives the driver an escape route if things go wrong, e.g. the driver loses
control of the car.

Shunt: A knock from the car behind you.

Sim: Simulation or simulator (depending on the context). It is a reconstruction of reality made with mathematical models and a high computational power.

Sound engine: It is the software used for the sound system.

Sound generator: The term refers to the part of the sound engine responsible for creating sound streams in real-time, which are sent to the sound
management system in the sound engine.

Sound management: The part of the sound engine responsible for playback and spatialization of sounds in the simulated environment.

Sound system: The term refers to the complete audio recording/editing/reproduction setup. This includes both hardware and software.

Springs: The springs form part of the suspension assembly and are the main means of supporting the car on the wheels.

Suspension travel: The distance through which the moving parts of the suspension travel in relation to the fixed parts.

Telemetry System: Multi-function system that measures all aspects of car and driver performance.

Tex or tx (computer graphics): A texture map is an image applied (mapped) to the surface of a shape or polygon. This may be a bitmap image or a
procedural texture.

They may be stored in common image file formats, referenced by 3d model formats or material definitions, and assembled into resource bundles.

Textures may have 1-3 dimensions, although 2 dimensions are most common for visible surfaces. Rendering APIs typically manage texture map resources
(which may be located in device memory) as buffers or surfaces, and may allow 'render to texture' for additional effects such as post processing or
environment mapping.

They usually contain RGB color data (either stored as direct color, compressed formats, or indexed color), and sometimes an additional channel for alpha
blending (RGBA) especially for billboards and decal overlay textures. It is possible to use the alpha channel (which may be convenient to store in formats
parsed by hardware) for other uses such as specularity.

Multiple texture maps (or channels) may be combined for control over specularity, normals, displacement, or subsurface scattering e.g. for skin rendering.

Multiple texture images may be combined in texture atlases or array textures to reduce state changes for modern hardware. Modern hardware often
supports cube map textures with multiple faces for environment mapping.

Texture space

Texture mapping maps the model surface (or screen space during rasterization) into texture space; in this space, the texture map is visible in its undistorted
form. UV unwrapping tools typically provide a view in texture space for manual editing of texture coordinates. Some rendering techniques such as
subsurface scattering may be performed approximately by texture-space operations.
11
Baking

As an optimization, it is possible to render detail from a complex, high-resolution model or expensive process (such as global illumination) into a surface
texture (possibly on a low-resolution model). Baking is also known as render mapping. This technique is most commonly used for light maps, but may also
be used to generate normal maps and displacement maps.

Tifosi: Italian Fans.

Time Penalties: Should the stewards choose to impose a time penalty the offending driver must, in normal circumstances, proceed to the designated area
and remain there until a specified time period has passed, after which the driver may re-join the race.

Torque: The amount of thrust driving through from the engine to the wheels.

Traction: The ability of the rear tyres to grip the track surface and cause the car to accelerate.

Traction Control: An electronically-controlled clutch allowing the car to accelerate as fast as possible without losing traction and the wheels spinning. This
system was outlawed for F1 in the ‘94 season.

Turn-in: The point on the track where the driver starts to steer the car into a corner.

Tyre Blankets: Special electric blankets placed over tyres just before a start to keep them up to racing temperature.

UI: In the industrial design field of human–computer interaction, a user interface (UI) is the space where interactions between humans and machines occur.
The goal of this interaction is to allow effective operation and control of the machine from the human end, while the machine simultaneously feeds back
information that aids the operators' decision-making process. Examples of this broad concept of user interfaces include the interactive aspects of computer
operating systems, hand tools, heavy machinery operator controls, and process controls. The design considerations applicable when creating user interfaces
are related to, or involve such disciplines as, ergonomics and psychology.

Generally, the goal of user interface design is to produce a user interface that makes it easy, efficient, and enjoyable (user-friendly) to operate a machine in
the way which produces the desired result (i.e. maximum usability). This generally means that the operator needs to provide minimal input to achieve the
desired output, and also that the machine minimizes undesired outputs to the user.

Understeer: Understeer is characterised by the front end of the car losing grip. This gives the rear of the car a tendency to carry straight on, through a
corner.

Vanilla (AC): The official version of the game, including all the original files, without any mod (in particular CSP).

VPN: A Virtual Private Network extends a private network across a public network and enables users to send and receive data across shared or public
networks as if their computing devices were directly connected to the private network. The benefits of a VPN include increases in functionality, security, and
management of the private network. It provides access to resources that are inaccessible on the public network and is typically used for remote workers.
Encryption is common, although not an inherent part of a VPN connection.

A VPN is created by establishing a virtual point-to-point connection through the use of dedicated circuits or with tunneling protocols over existing networks.
A VPN available from the public Internet can provide some of the benefits of a wide area network (WAN). From a user perspective, the resources available
within the private network can be accessed remotely.

VPNs cannot make online connections completely anonymous, but they can increase privacy and security. To prevent disclosure of private information or
data sniffing, VPNs typically allow only authenticated remote access using tunneling protocols and secure encryption techniques.

The VPN security model provides:

 Confidentiality such that even if the network traffic is sniffed at the packet level (see network sniffer or deep packet inspection), an attacker would see
only encrypted data, not the raw data.
 Sender authentication to prevent unauthorized users from accessing the VPN.
 Message integrity to detect and reject any instances of tampering with transmitted messages.

Common misconceptions:

 A VPN does not make your Internet "private". You can still be tracked through tracking cookies and device fingerprinting, even if your IP address is
hidden.
 A VPN does not make you immune to hackers.
 A VPN is not in itself a means for good Internet privacy. The burden of trust is simply transferred from the ISP to the VPN service provider.

VR: Virtual reality is a simulated experience that can be similar to or completely different from the real world. Applications of virtual reality include
entertainment (particularly video games), education (such as medical or military training) and business (such as virtual meetings).

Currently, standard virtual reality systems use either virtual reality headsets or multi-projected environments to generate realistic images, sounds and other
sensations that simulate a user's physical presence in a virtual environment. A person using virtual reality equipment is able to look around the artificial
world, move around in it, and interact with virtual features or items. The effect is commonly created by VR headsets consisting of a head-mounted display

12
with a small screen in front of the eyes, but can also be created through specially designed rooms with multiple large screens. Virtual reality typically
incorporates auditory and video feedback.

Wings: Devices fitted to the front and rear of the car which produce aerodynamic downforce. This allows faster cornering speeds. The rear wing also
produces significant aerodynamic drag. Wings mounted upside down give negative lift and hold the car down.

13
 PART 1:
ASSETTO CORSA
User Manual

14
Assetto Corsa - Unofficial user manual

1.0 - Is Assetto Corsa worth buying?

The short answer is yes. Today, there are many racing simulators on the market for PCs and consoles. Most are good, many are great, and a few are horrid.

Assetto Corsa (Italian for 'race trim' or ‘race setup’) is not a game. It is a superb simulation software from the Italy based studio Kunos Simulazioni SRL,
located at Vallelunga, just inside the international racing circuit, allowing the development team to work with the cooperation of real-world racing drivers and
teams.

It comes with a proprietary tire model, a licensed sound engine, realistic physics and aerodynamics. The exteriors and interiors of the cars are fully
modelled and the tracks are laser-scanned. This software is really good to enjoy a particular car on a particular track. It’s polished in all the essentials:
realism, visuals, immersion, configurability, expandability, performance, stability, and usability.

A proper wheel is strongly recommended to feel the car and the road through a detailed Force Feedback. The vanilla release requires at least a good mid-
ranged PC for an enjoyable gaming experience.

Pro tip: AC can reproduce the experience of race driving with a high degree of realism. But it is not the real thing. It will never be the real thing. Always keep
this in mind. This is due mostly to the numbers you input in the simulation: the physics engine is just a mathematical solver, and what makes the vehicles
“feel” right is their specific data. It means that with the right input values, AC can be almost identical to real life in terms of physics, but often the
specifications are strategically kept confidential by car manufacturers or simply are not available (especially with historic and exotic vehicles). In addition to
this there are other variables, for example human errors while interpreting vehicle data and dynamics. Heck, there’s still a lot of research going on in this
field. That’s why all kinds of engineers exist, so you don’t have to worry about it. Also, consider that even if the software is a simulator, its public release was
meant to be fun and satisfying1, being designed for common people. If the cars were truly accurate, you’d have a harder time! Kunos made compromises.

This simulator was born with moddability in mind, so you can create your own vehicles and tracks, along with the physics and much more, which later will
become the main topics of this manual. Mods have less boundaries in terms of how accurate they can get, within the limitations of the software.

Actually, some of the most detailed cars in AC were originally mods: for example, the Lamborghini Miura P400SV, the Porsche 917/30, the Shelby Cobra
427 S/C, the Nissan Skyline GTR R34, the Mazda MX5, the Mazda 787B. Sometimes the models were made by third-party 3D artists instead; the Alfa
Romeo GTA, the Mercedes C9 LM 1989, the Lamborghini Countach, the Ford Escort MK1 RS 1600 and the Praga R1 were all made by Mirza Rustemović,
senior vehicle artist at Studio397, who created vehicles also for rFactor 2 and The Crew 2. Due to their high quality, Kunos bought some mods and probably
commissioned a few models. It doesn’t mean that devs didn’t do anything, what were you thinking?

Not only that. Users started making graphic modifications to the vanilla game engine, remaking the original shaders. That’s where the most popular AC mod
excels, and it’s called Custom Shaders Patch (CSP), made by Ilja Jusupov (aka x4fab). The sim is almost unrecognizable after installing it, and new features
are added and expanded with every update of the mod, bringing over time also physics corrections and bug fixes, even if AC is not supported nor updated
anymore by Kunos. Mods prolonged the lifetime of this simulator to this very day.

If you still have doubts, there’s been a period in time when Ferrari used a modified version of AC (AC Pro) in the simulators for road cars. It’s worth noting
that in 2014 their F1 team switched to RFactor Pro (which software they used before is unknown, but it may have been something made in collaboration
with Kunos, as there’s been a close relationship between the software house and the Italian car manufacturer). Below is just a small proof (Fig. I).

Fig. I – Photo taken from a Ferrari simulator. This image is publicly available, so no worries. Does it remind you anything? Obviously I upscaled and enhanced like in movies.

AC Pro is an AC release for projects that involve a commercial and public use (industrial, training, marketing and promotional applications), distributed
upon direct request to professionals. I can’t say the exact number, but the price is more than 1500 euros at least. It is for the most part like the normal AC,
but with a view mode that can turn off any visible object, and an empirical tire model that reads from a custom look-up-table with OEM data. Comes also
with some features added so that you can use your own graphics and/or physics engines, and the models of the cars you want can be created by Kunos (or
with their assistance) and included in the package; you will also be granted with their customer support service.

1
In an interview with Stefano Casillo, Marco Massarutto and Aristotelis Vasilakos back in 2012, Kunos said that the public release of AC was originally intended as an arcade-ish title.

15
1.1 - AC vs ACC. What’s the difference?
With the 2019 release of the successor title, Assetto Corsa Competizione (ACC), updates and official support to Assetto Corsa have ceased. Yet, the
community continues to thrive, mainly because ACC contains only the tracks and cars in the events of the GT World Challenge series – firmly titled the
Blancpain Endurance Series. The cars and tracks are modelled very accurately and updated each season with the respective official liveries, and new
vehicles such as the BMW M4 have also been added. Technically wise, ACC runs on the Unreal Engine 4 (UE4) by Epic Games, while AC's engine was built
in-house by Kunos. ACC cannot be modded at all (aside from car liveries, but those aren’t technically mods) due to the Unreal Engine project encryption. Its
physics are also much deeper and more detailed because the devs could take their knowledge from AC and improve it, and because the focus is much
narrower. Also, it’s still officially supported and continuously improved.

AC instead supports many tracks and cars, including road vehicles. It can be modded in almost every regard, the opportunities are seemingly endless. This
sim is not tied to any official series, and that gave the developers creative freedom to go make it as versatile as possible.

From the point of view of graphics, ACC is slightly more realistic and refined, even if vanilla AC looks very good too (Fig. II).

Fig. II – At first glance there’s not much difference, but when playing it’s noticeable. However AC can be on par if not better, thanks to CSP and other graphic mods.

The game modes in both titles are fairly predictable for modern racing titles. Both have quick races, time trials, practice sessions and customizable
championship modes. Competizione includes a few extras such as hot stint mode, hot lap superpole and official race weekends, while AC has a time attack
mode, drifting and drag racing. Both have career modes as well, although not mind blowing. However, the career should not be the focus of any simulator,
as it is not a game.

In the end, AC and ACC are two separate simulators. It’s crazy how some people bought ACC and thought it would work with mods and Content Manager.
No, don’t laugh, I’m serious, it happened.

16
1.2 – Feature list
Below are the main characteristics of Assetto Corsa, so that you can compare it with other racing titles.

In general
 Accurate modelled cars (physics, aerodynamics, exterior & interior)
 In depth car setups, values in SI units
 Tires: accurate wear curve, degradation (blistering, graining, overheating), flat spotting (vibration)
 Damage model: visual (body), engine (accumulative), gearbox, suspension, steering, aerodynamics
 Laser-scans for many tracks (traditional modeling approach for the others)
 Multitude of driving aids
 Pit stop system: animated pit crew, tyre changes, refuelling
 Flag system: checker flag, yellow, blue and black flag
 Dynamic track surfaces
 Dynamic time of day in single-player
 Complex audio engine (powered by FMOD)
 Post-Processing filters (PPFx): many on-the-fly presets, glare, depth of field, color saturation, motion blur, crepuscular rays, heat shimmering
 Dedicated server client with basic admin commands
 Modding tools (cars & tracks)
 Built-in photo mode
 Replays (file size limitations may apply)

Singleplayer
 Three offline driving modes: practice, race, and challenge.
Practice: you choose whichever car and track combination you desire. You are alone on the track. So, it is suited to learning a new track or getting acquainted with a new
car.
Race: gives you total control over the selection of the track, the car, and the opponents. There are three options for choosing opponents: the single option forces all the
opponents to drive the same car you chose; the random option mixes things up by selecting the number of opponents and their cars, based on the difficulty level you
chose; the custom option allows you to choose the track, the car you drive, the number of opponents, their strengths, and the cars they drive.
There are three types of races: in a quick race, you start on the grid at a position you chose; in a full race weekend, you practice, you qualify for a starting grid position,
then you run the race. The session parameters - time of day, ambient temperature, track surface condition, starting position, race length, and whether or not to enable the
penalty assessments - can all be set.
Drag races are included, and are very straightforward. You must out drag your AI opponent, who is driving in the adjacent lane. Dragging is a test of talent for timing and
touch. You are allowed seven runs, and you must win a majority of the runs. You will probably need to tune your car to win a drag race.
Challenge: has four types of events: time attack, hotlap, drift, and special events.
Within a time attack your task is to drive lap after lap, flat out, until you reach or exceed the maximum points. There are three sectors on each track, with a timing gate at
the end of each sector. Driving through a timing gate earns you points. The catch is that as the laps wind on, the allotted duration in which you must reach the next timing
gate is shortened. Eventually, you run out of time, and the challenge ends. If you did earn the maximum points before the time runs out, you win the event.
Hot lap is similar to a time attack in that you drive as fast as you can, as long as you can. But the goal of this challenge is to surpass your previous hot lap time.
Drift requires you to collect points by drifting throughout the entire track. To earn enough points to keep progressing up through the levels, you need to drive sideways,
even on the straights. Otherwise, you will not earn a sufficient amount of points, before the time runs out.
A special event can be a drag race, a drift event, a track race, a time attack, or a hot lap. However, you cannot alter its parameters. In a track race special event, for
example, the car is chosen for you, you cannot alter the number of AI opponents, you are always dead last on the grid, each race is five laps, and you must progress
through four difficulty levels - easy, medium, hard, and alien. You can win even at the most difficult level with 100% AI strength, but you are unlikely to achieve this,
without altering your car’s factory set-up to some extent. In drag races the opponent will be an identical car, while in hotlap instead of your previous best, three lap time
targets, each progressively quicker, are pre-defined. The same applies to time attack special events.
 Career mode: racing games like Gran Turismo make a big show of the career mode, which obliges the user to progress from circulating mind-numbingly short tracks in
insipid cars to driving around full-length tracks in unrealistically fast cars. After having paid a substantial sum of money for the game, the user must still step through a
plethora of low-level career stages, before he can experience the fun bits - driving proper race cars on long racetracks. Racing simulators, like AC, do not foist upon the
user a mandatory career mode. Instead, he can drive whatever car he fancies on whichever track he likes. But AC also supports novice (N), intermediate (I), trofeo (T),
and so on, all the way up to advanced (A) career levels.
There is not much to say about the career mode. You start with a slow car that is relatively agile (Abarth 500 EsseEsse). To unlock the next level of career, you must earn
points and medals by winning races in the present level.
 Automatically generated list of favourite combinations
Multiplayer
 Online mode, LAN
 Server client included
 Public servers with Booking or Pickup mode, can feature mod-content thanks to server-client checksums

Missing features in comparison to other simulators / driving games (as of 21.12.14):

Dynamic time of day in Multiplayer (brought by CSP?)
Dynamic weather (brought by CSP)
Server controlled rolling start procedure
Day and night cycle (brought by CSP)
Spectator mode (online, broadcasting)

17
1.3 – History of AC (special thanks to Amen Zwa)
Assetto Corsa is not the first title made by Kunos Simulazioni. Actually, the first title is from when the company didn’t even exist: netKar “Namie”. Released
as freeware back in 2003, made by a single person: Stefano Casillo (founder of KS and lead developer until 2020), a genius and a perfectionist. According
to him, he developed netKar at home in the evening, as a personal project. When he started in 2001, he had neither the knowledge nor the experience in
implementing real-time simulators. He acquired the necessary skills by reading mechanical engineering textbooks. Impressive, that. netKar subsequently
became Kunos Simulazioni’s netKar Pro in 2006. It shall be said that Stefano started approaching the world of programming when he was 10-11 years old.

“Namie” was just a nickname for the release 0.9.9, the last ever free sim from KS. And it did have mods, too! The release 0.9.6 was called “Elisa” and the
0.9.5 “Kuraki”. If you don’t give names to your software, you aren’t truly having fun.

The netKar engine, too, hatched a string of well-respected titles, including Ferrari Virtual Academy (title from 2010), which enjoyed a rare blessing of
Maranello. Assetto Corsa is the 2014 follow-on to netKar Pro. KS started developing AC from scratch with the Unity engine in 2009-10, as a driving school
project for the Automobile Club d'Italia (ACI, Italian Automobile Club). In 2011 however, they built a completely new in-house engine, due to constraints of
external integrability i.e. not being modding friendly, and due to long loading times.

AC has basically nothing in common with netKar in its code. This was done on purpose, to start fresh with the project.

The game is coded in multiple programming languages. C++ is used for the simulation and Go for the multiplayer server. The user interface and launcher
core is coded in C#, but the interface frontend in HTML to allow users to create interface modifications. Python can be used for developing plugins for
retrieving simulation data in real time. APIs used are DirectX 11 for graphics, FMOD for sound and ODE for collision detection and rigid body physics.

PC demo
The Assetto Corsa Technology Preview was a playable benchmark that was released on 22 February 2013. It offered one car, the Lotus Elise SC, and one
track, Autodromo dell'Umbria in Magione, Italy, as well as two playing modes, free practice and time attack. The preview's main purpose was to allow users
to get their first taste of the engine, test it, and report feedback. The preview required the player to own a netKar Pro license.

PC early access
Assetto Corsa was greenlit on Steam Greenlight on 13 June 2013. The game was released through Steam's Early Access program on 8 November 2013.
This service allows developers to release a functional but yet incomplete product, such as beta versions, to allow users to buy the title and help provide
funding, testing and feedback towards the final production. Through the Early Access programme the game received updates roughly every two weeks,
adding new and improving existing content and features.

PC release
The Release Candidate, a feature complete version of the game, was released on 15 October 2014. The final version, following general bug-fixing and
performance optimizations, was released on 19 December 2014. The game continued to receive free updates, new features and paid DLC with additional
content such as new cars and tracks.

Console release
In May 2015, the PlayStation 4 and Xbox One version of the game was announced. It is published by 505 Games and was released after delays on 26 and
30 August 2016 in Europe and North America respectively. Marco Massarutto, co-founder and executive manager of Kunos Simulazioni, states that the
physics model of the console version is identical to the PC version and the rendering and physics engines had to be rebuilt to better utilise multi-
threading—the performance targets for the PlayStation 4 are 1080p, 60FPS, with the Xbox One "matching the PS4 as closely as possible". The console
version of the game received an entirely new UI optimised for use with a gamepad.

On February 14, 2018, a new release called Ultimate Edition, containing all previously available DLC, was announced for consoles. This edition was then
released on April 20, 2018 and is available also for PC.

Mobile release
In August 2021, a mobile port of the game was announced. It was officially released for iOS devices (iPhone and iPad) on August 31 and it was entrusted to
Digital Tales. The graphics are reduced to the bare minimum and not even comparable to the PC or console versions.

AC sets itself apart from the competition with its fanatical attention to detail. It is not without shortcomings, however. For instance, it currently has no
support for mist, rain, wet tracks, and loose surface rally tracks. But none of these shortcomings detract from the impressive achievements attained by the
development team in a very short period: a topping simulator that is realistic, immersive, fast, stable, and refined from the very beginning.

1.4 – How many cars are there in vanilla AC?

Since its 2014 release, Kunos developers were able to expand precisely from 37 cars across 10 manufacturers to 177 cars and 24 manufacturers. A bit of
an improvement I would say. (are the numbers correctttt=======??????=)

1.5 - How is AC for slow and amateur drivers?

- Slower cars often can provide the most rewarding experience for people with less skills. If the sensation of driving a car is what you're looking for in a sim,
then in my opinion nothing comes even close to Assetto Corsa.

18
- Raw speed doesn't guarantee wins. Consistency and respect for the rules is where you'll get good results. You can put in clean laps that don't involve
constant wheel twitches like in games and hybrid arcade simulators.

- Driving aids are available on each and every car: this gives you the chance to start with a lot of help, and altering the percentage of how much aids are on
allows users to slowly increase the difficulty level as their driving ability and familiarity with the car increases. With smaller cars, naturally this is easier, but
for more powerful cars it’s really helpful for someone new to the technique of not slamming the brakes and accelerator all the time.

- As a general guideline, I advise not to change anything on the car setups until you can drive 10 laps one after the other with a regular pace (lap time).

Only then start adjusting tyre pressure, gearbox sets, suspensions, etc.

- Car set-up tooltips are super useful if you do not understand what everything does when preparing your car for the race. A basic aid for a few quick
tweaks is fantastic and it is not common at all in racing games. Hover with the mouse on the setup entries to make them appear (Fig. III)

Fig. III – Example of the tooltips found in the setup screens of AC.

- The driving line: it’s a pretty basic assist for people that don’t understand how to find their own line and brake points on the track, and it gives you a
trajectory to follow with your vehicle.

It won’t be perfect and for racing it actually might hurt your development as you need to learn by memorising sections, turn in points, apexes and exits.
Following the line will normally take your focus away from the actual objects you need to look at as markers, like curbs, signs, poles and so on. Why is it
there then? Well, mainly to let you complete your first three laps.

The line will be green for throttle, yellow for coasting and red for braking (Fig. IV); in most games it changes colour in a dynamic way, if you’re going too fast
or too slow. In AC it’s not dynamic (is static) because it depends on the pre-recorded AI opponents’ line.

Fig. IV – The various colours of the driving line. As you can see the arrows follow the direction you should drive towards. This is a track mod with traffic, that’s why you see two lines.
19
This means it may be very bad on circuit/map mods, and even in official ones it won’t be the best path to follow with any car in particular. If you turn it off
you will improve much quicker.

Someone who understands lines and brake points can learn a brand-new track in 10-30 laps to a fairly good level. To be able to get the most out of a
specific vehicle setup you will likely need to drive more than that and every next lap you do you’ll likely learn something.

- How am I supposed to know where I need to brake when entering corners? Again, pick a braking marker or some static object like a pole or tree. Brake
when you reach it. Then keep braking later until you lock the wheels or make a mistake. Then adjust your technique to avoid it. You can watch onboard
footage of real drivers as well to find the optimal braking markers.

- You can also enable your ghost so you always have a direct visualization of your best round; you can offset it around 1sec or more ahead, this way you
can follow your own racing line and start testing where and how to go faster than yourself. Soon you will see that you can brake later, accelerate sooner or
coast faster through a turn and catch up on that ghost. In a while you will have no idea how you were so slow earlier and you will learn to interpret body
roll, wheel sound, etc. to estimate when you are on the edge of grip and suitable speed through a turn.

- Watch the replays of your races or practice sessions! You can definitely learn from your errors. Otherwise why should this feature be there? It’s rare to see
a good race.

- Playing with a controller: drifting is doable, so you may try it, but do not expect much results; you will probably get kicked from online play because it will
be hard not to be off pace and avoid contacts with one, and it may not be much fun.

2 - Basics
2.1 - PC vs Console versions
AC is available on PC, PS4 and Xbox One. It can be played also on consoles of the same kind (from Sony, Microsoft) compatible with older generations.

For example the simulator hasn’t been released for PS5, so you will be playing the PS4 version. However there are no improvements in resolution or image
quality between PS4 and PS5. The framerate is just higher and more stable.

The main difference between the PC and the console versions is that the sim can be modded on PC, while on consoles you will be able to play only vanilla.

You will need a Steam subscription (=account), in order to legally purchase, download, install, and run AC on your personal computer. Steam is a software
distribution service launched in September 2003 by Valve Corporation LLC, an American video game developer, publisher, and digital distribution company
headquartered in Bellevue, Washington.

Steam supports digital rights management (DRM), game review, and social media. You should download the Steam client from SteamPowered.com, install it
in the default folder C:\Games\Steam, run the client, and create an account. You receive a welcome email, which contains a code you must use to register
your gaming PC with the Steam service. Once your account and your machine are recognised by the Steam software, you may proceed to purchase our
simulator, using a credit card or a PayPal account.

You can run AC only under the control of the Steam client. Steam updates games automatically, and its DRM (Digital Rights Management) system ensures
that your copies are legitimate.

Yes, because you have, essentially, a leased copy of AC. The time of licence keys has apparently ended years ago in the world of games. Oh boy, it’s the era
of NFTs (Non-Fungible-Tokens) and pay-to-win servers. Nice.

Just as Steam is not required to reimburse you the value of your collection if you're banned from their service, if tomorrow Valve LLC closed shop, they
probably would not be required to turn off their DRM. Moreover, it would not surprise me in the slightest to learn that the DRM is mandated by the
publishers who allow Steam to sell their product, so while it's a nice thought, I find it unlikely that Valve would be able to legally turn it off as a final action.

Plus you don’t really know what kind of telemetry data does Steam collect from your PC, apart from the game achievements and progress. Anything else
should be none of their business. You like being watched, don’t you?

So what can you do if you don’t want to use Steam or it suddenly goes down? The only option is piracy, which is easy but illegal, although if Steam went
down then theoretically you could argue that cracking would be legal under the DMCA, as the product would be broken, and removing the DRM would be
required to fix it to a working state. It's a bit shaky though, because you have a "subscription", not a game arguably. But that hasn’t happened.

Enough with this digression. The latest AC release is the 1.16.4. People often think that 1.16.3 is the latest, due to the fact that this version appears more
often on the web (and to piracy), but the truth is that 1.16.4 is the so-called “Silent Update”. This is because it is a DLC which you can’t buy, being linked to
a Ferrari E-sport event featuring a couple cars, the Ferrari 488 Challenge Evo and the 488 GT3 Evo 2020 (Fig. V).

20
Fig. V – To obtain the vehicles you can try registering to the event here: https://esports-registration.ferrari.com/regulation or find a mod as replacement.

The update 1.16.4 includes also changes in the main launcher files and car data. If you buy the Ultimate Edition, these should be included, but you won’t get
the extra vehicles, being them related to the e-sport event you’d have to take part in. But if you really want them, register to the Ferrari website. If you are
not in one of the countries listed, you can just pick a random country and it should be fine. Once you finish the registration you should get a message to
verify your email address. After that you will get a “Welcome to Ferrari Hublot Esports Series!” email. In this particular mail you will obtain the Steam key for
the Ferrari 488 Evo. With it you can go in Steam and select the Games tab, then activate a product where you will put the key. The content should start
downloading.

The Ferraris are not the only Esport-related content: for example, you can get the Dallara Stradale by registering on esports.cusbologna.it and participating
to the tournaments. There are many official partnerships like this one.

Now, updating AC to 1.16.4 or directly buying the Ultimate Ed., you may encounter an error in CM with old versions of CSP telling you that v1.16.3 is
required. This can happen also if you have an older AC version (Fig. VI).

Fig. VI – Here the version is 1.16. This is usually not a problem with Steam, as the games are automatically updated (often this error is encountered with pirated copies of the game).

CSP looks at the changelog.txt located in the AC root install folder. This file is updated to reflect changes that were made to version 1.16.4. Old CSP
versions do not understand what release 1.16.4 means, so they cause this error. You can adopt different solutions to fix this:

1. Update CSP. This most likely will fix the error, as AC 1.16.4 is correctly displayed since CSP release 0.1.74. Otherwise...
2. Edit changelog.txt and remove the entry for 1.16.4;
3. Edit changelog.txt and change the first line from 1.16.4 to 1.16.3;
4. Rename changelog.txt to changelog.txt.bak;
5. Move or delete changelog.txt.
6. Leaving this error and not doing anything is also an option, as it does not appear to cause any functional issues so far.

21
2.2 - Hardware requirements
Official hardware requirements:

Minimum
OS: Windows Vista Sp2 (with KB971512 platform update)
Architecture: 32/64 bit
Processor: AMD Athlon X2 2.8 GHZ, Intel Core 2 Duo 2.4 GHZ
System memory: 4 GB RAM
Graphics: DirectX 10.1 (AMD Radeon HD 6450, Nvidia GeForce GT 460)
Graphics memory: 512 MB
DirectX: Version 11
Network: Broadband Internet connection
Storage (Hard Drive): 15 GB available space
Sound Card: Integrated

Recommended
OS: Windows 7 Sp1, 8, 8.1, 10, 11
Architecture: 64 bit
Processor: AMD Six-Core CPU, Intel Quad-Core CPU
System memory: 6 GB RAM
Graphics: DirectX 11 (AMD Radeon 290x, Nvidia GeForce GTX 970)
Graphics Memory: 3 GB
DirectX: Version 11
Network: Broadband Internet connection
Storage (Hard Drive): 30 GB available space
Sound Card: Integrated

Assetto Corsa is DirectX11 only, compatible with DirectX10.1 cards. It works also on older DX10 video cards but might have fps hit; in any case these did
not receive any support from Kunos and will never do, due to technical factors. To use DX10 (why would you?), you should set to 1 the following parameter
in the graphics.ini config file, under assettocorsa/system/cfg:
[DX11]
ALLOW_UNSUPPORTED_DX10=0 ; UNSUPPORTED, USE AT YOUR OWN RISK

A 64 bit architecture is required especially to use CSP. This is not directly related to the double precision physics. It’s just that the mod at its core doesn’t
work on 32-bit systems, and if you try to use it on an OS with such architecture, an error message will be displayed (Fig. VII).

Fig. VII – The error that will appear on a 32-bit system if you try to launch AC with CSP. dwrite.dll is the file that makes the shaders patch injection work.

If you start modding your Assetto Corsa installation, you may need a better setup. Keep in mind that the official hardware requirements are for the vanilla
game, while with mods you never know which is the right compromise, until you experience various solutions for yourself, playing with settings.

In case you want to turn a PC into a dedicated gaming box and maximize its performance, update your motherboard’s BIOS, the operating system patches,
the graphics card driver, and the input devices drivers. Remove all the software you don’t use from the machine, except the games (which you better keep in
a secondary drive, so that if Windows has any problem and needs repair/restore/reinstallation, you don’t have to worry about them). Even preinstalled apps
like MS OneDrive, unknown CD/DVD burning software, Chat/Messenger apps and others shall be deleted. Do not uninstall hardware drivers (i.e. nVidia,
AMD, ATI, Intel, Synaptics, Realtek, …) and system packages like Visual C++, .NET Framework, DirectX, Python libraries, SQL server client, Java, etc.
Disable speech recognition, and Cortana as well. Apply the most restricted privacy settings. Strip bare the Windows Aero user interface theme by disabling
all the eye candies, gadgets and transparencies. Disable unused services working in the background, and if you want, block Windows Update too. Especially
remove anti-virus software, because those run continuously in the background and steal CPU cycles. Now, since the machine will be unprotected, minimise
your web and email activities on it, or avoid them altogether.

At this point you should obtain a better performing machine.

Another tip: installing several registry/system cleaning tools like CCleaner or Glary Utilities to make your PC faster is not useful at all, it will eventually slow
down anyway. Those programs ignore a lot of things that should be “cleaned”. Just use the default Windows Disk Cleanup tool to clean the cache and
temporary files. Note that a fresh Windows installation is usually faster than an old one, in particular before you connect your machine to the Internet and it
starts with the updates.

22
2.3 - Is a ray-tracing graphics card required?
Always keep in mind that Assetto Corsa does not support ray-tracing technology (at least for now, who knows what modders can do?). It is not required to
buy an RTX graphics card then.

Wait… I’ve seen that you can add RTX to any game on YouTube videos. What about those?

Well, those are shader injections with a software called Reshade. Using Reshade doesn’t bring proper ray-tracing to your games, it’s just a lie. It's been very
concerning how many thousands of videos online say "RAY TRACING NEXT-GEN GRAPHICS FOR GAME X". 3rd party plugins approximate effects based
on screen space depth and color sampling, but you cannot light correctly a scene this way. Ray tracing is specific to the triangles in the entire scene, not
only to the pixels on screen.

The basis is this: any form of light in a computational environment has to be considered as a group of vectors, with a given direction and magnitude. They’re
called “rays”.

Screen-space ray-traced global illumination shaders (post-process Reshade ssRTGI) find the direction of the ray of light going out of each pixel on the
screen. This is a process, because we want to create a parallax effect, where rays scatter as they get farther from the camera and therefore intersect more
with things nearer, less with things farther. The process doesn't have access to the full depth map, so anything outside of the field of vision doesn't exist
(no light calculation). A depth buffer and color information are used. The program continuously casts rays so when you move around it has to reorient them
depending on what new information it sees, unlike ray tracing where it has all of the information at all times. Bounced light effects can appear and disappear
if the reflecting faces are visible on screen or hidden behind other geometries. These effects are nice, but easy to break if the player moves the camera POV
(point of view).

Proper ray tracing (usually RT or RTX) gives light weight as well as direction, it calculates how the light should react when hitting a material and where it
should go after that. So after light hits, for example, water, it'll reflect around the room, maybe light the walls slightly and also refract against the water. The
biggest difference is how light interacts with itself. If you shine two beams of light through different transparent materials, such as coloured glass, the
colours will mix and make the colour it’s supposed to, just like how real light reacts. This is called color bleeding. You also have scattered surface light
reflections. And nothing is baked in the textures. The whole process can actively take a lot of data from the geometry of the 3d scene being rendered, and it
happens at the GPU level. This technology is heavily demanding, which is why an RTX graphics card is needed for the calculations of the lighting effects.

RTGI shaders aren’t ray tracing. This doesn’t mean they’re bad. They can look really good (Fig. VIII), thanks to the implementations you can add, and to their
customizability. They’re just the less expensive (literally in every sense) and more exciting option.

Fig. VIII – There’s only one Minecraft with true ray tracing support (the leftmost) but, as you can see, a huge amount of nice screen-space shaders.

If the game you’re thinking of doesn’t support ray-tracing, it is not possible to add this feature without heavily modifying the core of the graphics engine.
Taking a game like GTA V as an example, you’d need the source code to do such a thing. Sadly, for a lot of games it is not publicly available (yet).

Recently, it seems possible to “remaster” games with RTX, thanks to the Nvidia Remix technology: https://www.nvidia.com/en-us/geforce/rtx-remix. This is very
recent, so don’t expect a new release of your favourite game soon.

2.4 - Dual GPU system

It is possible to run AC with two graphics cards.

If you are running a dual GPU system and encounter a full black screen in the vanilla launcher then make sure that AssettoCorsa.exe is assigned to the GPU
your desktop is using and acs.exe is assigned to your "high performance" GPU. These files are in the main installation folder, usually under the
STEAM\steamapps\common\assettocorsa path. This can be done in the Nvidia control panel for Nvidia users and in the Catalyst Control Center for ATI/AMD
users.

23
If you use CM to load race sessions, you shouldn’t encounter this problem, as acs.exe is launched directly.

2.5 - Virtual reality (VR) hardware support

Oculus CV1, DK2
Nvidia 3D Vision
NaturalPoint Track IR
D-Box motion systems
Track IR-Pro

2.6 - Gaming devices (PC)

AC is compatible with keyboard, joystick, pad (mainly 360), lots of wheels and professional motion systems.
It is strongly recommended to use a wheel with 900° of rotation.

- Officially supported hardware:

THRUSTMASTER
T300RS
T300 Ferrari GTE
TX Racing Wheel Ferrari 458 Italia Edition
T100 Force Feedback
TH8RS Shifter
T500RS
RGT Force Feedback Clutch
F430 Force Feedback
Ferrari F1 Wheel Integral T500
599XX EVO 30 Wheel Add-On Alcantara Edition

LOGITECH
G25
G27
G29
G920
Logitech MOMO Force
Logitech MOMO Racing
Logitech Driving Force
Logitech Driving Force Pro
Logitech Driving Force GT

FANATEC
ClubSport Wheel Base
ClubSport Wheel Base v2
ClubSport Shifter – all versions
Clubsport Pedals – all versions
Porsche wheels – all versions
CSR
CSR Elite

MICROSOFT
SideWinder Force Feedback

GAMEPADS
Microsoft XBOX 360 / XBOX One
Thrustmaster GPX

GENERIC
All Direct Input USB devices

- How to play with a PS4 controller on PC?

Connect it and use Ds4windows. Then bind all the buttons and you’re good.

- Keyboards

I'm not a hardware guy, but if I had to design a keyboard, I'd probably include some kind of electrical switch under each key, with a set of wires leading to
and from each switch so I could detect when they were pressed. Bzzzt, wrong!

Real hardware designers reduce manufacturing costs by sharing only a few electrical connections between many keys. Next time you are throwing out an
old keyboard, rip it open first and take a look inside. You'll see a crazy circuit board with a matrix taking voltage to and from the various switches, but if you
look carefully, you'll notice the same inputs and outputs are routed to many different keys. How can this possibly work? The trick is that in order to detect a

24
single keypress, you don't actually need a unique wiring for that key. As long as each key has a unique combination of input and output connections, you
can figure out things like "source #3 and destination #5 have voltage, so 'O' must be pressed".

You can also detect multiple keypresses, using logic like "sources #3 and #4 are connected to destination #5, which means both 'O' and 'K' must be
pressed". In fact, any combination of two keys can be reliably detected (the proof of which I shall leave as an exercise for the reader).

More than two simultaneous keys, however, are a problem. Some combinations may work ok, but others will try to connect source and destination wires
that are both already in use by other keys, in which case the new press will be completely ignored. Even worse, exactly which combinations can be detected
varies from one keyboard to another, depending on the details of how their wiring matrix is laid out.

This behaviour was fine for the word processing applications that keyboards were originally designed for, but is not so great for games. There is nothing we
can do to fix the hardware, but there are a couple of ways we can minimize its impact:
 Prefer the shift, alt, and ctrl keys, because these usually have dedicated wiring that will not cause conflicts.
 Avoid game designs that require pressing many keys at the same time.
 Avoid the keyboard entirely. Gamepads don't have this problem. They have other problems!

- Gamepads

Gamepads, like keyboards, are not perfect. They are designed to be cheap, sturdy, and nice to hold: accuracy comes second.

Specifically, the analog thumbsticks are not very precise at reporting their absolute position (although they are good at measuring relative movements, so
the returned values will change if you twitch the stick even a small amount). The main way you notice this lack of precision is that when you let go of the
stick it never goes back exactly to zero, just to some kind of smallish value roughly near to zero.

Thumbsticks that don't return exactly to zero are a bad thing. This makes game characters twitch around or sidle across the screen when they should be
sitting still, and it makes menu systems randomly change selection even when you didn't move the stick.

So why have you never noticed this problem? Because the deadzone takes care of it for you!

Usually the default modes apply the response curve in Fig. IX to both the X and Y components of the stick position.

Fig. IX -

In other words, if the position of either axis is close to zero, it clamps that axis to be exactly zero. There is no feedback from one axis to the other, so if you
are holding the stick straight up we will return a large positive Y value but still clamp your nearly-zero X input.

It is possible to implement a circular mode. This examines the position of both axes together, and only clamps to zero if the combined stick position is close
to the origin.

The plots of Fig. below show the effect of the two aforementioned deadzone modes on the X component of the input position.

Fig. - Independent axes mode on the left, circular on the right.

And in Fig. they are applied to the Y input.

25
Fig. -

Finally, in Fig. there are both axes combined.

Fig. - Notice how the independent axes deadzone (left) stays active all the way out to the ends of the vertical and horizontal axes, while the circular mode (right) is more subtle and only
affects the center location.

You will generally want to use independent axes mode for things where the X and Y stick positions control unrelated game values. For instance, steering a
car is independent of accelerating and braking, or moving up and down through a menu is independent of moving left and right. The circular mode works
better for things where the stick input is used to choose a location on a 2D plane, such as aiming a weapon or moving the character in a Mario64 style
platformer.

You can see how the right deadzone mode can make a big difference to how responsive your game feels. So yeah, controllers are not accurate at all. You
better use a broomstick handle.

2.7 - Format & reinstall

The game files are primarily handled through the Steam client. Missing files may be restored through a 'Check of integrity of game cache' via the Steam
dropdown menu. Backup your game configuration with your replays, screenshots and setups stored in the username\Documents\Assetto Corsa folder, if
you'd like to format your hard drive or do a clean reinstall.

If you have a modded pirated version of AC that doesn’t work anymore, try uninstalling the mods first. If it still doesn’t work you can try installing the same
version on another PC to retrieve the main files and copy them replacing the ones that don’t work. It can be time consuming, and often it’s faster to reinstall
everything from scratch instead of debugging. Otherwise search for a completely different pirated copy. Or buy the game when on sale if you can afford it.

2.8 - AC root folder

Basically the Assetto Corsa’s install folder. Linking it on your desktop will become super useful later when modding the game. How can you find it?

1. Open Steam and go to your library (Fig. VII).

2. Right-click on Assetto Corsa and select the Properties;
3. Select the Local Files tab and click on the Browse button;
4. A File Explorer window will open within the install folder; go in the parent directory (steamapps\common), right-click on the assettocorsa folder and
select Send To > Desktop (link).

26
Fig. VII – Nothing much to say, just follow the steps in order from left to right.

If you changed the destination folder during the Steam setup, or you have a pirate copy of the game, you should know where you installed it better than me.

Throughout this manual, we will often refer to the AC install folder like the following: %root%\assettocorsa

2.9 – Can I play Assetto Corsa on Linux or Macintosh?

Yes, you can, but you may have to put some effort to make it work.

Performance would be very bad in VR through emulation like Parallel. Just running the game would be bad through parallel on a screen.

On Mac Bootcamp is the best (and probably the only) solution. Even if in theory you port AC to the Mac OS, you can have problems with the Force
feedback (for ex. Logitech G25/27 doesn’t support FFB under several versions of Mac OS)

On Linux there are some alternatives:

 Install Steam from your distribution's software application, log into Steam, enable Steam Play in the settings, restart Steam, install the game.
 Using Lutris, a free open-source gaming platform that installs and launches games from Steam automatically.
 Other options are: dual boot Linux-Win (but then what’s the point of using Linux?), use a virtual machine with Windows (really slow, huge loss of
performance), use Wine (can be difficult to set up), or use Protontricks (it can potentially run very well, but it’s not worth the effort unless you're ready
to tinker with it and have a lot of patience).

And yes, you can host an AC dedicated server on Linux, so multiplayer is possible.

2.10 – Test setup used by Kunos

For reference, Kunos used the following setup bench for testing purposes (presumably support for bugs and fixes):

CPU: Intel Coffee Lake i7 8700k 4.7Ghz

Motherboard: AsRock Z370 Extreme4
RAM: 32GB Corsair DDR4
Storage: 2 x SSD Samsung EVO 970 M.2 1Tb | 3 x SSD Samsung EVO 860 500Gb
GPU: Asus ROG Strix GeForce RTX 2080 SUPER OC Edition
Monitor/display: Samsung Q4970R 3840x2160 | Oculus Rift S
OS: Windows 10 Professional
Audio compartment: Native Instruments Komplete 6 / AKG 240mkII / M-Audio BX5 D2 + Creative Sound Blaster Z / Magnat Monitor Supreme 5.1 set
Seat and controllers: R-Seat S-1 | Thrustmaster TS-PC | Fanatec Clubsport Pedals V2 | Thrustmaster TH8RS Shifter | DSD Sequential Bent

As a small addition, it is known that a Ks dev was using the following setup:
27
CPU: Intel i5-3570@3.40 GHz (OC 4GHz+)
Motherboard: AsRock Z77 Extreme
RAM: 16 GB DDR3
GPU: Zotac GTX 970 4GB
Monitor/display: Asus VG248QE 1920x1080
OS: Windows 8.1
Controllers: G110 + G400s + G27 | TrackIR 4

2.11 - Game performance characteristics

This game runs in two primary CPU threads: one for physics, the other one for everything else. It is CPU limited in single-player and GPU limited in
Multiplayer. In contrast to many other PC games, Anisotropic Filtering (AF) has a big impact on FPS. Higher Anti-Aliasing (AA) settings require an
increasing amount of GPU memory. Combining AA and FXAA yields the best AA outcome. Raising a single value, AF or AA, may not result in optimal
resource management and/or overall high graphical fidelity. Since AF and AA have almost the same impact on FPS, and AA a high impact on GPU memory,
a high AF and a low AA setting provide a compromise in FPS, graphical fidelity and resource usage.

Other settings with a relative high impact on performance are Motion Blur, Depth of Field, Reflection Quality and Reflection Rendering Frequency.

Also, the HUD apps can reduce the framerate.

3 - Game Configuration & graphics settings

3.1 - Default vanilla keyboard shortcuts
You can change almost all the keys in the options; some are fixed and not customizable, for example the function (F1-F12) numbers.

While in the vanilla AC launcher menu

F11 : Toggle fullscreen/windowed

During any session

Up/down arrows : Throttle/brake
Left/right arrows : Steer left/right
X : Shift Up
Z : Shift Down
L : Headlights
H : Horn
Q : Glance left
W : Glance right
CTRL +A : ABS on/off
CTRL +T : Cycle traction control modes between ON / min<TUNING<max / OFF
CTRL +H : Toggle UI (HUD) apps ON/OFF
CTRL +O : Restart the session
CTRL +L : Toggle drivers/opponents names ON/OFF
CTRL +M : Toggle mouse steering ON/OFF
CTRL +G : Toggle automatic shifter ON/OFF
CTRL +I : Toggle ideal racing line ON/OFF
CTRL +Q : Toggle damage display ON/OFF (it shows up when you take damage and will remain active after you take a lot of damage)
CTRL +J : Show damage display
CTRL +C : Enable AI driving the car
CTRL +numpad 3 : MGU-H (Motor Generator Unit – Heat) mode (hybrid vehicles only)
Numbers (1-0) : Live turbo adjustment (for cars that support it)
F1 : Cycle car cameras
F2 : Random cameras
F3 : Track cameras
F5 : Free external orbit camera (available for player’s car during race and for selected car during replays)
F6 : Extra car cameras
F7 : Free camera
F8 : Take screenshot
F9 : Cycle between bottom screen/compact leaderboard and ON/OFF
F11 : Toggle virtual rear mirror ON/OFF
+/- : Adjust FOV in-car
Page Up/Down : Adjust exposure (HDR)
\ : Open/close console (works in vanilla and if console is not disabled in CSP settings)
ALT+F4 : Quit session immediately (if your boss enters the office!)

VR (OCULUS)
CTRL +Space : Re-center view
Look L +Look R : Re-center view

28
Replays
CTRL +R : Start replay
CTRL +Space : Pause replay
CTRL +S : Slow motion (during replay)
CTRL +D : Rewind
CTRL +F : Fast forward
CTRL +P : Skip to previous lap
CTRL +N : Skip to next lap
CTRL+1 : Switch to previous opponent car
CTRL+3 : Switch to next opponent car
CTRL+2 : Switch to player’s car

During multiplayer sessions

CTRL+1 : Switch to previous opponent car
CTRL+3 : Switch to next opponent car
CTRL+2 : Switch to player’s car

In the showrooms
ENTER : Enter/exit the car
SPACE : Open/close doors
Numpad 7 : Headlights on
Numpad 8 : Brake lights on
Numpad 0 : Animate wing 0 (if present)
Numpad 1 : Animate wing 1 (if present)
Numpad 2 : Animate wing 2 (if present)
Numpad 3 : Animate wing 3 (if present)
W : Wipers
Arrows : Move the camera around the car
Page Up/Down : Change to previous/next skin
+/- : Exposure up/down
F : Roll left
G : Roll right

Server administrator commands:

/help : Prints the list of the available commands
/admin : Become administrator for the server. For example, if the password is "kunos" the command is "/admin kunos"
/next_session : Moves to next session
/restart_session : Restart the session
/kick : Kick a user using the rules (blacklist etc) of the server. To kick a player named "The Player": /kick The Player
/client_list : Show the player list by CAR_ID: name
/kick_id : Kick a user using the rules (blacklist etc) of the server. To kick a player using the CAR_ID 2: /kick_id 2
/ban_id : Ban a user using the rules (blacklist etc) of the server. To kick a player using the CAR_ID 2: /ban_id 2
/ballast : Add ballast (Kg) on the CAR_ID. To add 100Kg to CAR_ID 2: /ballast 2 100

3.2 - Resolution & Rendering mode

Assetto Corsa will run on Single, Triple screens or on VR devices. Many resolutions in combination with many refresh rates (Hz) are available.

3.3 - Anti Aliasing & Anisotropic Filtering

As both main graphical quality options, AA and AF should be looked at first when balancing fidelity and performance. Note that AF requires more resources
in AC in comparision with other games.

3.4 - Reflection Quality & Reflection Rendering Frequency

Both these settings are responsible for the reflection quality on the car's bodywork. Reflection Quality determines the resolution of the reflection and
Rendering Frequency dictates how often reflections on the bodywork will be updated.

3.5 - Shadow resolution, World detail and Smoke generation

Lowering Shadow resolution and World detail can help increase FPS on parts of tracks with a lot of detail or many trees that are casting shadows -
especially helpful on mod tracks. Lowering Smoke generation helps to reduce the FPS drop during race starts.

3.6 - Post processing effects (PPEs)

PPEs have an impact on FPS, Motion blur and Depth of field quality more so than the rest. The headlights of the car won't glow with PPEs or Glare quality
disabled and have a diminished glow with Glare quality reduced. You may reduce colour saturation below 100%, or set the PPE preset to 'Photogenic' in
order to bring the game visuals closer to reality. Enabling Fast Approximate Anti-Aliasing (FAAA) simultaneously with normal AA will reduce FPS greatly.
FAAA is not as effective as AA.

29
3.7 - Vertical synchronization (V-sync)
V-sync is a graphics technology that can either improve your gaming experience or destroy it completely. It’s designed to sync the current refresh rate of
your display monitor with the frame rate that is being rendered by the GPU. The video card is prevented from doing anything visible to the display memory
(where the pixels are stored and then sent as frames to the monitor) until after the monitor finishes its current refresh cycle (completes the visualization of
one frame, which depends on how the pixels are turned on or off, based on the display technology, i.e. CRT, LCD, OLED, etc.).

This is in order to fix a rendering issue known as screen-tearing, which is when information from multiple frames is displayed in a single screen draw, with
artefacts (Fig. VIII). The frames aren’t in sync and show two completely different and out-of-order pieces of visual information. As a result, your gaming
experience is completely ruined and your screen only displays an annoying mess of images.

Fig. VIII – Example of screen tearing on a triple-screen setup.

This problem is due to the fact some 3D scenes are more complex than others, and thus get drawn at variable rates. Not only that, graphics cards (and
computers in general) are not perfect machines, and depending on the system and the software used (game, driver, OS, etc.) the performance is not
consistent. V-sync helps get rid of screen-tearing, trying to match the exact refresh rate of your monitor to the frame rate of the GPU. By doing so, the
image you’re seeing on your screen is smooth and always in sync.

It’s important to know that having V-sync always turned on is not a good idea. It can be helpful but it can also become a nuisance if not used under the right
circumstances.

With a 60Hz display, V-sync would force a cap of 60 fps, meaning the display will anticipate a frame precisely every 16ms. If the GPU misses this timing
requirement (takes too long drawing the frame), the display will repeat the previous frame. This eliminates the chance of “tearing” by restricting the display
only to drawing frames every refresh interval, but can cause stuttering (wait time) when the 16ms window is missed (the display will repeat the previous
frame). So the responsiveness of mouse and keyboard and any other peripheral hardware will be delayed.

All these events happen during milliseconds, so let’s adopt a timeline to visualize them, like in Fig..

Fig. -
30
Therefore, if your framerate is overall lower than your monitor's refresh rate, activating V-sync won't improve picture quality, and it’s better to turn it off.

Without V-sync, tears happen the most when the number of frames per second you render on screen is a 1x, 1,2x, 1,25x, 1,33x, 1,5x multiplier of your
display’s refresh rate. If you run the game at these precise rates, you will see a tear (or more than one) on the screen, either stationary or slowly going up or
down. Then for 60Hz displays, very common nowadays, if you disable V-sync, you should not cap your framerate to exactly 60, 72, 80 or 90 fps, otherwise
you will obtain the worst kind of tearing possible, due to the rendering inconsistency of the GPU (for example in case you get 59.8 or 61.1 fps, 88.7 or 93.2,
and similar). How it happens is based on how waves work, so you can have some sort of harmonic effects. If you ever tried tuning your guitar, you know
that once two strings have almost the same note, when you pluck them together the sound is more intense. The principle is similar, tears appear more
often.

If you don't want tearing to happen but desire to have a framerate cap regardless, you need to use a frame limit that is not a precise multiply of your
screen's refresh rate. Else, you will encounter a much more noticeable periodic phenomenon. Screen tears are only visible to human eye when they appear
in the same place constantly. This is why using non-precise multipliers is important. The tears will appear almost randomly on the screen, and because they
only stay there for less than 1/60th of a second (if the framerate is > 60 fps), it happens too fast for the human eye to spot it. This doesn't mean that going
way above 60 fps on a 60hz screen is useless.

If you don't want screen tearing, use framerates that move the tear to a different place with each screen refresh. 83 fps is a good number for 60 Hz and 120
Hz screens.

3.8 - Maximum frame latency

To be changed in graphics.ini, a file located under %root%\assetto corsa\system\cfg. Open it with a text editor and search for the
MAXIMUM_FRAME_LATENCY line of code. This is the setting of how many frames the game should render the frames in advance to what you are seeing on
screen. The default value is 0. A value of 1 may improve picture quality and Force Feedback (FFB) response.

A high number of prerendered frames can reduce stutter, but since the computer renders frames in advance and doesn't know the input the player will make
at the wheel, it also makes the visuals not sync up with what is actually happening in the FFB.

MAXIMUM_FRAME_LATENCY=1 means at most one image will be prerendered;

MAXIMUM_FRAME_LATENCY=0 means that will be used the preset of your graphics card driver which is usually 3 or 4 prerendered images.

If you installed CM, you can change the frame latency from the settings easily (Fig. IX).

Fig. IX – How to change the frame latency from the AC video settings in CM.

31
3.9 - Stuttering
Sometimes stuttering could simply be related to too high graphics quality settings in game. Try lowering step by step your video settings until you achieve a
solid frame rate. If the issue is still present, here are some scenarios can cause stuttering:

- Addon in-game apps

- Messed up config files
- Video overlay software (MSI Afterburner, Fraps, Aida64, Gpu-z and similar)
- Screen recording software (OBS, Nvidia GeForce Experience, nVidia ShadowPlay, Xbox Game Bar)
- 3rd party graphics tools (Nvidia Inspector, ATI Tray Tools, SweetFX, ATI RadeonPro and similar)
- Background monitoring (Cpu-Z, Gpu-Z, Aida64, Intel Overclocking utility and similar)
- Controller emulation software and hardware (not original x360 gamepads, motionjoy software and similar)
- Antivirus / Firewall wrong configurations
- X-fire software
As you can see, there’s plenty of potential causes that can generate stuttering in Assetto Corsa (and in any other game!). So, before writing new threads or
posts on various forums, please check by yourself your PC overall status. You can always check the background processes with Task Manager.
3.10 - Mirror resolution & High quality mirror reflection

Quality of mirror reflections - has a minor impact on FPS and should be fully enabled.

3.11 - Field of View (FOV)

The Field of View ingame should mimic your FOV sitting in a car in reality. Correct FOV is important for proper (sim-) racing & gaming and to experience a
proper sense of speed while driving. Although there has been no official word if this game uses vertical or horizontal FOV, experimental results showed that
AC features vertical FOV.

3.12 - How to disable vertical head movement?

Tick the option in the view tab for 'Lock onboard camera to horizon'.

3.13 - Glancing left/right speed

Determines the speed at which you glance left or right during driving. This option is subjective, but an increase does help to reduce the time you are
looking away from the road while driving.

3.14 – Virtual Reality (VR) devices configuration

Stabilizing the view in VR

To stabilize head camera movement during driving you have few options:

1. Enable Lock Camera to Horizon in AC View settings.

2. Use RHM (Real Head Motion). This is a newer version that works with ACC for monitors and AC monitors and VR. Settings I use, feel free to experiment
with different values.

PP Filter

The Sol_Extra post-process filter works really well with VR.

Make also these changes in the SOL Config app (which you have to install if you don’t have it):
[general]
sol__use_cpu_split = true ; splits the weather calculations in parts over multiple frames
blacklevel__compensation = 3 ; adjust for your HMD

AC VR Settings for Samsung Odyssey+

Ultra

With a nVidia GPU, force Anisotropic Filtering in driver and disable in game. See “Nvidia Driver Settings”.

High

SteamVR Settings

Disable the Advanced Supersample Filtering (Fig. X), as it can cause additional blurring.

32
Fig. X – The SteamVR video settings you should use. How to open them.

The general video settings depend on the video card you have, so you can set them as high as you want while avoiding losing performance significantly.

Nvidia Driver settings

- The AF (Anisotropic Filtering) from the Nvidia drivers works much better than the original Assetto Corsa’s, so you can override the second with the first
one in the Nvidia Control Panel (Fig. XI); this will significantly lower texture shimmering. After setting the AF, check the “Texture Filtering – Negative LOD
Bias” parameter, because it will be automatically set to Clamp, overriding the in-game MIP_LOD_BIAS settings; it is recommended to set it back to Allow.
You also have to disable Anisotropic Filtering in the AC settings as it may add some performance overhead with both enabled.

- Enable MFAA (Multi-Frame Sampled Anti-Aliasing), that will improve antialiasing quality. For example, MSAAx4 in game settings is converted into
MFAAx8 with a smaller performance impact comparing to MSAAx8 (do not expect MSAAx8 quality though).

Enabling MFAA will add a ~5% overhead to the GPU load, also at lower framerates it doesn’t work that well, and should be off. Below 30fps the time
between frames grows so much that MFAA becomes increasingly inaccurate and the human eyes pick up on the AA sample pattern changes, which means
that this anti-aliasing technique is only usable with high frame rates.

Fig. XI – The settings you may want to change for VR optimization in the Nvidia Control Panel.

Enabling Windows Mixed Reality (WMR) Reprojection

First of all, what is reprojection?

To summarise without getting technical reprojection locks your VR frame rate to 45 whenever your system can't maintain 90 fps.

33
Well, to be honest it doesn't just lock it to 45. Your rendering rate is absolutely locked to 45fps under reprojection, but the frames are interpolated, guessing
(reprojecting) every second frame. So you still get 90 fps, just half of those are not “real" frames. Saying that reprojection only locks to 45 or to 90 fps is
very misleading.

Oculus devices activate reprojection individually per frame, on demand. Video can be up-sampled from effectively any achieved FPS to 90 FPS.

The technique is not very accurate, and the effect is entirely visible and to most people, quite unpleasant. Whilst it's pretty juddery, its consistency is better,
less nausea inducing than letting the frame rate fluctuate, and it also helps approximate head tracking movement when the system might not have the time
to display your movement otherwise.

It’s basically meant to have a decent experience when your system can't keep up. Playing at 45fps is bearable. Super-sampling (SS) has made it more of an
issue as it increases the workload on your system and increases the frequency reprojection is used.

You have to find the sweet spot where SS makes a difference to you visually without SteamVR having to use reprojection constantly. And not everyone
seems to get that. You may still want it active for general use; don’t worry, it will only kick in when needed. But turning it off and enabling the frame time
monitor in your HMD (Head Mounted Display) can help identify if you're actually running at 90fps or dropping frames that reprojection would otherwise be
masking.

Then, how to enable reprojection for WMR?

Go to Steam\SteamApps\common\MixedRealityVRDriver\resources\settings and open the default.vrsettings file with a text editor, you will find this script:
{

"driver_Holographic" : {

},

"driver_Holographic_Experimental": {

// Motion reprojection doubles framerate through motion vector extrapolation

// motionvector = force application to always run at half framerate with motion vector reprojection

// auto = automatically use motion reprojection when the application can not maintain native framerate

// disabled = turn off motion reprojection

//

// Comment out or remove this line to use the SteamVR settings for controlling motion reprojection

// "motionReprojectionMode" : "disabled",

// Motion reprojection indicator to display the mode currently selected

// green = off because application can render at full framerate

// cyan = on because application is cpu bound

// blue = on because application is gpu bound

// red = off because application running at less than half framerate or motion reprojection disabled

//

// green + cyan + blue = motion reprojection half-framerate mode or application requested motion reprojection

"motionReprojectionIndicatorEnabled" : false,

To activate Reprojection for all apps set motionReprojectionMode to either motionvector or auto depending on whether you want to always run at 45fps or
only when app cannot maintain 90 fps.

Close WMR and SteamVR before making changes.

If you prefer to control Reprojection per application AND without restarting WMR every time, comment or remove this line
// "motionReprojectionMode" : "disabled",

Restart SteamVR/WMR and now you can control the reprojection settings via SteamVR Motion Smoothing (Fig. XII). The default USE GLOBAL SETTINGS
on SteamVR is same as “auto”.

34
Fig. XII -

CAUTION: Reprojection adds some GPU overhead which can push your fps down if you don’t have enough headroom.
That means when you can maintain 90fps with reprojection disabled, reprojection on auto may trigger switch if GPU can’t keep up with frametime target
anymore.

You can also control Reprojection through the new WMR option in Steam Dashboard.

Rechargeable batteries for VR controllers

NiZn (Nickel-Zinc) batteries last longer and track better due to higher voltage (1,5 Volts). They need a special charger; you can get the full kit online.

There are positive reports on rechargeable Li-ion (Lithium) batteries as well, even if those have a lower voltage (1,2 V).

3.15 - Degrees of rotation

Determines the sensitivity of the steering wheel. If the the maximum rotation is matched with your wheel's rotation, both your and the ingame wheel will
rotate congruently. You may increase them to the maximum (1180°), in order to reduce sensitivity and therefore increase steering precision of Formula
cars.

3.16 - Throttle, brake and clutch boundaries

You may adjust pedal boundaries with the white sliders. The top brake boundary may be changed, in order to reduce the necessary force required to press
your Load Cell brake pedal and still retain 100% maximum brake in-game.

3.17 - Gear shift debouncing

Adjust slider to eliminate skipping gears while shifting.

3.18 - KERS & DRS activation

Both are implemented as activatable features in the game. These are expected with the addition of the McLaren P1. Albeit the Hi-KERS system of the
LaFerrari is fully modeled.

3.19 - Steering settings

Recommended to reduce all options to minimum other than FFB gain, in order to experience the purest FFB possible. You may choose a Filter value of 1 or
2% to reduce a sudden jiggle of the wheel while driving due to road surface imperfections.

3.20 - Brake gamma

A linear brake gamma (value of 1.00) is highly recommended to have a predictable and precise braking feel.

For Load Cell users: the human foot with its plethora of pressure receptors is able to detect and react to pressure a lot better than to foot travel. A linear
brake gamma and a linear pressure increase of the Load Cell will benefit greatly from that.

3.21 - Save configuration feature

You may save any configuration of your input devices via this feature. You may have to double click on an entry multiple times for it to load properly. You
also may save a general profile each for Street-, GT- and Formula cars.

35
3.22 – Audio configuration
Racing simulators have “simple” audio needs. The driver should be able to hear his engine, so that he may know when to shift gears, without having to look
at the tachometer. He needs to be able to hear his tyres screeching, so that he may know when he had been too exuberant in his application of throttle or
brake. He needs to be able to hear the opponents who are behind and next to him, so that he may know what defensive action to take. That is all; all the
other sound effects are icing on the cake.

AC emits the sound of the engine revving, gears crunching, tyres locking up, tyres rolling over surfaces like gravel and rumble strips, brake pads grinding
their rotors, the wind rushing by. It is quite a complex ambience.

You can adjust the relative levels of these sounds in the Audio settings panel (Fig.) which you may open by pressing the Options button. While you are
there, turn off vexing things like the UI music and the video cutscenes, for more immersion. And if you hear pops and cracks, move the latency slider to the
right. Otherwise, keep the default setting.

Fig. -

AC also generates other environmental sounds: the sound of loose stones hitting the under tray of the car, when you drive onto a gravel trap; the
suspension parts rattling, when you go over a kerb; the metal-on-metal gnashing, when you trade paints with another car; the impact when you hit a barrier.
The most important noise in this cacophony is the tire screech. AC emits this noise when you lock up the front wheels, spin the rear wheels, or wrest a
reticent car into a corner. When you hear this noise, you know that you are abusing your tires. So, let your aggression be tempered by this sound.

Lastly, set the master volume at a level that matches your other games. If you use the headphones with a DAC amplifier, you may wish to set the Windows
mixer volume slider to 50%, and control the loudness using the DAC amplifier’s volume knob. And if you use your HD television as the display, you may
wish to match AC’s volume level to that of the set-top box, so that you would not have to keep fiddling about with the telly’s volume setting, whenever you
switch amongst the video sources.

4 - Driving
4.1 - Hud & apps in general
You are free to move the in-game apps to anywhere on the screen you like. Even to a different screen, if you have a triple setup. They can be fixed in place
by clicking the pin in the top right. You have the choice 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. (Image)

4.2 - Assists & ABS. Should I use them?

TC (Traction Control), SC (Stability Control) and ABS (Anti-Lock Braking System) are available in AC and can be adjusted in the driving options. The levels
of TC and ABS can be chosen on the fly during driving by CTRL+T or CTRL+A respectively. A high value for TC is less restrictive and intrusive than a low
one. Formula cars don't feature ABS and not all street or GT cars have ABS or TC. If you enable Pro settings in the driving options, all gaming aids mirror
the aids of that particular car in reality.

Professional pilots do actually use assists every day, but it depends on the racing class.

GT3 cars are designed to be driven with TC and ABS for example. Talking about F1, traction control was first introduced in 1990 because the cars were
extremely difficult to drive. As a result, it banished the driver’s fear of losing car control, at least for a few seasons. Later on in 1994, the FIA decided banned
it. However, it didn’t last long, and it came back for the 2001 season. The triumphant return only lasted until 2008, and drivers had to adapt to new driving
abilities, especially in the rain.

Meanwhile, the ABS system received its own ban in the 1993 F1 season. Once again, the sole purpose was to shift the driver away from relying on
technology and using their own skill. Even in 2021, both systems are still banned, mostly because they do little to enhance a driver’s natural ability.

Considering sim-racing in general instead, in my opinion assists only become a sort of “cheat” when they’re applied to cars that don’t have them from the
factory. If you use them correctly, there’s no reason to worry or feel bad about the help they give you.

More subjectively speaking, you'll be a better racing driver without traction and stability control. The reason is that these electronic devices interfere with the
natural handling of the car: they deprive you of important information regarding what the car is doing in a particular situation, which you need to act
accordingly, counter steering for instance.

ABS instead is very helpful and can make you more consistent.

Generally, I encourage you to drive with 'Pro' settings. In order to get used to drive without assists, you can do the following:

1. Pick a car & track combination you know well;

2. Drive with assists enabled (your current settings of stability control, etc.);
3. Drive again with Pro settings (assists off, except ABS);
4. After cursing at the gods and throwing your screen out the window, enable assists again;
5. Now slowly reduce their value (if you drove with 100% stability control, go to 90%, then 80%, etc.);
6. If you found a comfortable spot, save these settings and drive the next couple of days or a week with these;
36
7. Repeat in order: step 3, 5, 6, 7;
8. If you end up with 0% traction and stability control, you are one step closer to the driving level "Senna". You can just repeat the process with ABS.

And if you want to experience how it feels to drive on cold tyres that gradually warm up as you trot about, turn off the tire blankets. But if you want tires that
are already warmed up, turn this option on. To enjoy how the feel of the car changes as the tyres fall off their optimum grip profile without having to pound
round the track for many laps, raise the tire wear multiplier.

4.3 - Ambient & track temperature

Default value is 26°C for ambient and 32°C for track temperature. These are used for Pro settings and serve as a benchmark for competitive hotlap times.
More ambient temperature raises the track temperature as well, which yields more grip and thus faster lap times. Multiplayer servers always use the default
value.

4.4 - Replays

You can watch your races, in singleplayer or in multiplayer. There are various functions (Fig.): you can playback at multiple speeds up to 5x, the slow
motion goes down to 12x slower, there are markers for each lap, so you always know at which point of the race you are, and there’s also an often-forgotten
built-in photo mode, if you see something nice and you want to save it for the future generations (it’s a poorly implemented feature in vanilla, you better use
CSP’s photo app or other mods).

Fig. XII – The most important functions of the replay bar on PC. We have an example of a modded version too.

If you made a mistake and didn’t save the replay of a race, before starting any new session you can go to documents/assettocorsa/replay and look for a file
named “cr”, which stands for current replay; rename it and restart the game. The replay will be available to watch and saved permanently.

This “cr” file only contains the replay of the last session, whether single or multiplayer. Rename it before launching another session if you want to keep it,
otherwise it will be overwritten!!!

You can create a link on your desktop or anywhere convenient to open to the replay directory quickly.

You can save only a selection of the replay by sliding the two green corner markers to the designated beginning and end.

4.5 - Track surface grip levels

AC supports a number of different track surface conditions. In tab. below are all the available presets with their numerical values.

Optimum Fast Green Slow Old Dusty

Session Start: 100 Session Start: 97 Session Start: 92 Session Start: 94 Session Start: 86 Session Start: 83
Ramdomness: Ramdomness: 20 Ramdomness: 20 Ramdomness: 15 Ramdomness: 30 Ramdomness: 10
Lap Gain:1 Lap Gain: 20 Lap Gain: 10 Lap Gain: 60 Lap Gain: 50 Lap Gain: 18

With the dusty condition, the track is initially very slippery due to, well, dust on the track. But as the session progresses, the rolling tyres sweep away the
dust, so a faster, grippier racing line forms, gradually. Off the line, the track is still dirty and slippery.
A track in the old condition has a worn-out surface, which is quite slippery. The surface does improve slowly, as the rubber is laid down over the course of
the session.
A slow condition track is slippery, and it may improve very slowly, if at all.
A green track is a good, clean track, but without a layer of sticky rubber on the racing line. So, it will be a bit slippery initially, but improves quickly as the
rubber is laid down. This is the condition you find a typical, modern racetrack on the practice day, the day before qualifying, and two days before the race.

37
A fast track has grip from the start. This is the condition of a typical track on the race day, because rubber had been laid down heavily over the past two
days, provided there was no overnight rain that washed away the rubber.
An optimum track is for those interested in setting hotlap records.

Randomness adds or subtracts a percentage to the starting grip. Example: session start at 86 and randomness at 30 means that the starting grip is 86%, but
with a random margin of +/- 3%. Think that even 1% difference is CLEARLY noticeable while driving.
Lap Gain: number of laps per car to add 1% grip to the tarmac surface.
Grip values and a 'Transfer_grip' value can be individually set in the server_cfg.ini in a dedicated server client. Example scenario:
- the session starts with 90% grip; at the end of the session, the grip is raised to 97%
- spread is 7%
now:
- if you put 100 in session transfer, you'll get 100% of that spread in the next session, so you'll get 97%
- if you put 50, you'll get 50% of that spread in the next session, so it will start from 93.5%

4.6 – Setup guide for simracers

Basic concepts (special thanks to Giulio Scrinzi, www.drivingitalia.net)

Setup is the nightmare of every simracer: you started training with a car you like, with which you feel you have a certain feeling. Step by step you realized
that you were able to put together a qualifying lap, as well as maintain a decent pace for the race. Then that was the moment when you went online to
challenge real opponents, and not the traditional, as much as predictable, artificial intelligence.

After the initial euphoria of the moment and perhaps some well-deserved success... behold, you meet someone faster than you. You try to push your car
beyond the limits, but you always pay that one second difference that gives you frustration. The reason? You may already know: given the same vehicle and
track conditions, your rival has a better setup than you, which gives him the advantage you don't have.

Compared to any other video game area, if approached seriously, simracing (simulated-racing) requires specific knowledge in order to maximize the
potential of a racing car. Throwing yourself into the various screens to modify the setup without knowing what you are doing is not only inadvisable... but
also counterproductive! That is why this guide exists, and it will go through every aspect in the setup of an automobile. Let's start with the basic concepts
that every virtual driver must necessarily know.

In particular, the focus is on beginners, all those drivers who have approached driving simulators recently and want to internalize notions that may prove
extremely useful when the time comes to tackle competitions of some degree of importance.

In fact, this guide can also serve already seasoned simracers with years of experience behind them, who want to brush up on the basic concepts and, then,
the more specific ones in finding the optimal setup for their favourite car. As well as for all those drivers who, so far, have been driving with the basic setup
base provided by one of the many simulators available on the market today.

The information you will find in the various parts of this guide, in fact, may find application on Assetto Corsa as on rFactor 2, passing through sim-cade
titles such as F1 2019 or others that are more simulative such as iRacing or Assetto Corsa Competizione.

Why modify the setup?

Let's face it: the various titles that make up the simracing world are already capable of providing highly competitive basic setups in the right hands. Of
course, not every car can be pushed to the limit, but it is no accident, for example, that there are series on iRacing where the setup is fixed for everyone,
where it is therefore possible to concentrate exclusively on driving, rather than getting lost in the details of modifying the suspension or the aerodynamics.

The same can be said for Assetto Corsa's Sim Racing System, which regularly features races with locked setup: along with the "casual racing" of simcade
(sim-arcade) titles such as F1 2019, these alternatives are definitely the best in order to learn driving fundamentals, as well as well as the various techniques
of defense and attack when it comes time to confront one's opponents on the track.

Why, then, modify the various parameters of a vehicle? The answer is: to know the true potential of the vehicle you drive.

One thing is certain: changing the setup cannot work miracles. Instantly using the setup of the best driver in the leaderboards will not allow you to obtain
the same time and to be as competitive. Before going to touch the parameters of a car, you need to know the most about its behaviour: what its reactions
are in slow turns, in fast ones, whether it suffers from understeer or oversteer, whether it bounces on the asphalt or loses grip under acceleration.

When you have found a certain feeling with the car you are driving, that will be the moment to move on and "create the setup". This procedure will allow
you to gain more confidence between the curbs, go faster and, as a result, lower your lap time considerably. Not only, modifying the basic setup will make
more pleasant to drive all those cars which, as it is, are difficult to "digest" both in qualifying and, especially, in longer stints.

How to modify the setup?

In real motorsport, and consequently also in simulators, a racing car represents an extremely complex system to manage: we are not talking about an
engine pushing a chassis and four tires controlled by a steering wheel! Many other parameters come into play, including differential, tire pressure, weight
distribution, suspension calibration, and aerodynamics, just to name the most important and widely known ones.

Working on the setup therefore represents a very complex challenge for a novice: it is not just a matter of changing a couple of settings.
38
In the world of virtual driving, in fact, a driver is at the same time a track engineer, whose job is to scrupulously analyse the handling of the car he is driving
to identify any possible problems that may affect his performance. Once recognized, he must be able to find the solution, acting scientifically on the setup:
this means making one change at a time and testing it with a couple of laps of the track to verify its effectiveness, keeping all other variables unchanged,
such as circuit conditions, air and asphalt temperatures or on-board loads.

Quick setup suggestions (special thanks to @L’Alessandro)

The following table shows which adjustments you can make to correct the car setup as a general rule. For a very specific case you should focus more on
solutions valid for the type of vehicle you’re driving.

QUICK SETUP FOR… PARAMETERS IF THE CAR UNDERSTEERS… IF THE CAR OVERSTEERS…
Corner Entry SLOW BUMP (suspension) DON’T AFFECT increase decrease
SLOW REBOUND (susp.) CAMBER increase decrease
BRAKE BIAS to the rear to the front
DIFFERENTIAL COAST decrease increase
FRONT TOE decrease increase
FRONT WHEEL RATE (springs) DO AFFECT decrease increase
REAR WHEEL RATE (springs) CAMBER increase decrease
FRONT CAMBER increase decrease
REAR CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT WING INFLUENCE increase decrease
REAR WING THE TOP decrease increase
FRONT HEIGHT SPEED decrease increase
REAR HEIGHT AND CAMBER decrease increase
Cornering SLOW BUMP (susp.) DON’T AFFECT increase decrease
SLOW REBOUND (susp.) CAMBER increase decrease
DIFFERENTIAL POWER increase decrease
DIFFERENTIAL COAST decrease increase
FRONT CAMBER DO AFFECT increase decrease
REAR CAMBER CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT ARB (Anti-roll bar) INFLUENCE decrease increase
REAR ARB (Anti-roll bar) THE TOP increase decrease
FRONT WING SPEED increase decrease
REAR WING AND CAMBER decrease increase
FRONT HEIGHT decrease increase
REAR HEIGHT decrease increase
Corner Exit DIFFERENTIAL POWER DON’T AFFECT increase decrease
REAR TOE CAMBER decrease increase
FRONT WHEEL RATE (springs) DO AFFECT decrease increase
REAR WHEEL RATE (springs) CAMBER increase decrease
FRONT CAMBER decrease increase
REAR CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT WING INFLUENCE increase decrease
REAR WING THE TOP decrease increase
FRONT HEIGHT SPEED decrease increase
REAR HEIGHT AND CAMBER decrease increase
Factors affecting tire temperature PARAMETERS TO OBTAIN > Temp TO OBTAIN < Temp
SLOW BUMP (susp.) increase decrease
TIRE PRESSURE decrease increase
WHEEL RATE (springs) increase decrease
ARB (Anti-roll bar) increase decrease
TOE increase set towards 0°
CAMBER increase set towards 0°
Bumps IF YOU LOSE CONTROL OVER A BUMP, YOU SHOULD…
FAST BUMP (susp.) decrease
FAST REBOUND (susp.) decrease
HEIGHT increase
WHEEL RATE (springs) decrease
Height IN GENERAL AND RAKE SETUP
Adjusting the heights in a setup (as well as the wings) is critical to distinguishing a performance setup from one which isn’t.
Generally speaking, there is a tendency to reduce the height of the car as much as possible in such a way such that the
aerodynamic load of the drag-generating ailerons and the roll of the car are reduced. However, there are special settings that
generate more aerodynamic load at the cost of top speed and drag, without changing the aileron incidence, which is
particularly appreciated at medium-fast circuits like Spa and Silverstone.
In the so-called Rake set-up (widely used in F1 cars) the front nose height is smaller than the rear, thus forming an angle
from 1° to 4° and facilitating the job of the car's bottom and the diffuser, which generate load aerodynamics with very little
drag. However, it is necessary to adjust the ailerons accordingly to restore the top speed.

39
Useful setup suggestions:
Camber: More negative camber means the outside wheels will have more grip during turns, but less grip during acceleration and straight-line braking.

Suspensions: Softening them gives the car more grip but it may feel like a boat. Stiffening them will produce a snappier behaviour. This means that the
vehicle will be more responsive to changes of direction, but will also manifest a more frequent tendency of losing control.

Bump and rebound have a simple logic: bump is how you set up your suspension to work when it compresses. Rebound is when it expands/extends. So,
for your front wheels, bump will affect braking and rebound will affect acceleration. For the rear wheels it's the opposite, since the rear lifts up during
braking, so the suspension expands. Also it affects the steering, since turning to the right will make the car roll to the left, so the left wheels will use bump
and right wheels will use rebound. On the left-hand turns, it will be inverse. In general, I prefer to set bump and rebound to symmetric settings between
left/right sides because I don't want to overcomplicate stuff.

Let me give you a few examples:

Car is understeering on corner exits when I apply throttle. This means the front lifts too much and front wheels lose traction. I will make rebound for the
fronts softer, in order to give more room to the wheels to contact the ground.

Car is understeering on corner entry. I will make bump softer on the front tyres, in order to make the weight of the car land smoother on turn-in.

Same logic can work for the rear suspension.

Fast Bump and Fast Rebound have similar usages, but they affect the very rapid movements of suspension on kerbs and potholes.

Also, the same principles apply to ARB (Anti-roll bar). The stiffer it is, the less the car rolls when turning. This will make the car more responsive to change
of direction, but it may reduce traction during turning. Making it softer will result in more body roll, which will make the car sway, but also more grip in
turns.

Aero: This is probably the easiest to understand, but still there are some tricks. More aero means more downforce, which means better grip on medium and
fast corners. Aero will not play a big role for speeds below 100 Km/h.

Now here's the catch. Increasing rear downforce means that you will have more grip in the rear wheels during a turn, but this means that the weight of the
car might shift slightly to the rear. So in most cars this has a negative effect of the grip of front wheels. This will probably affect you during braking after big
straights. You will see that a higher rear downforce gives less traction to front wheels, and might slightly increase your braking distance.

For cars that have front and rear downforce adjustable, this problem can be controlled by changing both parts in a similar way. This will let you
increase/decrease downforce as a total without hurting the overall aero balance.

Keep in mind that aero also affects suspension, since it pushes the car lower, but you may not feel the difference.

Differential: Assuming you have a RWD car, making your diff more "open" will make the wheels spin more under hard acceleration, but they will not cause
oversteer. This will make you slower out of corners (because wheel spins instead of producing acceleration), but more stable. The technical explanation is
that if a wheel has less traction (usually the inside wheel on a corner), more power will go to that wheel, which means that the spinning tyre will not be able
to stick to the ground, and the grippy tyre will get less power. That's how open diffs work in general. They are found in most consumer cars because they're
cheap and simple.

On the other hand, making your diff stiffer will reduce slip in your diff and make it act more like a closed diff, which means that both wheels will keep getting
some percentage of power. The percentage is adjustable by the diff setting. This setting will ensure your outside wheel gets power and car accelerates
faster. The problem is that it's easier to lose control and cause a spin. Essentially, drift cars have stiffer diffs in order to help both wheels spin during the
turn, so you understand that a stiffer diff is more inclined to cause oversteer, but this is also faster for a race car.

Some cars have separate controls for the diff during acceleration and coasting (when you let off the gas). The same logic applies.

4.7 – Driving techniques (special thanks to Rick Haslam and Nick Stokes)
The racing line

A racing car must take a bend or a series of bends at the maximum possible speed and reduce the shape of the corner to its minimum possible angle. The
best racing line can be seen as being made up of three distinct points on the bend:

A) the turn-in point, usually at the end of the braking area and the position when the car actually enters the corner.
B) the apex or the clipping point. This is the slowest part of the bend and the point where the car is nearest to the inside of the corner.
C) the exit point when the car is back on a straight line. This is usually the fastest part of the bend.

Obviously, the best racing line also depends on the driver and the car. Is he trying to overtake another car into the corner? Is the corner before or after a fast
straight? Is the track surface wet or oily? All these considerations come into play and the driver must adjust his line accordingly.

40
Typical corners and bends

A driver must try to use all the available space on the track, even the rumble strip-the run off area on the edge of the tarmac.

In a typical corner, for example a righthander, the driver arrives on the left side of the track, brakes, changes down, checks for his turning-in reference point
then steers the car towards the clipping point on the inside of the bend. Once past, he eases back to the other side smoothly and exits the corner.

Driver priority must be to get power back on as soon as possible to achieve maximum speed into the straight.

Here we have some of the most common types of corners you can find on any track, along with a brief explanation on how to take them.

- Fast Corner - 90 Degree Turn

Fig. XIII - Most of the racing circuits have a corner of this sort that can be taken Fig. XIV - There are many different ways to turn into this type of corner
at speeds in excess of 140mph. The driver turns in at A, passes the apex at point depending on whether the driver is about to overtake, but the classic approach is
B then keeps his line all the way through to exit point C. The driver makes no to turn in late at A, pass the apex again late at B, and accelerate fast from that
sudden turns on the wheel and the whole process should be very smooth. point to get a good clean exit at C.

- The Constant-Radius Corner - Double-Apex Corner

Fig. – There is a very long apex on this type of corner so there is no gain in Fig. - The key to negotiating this type of bend is to make one corner out of two.
taking the entry point late. The driver turns in early at A then stays close to the The driver aims for the ideal line and stays inside the track’s width, effectively
contact points B and B as long as possible. As he leaves the apex, he crosses making the exit line of the first bend the entry line of the second. If the line is
the track and touches his exit point at C. perfect then the driver does not have to correct his steering.

41
- Hairpin - The Tightening Corner

Fig. - The aim here is to turn in late to create the widest possible angle so that Fig. - The car stays wide so that the driver can touch the apex extremely late at
after point A the bend can be treated like a fast corner. The sharp initial turn is B, then brake, select a lower gear, cross the track following the curve of the bend
vital to make the car as fast as possible out of the hairpin. When point B has and get a good clean exit at C.
been touched the driver can safely put his foot down before reaching point C.

- The Opening Corner - The ‘S’ Bend or Chicane

Fig. - The driver turns in early at A, covers the short distance to the apex B then
smoothly moves to the outside. This allows the last phase of the bend to be
driven like a straight and the driver can accelerate quickly long before passing
point C.

Fig. - Ideally, a good racing line can straighten out some bends without the need
for sudden turns. The driver turns in slightly at A approaching the first right-
hander, then clips points B, B, B with hardly any modification before exiting at C.

42
- Tight Corner After a Fast Bend - A Long Straight After Two Identical Corners

Fig. - The important point about this series of bends is the approaching straight.
The driver turns in late to the right-hander and hits the clipping point well into
Fig. - Take a tight line into the fast right-hander but brake as the second point B
the bend. He then takes the fast left-hander as though the previous bend had not
approaches. The car must slow down to take the left-hander but this is not a
existed. Thus the first corner is taken slowly to give the car as much benefit as
problem, for the driver has gained speed in the first two thirds of the series of
possible from the oncoming straight.
bends.

- Cornering in Wet Weather

Fig. - Taking the classic right-angle corner as an example, it’s easy to compare the dry line with the wet line. The driver takes up position in the middle of the track, keeping
off the outside line which is likely to be very slippery. The line he drives will be cleaner and give far better grip in the rain. The car is kept in the middle of the track as it
passes the apex then steers for the outside line. The main aim of drivers in wet weather is to look for maximum grip.

43
Reaction of car through a corner

- Understeer - Oversteer - Neutral handling

Fig. - An understeering car means that the rear wheels Fig. - An oversteering car means that the front wheels have Fig. - The ideal situation, as the sideways drift of the rear
have better grip than the front wheels and so the car will better grip than the rear wheels. This can possibly be wheels is matched by those of the front. All four wheels
not react fully to the driver turning the wheel. Since F1 because of too much power or because the car balance is slide in the same way. The driver sets up the car on entry
cars are rear-wheel driven, the vehicle will begin to poor. This tends to make the back end of the car slip out to the corner, so the front wheels are straight and the
move towards the outside of the track. towards the outside of the corner. The consequence might driver doesn’t have to steer.
be the car spinning off altogether!
The driver in such a situation can do one of two things:
ease up on the accelerator, making the driving wheels To counter oversteer a driver can do one of two things:
push less, giving the front wheels a better chance to opposite lock on the steering wheel might just establish
grip; if the car still does not respond, brake lightly the car’s balance; otherwise easing up on the accelerator
without locking the wheels. The car will slow down will slow down the car and give the rear wheels a chance
enough to give good grip to the front. to grip. There are also certain times when drivers might
accelerate, but knowing when to do this comes with
experience.

Marker points

To set up the ideal racing line on a circuit you must find as many markers as possible to use as reference points. The individual tracks provide 300, 200,
100 metre boards before a bend but these are too general for most drivers; many rely on advertising boards, bumps in the track, certain trees or bushes for
turn-in points, braking zones or accelerating areas.

In fact, the driver must know every square metre of the circuit and the markers, once memorised, allow the driver to think ahead, to anticipate the next
corner. Imagine you are accelerating through a fast straight. When you see the marker for the braking zone into a bend, your mind will be already thinking
about the next marker for the turn-in point. As this is passed, you are thinking about the apex marker and finally the exit point. Think ahead. Look out for the
next marker. Don’t wait until you see it to react.

Braking

- Ideal Braking

In Formula One the driver aims to keep his foot down on the accelerator as long as possible. When he gets to a corner, he will wait until the last moment
before braking and then brake as hard as possible over the shortest possible distance. The only reason to brake should be to achieve the best speed for
entering a bend and the only reason for removing your foot from the accelerator must be to “jump” to the brake pedal.

Ideally, there should be no compromises with braking.

- Wheel Lock

Braking hard can present the driver with another problem; that of locking wheels. It’s possible to lock up one, two, or even all four wheels if you brake too
hard in a given situation. A locked wheel is no good to anybody. The tyre wears out excessively on the locked patch and this creates a flat spot which will
feel like violent bumps when the wheel is turning again. The tyre will be out of balance and the car almost impossible to control. To avoid wheel lock, the
driver must be sensitive enough to brake hard and to detect the first signs of lock-up.

Changing down

Changing down into a lower gear must always accompany the act of braking. One without the other is not good driving. The aim is to brake to the ideal
speed for the approaching corner then change down in order to be in the right gear for the moment you need to accelerate again. Changing down is done
as you brake. Any earlier and the car will still be at full speed; any later and the driver has too much to do in mid-corner.

Overtaking

If you’re not at the front of the grid in every race then chances are that you will need to overtake other cars at some point.

44
Overtaking is not just a matter of more power in your engine. It usually boils down to three factors.

1. Can you take a corner better than a rival?

2. Can you exit a corner faster and enter a straight at a greater speed?
3. Or, can you brake later than a rival at the end of a straight?

To overtake successfully, especially against a determined rival, you must be aware of the driver ahead.

1. Where is he slowest?
2. Where does he brake earlier?
3. On what part of the circuit is he the least confident?

Eventually, you will have a good picture of his strengths and weaknesses. You must make his worst manoeuvre your best, wait for the right moment then
make your challenge.

All the above assumes that the driver ahead will not make a mistake; but all drivers make mistakes during a two hour race, so take every opportunity offered
to you and wait for that error!

- Driving faster through a corner than a rival

The driver ahead is not confident through a certain corner. Choose your moment. Leave a space between the two cars so that he can’t force you to slow
down. Just enough room to let you attack the corner at the speed of your choosing. When you leave the corner you will have more speed than the other car.
The faster exit speed gives you the advantage to overtake in the following straight.

- Slipstreaming

Yes, there is the slipstream effect in AC (Fig.).

Fig. -

Slipstreaming is a phenomenon that usually occurs at speeds above 70mph. Catch a rival car on the beginning of a long straight and get very close behind
him (within a few inches).

Both of you are travelling at the same speed but you are in a small area, a few metres long, which is free of air turbulence. The car ahead is doing all the
work while you gain mph. You can tell that you are successfully slipstreaming by the loss of turbulence and the gain in acceleration.

By now you’re probably travelling at 140mph just inches behind the rival car. You wait until the last possible moment then slip out to the side of the other
car. Although you will now be subject to the same forces of turbulence, your speed gain during the sheltered period will give you the edge to move slightly
ahead.

- Outbraking a rival car

If a driver has managed to get a lead on a rival in the previous straight and is now on the inside line for the next corner, he must try to brake a little later into
the bend, giving himself right of way.

45
If the rival driver stays in contention, around the outside of the track, he is in danger of spinning off. It’s important to close the door after you exit the corner,
especially if the rival car is trying to get level again.

Fig. –

Take a strong position off the ideal line, in the centre of the track and make his overtaking attempt as difficult as possible (trying not to make accidents).
You’ll find mirrors to be actually very useful in these situations.

Common driving errors

- Overrevving

This is possibly the most common way a driver can ruin his engine and put himself out of the race. Changing down too early before braking sufficiently is
quite common among inexperienced drivers. A driver must be a third of the way into the braking zone before changing down. It is quite tricky to get this
right in short braking bends but in longer braking areas you can use markers for gear change points.

A second common way to overrev is by exiting a corner and not changing up at the right time; quite easy to do if you’re busy controlling the car through a
difficult bend.

Fortunately, modern Formula 1 cars are fitted with electronic rev limiters that prevent engine damage and bad gear changes. In AC this feature is
implemented for vehicles that actually have this kind of devices.

- Loss of control

The most common ways of losing control of your car in a race are:

1. Going into a corner too fast, giving strong oversteer.

2. Accelerating out of a corner too fast.
3. Under braking when there is too much bias on the rear wheels.
4. Mechanical failure. In AC mostly suspension/steering rack damage.
5. Oil, sand, dirt or grease on the track. This is not present in vanilla AC.

In all cases, as soon as the driver feels the loss of control, he must brake hard while keeping his revs up to prevent stalling. If possible, he must keep the
car on the circuit, for once it touches the grass the spin will speed up tremendously.

Spinning off before reaching the apex of a corner will result in the car moving across the track to the outside of the bend. Generally, the inertia that it retains
will send it off in an arc similar to the early shape of the corner (Fig.).

Spinning off after the car has passed the apex of the corner will often give the driver a better chance of staying on the track, for although the car will be
moving faster it is more likely to follow the exit profile of the curve.

Trying to slow down the car going onto the sand or the grass can be another solution.

46
Fig. -

If all else fails, just lift your feet from the pedals and let the car stop its own movement; obviously this may result in a crash.

WIP

4.8 - Fuel

The estimated laps for the current fuel load in the car setup options can only be calculated after a full lap has been completed (only with enabled fuel
consumption). This estimation will gain accuracy with more laps driven in the same sitting.

4.8 - In-game telemetry

AC has a basic telemetry interface (Fig.). It’s very useful for sim-racers who want to improve their skills. Not really useful for mod creators who want a
debug tool, since the data displayed is more related to what the driver does than what the vehicle does.

Fig. – The basic telemetry GUI inside any AC track session. You can monitor brakes, speed, gas and shifting. It’s a very simple instrument to evaluate your driving skills. In this
example the interface is slightly modded, so the icons on the left of the screen may be different on vanilla.

47
No information will be displayed if you haven't driven the current combination. You'll see red lines representing your fastest lap. You'll see white lines after
you've driven at least one complete lap afterwards - they always represent your last full lap. A higher white line than the red one means you applied more
throttle, brake, you were in a higher gear or were faster (speed). You can compare values by hovering over them with the mouse thanks to the yellow
vertical cursor.

Remember, this plot is normalized to distance, not time or speed. More time could've been gained or lost in slower sections of the track, than on fast
straights.

5 – Multiplayer

5.1 - Dedicated server configuration

A simple solution to configure your dedicated server is given by the Assetto Corsa Server Manager software (Fig.) which you can find under the path
%root%\assettocorsa\server.

You can also modify the same settings the old school way with the entry_list.ini and server_cfg.ini scripts inside %root%\assettocorsa\server\cfg. Start your
server by executing acServer.exe.

-entry_list.ini

Specify here cars and players, if pickup mode is enabled. Leave list empty for booking mode. The former mode doesn't work, if this list is empty. The skin
name must match the folder name of that skin. GUID is the converted steam ID (see 4.10 Steam community ID) but is not required for Pickup mode to work.
[CAR_0]
DRIVERNAME=Driver 1
TEAM=a
MODEL=abarth500
SKIN=Cinnabar_red
GUID=765411978771115547
SPECTATOR_MODE=0

[CAR_1]
DRIVERNAME=Driver 2
TEAM=a
MODEL=bmw_m3_e30
SKIN=Jet_Black
GUID=FAKE_CLIENT_0
SPECTATOR_MODE=0

[CAR_2]
[…]

-server_cfg.ini

The values don't have to be in a specific order. Below you find the script with explanations for the parameters.
[SERVER]
NAME=AC_Server ; Name of the server.

CARS=bmw_m3_e30;bmw_z4_gt3;lotus_evora_gtc
TRACK=magione;aosta_grand_sport_v2.0

% ▲ Specify available cars and tracks on the server. Their names must match the ones of the specific folder(s) in %root%\assetto corsa\content\cars (or
\tracks). Remember to distinguish them with the semicolon ( ; ), without spaces.

CONFIG_TRACK=
SUN_ANGLE=48 ; Specify the Time of Day via this value. Default value is -7.

% ▲ Some examples of SUN_ANGLE values:

08:00 = -80
09:00 = -64
10:00 = -48
11:00 = -32
12:00 = -16
13:00 = 0
14:00 = 16
15:00 = 32
16:00 = 48
17:00 = 64

PASSWORD=yourpassword ; Server user password key.

ADMIN_PASSWORD=mypassword ; Server admin password key.

UDP_PORT=9600
TCP_PORT=9600

▲ % Both UDP & TCP ports must be identical. Select your server ports and forward them in your router. The values are dependent on the individual server
configuration.

HTTP_PORT=8081
PICKUP_MODE_ENABLED=1 ; Default value: 0

% ▲ Select only if you want to use Pickup mode. Remember to fill out entry_list.ini afterwards.

LOOP_MODE=1 ; Important to enable to reduce server load. Default value: 1.

% ▲ The server will cycle through the specified sessions, if no cars are registered on it.

SLEEP_TIME=1 ; Default value: 0.

CLIENT_SEND_INTERVAL_HZ=18 ; How often the server will update the player cars’ position on the track. Default: 15. [Hz]

% ▲ Increase it for better multiplayer quality and better collision detection. Higher values cause higher server load.

SEND_BUFFER_SIZE=0
RECV_BUFFER_SIZE=0
RACE_OVER_TIME=180 ; Race end fade-out time. Default value: 20. Common value: 300. [s]

48
% ▲ How long the server waits to fade to black and reset all cars on track to their pit boxes after the winner finishes the race.

KICK_QUORUM=85
VOTING_QUORUM=80 ; What percentage of votes YES / NO will trigger the action in question. Default value: 75.
VOTE_DURATION=20 ; How much time the voting window lasts. [s]
BLACKLIST_MODE=1
FUEL_RATE=100 ; Default value: 100. Value in percent - adjust if needed.
DAMAGE_MULTIPLIER=100 ; Default value: 100. Value in percent - adjust if needed.
TYRE_WEAR_RATE=100 ; Default value: 100. Value in percent - adjust if needed.

ALLOWED_TYRES_OUT=2 ; Default value: 2 = normal penalty system enabled. 4 = penalties disabled.

% ▲ Values =1 and =3 have not been properly tested.

ABS_ALLOWED=1 ; Determines user freedom over the Anti-lock Braking System.

TC_ALLOWED=1 ; Determines user freedom over the Traction Control.

% ▲ For ABS and TC specifically: 0 = Always off; 1 = Factory settings, if the car features it, the user can enable/disable it, if it doesn't, it's
always off; 2 = User defined.

STABILITY_ALLOWED=0 ; Determines user freedom over the Stability Control.

AUTOCLUTCH_ALLOWED=0 ; Values: 0=no, 1=yes. Value determined by organizer.
TYRE_BLANKETS_ALLOWED=0 ; Common value: 0. Sometimes at Formula events: 1
FORCE_VIRTUAL_MIRROR=1
REGISTER_TO_LOBBY=1 ; Default value: 1. Must be enabled for either mode to work.
MAX_CLIENTS=18 ; Common value: same as max pit boxes on particular track. Default value: 25.

% ▲ Value has to maintain the number of available pit boxes for a particular track to eliminate any error messages during login.

UDP_PLUGIN_LOCAL_PORT=0
UDP_PLUGIN_ADDRESS=
AUTH_PLUGIN_ADDRESS=
LEGAL_TYRES=SV

[PRACTICE]
NAME=Practice
TIME=10
IS_OPEN=1

[QUALIFY]
NAME=Qualify
TIME=10
IS_OPEN=1

[RACE]
NAME=Race
LAPS=5
WAIT_TIME=60 ; (Buffer-) time before this session starts. [s]

% ▲ You may increase it for the race, in order for participants to load their race setup, adjust the fuel load and get ready for the race in general.

IS_OPEN=1

[DYNAMIC_TRACK]
SESSION_START=89
RANDOMNESS=3
SESSION_TRANSFER=80
LAP_GAIN=50

[WEATHER_0]
GRAPHICS=3_clear
BASE_TEMPERATURE_AMBIENT=18
BASE_TEMPERATURE_ROAD=6
VARIATION_AMBIENT=1
VARIATION_ROAD=1

[WEATHER_1]
GRAPHICS=7_heavy_clouds
BASE_TEMPERATURE_AMBIENT=15
BASE_TEMPERATURE_ROAD=-1
VARIATION_AMBIENT=1
VARIATION_ROAD=1

1. Dynamic_track
Default values:
SESSION_START=100
RANDOMNESS=0
LAP_GAIN=22
SESSION_TRANSFER=0

Values may vary between regions and events. Look up section 4.5 Grip levels / Track surface for further information.

Admin commands

Look at par. of this AC guide for those

5.2 – LAN Multiplayer (wip)

Via Ethernet cable

Possible with Port forwarding

to create your own LAN-server, you must use the acServerManager.exe located here ...\steamapps\common\assettocorsa\server\acServerManager.exe

includes all settings, cars, tracks, number of players up to 32 total.

49
6.0 - Errors and Troubleshooting
This paragraph is dedicated to the troubleshooting of your AC installation. Keep in mind that if you modded your AC installation, especially with CSP, you
may encounter any kind of bug or error, and do not expect to be able to fix it! If you play with mods you do it at your own risk!

GENERAL SUGGESTIONS

If you encounter errors of any kind, you can try the following:

 Run a Steam cache integrity check for AC; be aware that an integrity check resets all modified files to their original state, and overwrites all sorts of mods, like weather,
shader and sound mods.
 Launch the game and reconfigure all the options from scratch.
 Don't forget to check and eventually set the proper resolution/refresh in the video options.
 Rename your Assetto Corsa folder located inside the user Documents;
 If you didn't rename the folder above, then remove any python addon apps you've installed. To do this, delete the python.ini file in the Documents\Assetto Corsa\cfg path,
then delete the apps folder located in your %root%\assettocorsa install folder;
 If you are still facing issues, DON'T WRITE messages on any forums or social platforms reporting "I have the same issue!", because 99% of the time the same result
doesn't mean the problem is related to the same cause. Open your own thread, explaining your issue, describing the scenario the best you can, and attaching your logs
located in Documents\Assetto Corsa\logs. Many skilled users will help you as soon as possible.
 AC developers (Kunos) do not support AC anymore, so they won’t answer questions related to this software in the official forums. The support is active for Assetto Corsa
Competizione (ACC) only!

Usually, these steps fix the most common issues users are facing.

In some scenarios, unsupported or misconfigured third party software may be the cause of the problem. Try the following:

 Check that your controller is plugged in a USB 2.0 port (avoid USB 3.0 if possible);
 Update/reinstall Python software: https://www.python.org/ftp/python/3.4.3/python-3.4.3.msi
 Update/reinstall the graphics card drivers and DirectX software: https://www.microsoft.com/en-gb/download/details.aspx?id=35
 Reinstall VS Runtime (x86 & x64) with the latest: https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads
 Update/reinstall Microsoft .NET 4.6: https://www.microsoft.com/en-us/download/details.aspx?id=48130
 Update/reinstall Microsoft .NET 4.5.2: http://www.microsoft.com/en-us/download/details.aspx?id=42642
 Update/reinstall Microsoft .NET 4.0: https://www.microsoft.com/en-US/Download/details.aspx?id=17718)
 If you can't reinstall .NET, please use the Microsoft's Repair Tool: http://www.microsoft.com/en-us/download/details.aspx?id=30135
 If you are on Win10 and you can't update/repair your .NET installation, open a cmd prompt with admin privileges and run the command: sfc /scannow
 Close any video overlay software (VirtuMVP, Fraps, XFire, MSI Afterburner, Rivatuner and similar monitoring/video recording software);
 If you are a Nvidia GPU owner, disable Shadowplay and the Nvidia Capture Service in Task Manager. Use other programs to record your screen;
 Double check CPU and GPU temperatures;
 Check Windows user's privileges (set Steam and Assetto Corsa with admin rights);
 Temporarily shut down any antivirus or firewall (or be sure that you have exception rules for acs.exe and assettocorsa.exe executables);
 Last but not least, ask your best friend. Sometimes users can find the solution in just 30 seconds.

Many issues are discussed in section below as well. (oh boy this part will take a lot of time to complete)

- The server will shut down in loading screen - Make sure to type in the right password for the server.

- No text in loading screen, assettocorsa.exe will freeze – Try closing any other program open.

- Missing content, file errors - Run a 'check integrity of game cache' via steam context menu.

- kernelbase.dll error on Windows 10 – KernelBase.dll is a file stored in the system folder of the operating system. It is created automatically during the
installation of the OS and it’s used to launch .exe applications. When it is corrupt, you will get a .dll missing or not found error when you start the programs.

You can follow the methods below to fix this problem.

Method 1: Register the .dll file

1. Tap on the Windows key on your keyboard and type Command prompt.
2. Right click and Run as administrator.
3. Type: regsvr32 KERNELBASE.dll
4. Restart the computer and check.

Method 2: Copy the same file from another computer.

I would suggest you to copy KernelBase.dll from another computer running the same version and edition of Windows.

The location of the file differs in each system based on the architecture. If it is 64-bit, then it is located in C:\Windows\SysWOW64. If it is 32-bit, then it is
located in C:\Windows\System32.

Method 3: Create a new user account.

50
The reason might be due to user account corruption, so I would suggest you to create a local user or administrator account from the settings and check if
the issue persists.

Note: From the newly created account you will not see all your personal files under your default file location (i.e. the Documents folder). Your data will be
saved under C:\Users\Your_previous_user_name.

- UIAutomationCore.dll error - Check that this file exist: C:\Windows\System32\UIAutomationCore.dll. If not present, go to
C:\Windows\winsxs\amd64_microsoft-windows-uiautomationcore_31bf3856ad364e35_6.1.7600.16385_none_0c0d85465bcceb37

And from there copy/paste UIAutomationCore.dll to the C:\Windows\System32 directory.

If AC still doesn't start after copying the file, open a cmd prompt as admin, then type without the quotes "cd C:\Windows\System32" and press enter. Then
type exactly:

regsvr32 UIAutomationCore.dll

Do the same as above for C:\Windows\SysWOW64\UIAutomationCore.dll. If not present, go to: C:\Windows\winsxs\wow64_microsoft-windows-

uiautomationcore_31bf3856ad364e35_6.1.7600.16385_none_16622f98902dad32

And from there copy/paste the UIAutomationCore.dll to the C:\Windows\SysWOW64 directory. Again, only if AC still doesn't start after copying the files.
Open another cmd and run as admin then type without quotes "cd C:\Windows\SysWOW64" and press enter. Then type exactly as below:

regsvr32 UIAutomationCore.dll

- The game doesn't start at all when launched - Make sure the pre-requisite libraries have installed properly, you can find them in the AC install folder by
right-clicking on Assetto Corsa in Steam then Local Files > Browse Local Files.... Navigate to the _commonredist folder and run the setups for all the
included redistributables. Pay attention to any error messages you might get and make sure no antivirus or such software blocks their installation. These are
normally installed automatically on first run, but occasionally they will output errors which are not reported to you by Steam;

Use Steam's cache integrity check. Open your Steam games library, right click on Assetto Corsa and select Properties. Click Local files and then Verify
integrity of Game cache;

Check your installed Windows updates. If you have the KB2670838 update, please uninstall it and try if the game starts properly.

Also, some users have reported that they cannot start the sim if their main audio device is disabled. Obviously, enabling it solves the issue.

- Grey screen after introduction - Press F11. This will make the game's launcher exit full screen. In some configurations it has been reported that setting
AssettoCorsa.exe to run as administrator worked to by-pass this issue.

- The race session doesn't start when you press "start engine" - First thing to check is your video resolution in the video options. Then the windows firewall
dialog might be requesting access for acs.exe - accepting the rule exception addition can solve this. If the dialog doesn't show up, you might have to go
through the windows control panel options for the firewall and set it to allow acs.exe.

- AC runs smooth but every 3-5 seconds it freezes for half a second or less. It’s the same on high and low settings – May be a FPS problem. Make sure
that the refresh rate in your game and on your monitor are the same. Try also turning off the framerate limit and Post Processing filters. To understand if the
problem is the GPU, reduce the resolution to the lowest supported by your hardware and if you still get stuttering, you can completely rule out the video
card. That means it’s something to do with either your hard drive or the RAM. Otherwise, if you don’t, try updating or reinstalling the video drivers. You can
always try verifying the AC integrity via Steam.

- System crash while playing followed by an automatic reboot - You're likely getting a blue screen and have windows set to auto-reboot on such (you can
disable that to see the stop error by pressing Win + Break, go to Advanced > Startup and Recovery Settings and under System failure uncheck Automatically
restart).

Regardless if you disable auto-restart or not, to see which driver component is causing it, you can get Bluescreenview:
http://www.nirsoft.net/utils/blue_screen_view.html

This small software will go through the minidumps windows have recorded and it'll report the component at fault. Otherwise, you can use the built-in
system administrative tools if you know how to use them. You can find them in the dear old Control Panel.

- .NET 4.0 not installing and returns a 0xc8000222 error if invoked manually - You can find the installer in the AC install folder, navigating to the
_CommonRedist\DotNet\4.0 folder.

Before installing .NET Framework 4.0 by running dotNetFx40_Full_x86_x64.exe:

1. Press your Win key and type cmd, then right click on the result and select "run as administrator"
2. Once in the command prompt type in command "net stop WuAuServ" to disable windows update
3. Then press Win+R and type in "%windir%" at the pop-up window, it will take you to your windows installation folder
4. Find the folder SoftwareDistribution and rename it to SoftwareDistribution.old.
5. Then, go back your previous command prompt and run the command "net start WuAuServ" to restart windows update

51
6. Finally try again to install .NET Framework.

- User Interface too large - If you cannot scroll down to the options button to go to Options > General and then check Ignore Windows display-scaling
settings (you need to restart the launcher for it to take effect), you can edit your launcher.ini found in %UserDocuments%\Assetto Corsa\cfg and add
IGNOREDPI=1 under the [WINDOW] section.

- Stuck in Steam VR Home scene. AC audio coming out from the headset when in game, only no video - First and foremost, double check to make sure the
Content Manager / AC video settings are for OpenVR/Oculus (it must not be Single Screen).

If the problem still persists, open the Steam VR settings from either the Steam VR Status Dock or while you are using Steam VR. In the bottom-left you
should see the Advanced Settings, make sure it is set to SHOW. Now go into the General tab, turn SteamVR Home and Pause VR when computer is locked
to OFF.

Another thing to try if the error still occurs - in the regular Steam Settings > In-Game tab, uncheck the box labelled Use the Big Picture Overlay when using
a Steam Input enabled controller from the desktop.

Lastly if this still occurs I would suggest checking the AC settings in Steam Library and in the General tab, make sure that the Use Desktop Game Theatre
while SteamVR is active box is unchecked.

Almost forgot to mention, make sure you check with Task Manager (Ctrl + Alt + Del) after shutting the game down and confirm there are no instances of it
left running. Anytime you adjust settings in CM, you need to close and open the game for it to update effectively.

- 99% CPU Warning - Your CPU is at peak load. The exact number of your CPU’s load may not be accurate. The load indicators of the Windows Task
Manager are not necessarily correct - 100% CPU load is only accomplished by benchmark software like PRIME 95. The AI is only calculated on one
dedicated CPU core, try reducing grid size or overclock your CPU (if you decide to). Also, Assetto Corsa scales with raw clockspeed very well. Beware that
overclocking your hardware components may void their warranty. Many mod tracks are not as optimized as Kunos' tracks and may require more CPU
performance. AMD CPUs seem to be more prone to this issue than Intel's ones. If you’re a mod maker, always keep in mind the performance optimization of
your cars or tracks.

With CSP you can hide the CPU Warning message and let Windows manage the multithreading, so that the load will be split between the cores evenly.

- Discord app conflicts - Since July 2017, users report a conflict between Discord app and Assetto Corsa. If you have Discord installed, please fully close it
(double check it is not just in the system tray) and try if the sim works. Also, if you use the CSP mod, this problem should be fixed.

- ASUS SONIC SUITE II conflicts - Some users report showstoppers when the Sonic Suite software is enabled. Please fully disable it in order to make
Assetto Corsa work again.

- MSI GAMING APP issues - Some users report heavy stuttering by keeping the MSI Gaming App enabled. Please kill it.

- AMD Gaming Evolved app - Some users report showstoppers with the AMD Gaming Evolved app enabled. Please close it.

- Problems with Windows 10 users that upgraded from a previous MS-OS (MicroSoft Operating System) - Sometimes just upgrading to Win10 doesn't
work with all programs or games, you need to make a clean install; this is possible in the System options > Updates > Recovery. Keep in mind that this can
delete your beloved files and folders, so always make a backup of them first!

It can also help to reinstall the C++ packages (both x86 and x64), Microsoft .NET Framework, DirectX APIs and libraries. You can find the installers in the
following path: %root%\assettocorsa\_CommonRedist. The root is the path where AC is installed.

- My wheel doesn't work as expected after Windows 10 updates - By default, Windows 10 has the "automatic drivers update" feature enabled. In some AC
updates, this created troubles with some wheels. To solve the issue, unplug your controller(s), uninstall the related drivers and software (e.g. Logitech
Gaming Software / Profiler, Fanatec Control Panel and so on), reboot, then install them again (downloading them from the official websites or using the
original CDs/DVDs). Plug in the controller(s) and you should be fine. Just to be sure, please assign controls in game from scratch. You can also disable the
auto update in the system options (only if the problem persists).

If you want to disable the aforementioned feature, please read here and do it at your own risk: https://www.intowindows.com/how-to-stop-windows-10-
from-automatically-updating-drivers/

- Controllers are not detected in game - Go in Steam client > Settings > Controller > General controller settings. Disable everything.

- How to use menus with mouse-steering enabled - Pressing CTRL+M toggles mouse steering functionality on and off so you can access the in-game UI.

- The car veers left/right even when the joystick is not being touched - Recalibrate your controller in the Windows device settings and see if you can adjust
or increase the deadzone. That should be able to fix the potential joystick drift you're experiencing. Otherwise, try with a different controller or your keyboard
to eliminate the possibility of stick drift. You might not notice an issue in other games, but different games use different dead zones; this is the amount you
have to push the stick to activate it. Racing games have a smaller deadline so any issue with the controller in that range of controller input will show.

A brand new controller should solve the issue.

52
- Pressing a little the throttle pedal sends the engine to full revs – Calibrate the pedals. Check with the Pedals app that the input you give with your foot
corresponds to what the indicators show. You can also try moving the throttle slider axis in Content Manager up to 25%.

- No input from wheel and pedals – Try using your keyboard first. If it does work, delete the controls.ini file in your Documents\Assetto Corsa\cfg and re-
assign the controls from scratch in the AC controls settings (Fig.). Don’t worry, that file will be recreated. Then save the configuration in a preset (choose a
name). AC saves the last controller type selected, even when you don't connect it before opening the game.

Fig. – The Main and the Advanced wheel configuration in the vanilla Assetto Corsa launcher. To access this wizard go in the Options menu, then Controls > Advanced.

- Wheel shakes and oscillates left and right when driving - Usually this issue is related to a too high Force Feedback gain parameters. Assuming that your
Windows profiler settings are at default, you can try the following method:

1. Lower the Gain value; lower also the FFB enhanced effects, especially the Road parameter. You can try this combination for example: 50% FFB / 30%
Curbs (Kerbs) / 40% Road / 5% Slip.
2. If you want to reduce rotational force, you will simply have to turn down Gain. To enhance the feel of the road, increase Road Effect. This effect amplifies
the road feedback that is already there. So, the best name for that is "Road Effect Amplification".

The explanation of this issue, that happens especially on straights, is that FFB wants to show the user that the track is bumpy, so you have peaks in both
directions that result in the shaking. In corners it’s not as bad because you have an acceleration perpendicular to the trajectory, directed to its center.

53
- Wheel off center in-game even though it’s centred in real life – Try recalibrating the wheel. This implies using the wheel’s software and drivers, not the AC
options. The Assetto Corsa configuration wizard is there to help out people who don't really know how many degrees lock-to-lock their wheel has and it's
highly dependent on user input (obviously, since controllers do not report degrees of rotation); there is no calibration being done, nothing of that sort:
calibration is left to the controller drivers. Think of it like a quickstart guide, a simple step-by-step approach to control configuration that helps you get the
most basic controls set up and ready. Obviously anyone with some sort of experience in setting up simulators will likely not need it at all.

54
6 – Easter eggs
Like every other game, Assetto Corsa has little details that people miss almost always; here are some of them.

Fig. – This is written on the fire extinguisher in the Mercedes-Benz AMG GT3, on the passenger side floor. Ever thought about falling into the void?

Fig. – You can find this one on the Porsche 911 GT1-98. But to understand it you need a lot of “knowdlage”. Be careful.

Fig. – Track: Monza 1966. This is the stele made in 1948 to commemorate Arturo Mercanti, the Italian aviator who decided to build the circuit when he was president of the Automobile
Club of Milano in 1922.

55
Fig. – ‘Gina, the name Sebastian Vettel gave to his Ferrari SF70H, abbreviation of “Regina”, which in Italian means “Queen”. Is there any easter egg in my manual?

Fig. – Nope, I won’t tell you about this one, but it’s official; as you can see with modded AC looks 10 times better. If you want to get nuked you’ll have to find it. Hyped now?

56
7 – Curiosities
- A small version of the game “Pong” had been made by Stefano Casillo, entirely playable inside AC as an app. It’s not available anywhere.

Fig. – This was just a little experiment done in an interview back in 2012 to show the possibilities offered by AC in terms of moddability. You can see the ball (the green square) on the
right.

- Lines of code:

Did you know that since version 1.6 AC has a parameter dedicated to its simulation value?

You can find the parameter that influences how much AC is a simulator in the assetto_corsa.ini file inside the assettocorsa\system\cfg folder:
[ASSETTO_CORSA]
SIMULATION_VALUE=0 ; Value that determines the accuracy of the simulation. Inputs are numbers 0-10.

% ▲ This parameter overrides the standard physics settings, tuning the simulation. It is advised to leave the value as is, since the feature is
experimental. A value of 10 guarantees the knowledge of the universe.

You feel like you need more simulation? I only see 2 possible explanations here:

1. You did not increase the SIMULATION_VALUE enough;

2. You're too good at this.

Be aware that this line of code can turn up the physics so much that you can get out of the car and have a smoke.

Obviously this is a joke. In 2016 there was a group of people that kept saying AC has no simulation value because of some issue that was solved years
before. It became a meme and this was Kunos firing back a few shots (and me too here hah).

I wonder if the guys that were criticizing AC before set the variable to 1 and thought it was better. I wouldn't be surprised, because you actually have to set it
to 10…

57
8 - Photo album - a tribute to Kunos
A lot of work went into making AC a reality. I believe it’s fair to show and remember the people who pushed hard behind the scene. Many of these photos are from the early
years, but I believe they show more the true passion and joy that is always there at the beginning of every project. Thanks everyone - A&M

The Radiator Springs Racing team (RSR) meets part of the Kunos Simulazioni team back in 2012. From left to right: Maurizio Gilles, Mario Gilles, Andrea Lojelo, Luca Mosca, Mauro
Delega', Marco Massarutto, Stefano Casillo, Aristotelis Vasilakos and Fulvio "Gek" Genova holding the Assetto Corsa car plate.

Aristotelis Vasilakos, Jay Ekkel, Alex Hummler, Thomas Jackermeier, Alexander Loodin Ek, Georg Ortner and Marco Massarutto at the 2012 edition of the 24h of the Nürburgring.

58
Kunos Simulazioni (in this picture Marco Massarutto and Stefano Casillo) spent some hours at Evotek Engineering, an innovative company specialized in Automotive Design &
Research near Maranello. Evotek developed an innovative motion simulator, powered since 2011 by a prototyped version of Assetto Corsa. The Kunos team visited their partners, who
showed them some upgrades of their system and the new pedal set that will equip the cockpit.

Different timelines, different cars. And lots of wheels, it’s almost like a dispenser.

59
Fanatec CEO Thomas Jackermeier tries AC at the Kunos headquarters.

A little Pagani. Sometimes it’s nice to take a look at miniature models of the real thing. It evokes the inner child.

60
Kunos Simulazioni is a very disciplined company with proper hierarchy and great cooperation spirit. Here you can see the production manager and the physics modeling responsible
having a polite and civilized discussion...

Journalist John Denton having a go with the simulator for a review. Guys, do not insist too much…

61
Fanatec CEO Thomas Jackermeier visited once again the Kunos Simulazioni headquarters and went for a drive on the Vallelunga track using the car of the Assetto Corsa Licensing
Project Manager, Marco Massarutto.

62
Gathering data from real Tatuus open wheeler racing cars. Testing with Giovanni Martinez and Raffaele Bocchini.

63
One of the most inspiring Sim-racing related photographs ever. Lord Kunos (Stefano Casillo) programming in a pit box, with the Pitlane in the background. That is dedication.

A stack of Thrustmaster gear ready to be tested on the Assetto Corsa development version. After Fanatec it is the second brand of hardware that supported AC in the fullest.

64
Kunos working on VR when they received their Oculus Rift development kit.

The AC sticker applied to a Tatuus PY 012 as a teaser.

65
Renders of the Pagani Zonda R model during development.

Safety first. Development previews of the classic driver with helmet. The background on this presentation shot, shows us a laser scan of the historic Monza banking.

66
Working at the Nürburgring.

The KS development team shared a render showing the progress of the Nissan GT-R NISMO GT3 model soon after was announced a new license bringing the NISMO brand to AC.

67
Other preview shots showing renders of the Nissan.

Preview screenshots showing a clay model render of the BMW M4. After Marco Massarutto had driven the real world car at the Vallelunga circuit, he decided to try and license the
model for use in AC.

68
The 1993 DTM Champion Nicola Larini testing the development version of Assetto Corsa in his legendary Alfa Romeo 155 DTM. I see a Larini immersed in memories with a slight
smile. Mission accomplished.

69
Racing and time attack driver Jeff Westphal visited the Kunos Development studios testing a virtual Ferrari 458 GT2 at the Nordschleife. It is stated that Jeff was very impressed by the
fidelity of the car on the laser scanned version of the Ring. Developer of the vehicle physics is Aristotelis Vasilakos, behind him.

Showcase of the Lamborghini Huracan GT3 model being developed. The clay render of the car shows that the outer body was already completed.

70
Professional racing driver Ken Dobson visited the Vallelunga racing circuit for a test of the Scuderia Cameron Glickenhaus car. Ken took the opportunity to have a go at Assetto Corsa
driving the Ferrari 458 GT2 and upcoming Corvette C7.r GTE on the laser scanned Nordschleife.

71
Development preview of the Ferrari LaFerrari.

Taking a break right on that corner of Spa may seem a bit dangerous, but don’t worry, everything will be very, very fast…

72
The original shot for the game cover, with the Ferrari FXX K.

When Assetto Corsa launched into Early Access on Steam on the 8 November 2013.

73
The Assetto Corsa Development Team in 2016.

74
75
THE SOFTWARE YOU WILL NEED

You will have to use a good amount of software through this journey: most of the following programs will let you do the same things, but each one can
make the difference, thanks to different features that you may even ignore at the beginning.

What you will work with depends on how you “feel” the software and your experience with it.

Look at the list below for the programs used the most by AC modders. If I really had to choose here, I would try everything. This doesn’t mean you need to.

To begin with, you have to use a 3d modelling program; below are some (anything that does polygonal 3D modeling (not CAD) can be used, as long as it
can create dummies and export correctly formatted .fbx files; for more info, see pag.):

 Blender (https://www.blender.org/download); a free and open-source 3D creation suite. It supports the entirety of the 3D pipeline: modeling, rigging, animation, simulation,
rendering, compositing and motion tracking, even video editing and game creation. I’d say the learning curve is not too steep. It's just really, really, really long. I suggest
you to use Blender if you don’t have money to spend on software and you don’t want to deal with corporate licences; there’s also a huge community that can help you if
you need tutorials, guides, explanations or suggestions. Plus you can do cooler stuff.
 Autodesk 3D Studio Max (https://www.autodesk.com/education/edu-software/overview); often called 3DsMax throughout this manual, this software is mostly used to create
and edit game models. Kunos developers usually work with 3DsMax and other similar products of the same kind, so now you know what professionals use. Such a
program can be expensive to buy, but you can get a free licence available for students or educators on its website. Strange enough, it’s quite buggy.
 Autodesk Maya (https://www.autodesk.com/products/maya/overview); being mainly a 3D animation and visual effects software, maybe you should avoid it.
 Autodesk Softimage (https://www.autodesk.com/products/softimage/overview); just avoid it. We know for a fact that the developers at Kunos did use the 2013/14 version of
this software in the old days, but it’s outdated and has been replaced by 3DsMax and Maya by the same company (Autodesk), with a last release in 2015. In the official
car pipeline 2.0 (info at p.) there are still instructions dedicated to it: you can ignore them (they have been kept in this manual, but are of no use).

For textures, you can use:

 Adobe Photoshop (https://www.adobe.com/products/photoshop.html); in order to work with .dds textures you’ll need to install a free plugin, we’ll see how later); this is a paid
program, but you should be able to save a few bucks with a student license.
 Gimp (https://www.gimp.org); free and open-source. DDS editing is built in since release 2.10.10 so no plug-in is needed, unlike Photoshop. Sadly its DDS filter is pretty
bad by default in terms of dithering and colour-accuracy.
 Photopea (https://www.photopea.com); want to bring modding around? This is a nice online texture editor. A lot of people every now and then complain about not having
access to Photoshop, cs2 is slow as hell and Gimp is just, well, ugh. I’ve been searching around for free alternatives since I’ve been at home 150 miles away from my
computer with a valid Adobe account for a few weeks. Has support for all the psd, png, dds etc. files that you will encounter in AC. It’s free and a decent alternative with a
recognizable GUI. The DDS will default to DXT5 without mipmapping which is nice as well.
 Inkscape (https://inkscape.org); a very useful software if you need to work with vector graphics, which are different from raster graphics (those can be edited with
Photoshop and similar instead). This will prove its worth when it comes to recreating very detailed logos, for example on car liveries, from real photos.
 Adobe Substance 3D Painter (https://www.adobe.com/products/substance3d-painter.html); if you need to create textures from scratch, this is the tool for you. It’s widely used
in game and movie production as well as in product design, fashion, and architecture. It’s a go-to 3D texturing app for creative professionals. Has got a huge asset library
with thousands of 3D models, materials, and lights. Sadly, it can't export .DDS natively, so you’ll have to export to .png and import back into Photoshop.
 FontForge (https://fontforge.org/en-US); what do you do if you can’t find online the right font for your vehicle’s cockpit display text/numbers? You create a new one! As a
bonus, it’s an open-source software.
 Paint.NET (https://github.com/paintdotnet/release/releases); since apparently Microsoft Windows doesn’t like to open or preview .dds files, we’ll use it for that purpose2. It will
also allow us a quick editing. It’s a freeware software. When making skins for cars however it’s better if you use the options above.
 MS Paint (MS Windows accessories); If you can, use it on Win 3.1, where you can actually improve the graphics. I hope you aren’t this desperate, after all I suggested
many other free programs; inspires nostalgia, I get it, but there are many improved clones out there, for example PicPick (https://picpick.app/en), which while mimicking the
MS Office style has more functions, contrast correction, brightness adjustment and color balance to name a few.
 Adobe provides CS2 for free now (provided you follow their terms and conditions, etc) and it is just as good as any other program. If you chose that one
remember to take note of the Serial number that they provide to you.

You’ll need also a text editor to work with the various configs all over AC’s data folders; you can choose between:

 Notepad (MS Windows accessories); there is nothing more spartan; yes, it is reliable, but that doesn’t make things easier.
 Notepad++ (https://notepad-plus-plus.org); much better, adds colours, formatting, file management along with tabs, encodings, macros, and much more; one of my
favourites.
 TextPad (https://www.textpad.com/home); very similar to Notepad++, slightly better for programming.
 Visual Studio Code Editor (https://code.visualstudio.com); used the most by software developers, it’s a professional tool and can help by finding errors (in code syntax)
for you; it’s more advanced than a text editor, and it isn’t exactly a word processing utility.
 AutoEditor (https://github.com/leBluem/AutoEditor); made specifically for AC modding, may lack a lot of features you need/want. Not for newbies at all.

2
If you want to enable the preview of .dds textures in the File Explorer windows (MS-Win 10), you have to right-click on any .dds file, select Open with > Choose another app > in the message
box that will open, titled How do you want to open this file?, look at Other Options > select Paint.net and activate the checkbox Always use this app to open .dds files. Then click on OK.

76
 WinMerge (https://winmerge.org); if you want to compare different configs it’s very simple. It may be more useful while swapping physics between cars.

For our data collection, you will have to put some effort in your research with:

 Sheets of paper and a pencil? Yeah, sometimes you’ll want to write down something quickly, the old-school way.
 A standard Internet browser. You can choose any you like, but I recommend Mozilla Firefox because it’s open-source. I like that philosophy.
 Tor Browser (https://www.torproject.org/download); when you can’t find something on Google what do you do? You stop? No, you search on the deep web darling. Use the
DuckDuckGo search engine in combination with Tor. You’re scared? I am not. Get a good VPN for your internet connection.
 qBittorrent (https://www.qbittorrent.org); This software is one of the best (others are μTorrent and BitTorrent) for downloading torrent files (if you ever need to). Using a
torrent client and downloading torrents in itself isn’t illegal, as you can be downloading things that aren’t protected by copyright. I do not encourage downloading pirated
content, but you may search for ebooks, manuals and documents of all kinds. Just keep to yourself what you find, and be aware that there are differences between
countries: in some downloading copyrighted content for personal use is permitted, while in others isn’t, or sometimes the copyright law may not be enforced at all. You
do it at your own risk, while I’m only licenced to die, like us all.
 PDF and Ebook readers. During your research, you will often find yourself in need to open digital manuals and books of any kind, so use Adobe Reader or Foxit
Reader for PDFs, and Calibre for Ebooks (.epub). However you may not be able to read titles protected with DRM.

For calculations and graphs, you’ll need some worksheet editors and data analysis software:

 MS Excel (MS Office Suite); we sold our soul to capitalism, but there are always open-source alternatives, like LibreOffice Calc (which honestly I don’t like) or Google
Sheets (it seems a bit too simple for what we’ll have to do);
 WebPlotDigitizer (https://automeris.io/WebPlotDigitizer); with this program you can analyse images of graphs and obtain raw data automatically;
 Geogebra (https://www.geogebra.org/download); you can visualize in a Cartesian plan many mathematical functions and expressions with this software. You will need it, trust
me. I suggest you to use the Classic version.
 Lotus SHARK (https://www.lotusengineering.com/engineering-software); suspension design tool by Lotus. Very useful to make suspension physics. Sadly, it doesn’t have all
the existing suspension types, and you will need a licence, it’s not free;
 MoTeC i2 PRO (https://www.motec.com.au/software/latestreleases); useful telemetry tool to check what’s up with your vehicle. You’ll have to install the AC Telemetry client
app (ACTI). More about it later.

And for the sound? To provide a custom sound to your creations, you will need to install:

 Fmod Studio 1.08.12 (https://fmod.com); it’s the AC audio engine. This specific release, because AC supports it. Don’t use an older\newer version, it will cause bugs;
 Audacity (https://www.audacityteam.org); Probably the simplest yet most useful audio editor to modify your sound samples, it has also a ton of third-party plugins available.
There are also similar audio editing programs, like Goldwave (the interface maybe is a bit confusing at first) or Wavosaur (for people that love simple, old-school GUIs).
 Adobe Audition (http://www.adobe.com/products/audition.html); very similar to Audacity in many aspects, after all you’re always editing waves. One of the professional
solutions;
 ETG (Expression Tone Generator) (http://voicesync.org); Really useful to create formula-generated sounds. You can export wave files. It can be fun to experiment with
and may be useful when making noise and pure tones. Downloadable for free at https://download.cnet.com/Expression-Tone-Generator/3000-2170_4-10100942.html.
 Fmod Bank Tools (https://forum.bigant.com/thread-5237.html); This tool lets you extract the audio samples from a pre-existing Fmod soundbank in the wave format (.wav);
the export encoding should be PCM, Sample Rate 48khz, Bit Depth 16 Bits.

You may want to quickly make or edit mods sometimes, so here you have some utilities/programs that can come in handy:

 Content Manager (https://acstuff.ru/app); the best alternative launcher for AC with cool features to manage mods and edit assets, this will speed up the workflow a lot, as
you won’t have to launch the entire game every time, it will just launch the race session quickly and easily.
 3DSimEd (http://sim-garage.co.uk/3dsimed3-download); this tool can be useful only if you know what you’re doing; if not, avoid it. An issue for example is that it disables
objects casting shadows arbitrarily. 3dSimEd is not meant to edit AC cars, it's for conversions between games. It should be avoided by newbies (experienced people
already tend to avoid it), but you can use it to reverse-engineer mods if you want to learn, for example exporting kn5 models to fbx. This program is worth mentioning
here for this very reason.
 QuickBMS (https://aluigi.altervista.org/quickbms.htm); a little tool you can use to unpack AC data.acd files and models. More about it later on.
 Ninja Ripper (https://www.ninjaripper.com); an experimental utility for extracting geometry from 3D games using DirectX 11 and exploring it in a 3D editor.
 Swatchbin Texture Converter (https://tdohmn.webnode.page/swatchbin-texture-converter); a tool used to convert tex maps from Forza games to other formats, including
DDS10, PNG and BMP.
 Race Track Builder (RTB); not recommended; adopted by some to create circuits, it will let you get decent results quickly, but will never go beyond that. It's not
optimized for AC (nor race circuits in particular; its strength is point to point rally), so if you want good hardware performance you will have to do a lot of external work.
The usage of this program will not be discussed in this manual.

When you want to download/upload mods, you need a general-purpose software to open and eventually compress files/folders in archives:

 7-Zip (https://www.7-zip.org/index.html); free, without advertisements and simple, yet very functional. A must-have.
 WinZip (https://www.winzip.com/en/download/winzip); how much time has passed since I used it for the last time? Probably decades.
 WinRar (https://www.win-rar.com/start.html?&L=0); after the trial period you will be bombarded with annoying messages. For the little it does, this probably should’ve been a
free tool.

77
 PART 2:
CAR MODDING

78
INTRODUCTION
If you’re just wondering, as someone who doesn't know anything about AC modding, “Where should I get started?”, “How hard would it be for me?”, then
you came to the right place.

First, you need to have a level of insanity sufficient to commit hundreds, if not thousands of hours to creating toy cars and tracks for a video game.
This point is probably the most important. It is not a hyperbole. If you're coming here with no knowledge of polygonal 3D modeling, image editing, general
video game asset creation processes or the moderate level inner workings of modding for AC, you will literally spend thousands of hours to finish your
project, at least if you want to produce something good and satisfying.

It’s easy to begin looking into the process of making a car, getting it in-game, and feeling completely overwhelmed by the complexity.

Still up for it? Well, maybe in this manual I will be able to help you become conscious of the various steps, making things easier and more efficient this way.

There are already tutorials on car modding for Assetto Corsa out there. However, I feel they don't treat the subject as a whole. Example - the
car_pipeline_#.pdf 3 included in the Assetto Corsa installation (usually under C:\Program Files\Steam\steamapps\common\assettocorsa\sdk\dev). It's long
and complex, and has a lot of useful information. But it concentrates too much on the graphical side and not enough on the rest. And that makes it not so
straight forward to succeed with your first car mod. I personally like to start simple and once that is clear, continue to build on it. If you're anything like me
then please, keep reading.

What you see, does NOT matter.

Well, it matters if you want to make a top mod, and boost immersion, of course. And that should be our ultimate goal. But from AC engine's point of view,
you could drive a cube. Or you could simply drive on thin air. Under the hood, a complete working car looks like in Fig 0.1.

Fig. 0.1 - A bunch of dummies with specific orientation and names. You probably won’t need to use them all, it depends on the car. The selected cube is for the front left wheel.

...While what you actually see, could be this. Just the pilot hovering. But still, a working "car", see Fig. 0.2.

Fig. 0.2 - Technically a fully functional Subaru Impreza huh?

3
The hashtag is the release number; the first one by Kunos was 1.03, while the latest official version was 2.0, came with the AC update 1.14.3 and is called AC_Pipeline_PUB_Rev2.0. This
document will be an unofficial 3.0 manual.

79
The point is, do not be distracted by the visual mesh. All the work is done by the dummies, also known as NULLs, helpers, empties, nodes, etc. (Fig. 0.3),
and their naming, along with their hierarchy.

Fig. 0.3 – Some examples of dummies in Blender (3D editor); the first one will be the most useful for our job, as we need to know the orientation of the axis.

For those familiar with 3d animation, AC is working in the same way: dummies act like an interface between what the user wants to see and what the graphic
engine understands. Create them, name them correctly, place them at key joint points and have fun with the result by attaching the visual mesh(es). As long
as they're part of the scene and have the proper name and hierarchy it will work.

Technically in some cases you can work without dummies, but we want to make it simple (and hopefully you too), so we’ll use them (and you will too).

Our goal is to create a fully working vehicle. Just the pilot flying around would be a little boring. So, we are going to take some steps further. As you can
see, the limit is your fantasy when you’re making a mod for Assetto Corsa (Fig. 0.4).

Fig. 0.4 – Various examples of exotic vehicles brought to AC.

Don't worry about all the stages which seem very difficult now, just take it step by step. You don't need to know all the skills straight away, just dabble in
what interests you most, and the rest will come with time.

As soon as you drive a model you made for the first time, you will be hooked (or at least I was). AC is highly addictive. I can confirm that’s true.

80
TABLE OF CONTENTS
These are also roughly the steps to make a car mod. You can go to each respective chapter of PART 2 – CAR MODDING for its discussion. Page numbers

1. Prepare and populate the folder structures:

1.1 – Create a development (DEV) folder; p.23
1.2 – Create the final (FIN) folder; p.
1.3 – Add some template files to your mod p.

2. Modelling phase: with your 3D software (Blender, 3DS Max, Maya, etc): p.
2.1 – Make the actual car meshes with a good workflow (skip for conversions, you already have the model); p.
2.2 - Use the correct 3D coordinate system; p.
2.3 - Respect the dummy naming; p.
2.4 - Respect the scene structure and the hierarchy between dummies and mesh; p.
2.5 - Animate your model p.
2.6 - Add materials and textures; p.
2.7 - Skins
2.8 - Create LODs for your final product to achieve better in-game performance; keep in mind also the poly budget; p.
2.9 - Make a collider for the physics engine; p.
2.10 - Instruments/other stuff p.

3. Conversions: the good, the ugly and the evil:

3.1 –
3.2 –
3.3 –
3.4 –
3.5 -

4. Export to FBX up to 2014/2015 format (2016 is unsupported); p.

4.1 –

5. Transfer phase: With ksEditor.exe: p.

5.1 - Learn how to use it; p.
5.2 - Import the car .fbx model(s); p.
5.3 - Define the shaders/materials; p.
5.4 - Export to .kn5; p.
5.5 - Repeat for the collider; p.

6. Vehicle data: Configuration files and physics p.

6.1 - The Assetto Corsa physics engine: characteristics and features. p.
6.2 – How to create data for your vehicle mod: import, entry, organization. p.
6.3 – Data files: concepts, analysis and examples. p.

7. Adjustments during a race session p.

7.1 – The AC debug console. p.
7.2 – Apps: basic and developer, all the interfaces. p.
7.3 – Telemetry: the tool you need to learn.

8. Sound: give a soul to your vehicle. p.

8.1 – Elements of sound theory: you need them.
8.2 – The principles of vehicle sound synthesis.
8.3 – The audio equipment: systems, speakers, headphones.
8.4 – Means of vehicle sound simulation.
8.5 –
8.6 – Recording samples.
8.7 – Extracting audio samples from a source.
8.8 – Create a custom vehicle sound with samples. (too much samples?)
8.9 – Use an existing sound from another vehicle: the easy way.
8.10 – How to install sound mods for vehicles.

9. Releasing your mod to the public: think about it a little first. p.

9.1 - Pack your files p.
9.2 - Understand your boundaries as a mod creator p.

10. Car mods from the community. p.

10.1 - How to install car mods p.
10.2 - How to edit car mods (maybe?) p.

81
CHAPTER 1 - FOLDER STRUCTURES
This is how everything begins. Your first step before doing anything else. A good, clean folder structure will always make things easier. But this is also
required, so that Assetto Corsa understands everything.

For every project you’ll have to create two separate folders: the first one is a development (from now on we will call it DEV) folder, stored wherever you want
in your PC’s hard drive, with all the main reference data (photos, documents, etc.), your source 3D models and their textures; the second one is a definitive,
"final" (we’ll call it FIN) folder, located in the assettocorsa\content\cars path, which will contain the assets that are actually used by the game engine, and
thus can be considered the place where the finished product will be.

Now, following the structures we just identified, you can see in Fig. 1.0 a basic roadmap of the car mod creation process in AC.

Fig. 1.0 – This is a simplification of the whole thing. Some things are missing, but overall, this scheme is quite accurate. (FIX DATA+AUDIO into DEV)

Wow, I feel good now. Eat something ‘cos you’ll have to do some copy-paste work sooner or later.

If you have a double-screen setup, you might have some advantage by displaying each folder in a different monitor while working. The old-fashioned guys
will use two windows on the same screen (and no, I don’t care if you have a triple screen setup). However, for now just read and learn. I will see you at
paragraph 1.3, when you will start doing something.

1.1 - PROJECT FOLDER (DEV FOLDER) STRUCTURE

A vehicle project consists of a total of 5 models, including the high-poly model (~_LOD_A.fbx, Fig. 1.1), 3 optional, useful for game performance, additional
Level of Detail “LOD” models (~_LOD_B.fbx, ~_LOD_C.fbx, ~_LOD_D.fbx, Fig. 1.1) and a low-poly collider (collider.fbx, Fig. 1.1).

The naming of the files isn’t really important in this folder, what matters here is your ability to organize yourself. The names will become important in the FIN
folder, that’s why this is just a preparation work. The recommended way to set up your project folder then is the following:

Fig. 1.1 – DEV folder structure with all the files needed. The .kscp file is a project file created by ksEditor (info about this file in 3.A). (ADD AUDIO+DATA)

For now, since you just started, you can create the subfolders animations, PSD and texture, and put your 3d model (highlighted in green, Fig. 1.1) inside the
main folder.

82
As you can see the 3d model will later have to be exported to the .fbx format4. This is necessary because ksEditor reads only .fbx 3d models. All the LODs
have been created here, but you can obtain a working car mod just with LOD A, though it won’t be performance-friendly; for more information about LODs
check 2.E of this document.

The *.ini files (Fig. 1.1) are persistence files written by ksEditor and include the object and shader properties for the models.

The most important thing is the texture folder: here you shall put all the textures used during the modelling phase, so that afterwards ksEditor will be able to
find and associate them to the materials automatically (even the ones you will add while working with shaders within the editor, for example normal maps).
More about it at Chapter 3.A & 3.E. If the texture folder is missing every model you load in the editor won’t be exported as the program won’t find the
textures.

The animations folder will store all the animations you’ll make for your mod, and at this DEV stage those are the exports from your 3D software of choice
(Blender, 3DsMax, etc.) in the .fbx format.

The PSD folder contains the PSD source files of the car textures that can be eventually modified with Gimp or Photoshop. If you made several variations of a
texture but you don’t use them all keep the ones you leftover in this folder. You don’t want to spend time searching for the right files afterwards in ksEditor.

None of these files and folders will be included in the FIN folder, as they aren’t necessary for the game to work, and they will only increase the size of your
upload if you want to share/release the mod publicly. Also keep in mind that with a little amount of software it’s possible (with some time) to recover the
DEV files from a finalized mod (for example the .fbx model from a .kn5 file), often using 3dsimed, unless the mod is encrypted with an unofficial,
unsupported or broken standard5 (even though it isn’t impossible at all either, it just requires some time and other tools). We will return to this topic later
on.

1.2 - FINAL FOLDER STRUCTURE

The FIN folder has to be named so that the game understands it, always the hard way. Let’s consider an existing real-life car, like the one in Fig. 1.2.

Fig. 1.2 – Look at it. It’s a cool car, isn’t it?

This is a Ferrari 250 GTO Series II; you can’t name the folder like this, spaces need to be removed: you have to use underscore to separate any word you
use for the name of the folder. Just to be safe, use lowercase text only. Use the latin alphabet, without utf8- or fancy characters like “é” or similar. You have
to follow these rules in order to avoid unintended errors.

Good practice is also adding an author prefix consisting of an abbreviation of 2-4 letters; nobody wants to fumble around with 3 different mods of the same
car, all named the same because you and the other authors were too lazy to add a prefix, and this is really important when you want to edit someone else’s
car and release it to the community (giving credits to the original authors though).

Let’s say your name is Steven. Then we can name our folder st_ferrari_250gto_s2, or stev_f_250_gto_series2 for example. There’s plenty of names you
can give to your FIN folder, just don’t use weird ones.

Pay attention: there are length restrictions for car folders, from shared memory definitions you have:

Max length - car folder name: 32 characters

4
In the Windows 10 File explorer shown in Im. 1.1 the option to hide file extensions has been deactivated in Folder Options, so you might not be able to see the extensions on your PC. Don’t be
afraid, you can change this setting. In File explorer click on the menu View > Options (on the right) > drop-down menu Change folder and search options > click on the View tab in the window
that just opened > untick “Hide extensions for known file types”. That’s it. No need of tutorials.
5
This actually makes the mod look fine in-game (not guaranteed at all), but awful-looking in showrooms, especially with Content Manager showrooms, with unsupported encryptions (like v3;
sometimes those can’t even open and just report errors). You can’t edit your car, unless you use Custom Shaders Patch configs for a workaround (see, that’s why there’s no point in encryption, as
it can be bypassed in different ways). Anyway more about this near the end of PART 1.

83
In our example (Fig. 1.1), the car is called Your Car Name. Therefore, your_car_name will be the name of the FIN folder (any author prefix will be omitted
for clarity purposes). In Fig. 1.3 you can see it clearly. Everything is already in place, along with the models of the vehicle in the .kn5 format, which you’ll
have to export from the .fbx files we saw previously (Fig. 1.1). We’ll see what .kn5 files are and how they’re created later on; at this stage you can ignore
them.

Fig. 1.3 – Structure of the final folder in the game directories. The names of the .kn5 models don’t have to be identical to what you see here (except for collider.kn5), because they
need to be configured properly with a small script in order to work (pag. ); you’ll make everything tidier if you follow the example, but no one is forcing you to do so.

The green rectangles indicate the mandatory files and folders for the finished exported car. The data folder is usually there only during development, and we
will talk about the files it contains in Chapter 5. Let's discuss the other contents below, always looking at Fig. 1.3.

We have some files…

1. body_shadow.png: texture used by the game engine to apply basic shadows under the car body.
2. tyre_0_shadow.png: texture used by the game engine to apply basic shadows under the wheels, for wheel_
3. tyre_1_shadow.png: same as 2, but for wheel_
4. tyre_2_shadow.png: same as 2, but for wheel_
5. tyre_3_shadow.png: same as 2, but for wheel_
6. logo.png: logo of the car brand for the game loading screen (vanilla).
7. driver_base_pos.knh: a file that indicates the driver position in the car.
8. data.acd: encrypted file that contains the car data for AC and replaces the data folder (which you’ll find when editing mods) when the mod is finalized.

What are the .png textures for:

Car ground shadows are not generated in real time, and sun shadows as well6, but they are very important in order to improve the visual effect of the
ground position of the car and emulate an ambient occlusion effect on the ground (Fig. 1.4). That’s why for each car there are five ambient shadows textures.
Four textures dedicated to each wheel and another one for the car body (Fig. 1.5 & 1.6).
If not present, the car body texture is automatically generated once in game (CSP may shut down AC though, reporting the error for the missing texture, not
letting the game generate it; I’m experimenting about it), otherwise an existing one is used. Pre-made textures are used for wheel shadows. All the shadows
must be placed in the FIN folder.

Fig. 1.4 – The result obtained with shadow textures on the Abarth 500 EsseEsse by Kunos.

6
Custom Shaders Patch introduces dynamic shadows, however they’re quite expensive in terms of performance.

84
 Fig. 1.5 - Body shadow of the Abarth 500 EsseEsse by Kunos. Fig. 1.6 - This is one of the car tyre shadows of the
In game it looks as in Fig. 1.4. The shadow is blended with the Abarth 500 EsseEsse by Kunos.
dynamic shadow (not too clear=check).

The auto-generated shadow of the car is very rough. You can take the automatically generated body shadow tx and refine it with your favourite application to
obtain a smoother result. Otherwise you can generate the ambient shadows via CM showrooms, which include a lot of options (Fig. 1.7).

Fig. 1.7 – In CM showrooms click on Update ambient shadows and adjust the parameters; you’ll need to click on it again to confirm the result. After you set all the values for the first
time you can save a preset for all your future cars.

Fig. 1.8 – I like to check how the result looks on tarmac. I quickly made this showroom with a track model from AC’s assets.

Updating ambient shadows can fix problems like the ones in Fig. 1.9.

85
Fig. 1.9 – On the left the ambient shadow is too long, dark and misplaced; on the right the shadow is too bright, you almost can’t see it below the car.

…And we have some folders:

\animations:
This is where the animation files for moving parts like gear shift, steering, car doors, wipers, suspensions, hood etc. are stored for a car.
You can also add extra animations in this folder, perhaps for a spinning fan or an active spoiler/splitter. (huh?)

\data:
This is a key folder in your future car. Inside there are all the configuration files we need to work on for the physics. Once the car is ready to go public, there
is a possibility to release it exactly as is, but nowadays the entire folder is packed in one single encrypted file called data.acd.

\sfx:
There goes the sound. In order to have a working car mod, this folder and its contents are REQUIRED. Assetto Corsa uses the FMOD audio engine and all
the audio samples are packed in a *.bank file that must have the same name of the car’s main (FIN) folder.
The GUIDs.txt file is necessary for the soundbank to work, and we’ll talk about it later on.

\skins:
Car skins folder. Every skin has its own sub-folder with the preview of the car, which you might want to edit (skins later).

\texture:
Very important folder. All the car's functional textures, like flames and digital displays, must be here. To start, you can copy it from formula_k, because it
also contains some common shared textures, in the sub-folder flames. Otherwise, whatever new functional texture you create and use on your car, just drop
it directly in the texture folder.
The non-functional textures coming from DEV folder, once the model is finished, will be included in the .kn5 file you will export. (later)

\ui:
Used by the game UI (user interface), can contain these files:

- badge.png (128x128 pixels image), that is the logo of the car brand for game GUIs, only in vanilla AC; with CSP it can appear also in loading screens,
overriding logo.png in the main folder if you enable the “new loading screens” feature in CM. In Fig. 1.10 we have some correct examples.

Fig. 1.10 – Real brands logos.

Unless your car is fictional (which is pretty rare) I suggest you to use the real logos, not your own logo, as we don’t want to disrupt the immersion. Writing
your website in the “description” or “url” fields of ui_car.json script below will be enough to make some sleek and not disturbing advertisement. The
following (Fig. 1.11) are examples of logos you shouldn’t use if you want to be as serious and faithful to reality as possible.

Fig. 1.11 – Often this is just kitsch.

On the other hand, you can definitely use historic variations of a specific brand’s logo, but they have to be accurate for the car’s period (Fig. 1.12).

86
Fig. 1.12 – The progression of the Lancia logo (not all of them are present). From left to right, 1907, 1911, 1929, 1957, 1974, 2007.

Finding a good image of the correct logo doesn’t require a lot of time and it’s rewarding. Otherwise use those already in Kunos cars if the brand is the same.

- ui_car.json, which contains the basic data of the car, such as name, year\era, author (of the car, for example a modder, for official content the name will be
“Kunos”), racing class, power and torque curves, etc. for display purpose only, ignored by the physics engine. You should change the car’s name, so it will
be easy to find your creation in the menu . You can edit this *.json file with the text editors suggested in the beginning of this manual. Here we have
everything you can write inside your ui_car.json (this example comes from the Giulia Quadrifoglio by Kunos):
{
"name": "Alfa Romeo Giulia Quadrifoglio",
"brand": "Alfa Romeo",
"description": "The new Giulia represents the convergence of engineering […]",
% ▲ You can write anything in the car description, you can tell its history, some anecdotes, some info, just don’t leave it empty, at least prove you
put some effort in it.

"tags": [
"#Sportscars",
"rwd",
"turbo",
"manual",
"street",
"italy"
],

% ▲ Tags can be anything you want, but if you want them to be useful (as filters for session grids), use realistic tags like “race”, “GT3”, “rally”,
“F1”, “automatic”, “drift” etc. or look at those added by Kunos.

"class": "street",
"specs": {
"bhp": "510bhp",
"torque": "600Nm",
"weight": "1595kg",
"topspeed": "307km/h",
"acceleration": "3.9s 0-100",
"pwratio": "3.13kg/hp"
},

% ▲ These specifications of the vehicle are not used at all by the physics engine, they’re here just for display. However type in the correct data.

"torqueCurve":
[[500.0,144.0],[1000.0,194.0],[1500.0,353.0],[2000.0,440.0],[2500.0,607.0],[3000.0,607.0],[3500.0,607.0],[4000.0,607.0],[4500.0,607.0],[5000.0,607.0],[5
500.0,607.0],[6000.0,593.0],[6500.0,559.0],[7000.0,513.0],[7400.0,468.0]],
"powerCurve":
[[500.0,10.0],[1000.0,27.0],[1500.0,74.0],[2000.0,124.0],[2500.0,213.0],[3000.0,256.0],[3500.0,299.0],[4000.0,341.0],[4500.0,384.0],[5000.0,426.0],[5500
.0,469.0],[6000.0,500.0],[6500.0,510.0],[7000.0,505.0],[7400.0,486.0]],

% ▲ The torque and power curves here are just for visualization purpose, and they don’t have any impact on the physics of the car. They’re the curves
shown in AC and CM GUIs (Graphic User Interfaces). If you modified the physics of your vehicle, and the graphs displayed are old, the curves can be
copied from the data files (with some formatting needed), or calculated and directly updated with Content Manager.

"country": "Italy",
"year": 2016,
"author": "Kunos",
"version": null,
"url": null ; you can write your website (if you’re the author). Use this field to advertise yourself.
}

You can read the info/specs above in the AC GUI, and you can modify it (if you don’t want to use a text editor) with Content Manager too (Fig. 1.13).

Fig. 1.13 – This is what you’ll find in the CM window: editing from here is easy, just click on the text field and write the correct data/info.
87
- upgrade.png (64x64 pixels image), that highlights in the UIs the upgraded/tuned versions of a vehicle, for example S1, S2, GT, EVO, etc. Not only that.
You can create with CM custom icons with any text, limited to what you can actually read in the few pixels of these small images.

In the image below (Fig. 1.14) I added a dark background to be able to see some examples, as they’re transparent .png files.

Fig. 1.14 – The first three are vanilla icons. The other ones come from mods.

- camera_trajectory.json, and this config file can add a custom camera sequence and movement at the beginning of any game session, customizable for the
specific car. This is a CSP addition. It’s quite rare to find a mod with this feature.

This is the script:

/* use Copy button in camera settings in CM to get settings for a new item */
[
{
"duration": 30, /* time is seconds */
"items": [
{ "pos": [ 8.435, 1.290, 1.851 ], "look": [ -0.897, 0.448, 1.342 ], "tilt": 0.0, "fov": 11.9 },
{ "pos": [ 8.435, 1.290, -0.661 ], "look": [ -0.758, 0.448, -1.169 ], "tilt": 0.0, "fov": 11.9 }
]
},

{
"duration": 12,
"items": [
{ "pos": [ -1.491, 1.342, -3.518 ], "look": [ 0.514, 0.235, -0.426 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -2.284, 1.825, -2.422 ], "look": [ 0.663, 0.116, -0.634 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -2.866, 1.832, -0.345 ], "look": [ 0.578, 0.123, -0.219 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -1.715, 0.832, 2.787 ], "look": [ 0.578, 0.123, -0.219 ], "tilt": 0.0, "fov": 52.0 }
]
},

{
"duration": 30,
"items": [
{ "pos": [ 1.788, 1.568, -0.923 ], "look": [ -0.652, 0.945, 0.793 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ 1.923, 1.024, -0.928 ], "look": [ -0.516, 0.401, 0.789 ], "tilt": 0.0, "fov": 52.0 }
]
},

{
"duration": 6,
"items": [
{ "pos": [ -0.247, 2.358, -2.118 ], "look": [ 0.096, 0.425, -1.022 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -0.290, 1.241, -2.028 ], "look": [ 0.002, 0.684, -0.724 ], "tilt": 0.0, "fov": 52.0 }
]
},

{
"duration": 18,
"items": [
{ "pos": [ -2.513, 0.321, 1.305 ], "look": [ -0.175, 0.426, 1.358 ], "tilt": 0.0, "fov": 34.8 },
{ "pos": [ -2.454, 0.303, -1.271 ], "look": [ -0.116, 0.408, -1.218 ], "tilt": 0.0, "fov": 34.8 }
]
},

{
"duration": 7.5,
"items": [
{ "pos": [ 2.917, 4.160, -3.222 ], "look": [ -0.222, 0.257, -0.391 ], "tilt": 0.0, "fov": 31.9 },
{ "pos": [ 3.708, 1.690, -4.283 ], "look": [ -0.380, 0.493, -0.415 ], "tilt": 0.0, "fov": 31.9 },
{ "pos": [ 1.069, 0.970, -4.674 ], "look": [ -0.230, 0.534, -0.331 ], "tilt": 0.0, "fov": 31.9 }
]
},

{
"duration": 20,
"items": [
{ "pos": [ -8.995, 10.645, 10.252 ], "look": [ -0.511, 0.938, 0.467 ], "tilt": 0.0, "fov": 11.9 },
{ "pos": [ -5.600, 4.652, 12.311 ], "look": [ -0.286, 0.659, 0.694 ], "tilt": 0.0, "fov": 11.9 },
{ "pos": [ -0.939, 0.672, 9.655 ], "look": [ -0.111, 0.698, 0.708 ], "tilt": 0.0, "fov": 11.9 },
{ "pos": [ -0.971, 0.446, 5.547 ], "look": [ -0.410, 0.580, 0.596 ], "tilt": 0.0, "fov": 11.9 }
]
}

\extension:
With Custom Shaders Patch, a folder called “extension” can also be created to add more configuration functionality. It will contain the config file named
ext_config.ini, which will handle any behaviour related to CSP.

1.3 – COPY-PASTE TEMPLATE FILES

This is when everything begins. Now you will be able to actually do something quite simple but necessary. We will copy in the FIN folder most of the files
and folders we talked about in par. 1.2 from another vehicle, as there’s no point in making them from scratch, it would be just a waste of time. In the files of
the official AC pipeline 2.0 there’s the formula_k (Formula Kunos, basically a draft copy of the official Tatuus FA01) car used as a template for this exact
purpose.

88
You can copy the full formula_k folder or the basic archive that comes with this manual (where man?) in the
assettocorsa\content\cars path. You will have to change the name of the main folder (see par. 1.2) and edit/replace the following
files:

ui_car.json (ui folder):

Edit “name”, “brand”, “description” and later all the other lines that don’t match the info/specs of the vehicle. The three variables
indicated here will be enough to let you distinguish your mod from the rest of the content. Anyway you can change everything from
the beginning if you want to do the work only once.

.kn5 models (main folder):

You will have to replace the .kn5 model of LOD A with the one of your vehicle. If you make also the other LODs, you will have to replace
those too. The naming in the example below (Fig. 1.15) follows the logic we stated in par. 1.2.

Fig. 1.15 – Once you have all the models, you can replace the ones from the formula_k template with yours.

Maybe at the moment you don’t have any model. Then come back later, when you will have made some progress making/converting
and exporting your model(s).

lods.ini (data folder):

You will have to change the names of the models specified in this file according to the names you chose for the .kn5 models of your
car. Look at chapter 5 for this config.

89
CHAPTER 2 - MODELLING PHASE
At this point you roughly prepared the folders. With the word “modelling”, I am referring to the process that creates within the virtual (computer-generated)
world the 3D structures of real-world objects - that is, graphical modelling. We’re talking about CG, Computer Graphics. This is different from mathematical
modelling, which is the process of describing the dynamic behaviours of nature using equations (don’t ignore physicists!).

In the following paragraphs there will be info on how to make your models; paragraph 2.2 is for those who have average skills using a 3D modelling
software like Blender, 3DsMax, Maya etc., but need to improve their workflow while drawing cars, specifically for a game engine.

In case you are good at using 3D software and you already know how game graphics work, you can totally skip par. 2.2 and go directly to par. 2.3.

If you don’t need to create the car model at all, go directly to par. 2.4. Be aware that models taken from various games/third party sources may not be
accurate and faithful to reality. I suggest you to read par. 2.3.2 that will clear some things. If you need help with conversions, go to par. .

If you don’t know the basics of 3D modeling instead, I suggest you to start from par. 2.1 right here.

2.1 - 3D MODELING
Information technology has helped open up new possibilities for improving the design process; thus, several generations of computer-aided design and
drawing programs have been developed over the past few years. In the most recent of these programs, the physical object is configured as a virtual solid
model, that is, a mathematical representation of the object that can describe its shape, size, color, and other quantitative and qualitative characteristics.
Compared with traditional drawing, which provides a coded representation of a three-dimensional object with a series of plane images according to different
points of view, a solid model contains information about both the external shapes of an object and the internal space enclosed by these shapes.

This makes it possible to calculate physical properties such as volume, mass, center of gravity, moment of inertia, simulate assembly problems, determine
interferences, and automatically generate faithful models for structural analysis or numerically controlled machining. In the treatment of the relationship
between the physical object and the corresponding model, four main disciplines coexist, integrating seamlessly:

1. Geometric modeling, which is a processing activity on the model; it is mainly concerned with methods for mathematical representation of real objects;
2. Computer graphics, which deals with the methods and techniques for producing images from models: it basically approximates models with synthetic
images, that is, with a set of coloured dots (pixels) on a graphic display;
3. Pattern recognition which deals with the problem of recognizing an image, i.e., moving from image to pattern;
4. Image processing, which deals with the goal of enhancement or modification.

2.1.1 – CAD SYSTEMS

Why do we start from here? The answer is: the world of 3D modeling is confusing, and stating things clearly is always necessary.

The need to faithfully, completely and unambiguously communicate the characteristics of a real or imaginary object has led over the years to the search for
increasingly powerful representational schemes; thus, six generations of CAD systems have followed over the years:

1. First-generation, traditional computer-automated drawing (Computer Aided Drafting); an object is represented by its edges projected onto a two-dimensional plane (Fig.).

Fig. –

2. Second-generation, representation by edges (called wireframe); edges are represented in 3D, and two-dimensional views can be generated according to any viewpoint
(Fig.).

90
Fig. - Car 3D design at Mazda in the 1970s with the IBM 2250 Model 3 System.

3. Third-generation, representation of an object by its boundary surfaces (Boundary Representation, B-Rep); it is possible to obtain both the elimination of edges not in view
(hidden representation) and realistic images, with the appropriate choice of lights and colors, but the surfaces do not delimit a complete partition of space (Fig.).

Fig. – Example of a solid made with the Open CASCADE Technology development platform.

4. Fourth-generation, in which objects are represented by the 3-D space they occupy (Constructive Solid Geometry, CSG); the mathematical representation is unambiguous
and makes it possible to determine whether any point in space is part of the solid (is inside it), is outside the solid, or is on its surface (Fig.).
One of the advantages of CSG is that it can easily assure that objects are "solid" or water-tight if all of the primitive shapes are water-tight. This can be important for some
manufacturing or engineering computation applications. By comparison, when creating geometry based upon B-reps, additional topological data is required, or
consistency checks must be performed to assure that the given boundary description specifies a valid solid object.
The Quake engine (id Software, 1996) and Unreal Engine (Epic Games) both use this system. CSG is popular because a modeler can use a set of relatively simple objects
to create very complicated geometry.
91
 Blender is primarily a surface mesh 3D editor, but it is capable of simple CSG using meta objects and using the Boolean modifier on mesh objects.
Some other programs that support CSG are: AutoCAD, Autodesk Inventor, Autodesk Fusion 360, CATIA, FreeCAD, Rhinoceros, SolidWorks, Tinkercad, SketchUp.

Fig. -

5. Fifth-generation, very popular in recent years in industry, with which it is possible to model by elements (or features) such as ribs, holes, grooves (parametric, Feature-
based systems). A feature can be defined as a physical constituent of a part that has engineering significance and is mappable to a generic shape (Fig.).
The flexibility of these systems is further increased with parametric and variational techniques. In addition, it is possible to assemble the various modelled components
through complex coupling relationships.

Fig. – (left) An example of a feature tree to create a solid model by applying five form features. (right) Some of the operations that can be done with feature-based modeling.

6. Sixth-generation systems, characterized by explicit or history-free CAD modeling, i.e., based on direct manipulation of the geometry of the object being designed,
regardless of the construction history of the 3-D model, with the advantage of allowing a significant increase in design speed and creativity (Fig.).

Fig. - In this example, a parametric model that was built using symmetric design intent. A change has been requested to create a new version that is asymmetrical. Perhaps a simple
task for an expert user, but direct editing can make this easy for a novice.

Most current modeling systems use a hybrid approach, that is, they use both parametric modeling by feature (history based) and explicit modeling, so that
changes required by the design can be made quickly to pre-existing models without having to take into account the component's construction history.

92
Nurbs
CAD programs like Autodesk, Catia, Solidworks, Creo, etc. create primarily vector-based models that are of no use for games. Let’s explain this a bit further.
Nowadays most of the geometric constructions for industrial applications are based on a mix of B-rep, CSG and NURBS. There isn’t a clear separation.

Non-uniform rational basis spline (NURBS) is a mathematical model using basis splines (B-splines) that is commonly used in computer graphics for
representing curves and surfaces. It offers great flexibility and precision for handling both analytic (defined by common mathematical formulae) and
modeled shapes. It is a type of curve modeling, as opposed to polygonal modeling or digital sculpting. NURBS curves are commonly used in computer-
aided design (CAD), manufacturing (CAM), and engineering (CAE).

The key benefit of NURBS is that it isn't an approximation of a smooth shape. The math calculates an accurate definition of the surface shape which is still
smooth however closely the surface is examined (Fig.).

Fig. -

Why NURBS is used

In general, editing NURBS curves and surfaces is intuitive and predictable, and they offer unique features:

 Flexibility to create sculptural shapes;

 Tension to keep surfaces smooth and taught;
 Alignment to create smooth, invisible joins.

Designing with this level of attention to sculptural aesthetics is a specialised area of CAD modelling, typically used for premium products where elegance
and surface quality are important factors in the product's appeal (Fig.).

Fig. – A model of a vehicle made with CAD, like this one, can be used for production.
93
A NURBS surface is defined by a network of Control Points. The position of the control points 'pulls' the surface patch into a shape, like a flexible sheet.
They are said to be “parameterized”. This simply means that their resulting geometry is obtained from the input of parameters into mathematical models.

The key skill is choosing the right number of control points, and the right position of each of them to achieve the sculpted surface shape that you need.

Fig. -

NURBS allows the user to sculpt any shape, and is typically used for freeform, sculptural designs that can't be defined by dimensions or geometry (Fig.).

Fig. –

However, the surfaces need to be converted to triangulated geometries in order to be rendered by a GPU. This happens automatically while you’re working
with any CAD or 3D modeling software. Current GPUs are designed to render triangles because triangles are nice to work with.

GPUs can be made (and have been made) to render other primitives natively, but it's just not really worth it. If you tell a modern GPU to render a square or
a rectangle (quad), it splits it up into two triangles and renders those.

Not because there's a technical reason why a GPU can't render quads natively, but because they’re not worth spending compute power on. It's much more
useful to focus on rendering triangles as fast as possible, and then just emulate other primitives if they're needed.

Modern GPUs have hardware limitations so they don't work with quads, for example, but not because it's impossible to design a product which works with
quads. It'd just be less efficient to do so.

2.1.2 - POLYGON MODELING

NURBS and polygon models are typically both used to create freeform designs, but are based on completely different representations of the geometry, and
therefore have different methods of controlling the flexibility of the design.

Polygon modelling is based on meshes; it has traditionally been used in Character Animation and games modelling as it is particularly good at:

 Creating surface detail (wrinkles in a character's face, vegetation, rocks);

94
 Fast rendering calculations (polygon models are already tessellated);
 Easy to manipulate;
 Can have their UVs mapped out for texturing;
 Have infinite sides;
 Surface is made up of vertices, edges and faces;
 Very optimizable (triangulated polygonal faces);
 Cannot be used as a surface to draw Paint FX on;
 Generally easier to use;
 Easy to work with than subdivisions;
 Easy to attach;
 Can be modelled as a single, continuous surface.

Meshes are generally seen as easier to learn and easier to use than NURBS modelling, and because of this, it is beginning to be used more for concept
design work, but not for production quality final designs because of the lack of surface smoothness and precision.

A polygon model is a collection of flat facets that approximate a smooth shape. This is adequate for rendering or prototyping (and in fact NURBS models are
converted to a polygon representation for these purposes), but not for production.
The CNC (Computer Numerical Control) machine tools that create the tooling for final products work from the accurate, smooth NURBS data instead (Fig.).
You can’t design any product for engineering and manufacturing with polygon models.

Fig. –

Since for AC we will work with game graphics (the basics of which will be explained at par. 2.2), it’s the opposite: we actually need to use polygon modeling
instead of CAD.
You can technically convert a CAD model to polygons, but it will require a lot of work to be cleaned and optimised. The topology (see par.) will have to be
entirely reconstructed by hand, so the results are not immediate. It’s probably simpler to remake everything from scratch.
Then, if you need to choose a 3D modelling software, be sure it can work with meshes, and export your models to .fbx up to the 2014/2015 format.
I suggest to learn about the program itself first: you can read manuals, or learn how it works with practice on simpler things, to build experience. Only then
come back to continue following this guide. Don’t worry, no one is pushing you to rush things. The next pages won’t go too deep in the subject, but are a
good recap of the things you need to know the most.
My recommendation is to use Blender, due to the fact that it is free and open-source. If you need help to learn how to use it, you can use the following
books:

 Blender For Dummies (by Jason van Gumster); for beginners, it has a quite relaxed approach, very well written. Can be fairly interesting also to experienced users.
 The Complete Guide to Blender Graphics Computer Modeling & Animation (by John M. Blain); there’s a ton of examples, even physics simulations are discussed.
 The Blender Reference manual (from the Blender Documentation Team): https://docs.blender.org/manual/en/latest/index.html; less discursive but includes most of the features.


A professional alternative (which may be more complicated) is 3DsMax, but it’s very limited in terms of applications (for comparison, with Blender you can
produce photorealistic renderings, simulations, animations, entire movies, games, 2D graphics and much more).
I do not have enough experience with other programs to recommend them, but you will find brief descriptions at the beginning of this manual, under THE
TOOLS YOU WILL NEED.
95
2.2 - IMPROVING YOUR WORKFLOW WITH GAME GRAPHICS
You’re able to draw with your favourite software but you don’t know where to start from when it comes to your favourite car. Huh?

First of all, you need to look at what you’ll be working with till the end of the days: meshes (polygon modeling). You’ll need to learn also how to make your
3d models as performant as possible in terms of graphics, because we never want to make our game slower, and there are a few ways to implement this
feature in our assets.

2.2.1 - POLYGONS VS TRIANGLES

When playing around with meshes, in my experience over the years, the faces were always referred to as polygons in the modelling software I was having
fun with. Furthermore, the polygons in the mesh don't necessarily begin as triangles. Some may end up that way, but not all of them. It just depends on
how things turn out while I'm shaping things.

When you create 3D models, you will use “polygons” as your atomic elements. These polygons get attached together to form your final shape. Amongst all
possible polygons, you will mostly use triangles (tris) and squares/rectangles (quads) for your work (Fig. 2.0).

Fig. 2.0 – Examples of tris, quads and triangulation of quads.

Some 3D-tools do not even support other polygon types (n-gons) at all. An n-gon is a face that has five or more edges used to construct it. Now, from the
point of view of AC:

1. Game engines mostly work with triangulated meshes. If you import a mesh to a game, its faces are converted to triangles.
2. For performance (GPU), the triangle count matters, not the 'poly-count'. If you have a model made of 100 quads (4 sided polys), then it's triangle-count is actually 200.
3. When animating a mesh, differences can occur. If you animate a quad (or n-gon) mesh in the modelling software, it can look a bit different in game (since the mesh got
triangulated on export/import).

And there is another nasty caveat here: a quad can be converted to a triangle in 2 ways, see image above. And this can have an influence on the actual
display of your model due to lighting calculations along the triangle edges.

Now there are some ongoing discussions about when you should use tris and when you should use quads in your model. The most important issues with
this are related to texturing and animation. And during modelling you will face more problems with triangles than with quads especially when you plan to
use the “Subdivision Modifier” for your work. Here are some issues with triangles in your model:

 Using triangles in your model tends to not work well with subdivision.
 Triangles break edge loops. That can be bad when you try to optimize your mesh (reduce polygon count).
 Triangles tend to create much more complex mesh topologies (what is 3D topology? Read paragraph 2.1.2). While easier mesh topologies can be maintained with less
work.
Tris sometimes can be useful though, for example when optimizing your model or making certain shapes (Fig. 2.1). They’re really a double-edged weapon.

Fig. 2.1 – Detail of a car door geometry. Both tris and quads are used.
In the end, whatever you create will be converted into a triangulated mesh upon import to the target system, AC’s game engine here. This process is called
tessellation. Hence it makes a lot of sense to learn how you can use different polygons for optimization purposes.
For now the guideline for making your 3d models will be:

 Use Quads as much as possible while you are in the modelling stage.
 Use Tris where using Quads would make your model more complicated.
 Use Tris when they help to optimize your mesh in the Optimization stage.
 The mesh must be (when possible) in quads. Do NOT triangulate the mesh if it is not necessary.

96
2.2.2 – THE CONCEPT OF MESH TOPOLOGY (wip)

There’s a big difference between an optimized and a non-optimized model. Experienced modders and 3D artists think about it a lot.

Simply put, 3D optimization is the process of reducing the file size of 3D models. The size of 3D models comes from two places: geometry and textures.
Geometry refers to the actual mesh or structure of the 3D model which is made up of polygons. Textures are simply the images used to skin the 3D model.

The mesh decimation portion of 3D optimization removes or combines polys to reduce their overall amount (poly count). The file size becomes smaller and
requires less GPU power to render. This is something we’ll have to work on, because in order to produce a model that can be easily optimized (efficient)
you need to create a good topology.

When we talk about topology, we are referring to the actual structure of our meshes. How everything links together in the flow of the geometry, which can
be divided up into three types of atomic elements (Fig. 2.2):
 The first is the vertex, which is a singular coordinate in 3D space.
 The second type is the edge, which is a line that is constructed between two vertices.
 The third type is the face, which is a closed-loop of three or more edges that can create a flat surface (tris, quads, n-gons, already mentioned before).

Fig. 2.2 – The primitive (fundamental) geometric elements of your 3D space. This image shows also how you can choose which one to work with in Blender.

Mesh topology is the way in which all of your different types of geometry are formed. For example,
a good mesh topology will have plenty of quad-based faces, which allow you to evenly spread
your geometry around your model. On the other hand, bad topology could be the use of n-gons
where they are not required.

The easiest way to think about mesh topology is to divide up your geometry into a series of loops
and poles. A loop is where we’re able to select a section of our geometry that follows a specific
path (Fig. 2.3).
Fig. 2.3 – An edge loop around Fig. 2.4 – A face loop around
A pole, on the other hand, is often used to terminate that loop. In Blender for example, loops are the whole sphere. the whole sphere.
constructed from quad base geometry. The face loop that is created (Fig. 2.4) goes all the way
around our model and this is because the flow of our geometry is able to tell what direction we
want to select the next phase.
This is easy for Blender when working with foresighted faces as the geometry can go in one of a
couple of directions. In our example of the UV sphere, because we are going horizontally, Blender
knows that we are going from left to right and vice versa for our selection. So it simply has to find
the edge of the face on the opposite side of the selection, to continue the face flow. If you choose
to use anything other than a four-sided face, however, things become a little bit more complicated.
If we attempt to select a vertical loop for either our faces or edges, we find that it does not even Fig. 2.5 – A face loop Fig. 2.6 – An edge loop
reach the top (Fig. 2.5), and that’s because if we reach the look at the top of our UV sphere, we can interrupted by two poles. interrupted by two poles.
see that we are no longer working with a four-sided face. We are now working with three sided
faces, aka triangles.
Unlike the quad base geometry of a four-sided face, Blender does not know what direction to go in when a loop reaches a triangle, so instead of attempting
to guess what direction to go, it just terminates the loop at that location. This is what happens with our UV sphere. All of the faces are selected up to, but
not including the triangles, located at the top and bottom of the UV sphere. The triangle is therefore referred to as a pole a location where a loop is
terminated (Fig. 2.6).
The ability to create good 3D topology depends on your understanding of how loops and poles work, as well as geometry in general.
You may think that the best way to construct a model is to avoid poles altogether, but this is not true at all, and poles are a necessary part of many 3D
models.

97
An example of bad topology is when geometry overlaps. This can create what is known as shading artefacts on your 3D model when you apply smooth
shading or add textures to it.
Shading artefacts can be very distracting in terms of the visual appearance and the overlapping geometry can also affect your models’ functionality if you are
attempting to animate it.
It’s easy to create shading artefacts when you are using specific tools such as the bevel and boolean modifiers. It is most common when you manipulate
your geometry incorrectly in edit mode or you use tools that significantly deform that geometry. Again, the Boolean modifier is an example of this.
wip

2.2.3 – TYPES OF SHADING ARTIFACTS

WIP
So there are numerous ways in which we can create bad topology on our model. And some of these methods are not always going to
be intentional. Some of them are just going to be by-products of how we construct the object in the first place. But what are the best
ways to fix these options if we come across them?

Starting with the structure of our loop system, which is the actual flow of our topology. We can use tools like deleting, dissolving and
merging as a way of combining our geometry together and redefining our loops. We can also use the loop cut and slide tool to create
additional loops on our 3D models.

Shading artefacts are very easy to create because they can form as a result of either using a tool such as an edge slide incorrectly or
using another tool like a modifier to deform your geometry.

If you come across any shading artefacts, the first thing you should try and do is go into edit mode for that model, locate where the
shading artefact is and attempt to reposition the geometry there.

You can do this by pressing G twice to enter vertex grab or edge grab depending on the method of selection that you have active.

Using the decimate modifier reduces the overall amount of geometry on your mesh, but it’s going to destroy your topology as a whole. It does get rid of the
individual shading artefacts that are located on the surface, but also of your work, so avoid this modifier!

2.2.4 – NORMALS

Normals on your model can be affected by its topology, but this is just part of the story.
The normal in 3D modeling refers to the direction that your geometry is facing. Vertices can have an inward or an outward direction (Fig. 2.7).
Ideally, you always want to see the outward direction (the normal) of the geometry. The same also applies to a face where it will have an inward-facing side
and an outward-facing side.
In video game design, there is a process known as backface culling that ignores the inward-facing side of a face and therefore doesn’t render it.
If your normals are incorrect and the inward-facing side is pointing outwards towards the camera, then when you export that model into a game engine, that
geometry will not be rendered and you’ll be able to look through your asset, which you don’t want to happen.

98
Fig. 2.7 – How to display the vertex normals of a UV sphere in Blender: the blue lines represent with a vector each normal direction.

If normals are your primary issue, then what you can do is go to the overlays menu in the top corner of the 3D viewport, and then
select the face orientation option from this menu.

What this option will do is it will highlight your geometry in one of two colours, blue or red. The colour blue indicates the outward
facing side of your normal direction. While the colour red in the case the inward facing side of your normals.

The ideal scenario here is to not be able to see any red faces in your scene. But what you are able to do with this is select the red faces,
And then access the normals menu, which you can do by holding down the Shift key and pressing N.
In the normals menu, you have a variety of options, but if you have selected all of the incorrect normals then you can just select the flip
option at the top. Alternatively, you can select all of your geometry, go to the normals menu, and then select recalculate outside.

This should be able to flip all of the incorrect normals to the outside. Sometimes this option doesn’t always work, so it’s good to try this
first, and if it doesn’t work, use the flip option as the backup by selecting the faces manually.
Really WIP
tessellation, seams

2.2.5 - OPTIMIZATION OF YOUR MODEL (ignore the pictures at the moment) completely WIP
So what was the point of having a good topology?
Having a good topology helps avoiding artefacts in general, and makes optimizing your model easier. You’ll need less triangles in
general, so your models will be the most efficient. You can see different applications of optimization in Fig. 2.7 & 2.8:

99
Fig. 2.7 - Examples of mesh optimization. The meshes in the top row are the initial meshes; the meshes in the bottom row are the corresponding
optimized meshes. The first 3 columns are reconstructions; the last 2 columns are simplifications.

Fig. 2.8 – In this example notice how the final result is able to preserve information with a reduced amount of geometry. K here is just a parameter that
influences the cohesion of the vertices and consequently the topology of the mesh obtained. More info about optimization here:
https://sites.stat.washington.edu/wxs/Siggraph-93/siggraph93.pdf

the industry workflow is to model the car as a single piece and then start adding details like panel gaps etc once the shape is finalized
and subdivided, makes for a much easier and simpler work as you don't have to worry about keeping the topology in quads and
uneven density messing up curves.
Stereo:
I believe the main origin of that is models built to have the subdivision modifier permanently a part of the project, with 2 levels in
viewport and 4+ subdivisions for renders, to the point it stops getting smoother. For games where you aim for a polycount, it's just not
efficient to have subdivision applied to panel edges; you only want 2 or maybe 3 loops round the corner (one on the face, one into the
edge, possibly one rounding it off) but with 3x subdivision that's gonna be a minimum of 16 so the smoothing works correctly.

You can get much better reflections if you build the optimum edge flow without the gap, use subdivision, and then cut the gap in after.
To some extent it's better not to even have a row of edges right where the gap is, even if they're parallel; it's easier to add the corners
of a cut/extrude/bevel through the middle of faces than along edges. Since you're turning that edge from infinitesimally wide to 10-
15mm wide. So for example if a car has a door handle inset into the door, I generally aim to have a vertex at the center of where the
handle will be, so that the round-ish shape sits on the 4 quads around that vertex.

100
If you make your cuts and then subdivide it, you will never get normals consistent across panel seams. There can be an argument that
it's more realistic since in real life manufacturers have draft angles to contend with on their parts so the surfaces on either side of a
panel gap aren't perfectly aligned anyways, but in a digital model having a visible jog, or inconsistency, in the reflections makes the
model look a bit messy. If you subdivide and then cut the model into pieces, keeping a copy of the model that isn't cut, you can
transfer the normals information from the uncut model to the perimeter vertices of the seams in the cut one for pretty much perfectly
consistent reflections. I don't know the proper way to do this in your software, but @Stereo posted about his method while working on
his Porsche model a few months ago in Blender (using a data transfer modifier, which is better than the shrinkwrap method I've seen
others use). I'm sure your software would have a similar tool/workflow to achieve the same.

You can learn "proper modeling hygiene" all you want, but until you actually do it it doesn't mean anything. Understanding the theory
and how to implement it are two completely, utterly different things. The first car I tried to model in Blender I started 5 times because
it's really easy to say how it should be done, much more difficult to actually do it. They need to make a less-than-stellar attempt to
learn from to be able to actually learn for real. Telling him to just stop now and learn is counter productive, since stopping will prevent
said learning.

The difference between my 2019 models and my 2021 models is massive and if I wasn't so preoccupied with practicing and instead
spent more time learning the theory and actually implementing it I could've improved this much in 2 months instead of 2 years.

DDS can be compressed and decompressed on the fly as it enters the video memory, which helps reduce strain on VRAM and I/O for the memory. It's also similar in image quality to PNG,
although there are different options to make it more efficient than PNG.
There are also some lossless DDS formats (which will be the same quality as a PNG) but the file size will end up bigger as those are uncompressed.
Most GPUs can hardware decode DDS, they cannot hardware decode PNG.

2.2.15 - SETTINGS AND TIPS TO EASE THE WORKFLOW IN BLENDER

There are a lot of things to come to grips with, for each piece of software. An example: viewport clipping.

Setting it like this, will stop parts of models from disappearing from the 3D view.

You can get even smaller, if you write 0.001mm in the start field. However, do not go as small on large models, as not only it’s wrong, but it can cause
erratic 3D cursor behavior!

Pro tip: make yourself feel at home by adding some more functions to your Blender experience:

1. Head over into the user preferences and switch to the Add-ons tab (Fig.);

101
Fig. -

2. Enable some helpful Add-ons:

 Layer Management to organize the layers, e.g. by giving them names;
 Archimesh to easily build architectural objects like rooms or complete houses;
 BoltFactory to add imperial and metric bolts and screws to your models;
 Extra Objects brings default mesh objects like Roundcubes, stars, sqorus or diamonds.
3. In the same window, ensure that the FBX export format is enabled, to bring your models to the SDK editor.
4. Enable Import Images as Planes for easy blueprint setup (requires pre-cutted views of the blueprint you want to use).
5. Enable UV Layout to export the UV layout to a 2D image from the image editor.
6. Enable the Pie menus for easy and quick navigation or manipulation in the viewport. Since the 3.0 release of Blender this option is enabled by default.
7. If you plan to do some character rigging (for driver models and such), make sure to enable the Rigify add-on because it gives is a powerful help.

102
2.3 – SOURCE MATERIAL TO DRAW VEHICLES

Yes, no one is able to draw anything out of nowhere (unless it’s a product of your fantasy). Let me see what I got here.
The most useful thing you can get is a 2d schematic or a high-quality picture of the vehicle. One for each dimension, so three drawings are required for the
body. This is the minimum amount of reference images you need to model the basic shape of the body, as they can be considered orthographic projections
which you will reconstruct the three-dimensional model from (Fig.).

Fig. – This is the principle behind orthographic projections. You will have to go in the opposite direction, from the projection to the object.

If the design is symmetric, draw only half of the car, then mirror it.

2.3.1 - WHERE TO FIND REFERENCE MATERIAL

You will have to search a bit to find good images of the vehicle and drawings. Do not expect to be able to find good pictures easily, especially if you’re
making a rare or historic vehicle. Schematics are always the most helpful (Fig. 2.1).

Fig. 2.1 – A Mercedes-Benz schematic. Things like these are a must-have if you want some material to start with.

103
There’s a bunch of good places I can suggest to begin your research from:

1. http://britishracecar.com; you can find very detailed descriptions, a lot of shots of the cars.
2. http://tech-racingcars.wikidot.com/circuit-cars; another quite good website to find images and specs.
3. https://www.w124performance.com; there is almost everything for the Mercedes W124. This means also a lot of images and documents for 1990s Mercedes car parts.
4. http://www.mulsannescorner.com; a lot of specs, for engines too. There’s even aerodynamic data for some vehicles.
5. Look for the service manual of the vehicle. If you can’t find anything for free you may have to buy it. Repair instructions are always full of specs and illustrations.
6. Research on the deep web. It can often give more results. You will have to use Tor Browser and the DuckDuckGo search engine.

2.3.2 –BEING FAITHFUL TO REALITY (wip)

Often making models of a real object is considered an art. This is because unless you’re using photogrammetry, similar three-dimensional capture
techniques with a resolution around one millimetre, or the vehicle manufacturer design models (VERY unlikely) there’s a lot of human interpretation going
on.
Wip

For example, we have a comparison between the real Ford GT40 and the one portrayed by Kunos (Fig.).

Fig. – They’re very similar, but not identical. Many of the lights can be made functional in vanilla, but especially with CSP additional features and specific functions can be added.

104
2.4 – MODELING RULES AND TECHNIQUES

2.4.1 – WHICH PARTS TO MODEL

Should I model every single part of the car? The answer is: “No, but between the visible ones, as many as possible”.
Go as detailed as you want, and if you want to include the drivetrain or the engine you can. The only limits are your ability and the poly
counts (for this one see par.). However you can ignore hidden parts that no one will ever be able to see. Obvious

I won’t stop anyone from reproducing all the tiniest bits of a vehicle, but be aware that if your model is above 1 million triangles it will
have to be optimized (already after 350k tris you should begin to worry and use the LOD shortening technique, par.).
In any case, if Assetto Corsa or other titles will be able to handle (with future hardware generations) very high-poly assets (over 1
million triangles) in the future, you will always have your detailed models ready.

2.4.2 – COORDINATE SYSTEM: THE VEHICLE IN THE 3D SPACE (=how not to lose yourself in a three-dimensional space)
Let’s see where you should draw your model in the virtual space of your modelling software. The reference point is the origin of the scene (or world) here,
so make sure that the three axis, X (red), Y (green), and Z (blue) are always displayed. Blender shows a horizontal grid along with the axis by default.

The car must be oriented as shown in Fig. 2.10: The Z vector must be the front direction. The model must be placed with the wheels touching the ground
on the Y=0 coordinate.

The model bounding box must be centred in (Y, X, Z) = (0, 0, 0). The 4 different LODs (p.) must share the same position and orientation.

The measure units must be meters.

Fig. 2.10 – Origins of the model for Abarth 500 EsseEsse by Kunos.

You can find example scenes in Scene templates folder in the sdk/dev folder!

2.4.3 - MODEL BUDGETS AND LIMITS

According to the original Kunos pipeline 2.0, the ~_lod_A.kn5 model (fully detailed, see par.) of an official car must stay below 44 MB, including all textures
and meshes.
I would say a 70-80 MB .kn5 is still fairly reasonable for modern hardware. In any case, the textures have to be very well optimized. You won’t get the
model below 50 MB without compressing most of the textures.

It's probably reasonable to go up to 50% past the official suggestions on poly count (those in the KP 2.0), but then on the release mention that the mod is
going to perform worse than the vanilla content (e.g. lower framerate).

105
2.5 – MESHES: GENERIC PARTS OF A VEHICLE
The components of a vehicle must be divided in many parts in order to manage static & moving & animated objects and other features present in game.
Moving and animated are two different concepts: for example wheels are moving (rotating), while wipers are animated (by hand).

2.5.1 - RULES

At paragraph 2.4.2 you will find a list of names for visual meshes (= objects). Those “labels” are suggested and recommended in order to avoid any trouble
identifying common objects in your model. You can use the following guidelines to name your vehicle parts without encountering problems later on.

1. Single objects must not exceed a total of 65.536 (65k) VERTICES. Anything above that number will not be opened by ksEditor (which may crash). The same limit applies
to faces, but you will almost always hit vertices limit first. This does not influence the budget for the entire model; we will talk about that one later, (with respect to
triangles, not vertices) at par.
2. The AC engine does not support 2 OBJECTS with the same NAME in the same model. This will likely cause the game to crash (due to standard model encryption, more
about it later).
While Blender adds a progressive number to objects with the same name by default, 3DsMax allows the use of duplicate names, so pay attention to it.
3. Be consistent in naming meshes within your scene. When you have multiple LODs in the same scene, make sure you keep the same names for functional objects (lights
and emissive, etc.) and dummies throughout the entire scene for all LODs (details about LODs in 2.F) to ensure that the game scripts work as intended for each one of
them. However there must not be matching names inside the same export (within ~LOD_A.fbx for example).
4. Do not use spaces: underscore has to replace those in the labels (Fig. 2.11).
5. Use lower case text; empties/dummies require upper case text, so this trick will let you avoid misunderstandings and confusion. This also implies that you mustn’t name
objects the same as the dummies.
6. If you make groups/parents of meshes, you can add a number like this: wiper_1, wiper_2 and so on. The numbers can be added also if you have multiple objects of the
same kind (window_glass_1, window_glass_2, etc.).
7. The names can be anything (within these rules). In theory, if you respect the dummy hierarchy we’ll introduce later (2.C), you can even name your front tires Johannes
and Johanna, but what’s the point? I don’t want to imagine the end of those poor fellas.
8. You can use a prefix like EXT_ (for car exterior body parts) or INT_ (for interior objects), to differentiate them from NULLs. The Kunos pipeline suggests to use prefixes
such as MESH_ or GEO_. Those can work well too.
Avoid long names and prefixes life VISUAL_ for the objects (Fig. 2.11), they are just a futile complication, a shorter prefix and lower-case text is enough. (check)
9. You may not need all the objects in par. 2.4.2, it depends on the car you’re making the mod of, but the main ones are usually required.
10. The names in par. 2.4.2 begin with a capital letter; you can avoid using it, just type the whole text in lowercase (like in Fig. 2.11, if you remove the prefixes).

Fig. 2.11 – Don’t use long prefixes and names; the simpler the better. This helps to keep things clean. The scene hierarchy and the model in this example are incomplete.

106
2.5.2 - MESHES & OBJECTS

For starters, below we have a list of the most common parts you can find in a vehicle (modelled for AC). More details about them will be in the paragraphs
that will follow.

VEHICLE PARTS:

Main_body ; also called BODY; must be present in LOD A and LOD B.

% ▲ Everything that will be under the main body mesh will be static and attached together like a brick.

Doors ; only in LOD A (with animations), if present on the car. In LOD B the doors are welded to Main Body.

% ▲ Use Door_right (driver side) and Door_left (passenger side) as names. An animation for each one of them is required, don’t
make a single animation for 2 doors.

% ▲ Mandatory names of the exported door animations are: car_door_L.fbx and car_door_R.fbx.

Windscreen
Motorhood ; also called Hood or Bonnet; must be present in LOD A and B.
Exhaust
Trunk ; also called Boot; must be present in LOD A and B.
Front_bumper ; must be present in LOD A and B.
Rear_bumper ; must be present in LOD A and B.
Wheel_hub_# ; also called simply Hub, contains the brake calipers, must be present on LOD A and B.

% ▲ You can change the name from wheel to wheel adding its position: Wheel_Hub_RF (right front wheel), ‘’_Hub_LR (left rear
wheel), ‘’_LF, ‘’RR.

Wheel_rim_# ; you can call it Rim; it must be present in LOD A and B. In LOD C the wheels are simplified.

% ▲ You can apply the same naming rule seen with Hubs for rims: Wheel_Rim_RF, Rim_LR, and so on.
% ▼ Use the same method for blurred rims (Rim_Blur_RF_mesh), tires (Tire_LR_mesh) and brake discs (Brake_disc_mesh).

Rim_blur_# ; it’s a low poly version of the rim with a blurred texture; must be present in LOD A and LOD B.

% ▲ 2500 triangles for blurred rims should be the reference. There’s no point in making blurred parts high poly.
% For different wheels use the suffixes for the corners of the car (LF left front, RF right front, RR right rear, LR left rear)

Tire_# ; must be present in LOD A and B. In LOD C the wheels are simplified.

% ▲▼ Like wheels and rims, use the suffixes LF, RF, RR, LR.

Brake_disc_# ; sometimes they’re called Disco, which is the Italian word for disc. Must be present in LOD A and B.
Caliper_#
% ▲ Like wheels, use the suffixes LF, RF, RR, LR.

Front_light ; you can call them also Headlight, Light, etc.; must be present in LOD A, B and C.
Rear_light ; you can call them also Tail_light, Brake_light; must be present in LOD A, B and C.
Reflector
Wipers ; must be present in LOD A, B and C.

Front_wing ; splitter. must be present in LOD A, B and C.

Rear_wing ; spoiler. must be present in LOD A, B and C.

Diffuser
- STEER_PADDLE ; must be present also in Low Resolution (LR) and LOD B.

- SHIFT ; must be present also in Low Resolution (LR) and LOD B.

- Arrow ;
- Seatbelts ; to be included not only in COCPIT_HR, but also in Low Resolution (LR), LOD B and LOD C.

107
2.5.3 – MODELING SUGGESTIONS FOR VEHICLE PARTS (wip)

TIRES

Do not draw the tyre grooves, as it would require too many polygons. Keep the tread almost flat (a bit curved because you may want to represent the flexion
due to inflation pressure) and use normal textures for grooves. Below you can see (Fig. 2.12 & 2.13) the correct way to make your tyres. Fig. 2.14 instead
shows what you mustn’t do, which is modeling the grooves.

What you can do if you already modelled the tread? You can bake it to the normal textures. This can actually be a very good technique if you want to create
detailed, high quality patterns on your tx.

Fig. 2.12 – Front tire of Ferrari 312/67 by Kunos: the mesh doesn’t have any drawn groove. This tire has 40 outer sides, and some are highlighted.

Fig. 2.13 – Front tire of Ford GT40 by Kunos. Same story, with a different tread pattern. The tread effect is given by normal textures. This tire has 48 outer sides.

Fig. 2.14 – Front tire of Alfa Romeo Giulia Quadrifoglio by Kunos. This tire has got 80 outer sides. I think you got the point.

108
Fig. 2.14 – The perfect demonstration of what NOT to do. The tread has been drawn with every single groove.

An exception are Formula tires (Fig.), where the grooves (if present) are very simple and give more depth to the rubber. Normal tex are used anyway.

Fig. – Example of a Formula one tire model in 3DsMax.

LIGHTS:

Each car must have individual objects. The light mesh objects must be separated and detached from the body of the car and use specific naming
conventions. The mesh name must be controlled from the lights.ini script. The same scripts include the instructions for the ON/OFF conditions, as well as
the light emission colour.

The mesh of the light is made from different parts, which are divided according to their function (Fig. ).

Fig. – Example of light meshes

109
Some examples: Position lights, brake, rear, standard front lights, high beams etc.

There is no need to split the lights up as “right” and “left”. They can be one mesh because they turn on together. This is important to reduce the number of
separate objects of your model.

Please do an extensive research about light functionality, and strive to implement as many functions as possible. Each light source must be detached as a
separate object, avoid keeping all the different reflectors and bulbs in one object. This way, each element can be controlled individually to achieve realistic
results. A good example is shown in the image below:

COCKPIT PARTS:
(for more info about cockpit LODs, par.)

- Cockpit_hires ; high resolution cockpit mesh(es), the one(s) you see in cockpit view.

Cockpit_hires doesn’t need to be one object, and most of the times it consists of the dash, the seats, the interiors of the car basically. Every mesh of the
interiors must be linked as a child of the NULL COCKPIT_HR (par.). Keep in mind that a low resolution (LR) version of the interiors is required for
optimization purposes (see Cockpit_lowres below).

- Cockpit_lowres ; low resolution cockpit mesh(es), the one(s) you see from far outside the vehicle.

Cockpit_lowres can and should be made of the smallest number of meshes and materials possible, to keep the object count low (and so the number of
draw calls); it has to be included and linked as a child of the COCKPIT_LR dummy (par.), and included in LOD A, B and C. It is not required for LOD D and
would only add unnecessary complexity (it would not be visible anyway from that far).

- Steer ; steering wheel HR and LR interior, LOD B and LOD C.

SEATBELTS
The interiors can have two different mesh objects for the seatbelts: one for the belt ON and another for the belt OFF (Fig.).

Fig. –

They must be linked as a child of the COCKPIT_HR empty (see par.) and must be named as follows:

CINTURE_ON for the belt on the driver when is driving,

110
CINTURE_OFF for the belt on the seat, without driver (showroom view).

The names are in Italian (CINTURE = SEATBELT).

For LOD A, both ON and OFF positions are REQUIRED (COCKPIT_HR and COCKPIT_LR). For LOD B & C only the ON position model is needed.
Also keep in mind that the ON/OFF positions are needed only for the driver seat, not for the passenger seat.

Pro tip: For COCKPIT_LR you only have to show the low-poly seatbelts on the driver, without the need to separate them from the rest of the cockpit mesh.

To create the proper mesh of the belt on a driver, place the driver first, then animate it and verify how the arms move in order to avoid interpenetration with
the belt mesh (Fig.).

DAMAGEABLE PARTS
Parts that take damage may be:
Front bumper, rear bumper, front and rear hood, exhaust, wing and the extractor (diffuser) on various GT cars etc. It depends on the model at hand.
After the parts are done, you must set up the material properly and edit a script.

Certain body parts must be detached and placed under a NULL that acts like a pivot/center of rotation for the element when it receives damage. Upon
impact, a script is activated that makes the parts vibrate/rotate on the basis of the location and pivot of these nulls. We’ll see which are the empties
we’re talking about later.
Keep the nulls and also these parts separate in LOD B. In LOD C, the elements can be attached to the main body and they do not have to be movable.
If the damaged parts are significant in size (massive front and rear wings on formula cars, you can keep the most important items on the LOD C to
make sure there is no visible LOD switch when the car is damaged.
Use the following guidelines:

1) Make sure that you have closed the mesh in the interior. You put a black texture or something very dark to ensure that there is no gaping hole
behind the moving objects.
2) Place the dummy/null in the rotation point that is logical for the part. For the MOTORHOOD it can be the hinges, for a FRONT_BUMPER it can be a
point that allows rotation but avoiding any intersection with the main body mesh.
3) Detach parts only that don’t leave holes in the car when moving, or carefully cap the holes.

FUNCTIONAL ELEMENTS: LEDs and DIGITAL DISPLAYS

It is possible to have various LEDs and indicators lighting up in the cockpit (usually on the dashboard, Fig.) while driving. It is recommended to make the
cockpit dynamic with as many functional items as possible.
It is very important that you do extensive research about dashboard functionality and digital screens (if present) and prepare the model for dynamic displays.

Fig. – An example of a digital panel for a GT racing car.

Below we have the list of all the functions supported by the game engine (vanilla), separated depending on which script they are configurated into.

Digital instruments functions:

 Speedometer
 Current Gear
 Current Gear (color change)
 RPM
 Any RPM-dependent status indicator
 Tachometer
 Tacho Limiter

111
 Fuel level (bar graph)
 Fuel level (litres)
 Fuel economy (km with current fuel left)
 Fuel warning light/LED
 Estimated fuel
 Headlight indicator
 Ambient temperature
 Water temperature
 Current timing
 Time of day (clock)
 Lap time (current)
 Lap time (last)
 Delta (difference from previous lap)
 Total laps
 ABS level
 TCS level
 G-Force meter
 Max Speed
 Max RPM
 LED single RPM value
 LED Delta bicolor
 LED single Fuel value
 Tire pressure
 Turbo boost (bar graph)
 Turbo boost (pressure)
 KERS charge - battery level % (bar graph)
 KERS charge readout (number)
 KERS input (bar graph)
 KERS usage - amount of energy used
 KERS max usage per lap
 DRS LED warning
 DRS On/Off LED
 DRS level - wing °
 Gear change indicator
 Placeholder script for any static text or numbers
 Other

Each individual LED (such as for RPM, boost or KERS) or bar TAG must be a separate object and numbered in a series:

LED_RPM_#
TAG_RPM_#
KERS_CHARGE_#
KERS_INPUT_#
TURBO_#
% ▲ Where the hashtag (#) is the number of each specific item in a series.

Some cars have multiple displays and it is possible that certain items (such as RPM) are shown in more than one screen. In this case, make sure that you
differentiate between the two readouts: LED_RPM_1_# and LED_RPM_2_# etc.
For functional LEDs or warning lights, each item must be a separate object, using the following naming conventions:

LED_LIGHT ; Headlight indicator light

LED_FUEL ; Fuel warning light
LED_KERS ; KERS status light
LED_IGNITION ; Ignition status light

There are two ways to control specific items on the dashboard.

The first one is where the mesh is always present and the script controls the emissive value on a per object basis. This is the method used for RPM LED
series, headlight indicators and ignition status lights.

112
With the second method the mesh is disabled by default and the script controls how and when it should appear with the shader and object properties set up
in the editor. It should be noted that the meshes appear in the editor and the showroom. This is used for dynamic RPM bar graphs, boost bar graphs, fuel
level bars, shift indicators, fuel warning lights and KERS bar graphs.

NOTE: If in the second case the item is a light with emissive values, it must also use an individual material with the desired emissive
value set in the editor (e.g. fuel warning light).

When creating the texture for the digital display, you must take into consideration the dynamic readouts that are supported by the engine and must not
include them in the static diffuse texture.

NOTE: Do NOT use the convention _01, _02, _03 etc. for single digits for the suffix of tag object names, always use _0, _1, _2 etc. E.g.
LED_RPM_0, LED_RPM_1 etc.

113
IMPORTANT: If there is a digital display, create a NULL called DISPLAY_DATA with the orientation shown in the image below. If there
are more displays, use a serial number (DISPLAY_DATA_1 etc.) to specify each individual screen. The DISPLAY_DATA null is the
reference for the items in the digital_instruments.ini, it serves as a reference point and makes sure the text appears on the same
surface as the display. For this reason if the display is rotated/tilted, the null must follow the same orientation. To avoid clipping, place
the null so that its pivot point is in front of the mesh by a few millimetres and not directly on it.

Fig. - DISPLAY_DATA null orientation and example for KERS bar graph (3DsMax).

NOTE: When the display is located on the steering wheel, the DISPLAY_DATA null and all the TAG/RPM mesh objects must be a child of
the STEER_HR null to make sure they rotate along with the steering wheel.

DIGITAL PANELS

Digital panels can be used for two functions: Push-to-Pass status and on-track Position. This feature requires a digital_panels.ini in the car’s data folder and
pre-drawn numbers textures in a your_car_name/texture/display_panel folder that you’ll have to create. As an example, take a look at the
content/cars/ks_audi_tt_cup/texture folder in your game install folder.
You will also need a parent NULL (e.g. DISPLAY_PANEL), with the same orientation rules that exist for the digital instruments (see above).
For the explanations of the Push-to-Pass and Position functions, see the digital_panels.ini config file at pag.

114
2.6 – SKINNED MESHES
FBX skinned mesh objects are supported by the game engine. Skinned objects can have as many bones as necessary but no more than 4 bones influencing
a single vertex.

A good example of skinned mesh is the driver (explained later) or the gearshift lever with a fabric skirt at the base of the lever (Fig.).

Fig. - This example shows what kind of things you can do with skinned meshes.

2.6.1 - RULES FOR THE CREATION OF A SKINNED MESH

1. All vertices must be influenced by at least one bone. If a vertex is not influenced by a bone, its world coordinates will be 0,0,0, resulting in a long polygon that spawns
from the center of the 3D world to your space position.
2. A non-skinned object can be linked with a skinned mesh. Connect the non-skinned object as a child of the skinned mesh. In the above image, the skin has 2 bones but
the handle is a parent of the non-skinned yellow null.
3. Every material with a skin rig must be unique. A material cannot be used on a standard mesh and at the same time on a skinned mesh. Two different materials must be
created, one for the standard mesh and another one for the skinned mesh.
4. The skinned-mesh dedicated shader must be KsSkinnedMesh or the KsSkinnedMesh_NMDetail. The animation works only when the skinned shader is assigned to the
skinned mesh.
5. The skinned mesh must have the pivot in the 0.0.0 coordinates of the world. It can be child of another dummy, but this dummy must also have the coordinates of 0.0.0.

We usually put the skinned mesh of the gearshift or something else in the cockpit as the child of the cockpit dummy/null. And the cockpit Dummy/null is
usually in the 0.0.0 coordinates. Or you can simply leave the mesh free without linking it to any node.

NOTE: Do not use this shader on a standard mesh without bones. Avoid using skinned mesh on suspension parts! For
springs and rubber parts use scale animation.

115
2.7 – NULLs & SCENE STRUCTURE
After you drew your model from scratch or you converted it and now it’s ready to be used in your 3D modelling software, you labeled the objects (=meshes)
to distinguish them; now, if you remember what was written in the INTRODUCTION about the empties/NULLs/helpers, you must create an interface between
the visuals and the functions of your vehicle.

To recap:

NULLs are objects; they’re called dummies in case of 3Ds Max, transforms / locators in case of Maya, helpers in case of Blender. These are objects that act
like "empty" objects (hence the name empties), and what you really care about is their name, position and orientation. The visual meshes are parented to
them in most cases.

During this phase, placing and naming dummies correctly will be the key to success. In order to work in-game, the car needs specific NULLs to be present
in all the LODs, so it’s important to make sure that all car parts are functioning properly.

2.7.1 – RULES
1. Make sure to set up the system units BEFORE creating the dummies and exporting the car (about the export process later).
2. All dummies must have Z-axis pointing forward and Y-up (Fig.).

Fig. -

3. Remember that every NULL is also a possible center of rotation (pivot point). The pivot point of the dummy must be identical to pivot of child mesh (or vice-versa). If a
rotating mesh is not properly placed under a NULL with a correct center of rotation, the mesh will rotate the wrong way. See Fig.: the geometry of the wheel is centred
exactly on the helper.
4. Each dummy can contain multiple objects. An example scene is provided in the folder (nnnghhHHHH) with a folder structure and hierarchy to follow (Scene
templates/scene_nosuspanim_example_max).
5. Make sure you keep only one set of helpers in your scene and that you use a clear layer structure to hide/unhide layers for exporting various LODs (see example scene).
6. When we use NULLs the names are a key factor, so always respect them. This time you MUST use uppercase/capital letters (CAPS).
7. Never scale the nodes once created. Doesn't matter what size they are, but scaling them afterwards can cause all sorts of issues. (just ‘applying’ the scale in Blender
works? check)

2.7.2 – THE EMPTIES REQUIRED (location/position!)

MAIN NULLs:
The following main empties must be present in all the LODS (except where it’s specified otherwise).

NULLs that control the wheels (1 null for each wheel; LF stands for Left Front, RR for Right Rear, etc):

WHEEL_RF ; Right Front wheel.

WHEEL_LF ; Left Front wheel.
WHEEL_RR ; Right Rear wheel.
WHEEL_LR ; Left Rear wheel.

% ▲ Position: pivot points of the respective wheels. Each one is parent of the respective TYRE_#, RIM_# and RIM_BLUR_# empties.

Dummies that control the suspensions (one dummy for each suspension of our car):

SUSP_RF ; Right Front suspension.

SUSP_LF ; Left Front suspension.
SUSP_RR ; Right Rear suspension.
SUSP_LR ; Left Rear suspension.

% ▲ Position: pivot points of the respective wheels, basically identical to the WHEEL_# dummies. Avoid placing these empties
anywhere else, otherwise you will have to play with the offsets in suspensions.ini.

Empties that control brake discs:

DISC_RF ; Right Front Brake disc.

116
DISC_LF ; Left Front Brake disc.
DISC_RR ; Right Rear Brake disc.
DISC_LR ; Left Rear Brake disc.

% ▲ Position: pivot points of the respective discs, MUST BE THE SAME as the wheels’ pivots.

Helpers that control high (HR) and low (LR) resolution interiors (go to section for more info):

COCKPIT_HR ; High Resolution cockpit node. (LOD A only)

STEER_HR ; High resolution steer node. (LOD A only)

% ▲ Position: the steering wheel rotates around the STEER_HR dummy's Z axis. Place the dummy accordingly then.

COCKPIT_LR ; Low resolution cockpit node.

STEER_LR ; Low resolution steer node.

SECONDARY NULLs:
These are dummies that are required to complete the car; their presence is limited to certain LODs:

RIM_RF ; Right Front Rim. (LODs A and B only)

RIM_LF ; Left Front Rim. (LOD A and B only)
RIM_RR ; Right Rear Rim. (A and B only)
RIM_LR ; Left Rear Rim. (A and B only)
RIM_BLUR_RF ; Blurred Right Front Rim. (A and B only)
RIM_BLUR_LF ; Blurred Left Front Rim. (A and B only)
RIM_BLUR_RR ; Blurred Right Rear Rim. (A and B only)
RIM_BLUR_LR ; Blurred Left Rear Rim. (A and B only)
TYRE_RF ; Right Front Tire. (LODs A and B only)
TYRE_LF ; Left Front Tire. (LODs A and B only)
TYRE_RR ; Right Rear Tire. (LODs A and B only)
TYRE_LR ; Left Rear Tire. (LODs A and B only)

% ▲ Position: pivot points of the respective rims / blurred rims / tires, MUST BE THE SAME as the wheels’ pivots.

NULLs FOR ANALOG INSTRUMENTS:

To animate a needle on the dashboard, the arrow_# mesh needs to be placed under a proper null. Just as other objects, ARROW_ nulls must follow specific
conventions:

ARROW_SPEED ; Arrow for the speedometer.

ARROW_RPM ; Arrow for the engine tachometer, also called rev (=revolution) counter.
ARROW_TURBO ; Arrow for the turbo pressure.
ARROW_FUEL ; Arrow for the fuel level.
ARROW_WATER_TEMP ; Arrow for the engine water temperature.
ARROW_TIME ; Arrow for the car clock.
ARROW_LIMITER ; Arrow for the engine max RPM.

% ▲ The ARROW_LIMITER is a tell-tale found for example in the Lotus 49 and Lotus 72D cars, showing the maximum RPM in a given
stint. The rotation of the ARROW_LIMITER null must be the same as the ARROW_RPM null, and it requires NO script, as it is
controlled from within the core engine.

Each ARROW_ node must be linked to the COCKPIT_HR NULL!

Each instrument is controlled by specific values in the analog_instruments.ini script, located inside the your_car_name/data folder.
117
The needle mesh must be created in neutral position and linked as child of a specific null. The arrow then must be rotated to the 0 position as shown in the
image above.

The Y axis determines the arrow position on the gauge and must be placed at 0 (ZERO) or the start of the gauge at hand. The Z axis of the node must
always point FORWARD.

You can use the Data Scripts tab in ksEditor to set up the analogue scripts (see EDITOR section).

To ensure compatibility in the future, if present, set up gauges that are currently not supported by the engine in a similar fashion, with name conventions
that are consistent with the existing rules and the function of the instrument:

ARROW_VOLTAGE
ARROW_OIL_TEMP
ARROW_OIL_PRES
ARROW_FUEL_PRES
ARROW_WATER_PRES

NULLs FOR DIGITAL INSTRUMENTS AND DISPLAYS:

DISPLAY_DATA
DISPLAY_CLOCK
DISPLAY_RPM
DISPLAY_SPEED
DISPLAY_TEMP

NULLS FOR THE BROKEN GLASS MESH:

DAMAGE_GLASS_CENTER_1 ; (A and B)
DAMAGE_GLASS_FRONT_1 ; (A and B)
DAMAGE_GLASS_REAR_1 ; (A and B)
DAMAGE_GLASS_LEFT_1 ; (A and B)
DAMAGE_GLASS_RIGHT_1 ; (A and B)

The number at the end of name can increase if other nulls/dummy are present. The implementation of damage glass is fully explained
in the DAMAGE GLASS section.

NULLs FOR DAMAGEABLE CAR PARTS:

For the DAMAGE of car elements, the following nulls must be placed in the PIVOT point of the object around which the object rotates upon impact.

FRONT_BUMPER (A and B)
REAR_BUMPER (A and B)
MOTORHOOD (A and B)
REAR_HOOD (A and B)
FRONT_WING (A and B)
REAR_WING (A and B)
REAR_EXTRACTOR (A and B)

NULLS FOR ANIMATIONS:

When it’s necessary to manually animate the suspension (always, if you make a high quality mod), or the car has Dion axle suspension, you’ll have to
include some extra nulls in your scene:

REAR_AXLE ; For the center of rotation of the Dion Trunk axle.

HUB_LF ; Hub for the Left Front suspension.
HUB_LR ; Hub for the Left Rear suspension.
HUB_RF ; Hub for the Right Front suspension.
HUB_RR ; Hub for the Right Rear suspension.

Read par. 2.7.2 for more details about suspension NULLs.

Additional dummies for animated parts are:

WIPER_# ; for wiper animation (A, B and C)

% ▲ Position: rotating pins of the windshield wipers.

118
FRONT_LIGHT (_?) ; for headlight animation (A, B and C)
DISPLAY_DATA ; for digital displays (A only)
DOOR_L and DOOR_R ; for exterior door animation (A and B)

% ▲ Position: door hinges.

DOOR_L_1 and DOOR_R_1 ; for interior door animation (A only)

NULLS USED BY THE VANILLA SHOWROOMS CAMERAS:

FLYCAM_L_0 ; farthest camera from the car, on the left (driver side)

FLYCAM_L_1
FLYCAM_L_2
FLYCAM_L_3
FLYCAM_L_4
FLYCAM_L_5 ; driver’s seat view (after you press ENTER in the showroom)

FLYCAM_R_0 ; farthest camera from the car, on the right (passenger side)

FLYCAM_R_1
FLYCAM_R_2
FLYCAM_R_3
FLYCAM_R_4
% ▲ There is no number 5 for FLYCAM_R because there is no passenger view, you can only move the driver camera once inside the vehicle, and that’s enough
for vanilla showrooms.

These dummies (Fig.) are required for the animation of the camera from exterior to interior view of the vehicle in the vanilla showrooms.

Fig. – Only four of the ten FLYCAMS are highlighted (with yellow arrows) here. It’s a mess near the car but it works.

Without the FLYCAM empties your mod can be considered incomplete, as that nice and smooth transition will not work and you won’t be able to enter the
car, even if you have the door animations (Fig.). A file with the empties will be available in the extras of this manual.

119
Fig. – No matter how hard you push ENTER or click on the IN/OUT CAR button. Without FLYCAMS You won’t get in.

2.7.3 – GENERIC DUMMY / MESH HIERARCHY (wip)

Any object that is not a child of a NULL will be managed by the AC engine like part of the car chassis.

This means that you need to make every mesh that’s not part of the car body a child of an empty that has a specific purpose. For example, if we want the
wheels to rotate, we need to make the wheel meshes children of the various WHEEL dummies: the wheel_LF mesh is a child of the WHEEL_LF empty.

Now, since you will have parent and child objects, you’ll have to respect this rule: all the pieces of the geometry that belong to the car must be placed in a
HIERARCHY to define the specific properties of each mesh object in the game.

If we don't respect the hierarchy, the car may load fine, but nothing will move. In the example before the wheels will be stationary as if part of the body.

In the same way you must place all the others pieces like children of the correct NULL that is designed for the part that you are
creating. So for the rim there is a dedicated NULL and so on for all the other parts.

Fig. - Wheels objects are linked to the wheel null/dummy.

In the car example file you'll be able to explore how we placed all the NULLs and the relating mesh objects. In some cases naming
correctly an object works without using nulls: for example if you name the left front rim mesh “RIM_LF” you can make it child of the
WHEEL_LF empty without adding the RIM_LF null.

120
2.8 – VEHICLE ANIMATIONS
klòù

2.8.1 - SUSPENSION ANIMATION

The 3D suspensions of a car can be animated if needed, with a number of frames defined by the user.

In order to enable suspension animations (let’s call them ANISUS), you have to edit the following line in the car.ini script (pag.):
USE_ANIMATED_SUSPENSIONS=1 ; This value controls the suspension animations. 0= disabled (default), 1= enabled.

Usually they are disabled; keep in mind that other kinds of animations are automatically created, like the steering wheel movement.

ANISUS do have some disadvantages. They follow predetermined arcs and movements, so the setup values chosen by the player in game are not visually
represented at the wheels correctly. For example camber angles might differ visibly from the values selected in the setup screen.

To create an ANISUS, you will have to follow these steps:

1. Set the number of frames in your timeline (for example 20 frames).

2. In frame 0 the suspension must be in the lower position.
3. The frame in the middle of your sequence (in our example frame 10) will have the suspension in the neutral position.
4. In the last frame (the 20th frame in our case) the susp. will be in its higher position.

We use a NULL hierarchy to animate the suspension geometry (par. 2.7.2).

How do ANISUS work?

The engine verifies the position of the suspension along the Y axis and finds the
right frame to match the animation to the position of the physical suspension. It
will interpolate the frames to generate a smooth movement.

AC will search for the following NULLs:

SUSP_LF
SUSP_LR
SUSP_RF
SUSP_RR

The dummies must be placed and oriented to move the suspension on the Y axis.
Example of how to animate a suspension correctly in Fig..

NOTE: Before exporting the FBX, timeline needs to be set with the same number
of total frames as the number of animated frames created.

Example: If you animate 20 frames, do not export with a timeline of 30. This will
cause a crash.

Remember to set the timeline to 20 if you have animated 20 frames. Empty

frames will cause a crash and are not supported.

Fig. -

2.8.2 - SUSPENSION HIERARCHY

The suspension must have the hierarchy identical to one of the two FBX examples provided: TEMPLATE_Suspension_EASY.fbx and
TEMPLATE_Suspension_COMPLEX.fbx

The first scene contains a simple suspension hierarchy, made for a car with simple suspension system. The second is prepared for complex suspension
hierarchy, like 60’s Formula 1 cars, with more complex arms and particular suspensions. Those examples contains more empties. Some names can be
customized and we have named the customizable dummy in an appropriate way, inside the template.fbx ”Custom_name##”. (where # is a number).

121
All the NULLs are used for animated parts. Their use is optional. You can create the necessary number of empties as you desire.

The WHEEL_# and the SUSP_# dummies are mandatory for the ANISUS.
The engine recognizes also 4 other nodes for the hubs of every wheel, namely HUB_#. These nodes are designed to allow the hub to rotate in accordance
with the camber of the wheel.

In some cars, the transmission shafts might be visible. There is a convention name to animate these objects automatically. Transmission DUMMY/NULL
names:

TRANSMISSION_L_1 for the Left shaft

TRANSMISSION_R_1 for the Right shaft

If you have more transmission pieces to animate, you can use sequential of numbering. For example: TRANSMISSION_L_2, TRANSMISSION_L_3 and so
on. The same applies to TRANSMISSION_R_2 and so on. The engine recognizes the prefix “TRANSMISSION_L_” and looks for a sequential number after
it. There is no hard-coded limit on the number of transmission parts that can be animated. The transmission nulls rotate on the X axis and needs to be
oriented like the image below:

This node is useful for animating the joint on the Y axis according to the suspension animation, and the engine automatically rotates
the transmission according to the wheel on X axis. Avoid animating on the Z axis, as it is not used.

NOTE: In order to have a correct direction of rotation, the Z axis of the transmission nulls always need to point forward.

In the above image example, the hub is the parent of the steer arms.

This way you can animate up and down movements of the hub or the suspension and during the animation you can change the camber of the hub as
required by the actual physical suspension layout.

Inside the TEMPLATE_Suspension_COMPLEX.fbx you can find an example for the correct hierarchy.

Note: The SUSP_ node must always match the position of the Wheel_ node. The AC engine verifies the position of the suspension in 3D space by checking
the SUSP_ node. The wheel bounding box is recognized between the SUSP_ node and Wheel_ node. Those 2 positions must be the same.

Again the FBX file TEMPLATE_Suspension_COMPLEX.fbx is a perfect example.

122
2.8.3 - STEER ARMS and DIRECTION CONSTRAINTS
We can animate many different parts and just import the animation to the editor and from that export to the game, but the STEER arm cannot be animated.
Its position changes in the 3D space according to the HUB rotation (due to user steering input).

In order to constrain the movement of the steer arm to the HUB’s position and rotation, the convention name with a prefix “DIR_customName” must be
used. This indicates the direction of the X negative axis of this mesh, and the null called “customName” will point the X axis to the correct direction.

Example: a null called “SteerArm_L” will point the negative X axis in direction of a null named “DIR_SteerArm_L”

Pay attention to the rotation of the null which the animated mesh is linked to. In the image below the right-hand side Null point has a positive Z axis. The left
Null point has a negative Z axis. This allows the -X axis to point to the center of the car or any other direction required by the mesh. Inside the
TEMPLATE_Suspension_COMPLEX.fbx file, you can find a proper hierarchy example.

Fig. -

Note: You can create more constraints, if you have more objects to constraint to the HUB by simply giving them different names. Nevertheless, it is always
good in terms of optimization to use the lowest possible number of constraints.

At this point, if you have the front or the rear wheels attached to a unique piece of metal (Fig.) you may be asking: what’s the hierarchy between my
suspended axle and the NULLs? I can’t make the left and the right hubs both parents of the same mesh. The solution is simple, you split the axle in half,
and animate both halves together as one single piece. Take a look at the Maserati 250F by Kunos (Fig.).

123
You can animate your custom nulls in the following vectors: Rotation - Translation - Scale.

Inside the TEMPLATE_Suspension_COMPLEX.fbx example file, you can see the animation of the suspension spring, on SCALE Y .

Note: Never animate the mesh. Always animate the NULLs only! With this approach you can change and update your mesh every time you want without re-
exporting the animations. Use the same technique to create animations for any NULL that has to be animated. For example, doors, gearbox levers, or any
other parts.

2.8.4 - CONSTRAINT FULL ANIMATION SETUP

If you don’t want animate the suspension manually you can create a full CONSTRAN setup.

You can use the DIRECTION CONSTRAINT logic to force you suspension to work automatically without animate them.

A example of this kind of suspension setup can be found in the EXAMPLE FBX provided with the SDK.

Costraint_suspension_Only.fbx for generic FBX 2014 version

Costraint_suspension_Only_XSI_2014.scn for XSI 2014 version

Costraint_suspension_Only_MAX_2013.scn for 3ds MAX 2013 version

2.8.5 - ANIMATION EXPORT RULES

Once you have animated your empties inside your scene, you will have to export them to the .fbx format, and afterwards, using ksEditor, you will need to
export them a second time to an AC-specific clip format, called file_name.ksanim (ksanim stands for Kunos-animation if it wasn’t obvious).

Some rules must be followed:

1. To generate a clip, you only need to animate the nulls.

Animating the mesh itself is not needed. You can also export the mesh, but the editor will only export the objects/nulls that have animation keyframes.
As we mentioned before, it is a good technique to animate only the NULL/DUMMY so that you can change your animation independently from the
actual 3D mesh.
2. When you export an animated null, you must also export the hierarchy tree above it, as the name of an object inside the editor is determined by its
position in the hierarchy tree.
3. Always export using the FBX format, as it is the only format that supports animation. Do not use any other formats.
In the example shown in the image above, we have two null hierarchies that contain meshes as their children. We have animated the shift and steer
paddle and we need to export the animation.

Fig. - We cannot export the SHIFT PADDLE_L null only. We must take the entire hierarchy from COCKPIT_HR, including STEER_HR and SHIFT paddle_L. This way the editor will
define the null related to the position of SHIFT PADDLE_L in the hierarchy.

4. Only if you’re working with Blender, you can skip the step with ksEditor by using a .ksanim exporter plugin:

OPTIMISING ANIMATIONS

1. The frames are interpolated in the game. You don't need to export an animation with all the keyframes. For simple animations, like doors, gear levers
and so on, you can export just the important frames only. For a simple door animation, the “close” and “open” frames are enough, the game will
interpolate the rest. When you have more complex doors, with pistons, vertical openings, like those in a Mclaren P1, you can add more frames to
animate the door in a more precise way. But always keep in mind that the less frame you use, the more optimized the result will be, because the engine
interpolates smoothly between the keyframes.
2. Identical frames are optimized. If you create multiple identical frames, and the variation between them is 0, the frames will be optimized. Example: A
gear lever starts animation at frame 15 of the complete animation, because during previous frames it stays fixed to its position, waiting for the driver’s

124
 hand to first reach it. A keyframe must be placed to frame 0 and another one at frame 14, both in static position. The animation of the gear lever starts at
frame 15.There is no need to place more keyframes between 0 and 14.

CLIPS AND NAMING CONVENTIONS

There are two types of pre-programmed playbacks:

1. Ping-Pong: The animation played reaches the end is then played in reverse from back to start.
2. Loop: When the first frame match the last frame and the animation restarts the loop.

The specific naming conventions have a pre-programmed playback in-game, so the engine knows whether the playback should be LOOP or PING-PONG.

Driver animations clip names:

steer.ksanim ; Loop for the rotation of the driver’s arms on the steering wheel.

shift.ksanim ; PingPong for the anim. of the driver’s arm to the gearshift lever (usually a simple animation, check the fbx example).

shift_dw.ksanim ; PingPong for the anim. of the fingers that operate the paddle to shift down (usually left).

shift_up.ksanim ; PingPong for the anim. of the fingers that operate the paddle to shift up (usually right).

Vehicle animations clip names:

car_shift.ksanim ; PingPong to animate the car gear lever.

Important: this clip must have the same number of frames as the shift.ksanim to match the arm movement with the shift animation. If in the driver animation,
the shifting movement begins at frame 10, the shifter must also start to move at the exact same frame.

car_susp_LF.ksanim ; Controlled by engine for the animation of the Left Front suspension.

car_susp_LR.ksanim ; Controlled by engine for the animation of the Left Rear suspension.

car_susp_RF.ksanim ; Controlled by engine for the animation of the Right Front suspension.

car_susp_RR.ksanim ; Controlled by engine for the animation of the Right Rear suspension.

Animated suspensions above are interpolated with the physics frame by frame by AC, that’s why they’re controlled by the engine.

car_door_R.ksanim ; PingPong for the anim. to open the right-hand side door.

car_door_L.ksanim ; PingPong for the anim. to open the left-hand side door.

lights.ksanim ; PingPong for the animation of the car lights that are dynamic (e.g. Ferrari F40, Opel GT, etc.).

For doors and hidden/pop up headlights the closing animation is the open animation in reverse. Do not animate the closing sequence!

car_wiper.ksanim ; Loop for the animation of the wiper (here you must animate the full animation back and forth).

car_shift_up.ksanim ; PingPong for animating the paddle shift up.

car_shift_dw.ksanim ; PingPong for animating the paddle shift down.

Pro tip: You can create all the animations needed for your vehicle. You can also use new custom names and then engage them from a script (such as active
DRS, wings etc.). The names listed above are recognized automatically and managed by the game engine for the basic, most important features.

For example: the anim car_wing.ksanim below is a custom name. On certain cars Kunos created animations called wing_rear.ksanim or wing_side.ksanim.
These optional animations are managed from the config scripts, e.g aero.ini, extra_animations.ini, etc.

car_wing.ksanim ; PingPong for the custom animation of dynamic wings (animate only opening sequence).

2.8.6 - EXPORTING ANIMATIONS FROM THE EDITOR

Follow these steps to export animations:

1. Open the car FBX in the editor.

2. Open the ANIMATION with the Open FBX Animation option under the File tab (Fig.):

Fig. -

3. Find and load the FBX animation that you had previously exported to the “animations” folder.
125
4. When an animation is loaded it automatically saves a clip_name.ksanim file in the same folder where your FBX file is located, there is no need to
manually export the animation clip.
5. Select the Animations tab at the bottom part of the editor UI. Drag the animation slider, and you should see the animation playback.

6. You can load multiple animations into the scene. Every time you load an animation, a .ksanim file is saved with the same name as the source FBX.
7. If your fbx is not named properly, you have to rename your clips to match our name conventions, for example steer.ksanim for the animation of the
driver arms etc.

2.8.7 - CHECKING CAR ANIMATIONS

When all your suspensions clips are exported to the proper animation folder (see “Project Structure” section), you can load your car.fbx in the editor and
check if the animations work properly.

You can do this only after you have created the animation clips and by loading them into the editor.

NOTE: LOD B must contain the same null hierarchy and names of animated nulls as LOD A for the exterior (suspension, wings, pop-up lights), but not for
animations in the HR interior (paddle and shifter) and the doors nulls under the Cockpit_HR null.

Open you car_name.fbx

After the car is loaded, you can load the clip of the suspension that you want to test.

In the tab called “Car Animations” you’ll find sliders. These are designed to help you test the animation of the springs, the constraint of the arms and the
wheel rotation.

126
The sliders allow you to check the suspension in the editor and detect any issues, frame by frame. Here you can see an example: Moving the slider you can
check the hub behaviour.

2.8.8 - GENERIC ANIMATION EXPORTING GUIDELINES

There are some important things to keep in mind when exporting animations, especially door animation clips. When exporting a door
clip, the following hierarchy should be present:

Complex door animations may include a higher number of nulls, make sure that the naming conventions are consistent and that you
export every null that is animated (per side). For more information, see ANIMATION EXPORT.

Note that the meshes and nulls of the interior door elements are under the null, COCKPIT_HR. This is needed because the cockpit
switches from high to low resolution. The LR door will be hidden. So we have duplicated the door animation nulls with animation
included, and placed them outside of COCKPIT_HR.

When you export, remember to include all the cockpit door nulls (left image)

NOTE: When exporting the animation of the paddle shifters (car_shift_dw and car_shift_up), make sure that you export the parent
nulls as well. If the paddles are on the steering wheel, for each animation you have to export either of the paddle nulls (SHIFT_R or
SHIFT_L), the null for the steering wheel (STEER_HR) and the HR cockpit null (COCKPIT_HR).

To animate wipers, you may use a number of nulls depending on the complexity of the wiper. Usually a wiper with 2, maximum 3 pivot
points (and thus 2 or 3 dummies) is sufficient.
The wiper nulls must be located in the root of the scene and they must be present in LOD A through LOD C.

127
2.10 - LODs AND TRIANGLE / OBJECT BUDGET
2.10.1 - UNDERSTANDING GPU PERFORMANCE (WIP)
When C# code runs too slowly, you can profile it to see where the time is being spent.

Graphics programmers are not so lucky. If you work for a big commercial studio and have access to an Xbox devkit, the Xbox version of PIX (see
https://devblogs.microsoft.com/pix/gpu-captures) gives nearly as much information about GPU performance as profilers can tell you about the CPU, but for
the rest of us the GPU remains a mysterious black box which cannot be so easily measured.

I like to think of GPU performance investigation as a Sherlock Holmes mystery:

 Performance is dead.
 Who killed her?

We must gather clues, form a hypothesis, and then confront the villain to make them confess.

We do have one advantage though, and that is the ability to rewind time and run our program again with minor changes. This is an incredibly powerful tool.
Let's say the evidence leads us to suspect Performance was killed by Colonel Mustard, in the library, with the candlestick. To confirm this theory, we can
comment out our candlestick rendering code, and run the program again. Is Performance still dead? If she lives, we know the murder weapon was the
candlestick, so should probably investigate how many polygons that is built from, and how expensive a shader it is using.

To be successful with this kind of investigation, two things are required:

1. You need an accurate way of measuring whether Performance is alive, dead, or merely in a coma. Display the framerate, and turn off vsync. You normally want those on,
but should temporarily turn them off any time you want to check Performance's heartbeat.
2. You need a good mental model of how GPU hardware works. What made me suspect the candlestick? How did I know it wasn't the lead piping? Without some
understanding to guide our suspicions, we could waste a lot of time randomly investigating one thing after another. GPU performance is highly nonlinear, so you will
often find that removing an entire model makes no difference at all, but then making a seemingly minor change to a different model can double your framerate. To the
uninitiated, these results can seem pretty random.

Many people have a mental model of how computers work that goes something like:

"A computer is like a small cardboard box. Inside this box lives an elf. The elf obeys instructions from my program, in the order they are given. Some
instructions tell the elf to draw pictures onto the screen."

Functionally, this description is correct. If computers really did work that way, they would behave exactly the same as they do today, and could run the same
programs. It is not enough to understand graphics performance, however. It oversimplifies to the point of uselessness. Here is a more accurate model:

"A computer is like a cardboard box inhabited by a pair of elves, Charles Pitchwife Underhill plus his younger sibling George Pekkala Underhill (both
more commonly known by their initials). Charles is smart, well educated, and fluent in dozens of languages (C, C++, C#, and Python, to name a few).
George, on the other hand, finds it difficult to communicate with anyone other than his brother Charles, prefers to plan his day well in advance, and gets
flustered if asked to change activities with insufficient warning. He has an amazing ability to multiply floating point numbers, especially enjoying
computations that involve vectors and matrices.

When you run a program on this computer, Charles reads it and does whatever it says. Any time he encounters a graphics drawing instruction, he notes that
down on a piece of paper. At some later point (when the paper fills up, or if he sees a Present instruction) he translates the entire paper from the original
language into a secret code which only he and George can understand, then hands these translated instructions to his brother, who carries them out."

This second mental model explains performance characteristics that might otherwise seem rather odd. For instance, if we use a CPU profiler to see what it
is doing, then draw a model containing 1,000,000 triangles, we will notice the CPU takes hardly any time to process this draw call. How can that be? Is it
really so cheap to draw a million triangles?

The explanation is that it didn't actually do any work when he got this instruction, merely jotting it down on his "instructions" list. You can write down an
instruction which says "draw a million triangles" just as quickly as one saying "draw 3 triangles", although these will seem quite different to the GPU when it
later gets around to processing them.

This parallel nature of CPU and GPU is tremendously important when it comes to understanding how they perform. In a perfectly tuned game, both
processors should be running flat out doing useful work, something like Fig..

128
Fig. - Time is along the vertical axis, increasing down the page.

Notice how the GPU doesn't start processing the draw instructions for frame 1 until after the CPU is entirely finished with that frame, and the CPU is busy
with frame 2 at the same time as the GPU is drawing the previous frame.

In the real world, it is hard to make your CPU and GPU workload exactly equal. If you have more CPU than GPU work, the timeline looks like Fig..

Fig. -

Notice how the GPU is sometimes idle, after it has finished the work from the previous frame but not yet received any instructions for the next.

This is called being "CPU bound". The interesting thing about this situation is that if we optimized our code to reduce the amount of GPU work, that would
make absolutely no difference to anything. The GPU would be spending less time drawing and more time idle, but the CPU would still be running flat out,
so our final framerate would stay the same. Even more interesting, if we can find a way to do more things on the GPU without also costing any extra CPU,
we could add more graphical effects entirely for free!

The other way around, look at what happens if you have more GPU work than CPU work (Fig.).

Fig. -

129
In this situation the CPU has finished with frame 2, and is ready to hand it over to the GPU, but the GPU says "hey, wait a moment! I'm not ready for that
yet; I'm still busy drawing the first frame". So the CPU has to sit around doing nothing until the GPU is ready to receive new instructions.

This is called being "GPU bound". In this situation, optimizing our CPU code will make no difference, because the GPU is the limiting factor on our final
framerate. We could add more CPU work "for free", replacing that idle time with useful game processing.

In order to optimize successfully, you must understand whether your game is CPU bound or GPU bound. If you don't know this, you might waste time
optimizing for the wrong processor. But once you do know it, you can improve your game by adding more effects to whichever processor is currently sitting
idle.

So how do you tell which is which?

People sometimes oversimplify this to something along the lines of "graphics calls run on the GPU, while physics and gameplay logic runs on the CPU", or
even "my Update method runs on the CPU, while Draw runs on the GPU".

Not so! Don't forget that your drawing instructions must be translated into a format which the GPU can understand. If there are many instructions, it will take
a long time to translate them all.

If you have a small number of instructions which draw a large amount of stuff, this will be quick for the CPU to translate but slower for the GPU to draw. But
if you have many instructions that each only draw a small amount of stuff (for instance a million draw calls with a single triangle per call, or many changes to
settings such as renderstates or effect parameters), this may end up taking longer to translate.

Even if your program contains nothing but drawing instructions, with no update logic at all, it is still possible that it might require more CPU time than it
does GPU time, depending on how much translation and coordinating work is required.

Here is what usually happens:

 Your Draw method issues graphics calls, which are recorded into a buffer
 Your Draw method finishes
 The XNA framework calls GraphicsDevice.Present
 This calls the native IDirect3DDevice::Present
 The DirectX runtime does some translation, then calls the graphics driver
 The graphics driver does some more translation, then hands the final translated commands over to the GPU

Using a CPU profiler, you will see:

 Some time in MyGame.Update

 Some time in MyGame.Draw
 Some time in GraphicsDevice.Present

That last part is where the translation takes place. If your profiler is able to dig below the .NET code to see what is going on in the native layer, this will show
up as a mixture of d3d11.dll, kernel32.dll, and the graphics driver for your card (typically nv4_disp.dll or ati2dvag.dll).

You might think measuring how long Present takes would be a good way to see how much translation work your game is causing. Or you may have
cottoned on by now that things are rarely so simple. There are a couple of other reasons why Present could take a long time:

 If your game is GPU bound, Present will spend time waiting for the GPU to finish drawing the previous frame
 If you have vsync enabled, Present may spend time waiting for the next monitor refresh

Because it can mean several different things, profiling the Present call does not tell us anything directly, but it is an important clue.

People are often surprised to see how long Present can take. They protest: "I would understand if my Draw method was slow (I am drawing a lot of stuff,
after all), but surely it is a bug that the framework spends so long in this method I never even directly called?"

This can be confusing because drawing graphics is a play-now, pay-later kind of a deal. The time spent in Present is directly caused by the drawing
commands you issued, but the true cost of those commands didn't show up at the time you called them.

There is one case where a drawing command may pay an unduly large cost, and this is if the internal graphics command buffer fills up in the middle of a
frame (ie. CPU runs out of room on his piece of paper). If this happens, Direct3D will call into the driver, translating a batch of commands and handing
them over to the to GPU, without waiting for the final Present call. This will show up in your profile as an arbitrary drawing call taking an unusual amount of
time. If you find yourself wondering why the first 1,000 renderstate changes were almost free, but then the 1,001th took a long time, that call is probably
paying a deferred cost for all your previous drawing operations.

Understanding how this works can teach us some things about graphics drivers. You know how newer drivers often claim to include optimizations that
boost overall rendering performance? If you think about it, this only makes sense for games which are CPU bound. If a game is GPU bound, speeding up
the translation code in the graphics driver will make no difference, since that CPU code was not the limiting factor in the first place.

It is also interesting to think about this from the perspective of a GPU hardware designer. One of the big questions faced by silicon designers is how closely
to mirror the behaviour of the D3D API. If they keep their hardware close to the D3D spec, the translation work will be simple, so their driver won't require
much CPU, but this might complicate the silicon and slow down the GPU side of things. On the other hand, if they optimize their silicon purely to be as fast
130
as possible, they are likely to produce a better performing GPU, but at the cost of more complex translation which will increase the driver CPU load.
Benchmarks don't talk about this much (I guess because not many people would understand the distinction) but there can actually be differences where one
card is more likely to be CPU bound, while a different design tends to be GPU bound.

Santa’s production line

I oversimplified when I described the GPU as a single elf named George.

In fact, a modern graphics card has a complex pipeline with hundreds of elves working in parallel. In the same way that the CPU records drawing
commands into a buffer, then the GPU processes them while the CPU is free to get on with other work, each of these internal GPU pipeline elves is reading
input data from a buffer, doing some computations, then writing output data to another buffer which is consumed by a different elf further down the chain.

This lets us subdivide the concept of being "GPU bound" based on which particular elf is causing the bottleneck. In the same way that optimizing your CPU
code makes no difference if you are GPU bound, successfully optimizing GPU rendering depends on knowing which part of the pipeline you are trying to
speed up.

So what exactly does happen inside the GPU? The details vary from card to card, but these are the most important stages:

1. The vertex fetch unit reads vertex data from memory

2. The vertex shader processes this data
3. The rasterizer works out which pixels are covered by each triangle
4. The pixel shader calculates the color of each pixel
5. The texture fetch unit looks up any textures that were requested by the pixel shader
6. The depth/stencil unit reads, tests, and updates the depth buffer
7. The framebuffer stores the final output color, and applies alpha blending

Any of these may be your performance bottleneck, and it is tremendously useful to find out which. For instance if we learn our game is limited by vertex
shader processing, we know to optimize that rather than wasting time trying to reduce the number of texture fetches. Or if we are limited by pixel shading,
we could increase the number of triangles in our models without affecting the framerate!

So what factors affect the performance of each pipeline stage? Here they are:

1. vertex fetch
 number of vertices
 size of each vertex
 whether vertices are well ordered for cache coherency
2. vertex shader
 number of vertices
 length of vertex shader program
 whether triangle indices are well ordered for cache coherency
3. rasterizer
 number of pixels rendered
 number of interpolator values passed from vertex shader to pixel shader
4. pixel shader
 number of pixels rendered
 length of pixel shader program
5. texture fetch
 number of pixels rendered
 how many texture lookups per pixel
 amount of texture data read from memory
 mipmapped textures have way better cache coherency
 DXT textures are smaller than uncompressed formats
6. type of filtering
 anisotropic is the most expensive
 trilinear is usually only a little slower than bilinear
 bilinear and point sampling are often identical
7. depth/stencil
 number of pixels rendered
 whether multisampling is used
 read/write vs. read-only mode
8. framebuffer
 number of pixels rendered
 whether multisampling is used
 size of each framebuffer pixel (including MRT)
 read/write (alpha blending) vs. write-only (opaque)

To identify the bottleneck, we need some way of altering just one of these contributing factors, and without changing our CPU code in any significant way (if
a change affected CPU performance as well as GPU, that could invalidate our results).
131
Try running your game in a tiny resolution, say 640x480. This makes no difference to the CPU, vertex fetch, or vertex shader performance. Does the
framerate improve?

If reducing the resolution does not affect performance (and assuming you are not CPU bound), your limiting factor must be vertex processing. You can
speed up both vertex fetch and vertex shading by using fewer triangles in your models, or you could try to simplify the vertex shader.

If reducing the resolution speeds things up, you must be limited by one of the pixel processing stages.

Try enabling multisampling. If this makes no difference, you are limited by the rasterizer.

To obtain maximum parallelism between different stages in a pipeline, you should ideally buffer up an entire frame of data in between each stage. This is
exactly what happens when sending data from CPU to GPU, but the buffers between the internal GPU pipeline stages are much smaller, holding at most a
few hundred triangles or pixels.

This means the GPU bottleneck can change over the course of a frame. For instance you might find your terrain rendering limited by texture fetches, while
animated characters are limited by the vertex shader, and bloom postprocessing is limited by pixel shading.

If you use the techniques from my previous post to examine such a game, you will find it speeds up when you shrink the textures (because this makes the
terrain rendering faster), and also when you simplify the vertex shaders (because this makes the character rendering faster). Performance of the game as a
whole is affected by more than one thing, but each individual piece still has just one bottleneck. We would see no performance gain if we optimized our
terrain vertex shader, or compressed the character textures, for instance.

To diagnose such a case, we must split the game into pieces and examine each part individually. But this is easier said than done! Sherlock Holmes is of
limited use here: instead we must call in Dirk Gently to understand the fundamental interconnectedness of all things.

For instance you might think we could examine terrain performance by temporarily commenting out the character and bloom rendering, letting us measure
the terrain in isolation. Trouble is, if we make that change our game is likely to go from being GPU bound to CPU bound, at which point we can no longer
experiment with GPU performance at all!

A better technique is not to remove anything, but instead add a loop that will repeat the same terrain rendering 100 times in a row. The framerate will
plummet (if it doesn't, that proves terrain rendering must be an insignificant part of the overall performance profile) and this new lower framerate will be
entirely dominated by terrain. By increasing the amount of terrain being drawn, we can dwarf the other scene elements into insignificance, letting us use the
techniques from my previous post to measure the terrain while basically just ignoring everything else.

If you split a game into pieces and measure each one in isolation, then put everything back together and measure the final result, it is common to find the
whole runs faster than the sum of its parts. This is because, even though the GPU pipeline buffers are limited in size, they do offer some parallelism from
one task to the next. You might find that out of 10 characters, 9 are limited by vertex shading, but the vertices for the first are being processed in parallel
with the last few hundred terrain pixels, so you are effectively getting that first character for free. It is also common that the amount of such parallelism will
change in unpredictable ways if you swap the order in which things are drawn.

There are no hard and fast rules here. Measure everything you can. Try to break out different parts of your rendering and measure them in isolation. Don't
expect everything to make perfect sense: all things are interconnected when they run in parallel, so a seemingly trivial change in one place can have
unexpected performance implications somewhere entirely different. It often takes a leap of intuition to look at a collection of measurements and figure out
which contain important clues, which are just side effects of the measurement process, and which were caused by the fundamental weirdness of parallel
processing.

Normally, the CPU and GPU run in parallel. Framerate = max(CPU time, GPU time).

If your code causes a pipeline stall, however, the processors must take turns to run while the other one sits idle. Yikes! Now framerate = CPU time + GPU
time. In other words, programs that stall can be both CPU and GPU bound at the same time.

The easiest way to cause a stall is to draw some graphics into a rendertarget, then GetData on the rendertarget texture to read the results back to the CPU.
Think about what happens if you do this:

 The CPU is processing your drawing calls.

 It has filled the RAM with instructions for the GPU.
 The CPU reaches an instruction that says "copy data from GPU back into this array".
 But the drawing instructions haven't actually been processed by the GPU yet!
 The CPU cannot just note down the GetData call on a piece of paper. The next instruction might use values from the array, so the CPU needs that data right away.
 The CPU has no option but to immediately hand the incomplete list of drawing instructions over to the GPU , then wait around twiddling his thumbs in boredom until the
latter has finished drawing everything, at which point it can resume processing the GetData instruction while the GPU becomes idle.

One of the great successes of the Direct3D API is how it hides the asynchronous nature of GPU hardware. Many graphics programmers are writing parallel
code without even realizing it! But as soon as you try to read data back from GPU to CPU, all this parallelism is lost (one reason it is hard to accelerate
things like physics or AI on the GPU).

132
2.10.2 - WHAT ARE LODs
LOD means Level of Detail, and is a method of defining, via different variations of a model, how high or low the viewable quality of the model should be,
and how it should interact with the environment.

Resolution LODs are 3d models visible in-game to the player from the outside view. There should always be more than 1 resolution LOD (unless it is a low
poly object). In open-world 3D games it is standard practice to swap out high-resolution models with medium or low-resolution ones at far distance from
the observer. This is done to prevent excessive demand of computing resources. Without the resolution LOD technique, the games would be unplayable
due to bad performance. It’s a compromise between computing power and attention to detail of the human eye.

The switching of different resolution LODs happens automatically, based on various in-game conditions (e.g. view-distance, number of objects, video
quality, CPU utilization, etc.). In Assetto Corsa there’s a dedicated config (lods.ini) that manages this with a simple script. The algorithm needs enough
different resolution LODs to be effective. Therefore the modeller needs to provide multiple resolution LODs with different polygon density. They should be
ordered according to their polygon count. In the official Assetto Corsa content the highest poly count LOD has letter A, the second one letter B, and so on
until LOD D, look at Fig. 2.11.

Fig. 2.11 - Here are some examples of the progressive degradation of the mesh for each resolution LOD in AC.

133
In addition to reducing the polygon density, it is best practice to also reduce shader complexity and the number of textures used - those too eat valuable
resources. The lowest resolution LOD won't need a normal map and not even a specular or gloss map.

With the recent progress of CGI technology, upcoming games will probably stop using LODs. Unreal Engine 5 by Epic Games introduces the Nanite
technology, that is a new internal mesh format and rendering technology to render pixel scale detail and high object counts. It intelligently does work on
only the detail that can be perceived and no more. Nanite's data format is also highly compressed, and supports fine-grained streaming with automatic level
of detail.

A Nanite mesh is still essentially a triangle mesh at its core with a lot of level of detail and compression applied to its data.

The whole rendering process is a lot faster, so probably LODs will become a technique of the past. However AC uses them, so let’s dive into it.

2.10.2 – LOD TRIANGLE COUNTS

Assetto Corsa uses LODs to manage both exterior body and interiors of cars.

The following triangle-counts are the recommended in most cases7 for each LOD:

LOD A: 150,000 - 350,000 tris

- Well-made cars can reach higher poly counts, but are performance demanding!

LOD B: 20,000 - 50,000 tris

- LOD B must have the same null hierarchy as LOD A, except for the following NULLs (and their respective child meshes):

 COCKPIT_HR (which becomes COCKPIT_LR)

 STEER_HR (becomes STEER_LR)
 FLYCAMS, which aren’t present (those are missing in LOD C and D too).

LOD C: 5,000 - 15,000 tris

- LOD C can just have cylinders with 2d faces for wheels and tyres.

LOD D: 2,000 - 4,000 tris

- Go as low as possible for performance, while you can keep the main shape of the vehicle. Remove the interiors.

Of course, these numbers are generic and apply to most top-tier cars with elaborate interiors. The truth is that there is no real limitation (to go higher or
lower). It's just that going too low might hurt detail, going too high might hurt your FPS and the optimization of the game (unless you think everyone has
very powerful graphics cards, idea far from being accurate).

Pro tip: There is also no explicit limitation on how many LODs you can create, be aware of that. A number of four is the minimum according to the Kunos
official standard, but adding more is often an unnecessary complication, unless your first-level model (LOD A) is very high poly.

A nice rule you can apply is to go as low poly as you can without cutting down on detail.

THE LOD SHORTENING TECHNIQUE:

If you have well made LODs, you can even shorten switch distances, changing the values in lods.ini (pag.). Keep in mind that the LOD B shall be visible at a
distance of 15 meters or closer. If you create a good LOD B, you can reduce the distance of the LOD A switch to LOD B and increase graphic performance.
To achieve this, try to reduce the model keeping the curved parts smooth, parts that create evident reflections, such as glass or curved parts of the body.
Try to see how it works in the game and refine it. The switch between the LODs must be almost seamless, as smooth as possible without any visible “jump”
or flash.

Another aspect of modelling performance-friendly cars is the detail of the wheels.

Sometimes, you can get away with lower detail on the car body, but very well-made wheels. So here are some numbers to help in this direction as well.
Budget for a wheel (tire + rim) should be around 5-8k tris (for normal-looking rims, see Fig.). Can go as high as 12k in case of a complex geometry.

The recommended number of outer sides on the tires (what is an outer side? See Fig. 2.12) is between 40 and 80, depending on the size of the wheel, and
reduced by half in each lower LOD (C and D can easily have just cylinders with 2D faces as wheels). The rims can have even double the number of outer
sides compared to tires, depending on how many spokes you have and the size of the wheel.

7
You may be asking: why are these numbers slightly higher than those in the original KP 2.0? Well, because with the performance of recent generations of hardware the sim is decently playable
even on low-end hardware if you don’t crank up the video settings. The latest version of the pipeline was released back in 2016. PCs are far more powerful after what, 7 years?

134
Fig. – Wheel of the Ferrari 312/67 by Kunos. You can take these numbers as reference, or look at other official content. The colours highlight different meshes here. You can work with
as many of them as you want, but keep in mind the budget for your object count. Join them together if they’re too numerous.

2.10.3 - LOD OBJECT COUNTS

When producing the LODs, the most important guideline to follow is to reduce draw calls (number of objects) as well as the number of separate materials.
In AC amount of draw calls (objects/materials) scales almost linearly with FPS and is extremely important as you often have large grids of cars. Cars
shouldn't exceed 200 objects for LOD A unless there's a lot of animations requiring separate objects, or in some specific cases like very complex digital
clusters, but that can be somewhat alleviated using CSP. Exceeding a number of 300 is almost always inexcusable. The lower the object count, the better,
period.

Note: To save file space LODs B, C and D don't include separate copies of every texture, so those are just loaded from LOD A, and if you rename/remove
textures there you'll break the other LODs. Export all the models with the same materials in your 3D editor, and with the same shaders/persistence in
ksEditor (about it in section).

Also, LOD B must contain the same null hierarchy and names of animated nulls as LOD A for the exterior (suspension, wings, pop-up lights), but not for
animations in the HR interior (paddle and shifter) and the doors nulls under the Cockpit_HR null.

You can look at these numbers as reference for object count:

LOD A: 200 objects

LOD B: 50 - 100 objects
LOD C: 20 - 40 objects
LOD D: 2 objects
By LOD C, the number of materials and objects should drastically drop, while for LOD D no more than a maximum of 2 materials and a similar number of
objects (no rotating wheels are required) should be used. Based on how visible the elements are, it is up to your judgement to remove other non-essential
nulls, such as wings, bumpers, hood etc.

Pro tip: For LOD C ensure you still have the emissive objects for lights so you don't have casting lights without emissive on car mirrors or at a distance at
night for cars behind, or noticeable missing brake/rear lights for cars ahead. This affects replays too. However, you don’t need to put this in practice for LOD
D, as the cars are too far for the lights to be actually seen/rendered.

Let’s take look at some car models. All the examples in the next pages are “properly” working in AC (which simply means they load in sessions); some are
part of the official content by Kunos, others are mods made from scratch or conversions; check the triangle and object counts8.

8
Also bear in mind that LODs A, B, C, D in Content Manager showrooms correspond to LODs 0, 1, 2, 3.

135
Fig. 2.16 – This model is a conversion. It has got more than 1 million triangles but there aren’t LODs, and that means big trouble for performance. You might experience sudden frame
drops and lag. The FPS drop is noticeable to the naked eye if you have multiple cars like this on the race grid; you can also verify it with an FPS counter. Look at the triangle counts for
wheels: you can fit entirely another car’s LOD A in these values, because every wheel is too high-poly, as in Fig. 2.15. That’s the main problem here. Remember: for tyre grooves use
normal textures, do not draw them. I wouldn’t recommend playing with 20 opponents (or even less) with this mod on your PC.

Fig. 2.18 – This mod is performance friendly because the LODs are present, but they were generated with Simplygon, a software which can produce artefacts; just look at the crests
and the deformation on the LOD D model. More about Simplygon later.

136
Fig. 2.19 – The Alfa Romeo Giulia Quadrifoglio by Kunos. Being part of the official content, there is not much to say. LODs are obviously present, and the triangle count is on average.

Fig. 2.20 – This car comes with LOD A and B only. The latter is well made (most likely by hand), so it gets the job done; adding LOD C and D would be even better, in order to
complete the mod, however quality speaks for itself, you can’t see much difference indeed, even if the triangle count of LOD B is just 1/5 of LOD A.

137
Fig. 2.21 - Few details must be preserved even in LOD D: the most visible parts. From this point of view the LOD D of this mod may even be too much detailed for Kunos standard, but
look at the triangle count: we’re past the recommended values but not too much, so it’s fine. Keep in mind that lower LODs take the textures from LOD A.

138
2.10.4 - INTERIORS
In LOD A, the cockpit has 2 resolution LODs for interiors, one High Resolution (the Cockpit_hires meshes under the COCKPIT_HR NULL) for the cockpit
camera and showroom view, and one Low Resolution (the Cockpit_lowres meshes under the COCKPIT_LR NULL) LOD for most exterior cameras, replays,
and distant views (Fig. 2.22).

The following triangle-counts are recommended for interior LODs:

HR Cockpit: 120,000 – 150,000 tris

LR Cockpit: 9,000-20,000 tris
LR Cockpit in LOD B: 5,000 tris ; as low as possible while keeping a decent quality
LR Cockpit in LOD C: 2,000 tris ; some detail must remain above window/windscreen level (roll bars, mirror…)

Fig. 2.22 – Models from Abarth 500 EsseEsse by Kunos. (left) Cockpit HR interior LOD example (~125,000 tris). (right) Cockpit LR LOD example (~7,000 tris).

Always bear in mind that the budgets for the cockpit are to be considered WITHIN the entire model’s LODs (LOD A, B, C, D, etc.)!

You have to make a few compromises then. For example, you shouldn’t make a vehicle with a total of 400k tris and dedicate only 30k to the exterior and the
rest to the interior or vice versa. I would recommend splitting your budget in half between cockpit and vehicle body (maybe slightly less for the interiors).
Depending on the type of vehicle the proportion can obviously change. Open-wheelers with small cockpits can use less triangles for the interior and more
for details on the exterior, such as the engine and suspension. It is up to the judgement of the modeller to use the poly budget in accordance with the
complexity of the model, but it MUST be optimised as much as possible without hurting the overall quality. Try to reach a balance between the poly counts.

Pro tip: This should be obvious, but do not model parts of the interiors that no one will ever be able to see, unless you plan to make them visible in the
future (i.e. the engine under the hood, which you may show with an animation of the bonnet).

The HR and LR cockpit LODs must always fit the exterior LOD A, because while driving, the EXTERIOR MESH that you see is LOD A (Fig. 2.24). When the
camera moves farther away, the cockpit LR will switch and you’ll get a simplified version of the cockpit, with only one material (in most cases) and a look
similar to the HR version.

Fig. 2.24 – As you can see, once everything is inside, it just stays inside.
139
Both LOD B and LOD C must have a separate COCKPIT _LR mesh that matches the reduced topology of each exterior mesh and replaces completely
COCKPIT_HR. The interior mesh must fit the exterior mesh and the outlining vertices must be snapped. Do NOT use the same COCKPIT_LR mesh for LOD
A, LOD B and LOD C. Make sure there are no gaps between the interior and exterior mesh.

On the LR Cockpit, see Fig. 2.25, you must keep the most visible parts relatively detailed to ensure that the switch is smooth. In tin-top cars this includes
the top of the dashboard and the frame around the side windows and the rear window. In open-seaters the sensitive parts are usually the area around the
steering wheel and behind the driver.

Talking about materials, as a general rule the number of materials should be as low as possible, so the LR interior should only use 1 material, but if the car
has a customisable interior with multiple colour options, more than 1 material is allowed. As a consequence, it is possible to use the detail textures defining
the colours too.

LOD A

LOD A

Fig. 2.25 – Other examples of LOD progression for interiors and cockpit of cars.

2.10.5 - ABOUT SIMPLYGON (wip)

Simplygon is 3D CG software for automatic 3D optimization, based on proprietary methods for creating levels of detail (LODs) through polygon mesh
reduction and other optimization techniques. It enables game development companies to set up automated workflows to generate LOD chains.

Auto-generated LODs shouldn't be used. Yes, they may actually work and sure, it's better for performance, but an important step in creating LODs is that
you can get rid of objects and materials in total. Like much of the cockpit, the instruments, chassis details etc, basically thinning out the object tree you see
on the right in Blender. You can easily increase performance by just removing all those tiny details that require not only a handful of vertices, but more
importantly a lot of materials.

Merging “by distance” the way Simplygon does will also often mess up the UV maps which can be very obvious on LOD transition in-game.

The following example (Fig. 2.26) is (from left to right) a 114k tris mesh, subdivided to 615k, decimated to 38k and merged to 49k (numbers differ because
the modifiers are based on face count, not tris). Simply by looking at the mesh of the merge operation, you can see that the normals will be all over the
place.

140
Fig. 2.26 -

It's a lot better already when using decimate options (or whatever the tool is called in the 3D programme of choice), as that can keep edges and wheel
arches smooth and not mess up the geometry.

141
2.11 - MATERIALS AND TEXTURES
GL

2.11.1 – THE PRINCIPLES OF TEXTURES: RGB COLOURS

Each tone that our eyes see can be interpreted as the combination of different base colours, named “primary” because they make up the visible spectrum.

Color theorists since the seventeenth century, and many artists and designers since that time, have taken red (R), yellow (Y), and blue (B) to be the primary
colors (Fig.).

This RYB system, in the "traditional color theory", is often used to order and compare colors, and sometimes proposed as a system of mixing pigments to
get a wide range of colors. In color printing we have a slight variation of the same theme: the usual primary colors become cyan, magenta and yellow
(CMY), often with an additional black colour (CMYK) for inkjet printers and mass production (newspapers for example).

Fig. – The RYB (on the left) system predates the modern scientific color theory and is very often taught in schools, being considered part of the art education. You can see
also the CMY system in the upper middle.

The additive colour model instead is based on the human perception of colours as studied by science. Every colour can be obtained mixing the shades of
Red, Green and Blue (RGB). These are called additive primary colours (Fig.).

Fig. – From left to right, the additive primary colours.

The result depends on the proportions in the mix. It is customary to define these proportions by an integer between 0 and 255 for each primary colour. So,
the product is a triplet of numbers between 0 and 255:

Color [R, G, B]: [X, Y, Z]

We are going to use this colour model for everything related to graphics, especially textures.

142
2.11.2 - MATERIALS AND ksEditor
In the following section you will find information about how to use the AC editor and guidelines for setting up materials.

MATERIAL NAMING CONVENTIONS

In practice there are no rules on material names, as they have NO effect on the physics.

However, to unify the modding world with a common standard compatible with the official content, please use the following conventions for naming them in
your 3D software:

- Firstly, ALWAYS indicate whether it is for the interior or exterior (INT_ or EXT_), then indicate the name that is straightforward (usually indicating the
texture it is using) and lastly indicate if it has to use a certain transparency property, such as AT for alpha test. When possible, use the following names:

EXT_Caliper
EXT_Carbon
EXT_Carpaint
EXT_Details_AT ; for labels and logos (use alpha test mode with transparency OFF)
EXT_Details_Chrome
EXT_Details_Metal
EXT_Details_Plastic ; Details=using the exterior details texture
EXT_Disc
EXT_Engine
EXT_Lights_Chrome
EXT_Lights_Glass
EXT_Rim
EXT_Rim_blur
EXT_Rim_blur_Alpha ; transparent blurred rim part (use alpha blend mode and transparency ON)
EXT_Tyre
EXT_Window

INT_Details_AT ; for labels and logos (alpha test mode with transparency OFF)
INT_Details_Plastic ; Details=using the interior details texture
INT_Details_Chrome
INT_Details_Metal_Black
INT_Details_Metal_Flat
INT_Details_Gauges
INT_OCC_Carbon ; OCC=using the ambient occlusion texture
INT_OCC_Leather
INT_OCC_Alcantara
INT_OCC_Plastic
INT_OCC_Metal
INT_BELT
INT_LCD ; ALWAYS keep the digital display on a separate texture (for racing cars)
INT_FUEL_INDICATOR ; material with emissive for the fuel warning light

If needed, you can use multiple materials (for multiple carbon patterns), in this case, make a distinction with numbers or name (e.g.
INT_OCC_Carbon_Flat and INT_OCC_Carbon_Refl). In any case, strive to differentiate exterior and interior materials.

NOTE: For a more comprehensive guide and community tips to use the editor, see the following thread on the official
support forum: http://www.assettocorsa.net/forum/index.php?threads/ac-editor.10964/

NOTE: to find useful information and request help for general editor and shader-related issues, see the following thread on
the official support forum: http://www.assettocorsa.net/forum/index.php?threads/car-materials-shaders-modelling-stuff-add-
your-knowledge-here.19704/

143
2.11.4 - GENERAL TEXTURING GUIDELINES (totally wip)
The supported texture format is: directX DDS
This format can be outputted from Photoshop (for example) using the specific nVidia plugin, available here:
https://developer.nvidia.com/legacy-texture-tools
As a general rule, we recommend using the DXT5 format with high-resolution textures (with or without Alpha) and 8.8.8.8 format for
textures with sensitive gradient information (RGB maps, detailed normal maps) or small-size detail textures and 8.8.8.8 where Alpha
information is included.
We need for every texture a PSD source with layers inside. The layers must be placed inside layer folders with consistent and user-
friendly names.

Inside every folder we need a base layer that allows us to change important features of the texture.

Main Texture rules:

a) If the texture has an ALPHA CHANNEL, do not collapse transparent features, keep the transparent features in a specific layer.
b) If there is a normal map, provide in the layer also the greyscale texture so that it can be re-generated with the nVidia tool
c) ALWAYS work with DOUBLE resolution (no more no less) of the target image and shrink it to the right size only when you export the
DDS. Test your results to be sure that the reduction does not spoil the image too much (this could happen with tiny texts or symbols).
d) All PSD files must be in RGB Color 8 bit for channel mode.
e) Name them following naming conventions below. You aren’t forced to, but it can help keeping things in order.

Texture naming conventions for PSD source files:

Skin.PSD ; contains the main body textures
Ambient occlusion
Wireframe (UV)
RGB Map (material specular-gloss-ref map)
Material IDs and zones
Alpha channel

Ext_Details.PSD ; contains rivets, bolts, logos, and decals on the exterior

Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Rims.PSD ; contains rim base and rim blur texture plus the blurred spokes
Diffuse
Normal map
Ambient occlusionRGB Map (material specular-gloss-ref map)
Alpha channel

Calipers.psd ; contains the brake caliper texture

Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Lights.psd ; contains the light texture

Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Mechanics.psd ; contains the underside, engine and every part that is not included in the Skin
Wireframe (UV)
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Glass.psd ; contains the glass texture and all similar parts such as black frame
Diffuse
Normal map
Alpha channel

Grids.psd ; contains tileable grids and similar textures (use more if needed)
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

144
Tyre.psd ; contains tyre textures with blur and dirt
Wireframe (UV)
Diffuse
Normal map
Ambient occlusion
Alpha channel

Disc.psd ; contains the brake disc texture and the glow texture
Wireframe (UV)
Diffuse
RGB Normal mapGlow map

Windscreen.psd ; contains the fake internal glass reflection

Diffuse
Alpha channel

INT_Decals.psd ; dials, dashboard symbols, cockpit details and logos, plates, interior bolts
and stickers
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

INT_Details.psd ; contains coloured gradients and other details to use for smaller objects
Diffuse
Normal map
Ambient occlusion
Alpha channel

INT_Occlusion.psd ; contains the cockpit ambient occlusion texture

Wire frame stamp
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Belts.PSD ; contains cockpit belts

Diffuse
Normal map

Seams.psd ; contains stitching, seams, and similar textures in tileable form

Diffuse
Normal map

INT_cockpit_LR.psd ; contains cockpit LOW RESOLUTION texture

Ambient occlusion
Wire frame stamp
RGB Map (material specular-gloss-ref map)
Material ID and zones
Alpha channel

All the extra textures that can occur and are not mentioned here can have a name that explains in brief what they contain. To see
how to manage textures you can see examples in the example folder in the SDK.

RAW TEXT BELOW!!!!

TIRES

CAR MIRRORS
In order to make car mirrors work, a material must be created (the name is not important), and assigned to the mirror mesh objects.
The mesh must be mapped with the texture called MIRROR_PLACEMENT. This texture is mirrored and the UV must be mirrored as well
to make sure it appears correctly. The texture is divided in three areas. CENTRAL must fit the central internal mirror of the car. The red
shows the left, while the blue shows the right hand side mirror. The 2 points at the center of the lines indicate a point that must be
placed in the center of the mirror to make sure that the cars behind can be clearly seen.

Remember to keep the correct aspect ratio of mirror UV, otherwise the image of the reflection will be distorted. The image ratio of the
MIRROR PLACEMENT template is 4:1.

145
Example of the MIRROR_PLACEMENT file, applied to the various mirror mesh objects:

NOTE: Only use the MIRROR_PLACEMENT texture for UV mapping, the actual texture in the editor
should be a flat texture named mirror.dds.

EXPORTING TEXTURES AND OPTIMISATION

According to the original Kunos pipeline 2.0, the ~_lod_A.kn5 file of an official car must stay below 44 MB, including all textures and
mesh. I'd say a 70-80 MB .kn5 is still fairly reasonable for modern hardware. In any case, the textures have to be very well optimized.
You won’t get the model below 50 MB without compressing most of the textures.
When the PC runs out of memory, the game engine starts to reduce texture size automatically, however this is done in a way that does
not ensure high quality, so we have to avoid it in all cases and stay below the 44MB limit for the LOD A.kn5 file.

NOTE: As a general guideline, you can use the DXT5 compression for high-resolution textures. Use AL (8.8, alpha luminance) mode for
grayscale textures with sensitive gradients. Use RGB (8.8.8) mode for map textures and ARGB (8.8.8.8) for NM textures with fine
details. Remember to keep a complete set of ALL of your textures without compression as a backup so that if they have to be
outputted again, there is no quality loss due to the added compression.

NEVER use the DXT1 compression mode. Keep the PSD files organized and updated so that they can be used to re-output textures if a
change is necessary after the delivery of the model. Do not work on compressed DDS textures, always make your changes in the PSD
and keep it updated along with the exported textures so that the latest version of each PSD file corresponds to the latest DDS output.

Below you can see some examples of textures, along with a reference size in pixels. Taking into consideration priorities to maintain a high-quality look, you
can use larger textures provided that you optimize other textures better and you do not go over the limit:

Skin_00.dds ; (the main body) must be 2048x2048 when it have sponsor and livery on. If is flat, can be 1024x1024 and saved as 8.8.
Skin_00_map.dds ; 512x512 ARGB

Rim.dds ; 512x512; It can contain a base material for rim blur non-transparent parts.
Rim_map.dds ; is half of the rim size and saved as ARGB.
Rim_Spokes.dds ; 256x256

INT_Occlusion.dds ; 512x512
INT_Occlusion_map.dds ; 512x512 saved as 8.8.

INT_Cockpit_LR.dds ; 512x512 or 1024x1024 depending on the car roof if open or close. DXT5 compression is enough.

INT_Decals.dds ; 1024x512 DXT5

INT_Decals_NM.dds ; 1024x512 in DXT5 or ARGB.

Lights.dds ; 512x512 ARGB

Lights_NM.dds ; 512x512 ARGB
Lights_Map.dds ; 256x256 ARGB

Tyre_D.dds ; 1024x1024 DXT5

Tyre_NM.dds ; 1024x1024 DXT5

Tyre_blur_D.dds ; can be 512x512 or 256x256

Tyre_blur_NM.dds ; can be 512x512 or 256x256, save as ARGB.

Disc_D.dds ; can be 512x512 DXT5 when very visible and half the resolution when the disc is small/not very visible or there are no details.
Disc_NM.dds ; can be 512x512 ARGB when very visible and half the resolution when the disc is small/not very visible or there are no details.

146
Disc_Blur_D.dds ; half of the non-blurred disc textures.
Disc_Blur_NM.dds ; half of the non-blurred disc textures.

Disc_warm.dds ; always 128x128.

Damage.dds ; 2048x2048
Damage_NM.dds ; 512x512
Damage_Mask.dds ; 256x256

Dust.dds ; 1024x1024 DXT5

INT_Materials_D.dds ; 512x512 or less, depending on image content.

INT_Materials_NM.dds ; 512x512 or less, depending on image content.
INT_Materials_map.dds ; half of base texture resolution, save all as ARGB (especially NM and RGB map) to keep the quality of the gradients.

Mechanics_D.dds ; can be 1024x1024 if it contains a visible engine. If not, it can be half. Save as DXT5.
Mechanics_NM.dds ; can be 1024x1024 if it contains a visible engine. If not, it can be half. Save as ARGB.
Mechanics_map.dds ; always half of the diffuse one. Save as RGB.

Belt_D.dds ; can be 128x256 ARGB and must be vertically tileable.

Belt_NM.dds ; can be 128x256 ARGB and must be vertically tileable.

Stiching_D.dds ; can be 256x128 vertically tileable, save as ARGB.

Stiching_NM.dds ; can be 256x128 vertically tileable, save as ARGB.

Calipers.dds ; 256x256; in some cases can be part of the Mechanics textures if your car is a ‘60s open seater racing car. Save as DXT5.
Calipers_NM.dds ; 256x256; in some cases can be part of the Mechanics textures if your car is a ‘60s open seater racing car. Save as ARGB.
Calipers_map.dds ; is always half the size of the diffuse. Save as RGB.

Grids tileable and various similar 256x256 or also half, depending on the image detail, export as ARGB.

OPTIMAL USE OF TEXTURE SPACE

When you use your space in the texture you must make sure to optimize everything the best you can. Maximum means that all
available space must be used. You have to plan before you start to make sure that you use your texture space in the most efficient
way.

An example for the Decals_D texture with good use of space:

Include the alpha channel both in the diffuse and the NORMAL MAP to make sure it suits every shader type.

In the following texture you can see the normal map texture with the alpha channel visible. The uncompressed alpha
channel defines the outline of the details.

147
Look at the following examples for the occlusion or the car skin textures to see how to optimize the available texture space:

The parts use the maximum space available and and the padding (extension borders) fill up the remaining space. This
arrangement allows us to reduce the texture to as low as 512x512 (uncompressed) but keep the occlusion gradients at an
acceptable level of quality. It is recommended that all interior objects with an AO map be mapped on a single texture.

The same material groups must use the same scaling to make sure the detail textures appear correctly.

NOTE: You also have to make sure that in the UV map the different UV parts are using the same scale to make sure that
any detail texture (metal flakes or carbon) appear correctly without any stretching and distortion!

148
It is recommended that you use a checkered detail texture for mapping the body and interior textures that use
detail textures.

Also, and especially on the exterior, textures must be well organized. Look the second example:

149
2.12 - BAKING THE AMBIENT OCCLUSION
This topic deserves an entirely separate paragraph due to its importance.

To have a more realistic illumination effect, we need to bake the ambient occlusion map for the exterior of the car, the rims, the lights and the interior of the
cockpit.

Fig. –

Take the exterior, and remove all the DECALS objects. If you have a movable wing move it a bit far from the body. Bake the Ambient Occlusion at double
resolution (4096x4096).

For the cockpit: remove all the DECALS for logos and the stitching. For baking the interior, place the doors like in the image. For baking the steering wheel,
remove everything else and bake it facing UP.

NOTE: look the pink pieces, they don’t take occlusion, but they influence the cockpit for them. They will be placed under a different material.

Fig. –

Keep the doors far enough to avoid a dark occlusion on the borders and the doorsill.

150
A baked texture is never how we want it in the end. We suggest to edit it in Photoshop and create softer intersections with objects. Random pixels can
create a bad effect when they are in a visible place. Use Photoshop to make the transitions smoother where necessary. The AO textures are globally a kind
of soft gradients. Avoid sharp, pixelated and unclean transitions.

Fig. -

IMPORTANT: when baking make sure you use a wide-enough padding to avoid bleeding black artifacts around the edges with low-resolution textures.

NOTE: With high-quality occlusion maps, such as those baked using V-Ray, will require less retouch in PS later on so it is worth spending more time on
how to bake the textures at the best possible quality.

Substance Painter AO is better than CM’s one.

151
2.13 - SKINS and LIVERIES
So, you want to paint cars. Where can you start from? It depends.

 If you want to make liveries for official content or mods from the community, your starting point consists of templates.
 If you’re the creator of your model and you have all the source files, you can make skins very easily, and you should include templates if you want to
share your mod and let people create their own liveries.

You will work with textures both ways, so first of all you need a tex editor. Some of the programs you can use are listed under THE TOOLS YOU WILL NEED
at pag. For the examples you see here I will be using Adobe Photoshop for the most part. Feel free to use any photo editor that you desire.

You will also have to grab the NVIDIA Texture Tools for Photoshop. The reason you will need this is to save your template into the DDS file format.

2.13.1 – SKIN FOLDERS AND FILES

The final products will be archived in subdirectories under the FIN\skins folder of your car mod (remember? See par. 1). That is also the path where you will
have to install any skin mods you can find online for that specific car.

The skins folder has a subfolder for each livery, and its name must respect the same rules as the FIN folder, so you must use the Latin alphabet and
underscore as spaces. There are no particular rules about uppercase or lowercase text, and you can use capital letters. Do not overcomplicate things too
much, keep in mind that there’s a 32 (or 30?) character limit on the folder.

Pro tip: You can also give a specific order to your skins: AC looks for numbers which are in front of the folder name. The newer cars from Kunos have skins
structured like this: 00_clubsport, 01_cup_01, etc.
If you want your favourite skins to be chosen by the AI more often, you need to have a lower number there. For example, if you use a structure like this:
00000_axa_91, 00001_loeb_racing, etc., in the File Explorer window, sorting by name, the 00_clubsport skin will be between them, but the simulator will
choose 00000_, 00001_, 00002_, etc. one after the other. With more digits you won't get overlapping, even with many skins. Usually three digits are more
than enough.

Inside the folder of each livery several files must be included:

- skin.ini

Sahfdhòsaf
[driver_70]
SUIT=\sparco\white
GLOVES=\sparco_racecars_tide_rg9\white
HELMET=\helmet_1975_grey\plain

[CREW]
SUIT=\type1\grey_black
HELMET=\grey
BRAND=\lamborghini

- ui_skin.json

Dxgjx
{
"skinname": "",
"drivername": "",
"country": "",
"team": "",
"number": "1",
"priority": 3
}

2.13.1 - WORKING WITH TEMPLATES (wip)

If you’re editing a vehicle made by another person you don’t have all the source files, so you will want to pick up a car template, if the creator made it
available.

All the official cars by Kunos do have the templates (thanks to the devs!). They are located in your AC install folder, under the
%root%\assettocorsa\sdk\dev\skin_templates path (Fig.). Good mods do include the templates in their files, and the highest quality ones will put them in the
skins folder, or in the aforementioned path if you install them correctly.

152
Fig. -

At this point the question is obvious: what is a template?

It comes as a PSD file. It is a format created and saved with Adobe Photoshop.

Hopefully your editor will be able to open the .psd file. Do not worry about the other files for now. The users of Paint.net might have to install a plugin to be
able to use psd files.

2.13.2 -
FAQ
QUESTION [1]: My Ferrari is always a shade of red no matter what color I paint it! What's going on?

ANSWER [1]: You need metal_detail.dds in your skin folder. It can be found in one of the default skin folders. I suggest using the one from Blanco Avus.

Q [2]: My preview.jpg does not work in the game.

A [2]: If the folder of the skin has a space in the name then replace the space with an underscore. There is also a 30 character limit on the name of the
folder.

Example: Rename 'Red Hot Ferrari 458' to 'Red_Hot_Ferrari_458'

Q [3]: What DDS settings do I use?

A [3]: Typical Settings:

DXT5 ARGB 8 bpp interpolated alpha

Mitchell Filtering
Generate 6 MIP Maps

Suggested by Redcart:

8.8.8.8 ARGB 32 bpp unsigned

Mitchell Filtering
Generate 6 MIP Maps

Q: Do I have to make a different skin for each "step" or "drift" variant of my car?

A: No. Just copy the skin folder to the appropriate "step" or "drift" folder. (Early Access 0.4.1)

Q: What keyboard shortcuts can I use while I am in the Showroom?

A: http://www.assettocorsa.net/forum/index.php?faq/keyboard-shortcuts.18/

Q: How can I see a thumbnail preview of DDS files in Windows Explorer (like as if i was looking at my pictures folder)?

A: Install Paint.net, even if you don’t use it.

153
2.14 - VEHICLE COLLIDER
Collisions between vehicles are one of the most resource-demanding activities of any game, especially if 20 cars collide in a turn at the same time. Physics
calculations are very CPU intensive (especially when everything needs to happen in milliseconds). Therefore using a high poly mesh for collisions would be
almost impossible. To optimize such scenarios, a simple collider shape is used to calculate collisions between car bodies and track objects (Fig. 2.27). The
collider shape must be a simple solid object with as low polygon count as possible (40-60 triangles), without any UV or texture.

Fig. 2.27 – Comparison of collider meshes for two different cars.

2.13.1 - RULES FOR VEHICLE COLLIDERS

At this point let’s see which are the main principles we’ll have to follow to make a correct collider model:

1. The collider’s pivot point (=its origin) must be in the 0, 0, 0 coordinates and have the same orientation as the wheel dummies. This is fundamental if you want to avoid
any trouble with positioning the mesh correctly (especially if you have to adjust its location).
2. Do not use empties, the only thing that matters is the mesh. Do not set any dummy as parent of the 3D collider.
3. The collider should have no more than 40-60 triangles.
4. The collider must not extend below the floor of the car (so DON'T go as low as the ground); look at Fig. 2.28.
5. The collider must have no holes. The mesh must be completely closed.
6. The mesh must have a material without textures called “GL”. Make sure you add NO textures!
7. Once the mesh is done, simply export the kn5 from the editor, using the name collider.kn5.
8. The collider must be placed in the same folder as the car LODs, so the FIN folder.
9. A shader called “GL” must be assigned to the collider inside the SDK editor, look at Fig. 2.29. This is a special shader specifically made for a mesh that is not rendered
in game and used only for collisions.
10. AC reads colliders differently than any other kn5 model, there's a visual transform that gets skipped, it just goes to the vertex coordinates, so any "change XYZ to X-ZY"
settings in fbx exporters do not apply, you have to build it in the actual vertex coordinates you want to be used (usually tilted 90 forward in 3d editors).

Fig. 2.28 – Graphic visualization of the level the collider has to be at, referring to the car floor.

154
Fig. 2.29 – Selection of GL shader for a generic car collider; geo_collider is the name of the mesh, and it may vary if you named it differently.

The collider.kn5 is also used (within the car-related assets) to check for DLC presence; DLC collider models have a tag in the file that AC checks against
Steam, so if a mod uses a DLC car's collider and you don't have said DLC your game will crash. You can try swapping the collider.kn5 with one from
another car just to check. If that's the issue, then replace, edit, or create your own collider. I'm pretty sure you can just zero the tag out but you'd have to
understand the kn5 format because there are differences: .kn5 version 5 has no tag and .kn5 version 6 has it. Sometimes (luckily) the logs are pretty clear:
LOADING MODEL content/tracks/ks_nordschleife/25.kn5

VERSION=6

[CSP SAYS] Required DLC might be missing

However it’s easier to not worry at all about .kn5 versions and just do things properly from the beginning.

No mod should require DLC packs. Low quality mods keep having DLC colliders that prevent users from enjoying the assets freely, while an accurate
collider takes 10 minutes to model. When you encounter problems like these, avoid the content from this kind of authors.

Now, there are various ways you can make a 3d collider from scratch, sculpting it from a cube or using some tools. So there’s plenty of options. In the next
paragraphs I will consider some methods, either by hand or semi-automatic. Two software will be used: 3DsMax and Blender. Obviously the explanations
will be pretty slow to let you understand everything, but you will find plenty of shortcuts to do this or that.

2.13.2 - HOW TO CREATE VEHICLE COLLIDERS

This is probably the best way to get the job done, using your rock-solid mouse and keyboard along with some reliable Neolithic tools. The best part is that
you can achieve the result you really want, you make your own choices and take all the responsibility of your actions.

This method is very simple, so it can be applied to basically any 3D modeling program.

We will create a cuboid, basically a carton box, and sculpt it with some patience. We will also take advantage of the symmetry of the car.

Tools: 3D editor (in this example 3DsMax), ksEditor

Steps:

1. In 3DsMax you will have the model of the vehicle. Set the view to Orthographic, this will make things way easier. Move the viewport to the top of the car so that you see
everything (Fig. 2.30).
2. Draw a simple rectangle on-screen with the Box tool which you can find under the Create tab. Encircle the model (Fig. 2.31), staying with a bit larger margin to be sure.
3. Change the point of view to the side of the vehicle; in the Modify tab (Fig. 2.32), right-click on the on the mesh name (here Box) and set it as Editable Poly.
4. Set the selection method to vertices (Fig. 2.33). This will allow us to manipulate the mesh easily. With the Select Object tool, select only the top vertices of the box, then
press W on your keyboard to activate the Move function. At this point you can extend the collider to the top of the vehicle. Use the snap feature to make every movement
follow the axes (Fig. 2.34).
5.

155
Fig. 2.30 – In the Orthographic view there is no perspective effect, so you can clearly see the true boundaries of the car from each point of view.

Fig. 2.31 – Begin from the top view, that way you will cover most of the car right from the start.

156
Fig. 2.32 – Converting the mesh to Editable Poly will allow you to edit its geometry.

Fig. 2.33 – The rectangular selection is easier done than said. You can use the Edge or Face selection method too, but you will later work with vertices, so I want you to get used to it.

Fig. 2.34 – The snap is a very cool feature present in most CAD and poly modeling programs: it lets you move along the axes, use geometric elements as constraint points for all the
editing purposes. It speeds up everything. You better learn how to use it.

157
Fig. 2.35 - Enabling Edged Faces is fundamental, if you don’t you won’t be able to see the Swift loops you will generate.

Fig. 2.36 - You will probably need to create only two or three swift loops. I suggest making one for the front and one for the rear, to manage them better. Here I will draw only one of
them.

158
Fig. 2.37 - Deleting half of the collider will allow us to use the symmetry and work only on half of the mesh. Cars are symmetrical and we don’t want to spend more time than
necessary.

Fig. 2.38 - Depending on which side (left or right) of the collider mesh you deleted, you may need to tick also the Flip checkbox. This is due to the X-axis orientation. The X value must
be set to zero in order to align the collider’s and the vehicle’s symmetry axes.

159
Fig. 2.39 – Extrusion is easy, click on the faces and push or pull them inwards or outwards. Be careful: avoid creating non-manifold geometry with this tool.

Fig. 2.40 – Wireframe will let you see very well the boundaries of your model. We have to look at them in order to define the shape of our collider.

160
Fig. 2.41 – The selection method is the same as before, only that this time you NEED to use vertices.

Fig. 2.42 – Working with the snap is important. You want to move the vertices only in a fixed direction, here from left to right or vice versa (so along the Y axis).

Fig. 2.43 – Rounding the edges. This is a first sketch, and it’s already starting to acquire the right shape.
161
Fig. 2.44 – Switch the view to the front or the rear of the car and do the same as before: select the vertices and move them to your liking around the vehicle body.

Fig. 2.45 - This is our second stage. Now you have to think about the possible contact points to redirect your attention to the most important areas and waste less time.

162
Fig. 2.46 – After more work, this is the result. It may be not the best, but that’s what I managed to do considering all the points where the collisions may happen, mainly the wheel
covers and the front. For other surfaces, like the sort of roll-bar and the windscreen in this case, you can create extra colliders in the colliders.ini config file (par.), without complicating
things too much on the mesh. I used the swift loop tool again, to add other vertices in the middle of the vehicle. We are exactly at 60 triangles, and it’s difficult to make a very detailed
mesh. Probably I could move a couple vertices on the engine hood. Anyway this is perfect, according to the rules. Note that the counter must be set to Count Triangles, not Count
Polygons.

Fig. 2.47 – Always remember to set the origin/pivot of the mesh to the (0,0,0) coordinates. Otherwise you will have problems with the position afterwards.

163
Fig. 2.48 – The finished product. In my opinion it doesn’t look bad at all, although it doesn’t matter, as it will be invisible in-game.

2.13.3 – OTHER METHODS TO CREATE COLLIDER MESHES

In order to make colliders the best option will always be drawing them by hand, starting from extruding and sculpting a simple cube, like we saw with
3DsMax. It can be easily done in Blender with the same techniques (box, swift loops, mirror and extrusion).

If you don’t have much time or experience, you can practice with other small exercises that will satisfy you. The results are immediate and rewarding enough
to keep you wanting to learn more and get into modifying any asset. We will take a look at a couple examples, this time with Blender.

Please note that these methods are good because they give you almost automatically the general (basic) shape of the collider, but in order to respect the
rules of paragraph 1 (especially rules 2, 3 and 4), you MAY NEED to slightly edit by hand the mesh you’ll obtain. You can’t say I didn’t tell you, even if these
should be lazy tutorials.

METHOD 1: SHRINKWRAPPING WITH A ROUNDCUBE MESH

This process, explained with simple words, is similar to taking a table cloth to wrap our vehicle model and capture a very simplified impression of it, that
vaguely resembles the original form. And we’re indeed talking about the Shrinkwrap modifier in Blender.

First of all, to keep things as simple as possible, let’s exclude all the NULLs (they will otherwise cause problems) and the objects that don’t define the
generic shape of the vehicle. For example the shape of your collider should not encompass a radio antenna or other particularly protruding decorative or
less important exterior parts. We can exclude the mirrors too; in any case you’re free to decide on what to keep, just don’t overcomplicate your work.

Tools: Blender, ksEditor, a text editor, and for testing purposes you need also the Test Pad track mod available in this manual’s resources, or here:

Steps:

1. Start with your model in Blender’s Object mode, exposing the orientation of the geometry; select all the NULLs and press H to hide them (Fig. 2.35).
2. Skip this step if you’re working on an open-wheeler vehicle. Always in Object mode, select all the wheels (along with all of their meshes) and hide them too.
3. Do the same with mirrors or protruding parts, if you want them to be excluded from the collider’s shape or if they cause trouble (Fig. 2.36).
4. Select every mesh visible from outside the vehicle, or press A to select everything, and join all of them into one single object.
5. Spawn a mesh that will engulf the model, and afterwards will become the actual collider. Although it may be done with a simple cube, subdividing it, I prefer using the
Round cube mesh to enwrap the cars. It’s part of the Extra meshes add-on that already comes with Blender, but you probably need to enable it (Fig. 2.37).
6. The Round cube is spawned on the location of the Blender’s 3D cursor (in Fig. 2.38 the latter is located at the world origin). A small tab with the configuration options for
our newly created mesh is on the bottom left of the screen. Don’t miss it.
7. Change the radius size to make the Round cube engulf the whole vehicle. You can also determine how much geometry subdivisions should be used. Keep the number of
subdivisions low. To have a better look at what you’re doing use the wireframe view, like in Fig. 2.39. In addition, don’t forget to assign a material to the new mesh; do it
immediately, any material will be fine. You’ll change the shader later in ksEditor, to make the collider invisible.
8. Now on to the main part, that involves the Shrinkwrap modifier. Orbiting, panning and zooming in, move your viewport inside the wrapping mesh (our Round cube),
select the pipette in the modifier’s options and click on the vehicle mesh (that’s why we joined all the objects together in step 4) to choose it as the target of the modifier.
9. The mesh will be wrapped around the vehicle. The default settings are good, but you can adjust them to your liking (Fig.).
10. Apply the modifier (Fig.). Check the result for airtightness and triangle count. In case the mesh needs a clean-up, especially if you used a high number of subdivisions in
step 7, read step 11.
11. To clean-up. Select the Roundcube mesh, press Tab to enable Blender’s Edit Mode and click on the empty 3D space to deselect everything. Via the menus, select all the
non-manifold geometries and merge them by distance (Fig. 2.43).

164
12. On final inspection hide the vehicle mesh and look for inverted faces on the collider, which you can see with a red colour (the backfaces). In Edit Mode flip the normals
on those faces so only the blue faces (the front-oriented faces) remain outside of the collider (Fig. 2.44).
13. Check again the collider, until you’re happy with the result.
14. At this point press Tab to exit Edit Mode and with the Roundcube mesh being the only selected object, export the final product in the .fbx format (Fig. 2.45).
15. After exporting the FBX start ksEditor and load the new FBX. Normally the collider will appear horizontal over the camera and with its rear side immediately visible. Right-
click on it and in the Material tab set its shader to GL.
16. Then save the .KN5 as Car (No textures) in your FIN folder, with the name collider.kn5.
17. Check the collider on the Test Pad track mod against the various walls and kerbs.

Fig. 2.35 – In this image you can see the first step in detail. Just follow the numbers. The false colors are blue and red by default.

Fig. 2.36 – Joining all the parts that form the general shape of the vehicle, without the protruding elements. You can choose what to keep and what to remove (by hiding it).

165
Fig. 2.37 – If you don’t find the Round Cube mesh in the Add menu (Shift+A), you have to enable it via the Extra Objects add-on in the Blender Preferences.

Fig. 2.38 – Add the Round Cube to your scene.

166
Fig. 2.39 – The configuration settings let you define also how many divisions of the Round Cube should be done. The value must be low; keep in mind rule 2 for colliders: the mesh
must have no more than 40-60 triangles.

Fig. 2.40 - If you prefer a closer matching of the vehicle’s shape you need to subdivide the Roundcube mesh before using the Shrinkwrap modifier. This implies that afterwards you will
need to merge densely packed vertices and decimate the result, to clean up the collider’s geometry. I do not recommend subdividing, keep things simple.

167
Fig. 2.41 – The inside of the Roundcube mesh is red because those you see are the backfaces. In 3D modeling, every face has a front and a back side; this is called face orientation.

Fig. 2.42 – You can select any wrap method you like, I suggest to use Nearest Vertex. Keep in mind that after you apply the modifier you won’t be able to change its settings anymore.

168
Fig. 2.43 - If needed the clean-up can be done easily selecting all the non-manifold geometries and merging them by distance. Hold the left mouse button and drag over the slider until
the problems shrink down to a dot. Then repeat the airtightness check. The face count for this example is 90 tris. It is sufficiently low, according to the rules.

Fig. 2.44 - If you subdivided, the more faces the more you will have to adjust in these additional steps. That’s why I recommend to abstain from subdividing and tightening up the
collider, to save editing time and CPU cycles in-game. 90-tris colliders are better than 146-tris ones when AIs or players pile up or hit the walls on the track.

169
Fig. 2.45 – These are the settings to export the collider model in the .fbx format from Blender. Apply Transform is required if you want to avoid the collider to be rotated when opening
the model in ksEditor.

METHOD 2: USING THE CONVEX HULL MODIFIER

Probably the ultra-fast version of a milkshake, only that we’re drinking it while on fire, approaching the edge of a crevice, without brakes. Yeah, that fast.

Let’s explain it VERY quickly.

Tools: Blender, ksEditor, a text editor, and for testing purposes you need also the Test Pad track mod by Stereo.

Steps:

1. Select the body mesh and enter Blender’s Edit mode pressing the Tab button. If you have more meshes, before anything, select all of them (except the wheels and
mirrors) and join them into one object.
2. While in Edit mode, press the letter A on your keyboard to select all the geometry of the body object, then press Shift+D immediately followed by Enter to duplicate it. It’s
important that you don’t move your mouse while doing this.
3. Go to the Mesh menu and click on Convex Hull. You can configure the transform parameters in the tab that appears in the bottom-left corner of the screen.
4. Right-click on the already selected geometry and choose Separate > Selection. The collider geometry will be separated into a new object.
5. Press Tab to exit the Edit mode and go back to Object mode. Click on the empty space, then click on the collider. You may want to look for it in the Outliner and change
its name, since Blender adds a progressive number.
6. Give a new material to the mesh you just created, with no textures.
7. At this point with the collider mesh being the only selected object, export the final product in the .fbx format. The settings are the same as METHOD 1 (Fig. 2.45).
8. After exporting the FBX start ksEditor and load the new FBX. Normally the collider will appear horizontal over the camera and with its rear side immediately visible. Right-
click on it and in the Material tab set its shader to GL.
9. Then save the .KN5 as Car (No textures) in your FIN folder, with the name collider.kn5.
10. Check the collider on the Test Pad track mod against the various walls and kerbs.

You can follow some of the tricks we applied in METHOD 1 to this second procedure. Checking normals is always a good thing, and some protruding parts
of the vehicle body can be excluded from the collider. Always pay attention to the wheels! In open-wheelers you MUST include them!

The cons of this method are that the collider you obtain may have a too complex geometry. If you do, you can always edit by moving and merging the
vertices.

170
Fig. 2.46 - Since I made this model for testing purposes, it is pretty simple. I already have every part of the body joined together.

Fig. 2.47 – After the duplication in Edit mode, apply the transform.

171
Fig. 2.48 – Separate the collider object from the car body object by Selection.

Fig. 2.49 - Rename the collider and give it a new material. There’s already a hidden COLLIDER mesh, as you can see. That’s because I already made my collider by hand. I’m not lazy.

Rotate pivot point

You shouldn't trust the CM showroom to show you where colliders are. But if it works that way ingame too then you have to import
the collider kn5, move the mesh (not any other object, has to be the mesh) and re-export it.

Colliders don't use the object transformation matrix at all, it directly reads the vertex coordinates and uses those. So if want to scale
the collider you just have to scale the mesh itself. In blender you use the scale tool in Edit Mode (switch from Object Mode using tab).

3. DIFFERENCE BETWEEN COLLIDER MESH AND colliders.ini

Wip

172
2.15 - ADDING THE DRIVER MODEL
fdg

The driver_base_pos.knh file is a sort of single frame animation.

If you want to use a custom driver mesh go to the section CUSTOM DRIVER, otherwise follow these steps:

2.15.1 - 3DsMax USERS

A copy of AC driver with the bones skinned, basic animation of the steer rotation, helmet and some textures, is provided as an example
template. It can be placed inside any custom car.

For a proper placement follow these steps:

1. Import the template file DRIVER_BASE.fbx in your 3D application. You should see the driver as in picture.

Inside the template, a basic steering wheel rotation animation is provided as an example.

The animation consists of 200 frames. The neutral position is on frame 100. From neutral (100) to 0, the steering wheel rotates to the
left. From neutral (100) to 200, it rotates to the right.

2. place your driver on the seat, with his hands on the steering wheel. Probably some modifications of our animation template will be
necessary.

The image here shows an example placement: The driver mesh and position can now be exported and it will contain the correct
hierarchy, and the correct names for the bones and various objects.

MPORTANT:

Remember to set the unit in EXPORT (for the provided pilot) to Meters. If not, the editor will produce a weird position of the bones and
a wrong result. Keep the same GENERIC UNITs in your 3D software.

173
This is needed because of the original scale of our pilot is 1 and must remain 1 even when exported. For a bone created with a scale of
1 inside 3dsMAX or MAYA, this problem should be not present.

2.15.2 - BLENDER USERS

WIP
2.15.3 - EXPORT THE DRIVER MODEL FROM ksEditor

How to export the driver base position from the editor:

1) Open in the editor the FBX file with the driver placed in the correct base position.

2) Save Driver Base Pos

A file named driver_base_pos.knh is created and stored in the same folder where the source FBX is located.

174
This file must be placed in the following path: AssettoCorsa/content/cars/CAR-NAME/ where car-name is the car’s folder.

The game engine will load the driver and place it using the correct position information stored in the driver_base_pos.knh file.

2.15.4 -DRIVER ANIMATIONS

The provided template file DRIVER_BASE.fbx contains a basic example of a 360° steer rotation loop animation.

This animation will probably not match the steering wheel of your car’s design. The animation must be modified to match your custom steering wheel
dimensions and placement.

Note: The animation must be 200 frames where frame 0, frame 100 and frame 200 match to allow a LOOP animation. For 3DS Max users we have prepared
an animation rig that can be downloaded from the Driver animation folder in the Dropbox link.

After editing the animation, save the keyframes of the arms NULLs only and export the FBX with ONLY the animated parts. Animating the pedals is not
supported yet. The image below shows the hierarchy:

The bones of the arms are highlighted in the blue and red area in the image, and every bone is parent of the RIG_Clave_L and RIG_Clave_R bones.
To animate the hand that does the shifting, animate the arm bones from RIG_Clave_L/R up to the fingers.
To animate the paddle gear change, animate the fingers only.
For every animation you must export a copy of the driver.fbx with ONLY the animated parts needed for the desired clip. Example: Export driver.fbx with the
steering wheel animation only, then another one with gear animation only etc.
Store the driver animations with the names indicated below in the animation folder of your car project folder with all the fbx files and textures.

Steer.fbx for the 360° steer rotation

Shift.fbx for the gearshift animation
Shift_up.fbx for the paddle shift up
Shift_dw.fbx for the paddle shift down

See the section EXPORT ANIMATIONS FROM THE EDITOR for instructions on how to create a clip.

Note: Always verify that the car shift animation and the driver shift animation have the same number of frames so that the animation is perfectly
synchronized in the game.

Warning: There is typo in the name of the “neck” bone, which is spelt as “nek” by error. Albeit being incorrect, the game still works with this wrong name,
so please do NOT correct the typo and keep it “nek”.

Example: When the driver changes gear, his arm starts the animation with the hand slightly distant from the steering wheel.

(see image below)

175
On frame 0 the hand is slightly away from the steering wheel. On frame 10 the hand is on the gear lever. On frame 20 the hand moves the gear lever. Be
sure that the gear lever animation is synchronized with the hand.

For example, if the hand needs 10 frames to reach the gear level, the gear lever must have 10 frames in the static position before it starts to move.

NOTE: See the following forum thread for a driver rig and explanation to be used in 3DS Max (many thanks for the_meco):

http://www.assettocorsa.net/forum/index.php?threads/custom-steering-animation-rig

DRIVER SCRIPTS (Send to data)

FAQ:

Q 1: I'm failing to move the driver. I edit the driver_base_pos.knh in the ksEditor just fine, but it's not affecting any change. I tried a different steer.ksanim
and it changes the driver position, but also only to a specific one - and then editing the driver_base_pos.knh again has no effect.

A 1: The steering animation does override the body position, so my advice would be just to do the steering animation. What I do is use The_Meco's brilliant
driver rig for steering animations, and also use it to export the driver position at the same time.

http://www.assettocorsa.net/forum/index.php?threads/custom-steering-animation-rig-1-7.18201/

This always seems to work for me, and both the animation and driver position don't conflict.

It seem like the steer animation fixes the position of the driver in the car, and the driver_bas_pos fixes how the body of the driver bends on those
coordinates. The steer animation itself is then again dependent on the STEER_HR Null's position too.

If you are a Blender user you should try using Stereo's Blender rig, I had much success with it: http://www.assettocorsa.net/forum/index.php?threads/bone-
animation-rig-blender.34594/

You don't need the KS Editor for that one at all, it can export .ksanim and the .knh directly

(wip)

176
CHAPTER 3 – CONVERSIONS
Why is this chapter here? The answer is: because you deserve it to be here. After all, you’re not doing a lot of work, which means that you don’t have the
priority over scratch-made content. Someone may ask: but aren’t they illegal, demonic artifacts to be censored and thrown into the pit of hell? Yes, unless
you have an agreement with the copyright owners (their explicit permission, and it’s better if you have it written down on paper). Information by itself is not
malicious, but it should not be misused. There are tutorials on the net for making gunpowder at home, what can a mod for AC be in comparison?

The main focus of this chapter (and the inner meaning of the term “conversion” in this manual) is allowing you to convert third party (with respect to AC)
game assets to a format which you will later be able to manipulate with your 3D editor of choice. You will also become more aware of the possible
consequences of using converted models, from the point of view of realism. More about the legal downside will be explained at par.

After any conversion, you will need all the information written in Chapter 2 to make it work in AC; take a look at it before and after coming here. Depending
on the type of game you’ll convert from, you will need different tools. They will be specified, but you can find them also at the beginning of this manual,
under THE TOOLS YOU WILL NEED.

3.1 - MODEL RIPS

What are model rips? What does the word “ripping” mean in the digital world?

The former origins of ripping involve taking data from a physical CD or DVD optical disc and putting it onto a hard drive or other similar storage media.
Once data has been ripped from a disc, it can be played back without requiring the original disc to be present. These processes allow the duplication of data
in order to back up CDs or to put audio, video or other content onto some other platform or device, legally or not. Thus ripping is also known more formally
as Digital Audio Extraction (DAE).

While "ripping" sounds destructive, the process does not affect the original data. However, the copied data may be decoded, decrypted, decompressed,
converted or modified during the process, so that it can be played on a computer via basic means (including open-source software, which amplifies the
freedom of choice). For example, DVD ripping programs may convert .vob encoded video files (which are specifically formatted for DVD players) to standard
.mpg or .mp4 files. The resulting video data can be played back using a simple video player program.

Over the years, the term has gained a more generic, less formal meaning, especially in the communities, involving the copy, decryption and edit of any kind
of digital asset, including 3D models, which are our main focus here.

3.2 - THE PREMISE TO CONVERSIONS

At this point we shall make a significant premise. It’s important to keep in mind that the models you will find in games or online often aren’t accurate or
faithful to reality at all. You may get different models of the same vehicle but you may not be able to tell the difference because you don’t know very well
how the real thing is. You may also find low quality assets that are more faithful to reality (Fig.) than higher quality ones, but sadly people tend to choose
higher poly models than opting for realism, and that’s pretty much wrong.

177
Fig. 3.0 – These models should portray a Nissan Skyline GT-R R32. The model A (top-right) is much more accurate despite being lower poly. B comes from Forza.

Also, it can happen that the 3D artists get the proportions completely wrong. Game developers can’t always get CAD models and drawings of the vehicles,
due to licences, industry obfuscation of the designs, or the accessibility to the real vehicles (especially if historic, vintage, rare, expensive, exotic or owned
by privates: not everybody allows strangers to take measures on their 200.000-dollar Duesemberg or their 20+ million-euro vintage Ferrari), so they
“eyeball” them, which means they make the model from photos, looking at the proportions with the naked eye. We’re humans, and all kinds of things can go
wrong with a model (Fig.). And sometimes the authors just don’t care.

Fig. 3.1 – Same models as Fig. 3.0. Here you can also see that B’s roof is flatter (and that’s wrong).

Following the masses is not our goal. We aim at realism, so unless you know exactly what you got your hands on, you better wait and look at some car
reviews, magazines and photos, to understand which model is portrayed in the game you made the conversion from.

Even an untrained eye can see the difference

178
3.3 – HOW TO CONVERT FROM VARIOUS GAMES
The title is self-explanatory. But things are not really straightforward.

Most of the times you can use 3DsimEd to import the files from the games and convert them in a format that you can open with your 3D editor of choice.

Since the procedures are very similar for different games, this manual won’t cover all of them; only one example will be provided. After all, you can find
instructions and tutorials on this topic very easily online, as there aren’t many racing titles that’s worth ripping from. Use conversions to learn modding, not
to make profit on someone else’s work!

3.3.1 - Example with FORZA titles: Horizon 3 & 4, Motorsport 7 & 6: Apex
To convert assets from these games to a usable model in your 3d editor, you will need 3DSimEd and possibly Swatchbin Texture Converter. The result of
this method will be a .3ds file compatible with both 3DsMax and Blender.

You will also be able to get the LODs for each vehicle, since Forza assets include them. Don’t miss that part. More about LODs at par. 2.9.

About textures, you will have to reapply them in your 3d software. In addition, the converted cars may not have the tires, which you’ll have to add by hand.

STEPS:

1. Obtain the assets you want to use. You can either rip them by yourself if you have the games installed on your PC (under the install folder\media\cars),
or download them pre-ripped from this website (you’ll have to create an account though): https://gamemodels.ru/files/category/1162-forza-motorsport-series
2. If your source is on the web, always scan with your anti-virus of choice the compressed archives you get in your downloads folder. It’s just better than
nothing, because this doesn’t always guarantee safety (if you don’t want to put your personal files at risk you shouldn’t go online, that’s the rule).
3. Choose a location you’re comfortable with, anywhere you want on your hard drive. But not on your desktop, please. You will have to adopt a subfolder
system, based on the games your models are from (Fig. 3.2). This will allow us to make 3dSimEd believe that it is working in the original game
installation folder, when in fact we are simply in a dummy location. If you don’t follow this structure or use wrong names, the program will import an
empty scene.

Fig. 3.2 – The subfolders you should create to make everything work.

Inside each folder of the games create a subfolder called media, then inside media create a folder called cars. Then extract all of your ripped or pre-ripped
contents there. The final path will be like this: %root%\FH3\media\cars\your_ripped_car_folder (Fig.).

4. The internal structure of the ripped folder (or the extracted pre-ripped archive, which usually includes all the files from the original game) should be like
in Fig. 3.3. Keep in mind that here may be more or less files and folders.

Fig. 3.3 – You can see the final path on top. This example uses the 1932 Alfa 8C assets from Forza Motorsport 7.

5. You need to rename the model's folder using the same name of the .carbin file inside. This step is necessary or 3DSimEd won't recognise the folder. In
our example the alf_8c_32 folder (Fig. 3.3) will be renamed to ALF_8C_32.

179
6. Now open 3DSimED31w and press on Import in the top left corner. Look for the .carbin model and make sure to select the correct import method from
the menu (Fig. 3.4). This will allow you to choose which car LOD to import. Load the model and select these settings when this window pops out. Then
click "OK"

Fig. 3.4 – For starters, you want the full detail model (for Forza it is Lod0), and the conversion of the swatchbin textures to the DDS format.

7. The model you choose will be displayed (Fig. 3.5).

Fig. 3.5 - LODs are a lot useful for optimization. Forza has even six of them. Don’t waste this opportunity! Many mods could have them but they don’t because of the creator’s laziness.
You will have to edit the models however, to make them fit the poly requirements, or adjust the behaviour of the LODs (see par.2).

8. Now go in the Tools tab and click on Split Objects by Material. A brief message will appear, then press Ok, and the software should now tell you that the
objects number has increased.
9. At this point create a new folder inside your Forza model’s location, and call it however you want. Here it will be named 3DS.
10.Go into the Export tab of 3DSimEd and click on Save to .3DS.
11.Select the new folder that you have created in step 9 and click on Save, then tick the boxes in the window that appears and then click on Ok (Fig. 3.6).

180
Fig. 3.6 – After you click Ok, it may take a while to save, especially on low-end machines. Please wait until it finishes.

12.You will now have the .3DS file inside your folder. Import it in 3DsMax, so that you’ll keep the model in quads (this way it’s possible to use some
modifiers, like smoothing, without the need to edit its topology) (Fig. 3.7).

Fig. 3.7 – As you can see, the model is still in quads. The wheels will have to be fixed or replaced entirely (if you don’t want to draw new tire meshes).

Now that you have the model you can also export it as a quadded .obj model from 3DsMax in case you want to work on it in Blender or any other software
easily. If you import the .3DS directly with Blender, the quads will otherwise be converted in triangles (even though the add-on has been removed in the
latest releases). That’s not what we want. Instructions about this at the end.

13.Now let’s export the textures. Go back to your previously created folder and create a new folder inside for the tex. Here we will call it Textures, however
you can name it however you like.
14.Go back into 3DSimEd and, in the Export tab, click on Plugin Export, select the Textures folder created and choose Wavefront Obj as the file format (Fig.
3.8). Click on Save, keep the export settings the way they are by default and press Ok (Fig. 3.8). This .obj model (you can see it in Fig. 3.9) is
triangulated, not quadded, so don’t use it. We’re just exporting it to get the textures automatically. Delete it afterwards to avoid confusion, especially with
step 12.

181
Fig. 3.8 – As you can see, there are also .kn5 export formats. You may be tempted to use them, but DO NOT. The car model, coming from another game, won’t have all the AC
dummies, the correct object names, the proper shaders, etc.; the exports simply won’t work or you may get any kind of error.

15.Now our Textures folder will contain the textures in the .dds (dx10) format which you will have to convert in other formats like 8888 or dxt5 (Fig. 3.9).
Most of them are detail tex. From now on you can use or replace them with others (paint colours, Alcantara, carbon fiber, etc.).

Fig. 3.9 - These are all the tex we got from our Alfa Romeo model.

16.You will need the normal-map textures; in case they appear red, they will have to be inverted and colour-keyed to make them look like the correct blue-
ish ones (Fig. 3.10).

Fig. 3.10 – On the left is the original tex. On the right the modified one. This shouldn’t be necessary too often. Here Adobe Photoshop was used to invert and change the tone.

182
17.The model may not be immediately ready for use, some parts may have to be moved and placed in the right spot and the rims may have to be resized
manually. These adjustments can change depending on the game the model is from (in our example FM7; models from FH4 usually need more fixes).
18.There may be missing textures in the exported files. These are mainly shared Forza textures or detail textures that weren’t converted in step 14. You can
either use your own detail textures or download the shared textures from here: https://gamemodels.ru/files/file/8377-textures-and-materials-pack-forza-
horizon-4
To convert the .swatchbin textures of this archive (if you download it), use the Swatchbin Texture Converter: load the textures and save them as .dds.
19.For the missing tire meshes, use those from an official Assetto Corsa vehicle that shares the same rim size, or make your own.

- Remember to follow the AC modding guidelines for object names, dummies/empties and everything else. You can find most of the rules in this very
manual.

- Two more things worth mentioning are that Forza models aren’t fully mapped, so you will need to remap most of it, and you will need to manually merge
the objects that share the same material for a better optimisation, as we detached them all in step 8.

HOW TO OBTAIN A MODEL FOR BLENDER

- As mentioned in step 12 of the conversion procedure, while you have your quadded model open in 3DSMax, you can go to File, Export and select the
.OBJ file type, then Save, wherever you want. The .obj model saved in step 14 is triangulated, not quadded, so delete it after you obtain the textures, to
avoid confusion. Use the export settings in Fig. 3.11 to export the quadded .obj from 3DsMax. In this example we will save this model in the 3DS folder we
previously created. The model will keep its materials but will lose the tex; that’s not a problem: we can always put them back on later, since we saved them
in the Texture folder.

Fig. 3.11 – The export settings for the quadded .obj model. They’re basically the default settings. Once it's all set, click on Export. You may get some texture errors, click on Don't
bother me again and then on Skip.

Once the export is done, you can close 3DsMax and open Blender. Inside this program, import the quadded .obj model with the settings in Fig. 3.12.

Fig. 3.12 – The Blender import settings for the quadded .obj model. Remember to select Split by Object and Split by Group.

You should now have your quadded Forza model in Blender (Fig. 3.13).

183
Fig. 3.13 – You will obviously have to rename a lot of objects. And re-assign textures to materials. But with patience you can do it. You can thank me later.

184
CHAPTER 4 - EXPORT YOUR 3D MODEL(S) TO .fbx
“Blender’s FBX exporter is notoriously funny, crazy, but most of all ineffable and cryptic” – A&M

After all the drawing, the naming and the structuring you did on your model (hoping you did it correctly), you can finally export it to a .fbx file which
ksEditor will be able to read. Let’s see.

4.1 - EXPORT SETTINGS

We’re going to export our 3D drawings (.blend for Blender and .max for 3DsMax) in the format supported by the FBX version up to the 2014/2015 plugin
(for Autodesk Softimage XSI and 3dsMax). Avoid using attributes that are not supported by this export format (such as physics constraint or mesh smooth
operators etc.). The 2016 plugin is unsupported!

The FBX data used by the AC engine are the following:

 Polygon mesh
 Normals (custom normals are supported)
 Texture coordinate UV (one layer only is read from the AC engine)
 Bones with vertex weight
 Nulls/dummies/nodes
 Hierarchy structure
 Animation data
 Basic mesh transformation (scale, rotation, position)

Reminder: The AC engine does not support two OBJECTS with the same NAME in the same MODEL. This will cause the game to crash (due to the .kn5
encryption). Make sure that you pay attention to this rule. Of course, when you have multiple LODs you have to use the same names for functional objects
and dummies, but there must not be matching names inside the same model export (i.e. within LOD A). Each LOD is a different model.

As a reprise from Chapter 2, make sure to set up the system units BEFORE creating the dummies and exporting the car!

Every mesh MUST have one TEXTURE UV set. The mesh must be (when possible) in quads. Do NOT triangulate the mesh if it is not necessary. For a
skinned mesh you can have as many bones as needed, but every single vertex can be influenced by up to 4 bones and not more. During the import process
the AC Editor ignores all unnecessary data included in the FBX.

In the next paragraphs are the settings to use to correctly export the assets with each of the supported programmes. Again, remember to set up your system
units before exporting (in Autodesk XSI it is not required). Did I say it enough times?

4.1.1 – Autodesk 3DsMax SETTINGS

In Fig. you can see the System Unit settings for 3DsMax.

Fig. 4.0 – The correct System Unit set up.

As a limitation of 3DsMax, if the System Unit Scale (Fig. 4.0) is wrongly set to mm or cm, even if the dimensions are correct, the dummies of the exported
model will still have the wrong scale. If the model and the dummies have been created in the wrong scale, one remedy is to export the model as .fbx and
re-import it in a scene using the correct system unit scaling. To avoid the trouble, please use the settings in Fig. 4.0 above.

185
NOTE: Make sure that you reset Xform after every modification that affects scale. It is advised not to scale suspension and wheel
nulls/dummies. (check)

In Autodesk 3DS MAX 2013 use the following export settings:

1. To export the base asset with no animation (Fig.) 2. To export animated NULLs/dummies (Fig.). (DELETE shorter)

Fig. - kkkk Fig. - kkk

Important:

The mesh must be scaled 1:1, rotation must be frozen on the mesh (reset Xform in 3DS Max) and objects should not have animated transformations. Only
the dummies/nulls may have different transformations. When they are animated they can be rotated and scaled, and some of them can act as bones for the
skinned mesh.

186
4.1.2 - AUTODESK SOFTIMAGE XSI 2014 SETTINGS

4.1.3 – BLENDER SETTINGS

(wip)

187
CHAPTER 5 - THE SDK EDITOR: FROM THE .fbx EXPORT TO .kn5 FILES
After you exported your models in the DEV folder as .fbx files, you’ll have to convert them in the .kn5 format that AC uses for its 3D assets; you’ll have to
define the shaders of your models too. This is not the end for you. Stay tuned.

5.1 - WHAT ARE .kn5 FILES

.kn5 files are mainly the models that the simulator is able to load. They are encrypted of course.

File format overview:

A .kn5 file contains 3 main sections:

1. Textures: Simple file blobs with a name.

2. Materials: Defined by multiple properties like what shader to use ("system\shaders") and properties for the selected shader. They also contain a list of texture names as
input for the shader.
3. Nodes: They define most of the game objects. There are three main node types:
 Base node: Only has a name and a transform matrix.
Base nodes are sometimes only containers and sometimes game relevant locations.
A .kn5 file has at least a root node that contains every other node. Every node has a list of children, but only base nodes are allowed to have them.
Base nodes with special names like "AC_START_0" define the location and orientation for certain game objects. This one would place the start location for car 1 on
tracks.
 Mesh node: Defines a mesh with vertices, indices, a single material and some other drawing optimization values
 Skinned mesh node: Mostly like a normal mesh but also contains bone definitions.

5.2 - THE SDK EDITOR (ksEditor)

KsEditor is part of the software development kit (sdk) made by Kunos. It’s a small program than lets you export .fbx models to AC .kn5 game files (Kunos
proprietary format), allowing the configuration of shaders and textures for each material.

You can also use it to check and convert the .fbx animations of your vehicle to the .ksanim format (ksanim stands for Kunos animation).

It is a WYSIWYG editor, which means “What You See Is What You Get”, so the results you obtain in its viewport will look the same in-game. This is because
it uses the same graphics engine of the game. Obviously vanilla.

Keep in mind that there are no undo/redo functions! Everything you do in the editor, if not saved, can be lost forever if you don’t screenshot or note it down!

5.2.1 - LOCATION
You’re asking yourself where to find this program on your machine; you have three alternatives:

1. Use the one included in your Assetto Corsa Steam install folder, usually under Steam\steamapps\common\assettocorsa\sdk\dev\editor; otherwise read
PART 1: AC MANUAL of this book to learn how to find your install folder.
2. Use the one you can find in the attachments of this manual (which has also new shaders included).
3. Launch it directly from Steam. You’ll have to search for and install the so-called AC SDK (Fig.).

Fig. – How to install ksEditor from your Steam library.

I suggest you to use the first two methods that involve File Explorer, that way you can create a shortcut on your desktop9 to launch the program immediately,
without Steam open in the background every time.

9
Simply right-click on the ksEditor.exe in the folder you chose > click on ‘Send to’ in the drop-down menu that appears > click on Desktop (create shortcut). Done.

188
5.2.2 - SETTING UP THE INTERFACE
When you open the editor for the first time, make sure you open the window in full screen, then save the layout (open layouts > cursor on one Layout >
change the name > click on Save Current layout > Restart editor under File menu).

Fig. 5.0 – How to create interface layouts. If it’s the first time you open ksEditor, you just have to rename the first Layout already selected. You can create plenty of layouts for all your
needs, but to be honest, this is a set-and-forget feature.

Each Layout saves the editor window’s size, resolution, and the layout (disposition) of the panels on screen, especially if you detached them. Yes, because
you can detach the panels of the editor from the main window to manage your screen space (Fig. 5.1).

Fig. 5.1 – How to separate panels from the main window of ksEditor.

Also, set your editor preferences under Utilities > Data Editor (Fig. 5.2).

Fig. 5.2 – Editor configuration. The default Default Weather (sorry for the repetition) should be fog. Change it immediately.

5.2.3 - IMPORT .FBX 3D MODELS

This operation is very easy, as you just have to open the .fbx model from the menu (Fig.).

The loading process may take from few seconds to several minutes, depending on the complexity of the model.

Once imported, the viewport will be positioned at the (0, 0, 0) 3D coordinates of your model. The location in space corresponds to the origin of your scene
in Blender or 3DsMax. This is valid both for tracks and vehicles. That’s why when you open a car model you’re always positioned at the bottom.

5.2.5 – USAGE AND PARAMETERS OF THE 3D VIEWPORT

You can navigate the scene using the left mouse button to rotate the viewport and the arrow keys on your keyboard to move it in four directions. With the
up/down arrows you can move forward/backwards, with the left/right arrows you can strafe left/right.

189
To move the viewport vertically, use the Page up/Page down keys.

There are three movement speeds:

 Normal, the default one when using the arrow keys;

 Slow, activated holding the Shift key while moving;
 Fast, activated holding the Ctrl key while moving.

To select an object in order to look at its properties, use the right mouse button. When selected, it will glow with a purple colour, and its name will be
highlighted in the Scene tab (Fig.).
Fig. -

Double-clicking an object with the right mouse button will make the viewport look towards it.

The scene light in the editor can be changed under the Illumination tab, Fig. 3.6:

Fig. 3.6 – Sun position, weather and post-process filter can be selected from this panel.

5.2.6 – WORKING WITH OBJECTS

When any object in the viewport is selected, its properties will appear in the Object tab in the lower part of the screen (Fig.).

Fig. – The Object properties editor.

These properties are related to the active object only. Let’s explain what each of them does:

 CastShadow:
 Center:
 IsActive:
 IsRenderable:
 IsTransparent:
 Layer:
 LodIN:
 LodOUT:
 Material:
 Name:
 Position:
 Priority: The graphics engine renders the objects according to the object list (left column) from top to bottom. With the priority setting you can change and sort it to your
needs. The higher the number, the higher the priority. You can also use negative numbers.
 Radius:
 Scale:
 Triangles:
 Y- and Y+ buttons:
 Reorder and collapse buttons: For the object priority

190
5.2.7 - WORKING WITH MATERIALS AND TEXTURES
The SDK editor can use various texture formats: DDS, PNG, JPG; use always .dds textures, as they’re the recommended format, look at SECTION 2.E.

JPG is a compressed format, so avoid it. PNG has the best quality, but DDS is faster, has better compression, uses less memory and has pretty good quality
too.

These formats for example won’t work if you try to import them in the editor: TGA (will assign and export but crash the game on load), BMP, TIFF.

All the tx must be in the texture folder of your project, which should be in the same path as the .fbx model (so under DEV\texture). You can review them
using the Texture Review tool under Utilities/Texture Review (Fig., option visible only when a model is loaded).

Fig. -

It is recommended that you keep your texture folder organised. You can back up unused textures with the “Move Selected in backup folder” button.

- It is mandatory that every mesh/object in your model has a material attached, otherwise when opening the .fbx model (which you will have to export later)
with ksEditor, you will encounter the following error (Fig.):

Fig. – The mesh, in this case named “Roundcube”, doesn’t have a material attached. This error will make ksEditor crash.

- When working with materials and textures, all the objects with the same material will be affected.

- When a texture is not assigned to a material slot, the value will appear as NULL.

- You can use a Copy&Paste tool to copy existing shader properties to a second material. Note that first you need to select the correct shader (if source is
ksPerpixelMultimap, the target needs to be a multimap material as well and so on), then fill in the shader slots manually! After these steps are done, you can
use the tool under Material Tools to copy and paste the shader values, as follows:

191
- Transparencies and cast shadow settings can be applied globally to materials under the Materials tab:

Fig. -

Persistence files
Let’s say that our project is finished. We assigned all the materials, we are happy with the results and we want to save our work. At this point you want to
create a persistence file.

What is a persistence file?

Persistence files store all the shader settings and object properties of your model. They can be saved under the File menu (Fig.). Be aware that they don’t
work like an undo button, because they save the last changes you made, not their history, so you can’t go back.

Fig. -

You can also load existing persistence files from higher LODs. Note that loading a persistence file on a new export will only transfer shader settings,
transparencies and cast shadow settings will have to be set manually. However, for later persistence updates using the load function (once the
transparencies are set), the transparencies will not have to be set again.

General guidelines to using different alpha modes:

Where possible try to avoid using Alpha Blend mode. Blend requires transparency, which can cause issues with draw priorities, because
some objects can be viewed from two directions.

A common issue is the interior: interior objects sometimes (such as the transparent interior windshield banner) need a priority set to 1
to avoid the object being drawn before the external glass objects when viewed from outside. However, from cockpit view, this can
cause issues with the blurred rim on opponent cars, because the blurred spokes object with a priority of 0 will draw before the interior
banner, if for example it goes around the windshield.

Of course, Alpha Blend mode is still required for glass objects and the blurred rim spokes. When using priorities, make sure the priority
is applied on the object level, not the sub-object level.

Additionally, if the transparent object is linked to a helper, you have to assign the priority on the highest level in the hierarchy, thus the
helper itself (see the section about Damage Glass).

192
It is recommended to detach all transparent object as separate objects in your 3D software before exporting. AVOID including transparent objects in a group
object with multiple material IDs. This is very important because otherwise adding a new materiaI ID later on could cause the transparency and cast shadow
settings to “migrate” to another subobject, incorrectly assigning transparency to otherwise opaque pieces of mesh.

Alpha Test mode usually works to a satisfying level when the alpha has no gradient. Alpha Test requires no transparency, which is why no issues will arise if
more layers are in front of one another. In Alpha Test materials, transparency is defined by the Alpha channel in the Normal Map.

Alpha Test mode can also be used to hide certain objects using a simple texture (make sure you disable shadow casting for those objects). Remember that
you control transparency with the Normal Map alpha channel.

Opaque mode is required for non-transparent objects, or where the shape of objects is defined by the mesh. Make sure you don’t group objects with
different properties in this respect under the same material.

If you have objects that require the alpha channel to define their border, group them under a new material. As a general rule, keep alpha and non-alpha
objects in separate materials.

5.2.8 - USEFUL SHORTCUTS

Specific shortcut keys have been added to the editor that allow faster work and quick feature testing:

 F1 switches from RIM to RIM Blurred. The effect becomes visible and can be tuned faster.
 F2 (hold pressed) shows the 3d model’s origin.
 F3 switches from COCKPIT_HR to COCKPIT_LR (if exist) and vice-versa. Useful to check if the switch of the cockpit models is too abrupt.
 F4 shows the GLASS damage mesh on and off. This command works only if the glass damage mesh NULL exists.

5.2.4 - MANAGE YOUR PROJECTS

To make modding easier, you can use the built-in Project Manager to save and manage projects: after you set up your DEV and FIN folders (more about
them in Chapter 1 P2 or pag.) and you exported your models (LODs included) to .fbx (info Chap.) you can define all your folder paths, to be able to
immediately find all the models of the car you’re working on, without searching for them every time you open the editor (Fig. 5.3, 5.4, 5.5). Your project
settings will be written as a .kscp file inside the KN5 Output Folder you select.

193
Fig. 5.3 – If you already set up your DEV folder click on Edit Project to create your first project in ksEditor.

Fig. 5.4 – This window will open when you click on Edit Project (Fig. 5.3); insert all the paths and filenames requested (clicking on the buttons with the dots, File Explorer will
open and you will be able to select your files). Pay attention to the difference between LODs.

Fig. 5.5 – After you click on Save Project, you’ll be able to open and edit your project; you will find all of its LODs in the drop-down menu under Car Project.

5.2.9 - FAQ
QUESTION [1]: Why does ksEditor have bad graphics? “I just started modding, and I want to play a little with textures but, it’s really hard because the editor
has a low resolution in the viewport, and textures look the worst possible, like in Fig. 5.13. My PC is a nuclear power plant, has 128GB of RAM and three
SLI GPUs, so I don’t think it depends on what specs I have”.

194
Fig. 5.13 – You can definitely see the model (a track), but with this poor resolution it’s pretty useless if you want a somewhat faithful representation of what will appear in-
game.

ANSWER [1]: Follow the first lines of paragraph 5.2.2. That should fix it. You can also edit the video.ini file in the %root%\assettocorsa\sdk\editor\cfg path.

QUESTION [2]: The viewport camera moves really slow even while holding CTRL. How can I fix it?
ANSWER [2]: Change the camera speed value in the Data Editor configuration, see Fig. 5.2.

WIP

5.2.10 - CURIOSITIES AND AMENITIES (you better know this info, you might get confused in the community otherwise):
A modded ksEditor exists, made by x4fab: ksEditorAT (version 6). Keep in mind most likely it’s outdated, or at least SOME SHADERS ARE MISSING,
ksBrakeDisc for example. It’s possible to add them though by copying from ksEditor resources, but I think it really ain’t worth the effort to do so. ksEditor is
perfectly fine for what you need to do. Also, as Ilja says, “be aware that if something fails, ksEditorAT is maybe somewhere in the background, window not
on screen or taskbar, and you may have to kill it in task-manager; then...its a good idea to test in normal editor first”. It has some cool little features, but isn’t
immune to crashes (like the original program). You can download it from this website: https://ascobash.wordpress.com/2015/07/22/kseditor/

195
5.3 – THE AC GRAPHICS ENGINE
The Assetto Corsa graphic engine is mainly a tailored Yebis-based shader system. The following are the main post-processing features of a Yebis shader
system.

YEBIS Features:

Glare

 Bloom (Soft Round Glare)

 Star
 Radiating Lights and Cross Filters
 CCD Smear
 Anamorphic Lens Flare
 Ghost
 Afterimage
 Soft Focus
 Light Shafts (Godrays)

Lens Effect (Optical Simulation)

 Depth-of-Field (Defocusing)
 Aperture (Bokeh with realistic lense aberrations simulation) Open/Close Simulation of Diaphragm Blades Lens Aberration/Correction Simulations
 Autofocus
 Focus Breathing (Inner / Rear / All-group Focusing, etc.)
 Airy Disk Simulation (Small Aperture Blur)
 Lens Distortion
 Barrel / Pincushion
 Fisheye Lens Effect
 Chromatic Aberration
 Vignetting
 Natural Vignetting
 Optical Vignetting
 Image Circle (Representing Scope)

Film/Photogalvanic Effect

 Tone Mapping
 Auto-Exposure
 Photosensitive Simulation
 White Balance
 Motion Blur
 Camera Motion Blur
 Object (Velocity Map-Based) Motion Blur

Others

 Anti-Aliasing
 Ambient Occlusion
 Color Grading / Gamma Correction
 Various Input / Output Color Spaces
 Various EOTF methods for HDR Output

196
5.4 - DEFINE THE MATERIALS: SHADERS
5.4.1 – WHAT ARE SHADERS IN AC
Workflow: tracks can use both specular and metalness; cars use metalness.
Main rule: never trust CM showrooms. Always look at the results of your work in a-game session. Also sometimes ksEditor is not good
at showing the final result with shader edits, always be aware of this.

CSP shaders work on top of vanilla ones?

5.4.2 – VANILLA SHADER TYPES

AC has got different shaders you can use for any type of material; below we have the list of all the accessible vanilla shaders. The ones which are not
mentioned here (and that you will never see unless you search for them) are hidden even from the sdk editor, as you don’t need to use them, being
hardcoded or outdated. To make it short this is what you’ll work with: (add page numbers)

1. GL p.
2. GL2D p.
3. ksBrakeDisk p.
4. ksBrokenGlass p.
5. ksCarPaintSimple p.
6. ksClouds p.
7. ksColourShader p.
8. ksFlags p.
9. ksGrass p.
10. ksMegaShader p.
11. ksMSDepthResolve p.
12. ksMultilayer p.
13. ksMultilayer_fresnel_nm TRACKS p.
14. ksMultilayer_objsp p.
15. ksOrenNayar p.
16. ksPerPixel p.
17. ksPerPixelAlpha p.
18. ksPerPixelAT p.
19. ksPerPixelAT_NM p.
20. ksPerPixelAT_NS p.
21. ksPerPixelMultiMap p.
22. ksPerPixelMultiMapSimpleRefl p.
23. ksPerPixelMultiMap_AT p.
24. ksPerPixelMultiMap_AT_NMDetail p.
25. ksPerPixelMultiMap_damage p.
26. ksPerPixelMultiMap_damage_dirt p.
27. ksPerPixelMultiMap_NMDetail p.
28. ksPerPixelNM p.
29. ksPerPixelNM_UV2 p.
30. ksPerPixelNM_UVMult p.
31. ksPerPixelReflection p.
32. ksPerPixelSimpleRefl p.
33. ksPerPixel_dual_layer p.
34. ksPerPixel_nosdw p.
35. ksPostFOG_MS p.
36. ksShadowGen_debug p.
37. ksSimpleShader p.
38. ksSkinnedMesh p.
39. ksSkinnedMesh_NMDetail p.
40. ksSky p.
41. ksSkyBox p.
42. ksSkyCubemap p.
43. ksTest p.
44. ksTree p.
45. ksTyres p.
46. ksWindscreen p.

While below there are extra shaders that come with CSP:

1. ksMultilayer_fresnel_nm4 p.
2. ksMultilayer_objsp_nm4 p.

197
 3. ksPerPixelAT_NM_emissive p.
4. ksPerPixelMultiMap_AT_emissive p.
5. ksPerPixelMultiMap_emissive p.
6. ksPerPixelMultiMap_NMDetail_emissive p.
7. smSticker p.
8. stPerPixelMultiMap_specular p.
9. stPerPixelMultiMap_specular_damage_dirt p.
10. stPerPixelNM_UVflow p.
11. st_multimap p.

EXTRA ++ SHADERS

stFlow

5.4.3 – COMMON SHADERS PARAMETERS: TEXTURE SLOTS

While working with ksEditor you will find several texture slots for each shader (Fig.). Let’s see what they’re used for. We will explain all of them here, but
each shader will use specific ones.

txDiffuse: It is your main tex. The color of an object is defined by this slot. It is the diffuse map, often called
colormap.

The pixel values given by the colormap are influenced by two slots, the ksAmbient and the ksDiffuse.

normal map = similar to bumpmaps (affects lighting only and creates a 3d-ish look on flat surfaces)

detailmap + variationmap = blends details or variation into a colormap

alpha channel = black&white map is usally used for transparency and specular highlights

5.4.4 – COMMON SHADER PARAMETERS: MATERIAL SLOTS

ksAmbient and ksDiffuse are added to give the color, not multiplied.

ksSpecularEXP is basically the roughness of the object.

isAdditive is a parameter very important to reflection properties.

isAdditive = 0 means that the maximum reflection sharpness is only achieved with a specular power of 255. Think
of this like a simple material - plastic, rubber, whatever. It's only reflecting at one layer so specular + reflective
sharpness are tied together (to get technical, the specular spot is the reflection of the sun - it's just that the sun is
so much brighter that it needs special casing).

isAdditive = 1 is literally true, it sets reflections to additive (instead of the default fresnel mix). I think this is for
glass. Same deal, specular power of 255 is sharp reflections.

isAdditive = 2 means that reflections are almost always sharp - specular power of 8 or higher will do it. It's also
back to the original case of fresnel mixing. Think of this as something with a clearcoat - the undercoat of paint can
have a metallic specular setting, the clearcoat still has sharp reflections.

detailUVMultiplier entirely depends on your UV map

198
5.4.5 - VANILLA SHADER DESCRIPTIONS (wip)
1. GL
This is the shader assigned to car colliders. It requires a material in order to work, but no textures. Simply give a generic material to your mesh in your 3D
modelling software of choice.

In ksEditor after you assigned this shader to the mesh, it will appear rainbow-coloured (Fig.), while in game the object will be completely invisible (but
collidable).

Used for tracks?

Fig. – The collider mesh after the GL shader has been assigned to it.

2. GL2D

3. ksBrakeDisk
The shader for the glow effect when the brake discs reach extremely high temperatures.

Brake glow textures should be entirely black except for the actual glowing part of the texture. Otherwise the entire texture will light up, rather than just the
glowing disc.

Fig. – dfsaf

The glowing is controlled by the brakes.ini data file (see p.).

This shader is required for the CSP brake disc FX, which is added in the ext_config.ini script. CSP just changes the shader to a better looking one with extra
features.

199
4. ksBrokenGlass
This is a shader for, obviously, broken glass on the windscreen/windows/headlights upon car impact/accident.

You need 2 objects on the same position, one for the glass itself (with its specular, fresnel, etc. shader parameters set) and another for the damage (of
course the damage meshes need their own separate material).

Assign to the damage meshes the AC common damage_glass.dds texture you find in SteamApps\common\assettocorsa\sdk\dev\car-pipeline-1.03\Common
Texture, along with more tex.

The meshes for the glass damage must follow the naming explained at chap.

In the object parameters in ksEditor set Is transparent = true and Cast shadow = false.

To adjust the behaviour of the glass when the car is taking damage you can tweak the damage.ini script as well. More about it in chap.

CURIOSITIES AND AMENITIES:

- Broken glass is so annoying, and in AC happens with slightest contact even door to door or rear end crash, and disturbs you the whole race.

Well, it’s only your fault if you drive badly! Maybe for a car with a vinyl/plexiglass windscreen you can avoid adding glass damage because it looks out of
place. Always aim at realism.

- I don’t like the default broken glass texture. Don’t worry! There are mods for this too! (Fig.)

Be aware that changing the common glass damage texture will change it for all cars in AC.

Fig. – Here you can see the vanilla glass damage on top. It is not really high resolution, but looks quite realistic. Obviously you can create your own texture. You can find this mod (by
@Xerox) here: https://www.racedepartment.com/downloads/hd-windshield-damage.10965.

200
Fig. – Another texture mod, this time by @JackCY. You can find it here: https://www.racedepartment.com/downloads/a-broken-glass.4783.

Fig. – My favourite, not too intrusive and quite realistic. Made by @RealAKP. You can find it here: https://www.racedepartment.com/downloads/new-damage-and-dirt-textures.13531.

201
5. ksCarPaintSimple

6. ksClouds

7. ksColourShader

8. ksFlags
Shader for track flags, that makes them wave back and forth in the wind (Fig.). It lets you specify the frequency and the intensity of the distortion. The boh
value is just a filler. There is nothing physical in the vanilla weaving. It’s purely visual.

Fig. -

The UV map is correct only if set properly from left to right. You assign the ksFlag shader, and the UV mapping must have the left edge of the flag attached
to the pole, along with the texture (Fig.). The left side of UV is still and as the texture coordinates go towards the right side, it moves.

Fig. – Here the frequency and distortion parameters are set to zero, you just set them to your liking. You can see the behaviour in the editor, one of its few dynamic things.

You might come to the conclusion on your own that using a texture with 16 nation flags from left to right is bad, because the rightmost flags get waved
excessively. If you want to put more things, the tex must be vertical (Fig.) and flags have to be single row from top to bottom, with the reverse side as well.

202
Fig. -

You can use this shader for cars too, for example if your vehicle has got national flags (Fig.).

Fig. –

CSP brings the ksFlagsfx shader, which responds to the wind speed as well as direction. That’s what is used to make trees move on tracks.

9. ksGrass
ksGrass doesn't use a mask texture.

Making grass surfaces using ksGrass is just not right. This shader is only meant to be assigned to 3D grass and foliage objects, not terrain, and CSP never
included a caveat for tracks that don't use it as such; low effort mod tracks often use ksGrass for terrain for some reason, which causes issues with the
retrofitting of CSP features: GrassFX does not work on ksGrass shader indeed.

With a track that uses ksGrass as the ground/terrain shader, GrassFX makes the ground go invisible.

You better apply another shader, like ksPerPixel to the grass surfaces, and then use correctly CSP configs. Keep things as simple as possible and avoid any
trouble.

203
10. ksMegaShader

11. ksMSDepthResolve

12. ksMultilayer

TEXTURES:

txDiffuse: main diffuse texture. Alpha channel works as specular map.

txDetailX: four detail textures. Their appearance is controlled through txMask.

txMask: RGB+Alpha image. R, G and B values control how much txDetailR, txDetailG and txDetailB show upon the main texture. Alpha brightness regulates
txDetailA: the more white it is, the more txDetailA will be visible.

SHADER VALUES:

multR, multG, multB, multA options scale the detail textures. They don't follow the mapping on the diffuse texture, they use a simple planar one.

multA is the only one that can be scaled separately on X and Y (or shall I say U and V).

204
magicMult: still can't sort this out. Zero makes the texture black, 1 makes it extremely bright.

13. ksMultilayer_fresnel_nm
Kunos used this shader in official tracks for the road tarmac mesh, featuring diffuse(&alpha), MASK(RGBA) Normal map(&ALPHA), all DXT5 DDS.

A multilayer diffuse, with fresnel lighting and a normal map. This is the ksMultilayer_fresnel_NM shader. The specular is contained within alphas of all
texture. The reason for this shader is as the view (camera) gets closer to the object more detail appears. So it blends between the information on the diffuse
and the detail. the downside of using this is zero reflection property. So it is mainly used for non-reflective objects.

Mask system. It places a new texture as camera gets closer. Nice blend into diffuse. Each channel RGB or A is drawn independently. There can be 4 detail
textures. In the ksEditor you can select all of the textures and any other detail textures.

The normal map follows the same size and automatic (LINEAR) UV arrangement the mask places it with. The scaling is configurable. All linear UV work
within the UV that the diffuse is using. So on a UV mapped road it will flow. On a massive tile of scenery it doesn’t need to fit the detail UV system. Very
configurable depending on the modelling layout chosen.

Detail textures are tileable within the UV map of the diffuse. A detail texture may span 1m square or whatever you want but within the UV mapped model. As
we get closer the tarmac grain and detail appears; as we get away from it in game it blends to the main diffuse.

Here are the settings from ksEditor.

Let's go through all those textures and how to set them up to produce what you see above.

1. txDiffuse

This texture should be 1024x4096. You want as long a texture as possible to limit the amount of times it repeats. Shown
below is the diffuse with the alpha channel next to it. Basically, the alpha channel here is your specular level. White is 100%
and black is 0%. What I simply do is make the alpha channel a copy of the diffuse and adjust the levels how I want them to be.
The format of the diffuse should be DXT5 and with about 4 mipmaps.

In general you only want to use one single diffuse for your entire road. You may ask "how do I get color variations and such?"
The answer is in the detail textures which I will get to that in a later post.

205
2. txMask

My mask is fairly small at 128x512. It does not need to be as large as the diffuse. Mine looks like this and is in DXT3 format with 4
mipmaps.

The red is where the main road detail image is shown and the purple is where the main red channel detail is mixed with the blue channel
crack texture. You can play with this bad boy all day long and even mix in the green channel if you want with another detail texture. I only
used the two channels. You shouldn't need to use the alpha channel with this so it should be 100% black if it is not used with a detail
texture.

3. txDetailR

The main detail image (in this example).

Fig. -

It should be 1024x1024 in DXT5 format with 4 mipmaps and it looks like this. The main texture is on the left and the alpha channel is on the right. This
alpha channel is also specular so here you want it fairly dark with only some pebbles light to light up by the sun.

4. txDetailG

The green channel.

If you are not using any of the color channels in the mask you can simply repeat the main detail image just to complete the form in the editor. In my case I
don't use green so it gets the main detail again.

5. txDetailB

The blue channel.

Used in this example for the cracks texture. It should be 512x512 and DXT3 with 4 mipmaps. Again the alpha channel is specular. You will have to fine tune
it so it matches the detail texture it blends with.

6. txDetailA

It is not used in our example, so it can be set to the main detail like the green channel.
206
7. txDetailNM

Normal map.

It should be 1024x1024. No alpha is used on this and it can be DXT1 with 4 mip maps. You adjust the normal map resolution with the two numbers in
"detailNMMult".

SIDE NOTE: Photoshop exports a full black alpha as full white somehow. Making the alpha #010101 fixes this. It doesn't matter if you use a black detail
texture, though. But it's worth mentioning for people who experience weird results inside the Editor.

So there it is, asphalt in all its glory. If you get this to look right, it's a huge step in bringing your track to "AC standards".

Mip maps get added automatically BUT it increases load times substantially.

14. ksMultilayer_objsp
ksMultilayer_objsp is the same as ksMultilayer, but in this the detail textures are not planar-mapped, they share the same UV from the diffuse. Also, all 4 are
adjustable in both dimensions.

15. ksOrenNayar

16. ksPerPixel
This shader is basically for plastic surface types, but it is one of the most used shaders in AC, being really versatile, so it’s not limited to that purpose.

17. ksPerPixelAlpha
It’s just a version of the ksPerPixel shader with the control of the level of transparency, that can be changed by the game engine.
Obviously if you don't want the engine to have control over the level of transparency, use ksPerPixel, it has less functions to be
calculated.

ksPerPixelAlpha includes an adjustable alpha-strength.

For Multiple transparent object-layers set "IsTransparent=True".

Disable casting shadows for skidmarks, dirt, etc.

ksPerPixelAlpha usage for track skidmarks (grooves):

1. Create a mesh on top of the road surface and map it with a semi-transparent dirt, rubber, tiremark texture
2. In the AC-Editor apply the following shader settings
shader: ksPerPixelAlpha
alphablended: true
castshadow: false

Play around with the alpha value and note the best min/max values for the given case.

3. Edit the grooves.ini:

[HEADER]
GROOVES_NUMBER=3 <--- number of individual objects

[GROOVE_0]
NAME=Rubber1 <--- name of the object
MIN=0.05
MAX=0.6
MULT=5

207
% ▲ The multiplier defines the change of saturation of the texture with every car crossing. Strangely higher values result in slower buildup of rubber.

Using ksPerPixelAT for skid marks causes some pixel artefacts and visible steps in gradients. ksPerPixelAlpha is the better choice, it's
smooth and gradients work fine. MULT=5 works for 5 laps (w/ 16cars) perfectly.

If you are using multiple groove layers, don't forget to set your object transparency (isTransparent=True).
More about track grooves in ()

18. ksPerPixelAT
This shader is commonly used for plastic fences. It’s the ksPerPixel shader with alpha test properties (AT=alpha test, for “transparent”
stuff), given the AlphaTest flag for ksEditor. It uses alpha as ON/OFF; there is no transparency: either a pixel is drawn or not. It can be
alpha blended (gradient instead of ON/OFF), but it's a waste of calculations.

19. ksPerPixelAT_NM

20. ksPerPixelAT_NS
It is basically the ksPerpixelAT shader without the rendering of the shadows (No Shadows) on it and a different filtering of the texture. It's an old shader, I
think no more used in any content.

21. ksPerPixelMultiMap
This shader is the basic car paint shader, but it’s really multi-purpose. It has standard diffuse, gloss, reflection, specular (specular always black and white, no
colour ever in AC). If you’re working with body paint, it’s preferrable to use ksPerPixelMultiMap_damage_dirt which includes all the features, with dust and
damage on the vehicles.

208
The NM texture slot is for model details and is always displayed.

22. ksPerPixelMultiMapSimpleRefl

23. ksPerPixelMultiMap_AT

24. ksPerPixelMultiMap_AT_emissive

25. ksPerPixelMultiMap_AT_NMDetail

26. ksPerPixelMultiMap_damage

27. ksPerPixelMultiMap_damage_dirt
209
The standard shader for body paint. The NM texture is for damage, not for model details, so it is displayed only when the vehicle takes damage. There are
also slots for dust/dirt on the car.

The damage shader is hardcoded in AC, and it only applies damage if the shader name is exactly ksPerPixelMultiMap_damage_dirt.

FAQ
QUESTION [1]: How do I get dirt to appear on glass? Only the ksPerPixelMultiMap_damage_dirt has the dirt feature, but it doesn't support alpha.
ANSWER [1]: You don’t.

28. ksPerPixelMultiMap_emissive

29. ksPerPixelMultiMap_NMDetail
Sandtrap shader which switches to different nm texture at close range although that might look really weird. It is used on sand traps so
one nm texture creates the sand dune effect while the other texture creates the sand nm effect at closer range.

30. ksPerPixelMultiMap_NMDetail_emissive

31. ksPerPixelNM
txDiffuse = main diffuse colormap

txNormal = normalmap

Notes: This shader is used for rocks and similar surfaces with a large amount of normalmap-details

32. ksPerPixelNM_UV2

33. ksPerPixelNM_UVMult

34. ksPerPixelReflection
Make sure your external glass is ksPerPixelReflection, internal ksWindscreen; make sure your faces aren't flipped to the inside on the ext_glass.

35. ksPerPixelSimpleRefl

36. ksPerPixel_dual_layer

37. ksPerPixel_nosdw

38. ksPostFOG_MS

39. ksShadowGen_debug

40. ksSimpleShader

41. ksSkinnedMesh

42. ksSkinnedMesh_NMDetail

43. ksSky

44. ksSkyBox

45. ksSkyCubemap

46. ksTest

47. ksTree

210
ksTree is like the ksPerPixel shader, the only difference is that materials don't receive environment object shadows. You can use ksPerPixelAT for trees (close to the
track/track cameras). It's recommended to use Y-tree meshes for correct lighting. X-trees have some lack of edgepoints.

It seems to have an "auto-normals function". Meaning that if you have the origin set somewhere on the trunk axis, it will automatically orient normals in a sphere-like manner
in order to achieve the best lightning; hence making the trees NOT look like cardboards.

Works like ksPerPixelAt_NS but with a better filtering (=?).

48. ksTyres
Which alpha layer should one use for tire rubber textures? What does the alpha actually do?

With ksTyres alpha is a specular map (white = more specular, black = less) so basically the glossy parts (sidewall outside of text) have high alpha, tread has
low alpha, grooves in the tread even lower.

If you use normal map it has more effect then what the specular does, but for things like the logos, the alpha layer works really well, and even more for the
grooves in tread, you get really nice dark lines. It's also good for adding texture, especially when a sharp normal map looks too puffy in reflection/specular
highlights if you try to add little rubber bumps (eg. a slick tire).

49. ksWindscreen
make sure your external glass is ksPerPixelReflection, internal ksWindscreen; make sure your faces aren't flipped to the inside on the ext_glass.

WIP

5.4.5 – CSP SHADERS DESCRIPTIONS

1. ksMultilayer_fresnel_nm4
Shader which is very similar to ksMultilayer_fresnel_nm, but with four separate normal map textures aligned with the detail maps (instead of one texture
mapped to the main UV), and masked with txMask. Has four separate options for fixed tiling, instead of using ksEmissive trick. Good for landscapes.

Tiling fix

Unlike the original multilayer shader, this one has proper options for tiling fix, separate for each channel: tilingFixR, tilingFixG, tilingFixB and tilingFixA. To
enable tiling fix, change according option from 0 to 1. Please keep in mind tiling fix requires an extra texture sample, do not use it for textures which are too
high res.

2. ksMultilayer_objsp_nm4

3. ksPerPixelAT_NM_emissive

4. ksPerPixelMultiMap_AT_emissive

5. ksPerPixelMultiMap_emissive
This shader is an exact copy of the vanilla ksPerPixelMultiMap, but with an extra txEmissive map used as multiplier for emissive color. You can use a black
and white mask in there, or add color. Original shader multiplies txDiffuse by ksEmissive (similar to “Multiply” blending in Photoshop), this one also adds
txEmissive multiplication step.

211
Few examples:

 White txDiffuse, red txEmissive, ksEmissive set to (1, 1, 1): red glow.
 Red txDiffuse, yellow txEmissive, ksEmissive set to (1, 1, 1): red glow.

Set emSkipDiffuseMap to 1 to stop txDiffuse from affecting emissive color.

Multi-channel mode

To enable multi-channel mode, set emChannelsMode option to 1. In that mode, shader will use red channel of txEmissive as a mask for ksEmissive, green
channel is mask for ksEmissive1, blue is for ksEmissive2 and alpha is for ksEmissive3. Later, in either car or track config, you can bind different emissive
variables to different events, allowing you to use a single mesh for, for example, braking, parking and reverse lights without splitting.

If you have a symmetrical mesh, you can use more than four channels: for example, if you set emMirrorChannel3As4 to 1, anything on one side of
symmetry plane would use ksEmissive4 instead of ksEmissive3. Use emMirrorDir and emMirrorOffset to setup symmetry plane (default value for mirror
direction would be 1 0 0, to mirror from left to right; also, keep in mind it uses local mesh coordinates). With this option, you can get all car’s rear lights
from a single mesh: use three normal channels for brake, parking and reverse lights, and third+fourth for turning lights (so map for turning lights would be
set in alpha channel of txEmissive).

6. ksPerPixelMultiMap_NMDetail_emissive
This shader is an exact copy of the vanilla ksPerPixelMultiMap_NMDetail, but with an extra txEmissive map used as multiplier for emissive color. For a more
detailed explanation, see the description of the ksPerPixelMultiMap_emissive shader above.

7. smCarpaint
smCarPaint is made to work with ksPerPixelMultimap or ksPerPixelMultimap_damage_dirt; anything else won't look quite right.

8. smSticker

9. stPerPixelMultiMap_specular

10. stPerPixelMultiMap_specular_damage_dirt

11. stPerPixelNM_UVflow

12. st_multimap

5.4.7 – SUMMING UP: WHICH SHADER TO USE

Materials:

Plastic

Aluminum

Steel

Chrome: ksPerPixelReflection

Rubber

Carbon fiber

Paint (flakes)

Glass

212
5.5 - EXPORT YOUR MODELS TO .kn5
I never drink coffee; I don’t like it. Personal preference. However you shall drink something now, as you’re almost ready to do bring your .fbx files into the
AC format. After all the settings you changed for your shaders (hoping you saved the persistence quite often) you should be ready for it.

It’s just a small part of the work when making a mod, but you will have to do it quite often while testing and editing your creations
(especially if you do a lot of trial and error), so you probably will get used to this operation, which consists of the following steps:

1. Open with ksEditor your .kscp project or your single .fbx file
2. Check if every shader/material has its respective textures assigned
3. Click on the File menu and in the cascade menu that opens go to Save KN5, then select Car.
4. In the File Explorer window that appears, open the FIN folder and give the name you chose to the file.
5. Done

213
CHAPTER 6 - VEHICLE DATA, CONFIGURATION FILES AND PHYSICS
At this point the AC graphic 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 are responsible for every behaviour, from physics to animated graphic elements; it’s important to understand that
each file has a very specific function here. However the subject will be treated as a whole, since all these configuration files influence the driving experience
(the so-called “feel”) of your vehicle in a different way.

At the moment the data examples of Par. 6.3.3 are vanilla AC only, even if there are a few explanations about CSP features here and there. 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 patch, especially with mods that require it to work, whether 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. 6.0).

Fig. 6.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).

CSP features can be added without altering vanilla data, via a config override in the extension folder of your mod. Then the advice is: first complete the
vanilla part of the physics/data and after “build on it” with CSP, in order to minimize the need of backtracking bugs.

6.1 - THE ASSETTO CORSA PHYSICS ENGINE (Wip)

We can divide the AC physics in two parts:

1. The physics solver

2. The physics formulas

Let’s explain both for a while.

6.1.1 – AC’S PHYSICS SOLVER

The physics solver of AC is based on ODE (Open Dynamics Engine), which is a free, industrial quality library for simulating articulated rigid body dynamics.
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 AC, BloodRayne 2, Call of Juarez, S.T.A.L.K.E.R., Titan
Quest, World of Goo, X-Moto and OpenSimulator.

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.

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

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 the most), 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.

6.1.2 -
6.1.3 - PHYSICS RATE
The AC physics rate is 333Hz (=3ms). That is the clock frequency (tick) of the physics engine. This is not the FFB frequency.

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 curious, you can calculate how much track length the physics skip between every tick with the following kinematic equation (units in square
brackets):

[ ]= [ / ]∙ [ ] [1.0]

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 you can use the formula below, then input the result into [1.0]:
[ / ]
[ / ]= [1.1]
,

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.

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

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.

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. Obviously in replays physics are not calculated.

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

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

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

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

What about CSP 64 bit physics? WIP

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

 See these tabs in Content Manager: Content > Cars > YOUR CAR > Unpack Data button. Look at Fig. 4.1;
 If you don’t see the Unpack Data button, you need to enable Developer mode in CM to activate this feature: click many times (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 unofficially encrypted with CSP. More about it at par.

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

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

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.

218
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 2 engines and
turbos.

ANSWER [2]: AC gives the priority to the data.acd file if present. Move or backup & delete it into another path, outside your FIN mod folder. 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.

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.

We can highlight some other issues you may encounter when swapping physics:

Floating or sinking wheels

The car has the wheels that sink in the asphalt or that aren’t touching ground (Fig. ).

219
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; 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 tx 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 very low. Vice versa the same will
happen but this time the POVs will be too high. There’s a ton of mods out there that suffer from this problem.

QUESTION [4]: What happens with online racing if I edit my vehicles? Will they still work? 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.

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

221
6.2 - 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, from referred to as data, interpret it correctly and
input it into the simulation as correct parameters in order to produce an intended input-in, output-out behaviour.

A simplified model of 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 is sufficient enough that accurate parameters are required and are able to produce reasonably accurate behaviours. In the case that accurate
parameters cannot be determined with complete certainty, 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.

Not every car is created equal when it comes to amount and fidelity of data present. Ideally one should make a car that they own themselves and have
access to and have acquired detailed data for from road testing and K&C (Kinematics and Compliance) testing, dynamometer testing and wind tunnel testing.

This is not always a reasonable expectation. If one is willing to accept somewhat lacking simulation accuracy, one can make a car that has less resources
available to aid in the process. Choosing to do will place a somewhat higher stress on having sound fundamental understanding and a good “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 in 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.

6.2.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. 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 one the highest quality third-party info you can find (Fig.).

Fig. – (left) Italian homologation form of the Fiat Abarth OTS 1000 Coupé. (right) German homologation form of the Audi 100 Coupé S.

Forums also occasionally have resourceful users post their own measurements or findings so don’t ignore them. Car magazines can be trusted to some
extent, but their reliability is limited.

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 (i.e., 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 behaves.
222
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.

Squeeze like a lemon every forum that has a search function. Take screenshots of conversations, they will come in handy. And if it takes too long or the
search blocks itself, like on the Discord social platform, download the entire website/chat. At that point it won’t escape from your hard drive. It’s 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. Good sites if you 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.

Also, don’t make the mistake of believing in too many generalizations. There are common design principles and good solutions especially for road cars, 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.

Much of the same applies to tires. While they all generally follow similar trends and logic, strange data anomalies can be present. Don’t be too afraid to
deviate from “acceptable” values, but be ready to make an argument for your case. “To me it feels like” is not a terribly convincing argument, but sometimes
it is embarrassingly close to the reasoning used for some tire parameters. One should refrain from making “opinion based” changes to suspensions of cars
especially when good data is present and tread with utmost care when seemingly going against data. 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.

6.2.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 a typical dyno sheet.

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. 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 are to be “grabbed”.

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

Fig. – A File Explorer window will open after you click on Choose file (2). Select the image you want to process. The 2D (X-Y) plot type (3) is the most common.

2. Locate four known points on the axes of the graph (Fig.). 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.

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

3. Enter the respective values of the pinpointed units on the plot (Fig.) so that the program can calculate every value.

Fig. – The values come straight from the graph. A rotation correction can be added if the lines are not perfectly straight, maybe if you have a scan from a printed document (like here).

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

225
Fig. – For a curve like this one, being pretty linear, you can increase ΔX and ΔY to reduce the number of points and you can remove some of them, especially in the portion between
2500-4000 RPM.

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. We don’t need too much precision.
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 ready to be used in AC
files! Yay!

Fig. – It wasn’t difficult, right? This specific LUT, being related to power, can be used to create the power.lut AC data file; you may be tempted keep it as-is, but you don’t know that the
values will have to be converted to torque, so what you see in this 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!

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

226
Fig. – This is neat, and as you can see WebPlotDigitizer can be very precise.

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

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.

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.

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

6.2.5 – MAIN PHYSICS CONCEPTS

Brief explanation of the main ideas to barely understand what’s going on.

227
6.3 - 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.

6.3.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, steer_brake_controller.ini) p.
8. cameras.ini p.
9. car.ini p.
10. colliders.ini p.
11. damage.ini p.
12. dash_cam.ini p.
13. digital_instruments.ini p.
14. digital_panels.ini p.
15. driver3d.ini p.
16. drivetrain.ini (also final.rto, ratios.rto, ctrl_single_lock.ini, ctrl_awd_center_lock.ini) p.
17. drs.ini p.
18. electronics.ini p.
19. engine.ini (also ctrl_turbo.ini (ctrl_turbo0.ini, ctr_turbo1.ini, etc.) p.
20. ers.ini (also ctrl_ers.ini, ctrl_ers_front.ini) p.
21. escmode.ini p.
22. extra_animations.ini p.
23. flame_presets.ini p.
24. flames.ini p.
25. fuel_cons.ini p.
26. lights.ini p.
27. lods.ini p.
28. mirrors.ini p.
29. proview_nodes.ini p.
30. setup.ini p.
31. sounds.ini p.
32. suspensions.ini p.
33. tyres.ini p.
34. wing_animations.ini p.

CSP files?

228
6.3.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 an are often used as fillers.

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.

DYNAMIC CONTROLLER INPUT LIST:

 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
…plus CSP added ones…

Some files include controllers inside, for example aero.ini has them for the wings. Standalone controllers instead are 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

229
6.3.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 (WIP)
The following code defines and all wing-type objects, including DRS. Wings determine the downforce 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.

% ▲ Wings define the downforce levels.

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 frontal 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

% ▲ AOA is Angle of Attack. It is the pitch angle of the wing relative to its direction of travel, 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 alpha is the more lift you will get out of a given wing
with two very important caveats. One, as AoA increases, drag increases, which means fuel efficiency goes down.
Two, 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.

LUT_GH_CL= ; Ground height (GH) aero lift multiplier lookup table

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

% ▲ 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.

% ▲ 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

LUT_GH_CD= ; Ground height (GH) aero drag multiplier lookup table
CD_GAIN=0.7 ; Coefficient of drag multiplier (for easy fine tuning). [dimensionless]

% ▲ Drag has the same dependencies of lift, as the medium, air, is the same. So the variable defined is called the drag coefficient, designated “CD”.

% ▲ 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). The values are coefficients, meaning they are the standard dimensionless constant that works at any speed. You might see "20lb
at 100mph" in a magazine but any detailed wing analysis uses CD.

% Determining the value of the drag coefficient 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.

% 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):

Drag/Lift Force = Coefficient of (respectively) drag/lift * Area of the wing * 0.5 * air density (ρ = rho) * Velocity^2

% The same equations in the physics literature are written like this:

F (lift)= CL * A * 1/2 * ρ(rho) * v^2

F (drag)= CD * A * 1/2 * ρ(rho) * v^2

% Or like this:
∙ ∙ ∙
= (1.0)

∙ ∙ ∙
= (1.1)

% 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)
,
% If you have the speed in miles/h, you can convert it in m/s with this other little formula:

[ / ]∙ ,
[ / ]= = [ /ℎ] ∙ 0,44704 (1.3)
,

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 (#)

230
% ▲ 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

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 setup. The actual angle is relative to the design heights of the suspension and the velocity the surface is
travelling at vs the 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)
YAW_CL_GAIN=-0.0

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

[WING_1]
NAME=SCREEN
CHORD=0.02
SPAN=0.30
POSITION=0,0.624,-0.528
LUT_AOA_CL=empty.lut ; set to empty.lut, gives no lift generated from this wing
LUT_GH_CL=
CL_GAIN=0.0
LUT_AOA_CD=empty.lut ; set to empty.lut, gives no drag generated from this wing
LUT_GH_CD=
CD_GAIN=0.0
ANGLE=0
YAW_CL_GAIN=0.00
ZONE_FRONT_CL=0.001
ZONE_FRONT_CD=0.001
ZONE_REAR_CL=0
ZONE_REAR_CD=0.00
ZONE_LEFT_CL=0
ZONE_LEFT_CD=0.0
ZONE_RIGHT_CL=0
ZONE_RIGHT_CD=0.0

[FIN_0] ; vanilla physics have a "fin" wing type that gives sideways lift with yaw (equivalent of angle of attack);

% ▲ Front and rear fins can yaw at different angles. 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.

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
ANGLE=0 ; the angle of attack is yaw angle (taking into account wind)
ZONE_FRONT_CL=0 ; CD always comes from where the car is headed, while CL is purely lateral
ZONE_FRONT_CD=0
ZONE_REAR_CL=0
ZONE_REAR_CD=0
ZONE_LEFT_CL=0
ZONE_LEFT_CD=0
ZONE_RIGHT_CL=0
ZONE_RIGHT_CD=0
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

% ▼ ADDITIONAL CSP PARAMETERS

These parameters can be added if you use Custom Shaders Patch and can give more controls over the aerodynamics of your car.

New HEADLIGHTS input for aero controller:

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

LITTLE EXPLANATION

- The intended usage of wings is BODY for overall body drag, and FRONT/REAR for separated front/rear lift (centered 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

231
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 apply, relative to the CoG of the car. Examples of correct wing placement are in
Fig.. However, the forces aren’t actually perpendicular to what the respective wings look like (Fig.). In Assetto Corsa the lift force is always applied directly
downwards relative to the car and drag directly against the direction of travel. The angle of the wing basically influences the resultant of the vector sums of
the lift and drag forces.

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.

- 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

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

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

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:
- For aero look-up-tables, the input is either Angle of Attack AOA or ground height GH (distance from the middle of the wing to the ground), 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

MAP_YAW_CL = filename.lut ;degrees|multiplier

MAP_YAW_CD = filename.lut ;degrees|multiplier

Some examples of names you can use:

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

233
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

reference empty.lut it in all the empty aero.ini areas

CSP ADDITIONS

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.

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

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

QUESTION 4: Where should I look for the downforce levels of cars?

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

QUESTION 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?
ANSWER 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
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.

235
PHYSICS (for aero.ini)
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.

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

Fig. – Smoke tests for various vehicles, in order from top left to bottom right: wooden 1:5 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

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

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

237
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

+ = (1.4)

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

= (1.5)
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:

= (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.

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

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

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

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.

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

241
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 figure 7. 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.
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

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

wip

We know that 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.

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.

243
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 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. –

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.

wip

244
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:
- 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.

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

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

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.

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

-It is a fact that in many situations the AI fails to account of the "space shrink" when speed decrease (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 impossible to analyse... the accounts of 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.

-The problem with AIs is that they don’t use the exact same physics, so the speed an AI can leave a corner is not identical to the player’s. Very often you
can't run the same line as them since they're using 120% as much horsepower/grip (to compensate the jankyness of their trajectory) and you win because
their route is not very optimal.

-Oh, and the aggression slider is there to let them 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 ai drift?".

Of course the answer is NO (STILL, UNLESS…???), but there are ways that I've seen, by manipulating ai.ini and tyres.ini files to get slip and counter-steer.
Only info I have is that one user edited the tyres.ini 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.
Besides AI SPline editing, there aren't settings to make this happen, unless you change the values to force it to happen with trial and error.

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

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

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

% ▼ For all the other headers below can and must be used the same lines of the [RPM_INDICATOR] section (even though probably you don’t need them all).
The common ones will be skipped. Eventual additional or differently-functioning lines will be present and explained.

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

[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

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

- The telltale tachometer is a tachometer that has a second (usually red) arrow that shows the highest amount of revs reached (Fig.).

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.

ABOUT RELATED FILES

LUTs:

247
analog_speed_curve.lut
This is a separate look-up-table table for the speedometer, but it is rarely used. You just input the filename in the LUT field of the [SPEED_INDICATOR]
section. The file itself looks like this:
0|0
100|45
200|90

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

6. blurred_objects.ini

The visuals of wheels spinning at high rotational regimes 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 speed an object will appear or disappear.
You can use more than one rim_blur per wheel, so you’ll have smoother transitions, for example with 2 or 3 meshes/objects. There’s a lot of space for implementations.
You can even enter things completely different from rims, in order to make them appear/disappear whenever you like. This is what I call moddability!
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.

[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

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.

248
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, for example using blur object too, you
would need to paint both the RIM and the blur or make a new blur texture which implies mapping the rim. AC rim blur also keeps working 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 smaller 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. After all, if a user doesn’t like it, he can always disable it, changing the values in blurred_objects.ini. Players are not photographers.
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 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.
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? Make 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. And the first theory is just an excuse for lazy people.

249
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 has no
RIM_BLUR models (note that the speed is 105 kmh).

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.

CSP ADDITIONAL:

Custom Shaders Patch adds a new thermal model for brakes, which requires more configuration and supplementary lines of code in brakes.ini.

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

250
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)

[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

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.

251
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

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.

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

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.

253
9. car.ini

This is a crucial file for the vehicle’s data, because it regulates basic parameters for visuals, physics and interface. You can also change the position of the
main vehicle cameras (the ones activated with the F1 or user-assigned key), under [GRAPHICS].
[HEADER]
VERSION=2 ; SYNTAX: [VERSION=1; 2; extended-1; extended-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.
With CSP, extended-1 or extended-2 may also be used 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.

[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 ; Alternative name used for in-session naming of the car. Use with VERSION=2

[BASIC]
GRAPHICS_OFFSET=0,-0.370,-0.208646 ; 3d axis correction (x,y,z); values move the VISUAL sprung mass of the car, the body, 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. Width,
height, length will be the standard format used by Assetto Corsa dimensions.

GRAPHICS_PITCH_ROTATION=0.0 ; Changes 3D object (vehicle body) rotation in pitch. [deg]

TOTALMASS=1075 ; Sum of the sprung and unsprung masses (total vehicle weight) + driver, but WITHOUT FUEL. Other types
of fluids should 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 ; Car polar moment of inertia (x,y,z), calculated from the car dimensions. [m]

% ▲ Generally inertia is used to modify the car's behaviour in turns depending of engine's position.
The SPRUNG inertia of the car is determined in the form of a dimension box that has mass specified by TOTALMASS. Unsprung masses generate their own
inertia separately. You must NOT input in the car dimensions.

% ▲ Usually low-quality drift car mods tweak this parameter 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.
Drift car mod packs are not realistic at all on average, in terms of AC physics. 5-6 meters of inertia box are pretty common on these mods.

% Mid- and rear-engine cars should have the third value smaller than the car's length but nothing other than going "by feel" was recommended and nothing
other than the remark in some of the Kunos' car.ini files is provided. A solver to solve for sprung inertia from total car inertia has been developed and
may be shared in the future. 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). [meters]
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. [degrees]
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). Maybe not working
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.010000,-0.239999,0.910001 ; Bumper camera position. [meters]

BUMPER_CAMERA_PITCH=-2.999850 ; Bumper camera pitch angle. [degrees]
BONNET_CAMERA_PITCH=-14.999748 ; Bonnet camera pitch angle. [degrees]
BONNET_CAMERA_POS=0.000000,0.940000,-0.330000 ; Bonnet camera position. [meters]
CHASE_CAMERA_PITCH=0 ; Chase camera pitch angle. [degrees]

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

% ▲ 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.

% ▲ Steering ratio is the ratio of the number of degrees turned at the steering wheel vs. the number of degrees the front wheels are deflected. So for
example, if the steering wheel is turned 20° and the front wheels only turn 1°, that gives a steering ratio of 20:1. For most modern cars, the steering
ratio 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).
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:
; Enter AC in dev app mode enabled
; Open SUSPENSIONS app
; turn your steering wheel by 90 degrees
; check the actual steer ratio value
; modify the LINEAR_STEER_ROD_RATIO value until in-game steer ratio and car.ini STEER_RATIO values are similar.

% ▲ 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.

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

% ▲ If you know how many litres does your vehicle consume per second, you can use the following formula to obtain a rough CONSUMPTION value:

254
CONSUMPTION = (1000*Fcon)/rpm*gas
Where Fcon is how many litres per second the car burns, rpm is the rotational regime of the engine and gas is the throttle input.

The same formula can be written like this:

1000 ∙
=
∙
If you don’t have data, you can estimate the fuel consumption. Good sources are the race leaderboards. Read the FAQ for more info.

FUEL=50 ; Default starting fuel amount which the car loads in game with. [litres]
MAX_FUEL=100 ; Maximum fuel capacity [litres]

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

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

% ▲ These lines act as reference point for the ride height value shown inside the setup screens. They are also used by 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]
MIN_HEIGHT=0.010 ; Minimum front/rear allowed setup ride height as determined by the lines under [RIDE]. [meters]

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

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

[PIT_STOP]
TYRE_CHANGE_TIME_SEC=2 ; time spent to change each tyre wip
FUEL_LITER_TIME_SEC=0.05 ; time spent to put 1 litre of fuel inside the car
BODY_REPAIR_TIME_SEC=1 ; time spent to repair 10% of body damage
ENGINE_REPAIR_TIME_SEC=1 ; time spent to repair 10% of engine damage
SUSP_REPAIR_TIME_SEC=1 ; time spent to repair 10% of suspension damage

LITTLE EXPLANATION

- car.ini shall be the first config you work on. It’s one of the fundamental ones, 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.

- How is inertia portrayed by AC?

The car inertia is not measured by taking the weight and position of every single car part, it is measured building a solid box based on the car dimensions.
When we're pairing the INERTIA with the TOTALMASS, 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. -

Cars with the engine further away from the center of the overall mass will have a bigger inertia box, due to higher moment of inertia.
There is no problem as far as we want to drive a solid 1-ton brick around. But how can we describe the inertia of a car and not the physical behaviour of a
brick?
The calculations inside AC are made in a way that if you put the rough dimensions of the car in the INERTIA line, you get pretty good behaviour. If you're
more advanced, you can have other options:

1. Measure the vehicle inertia on a rig or find such detailed data. If you manage to, use the [EXPLICIT_INERTIA] section, recommended for use with real life data.

255
2. Calculate all the inertias with whatever program (i.e. CAD software) or method you want to use. Get the values and input them into the [EXPLICIT_INERTIA] section.
You could also create a box with the same inertias and insert its dimensions in the INERTIA line, but it’s less accurate.
3. Roughly (not directly) insert the dimensions of the car in the INERTIA values. This is an estimate. 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.

Inertia is something you either have data for or you don't. If you don't it's fine to continue using the “box" system with the INERTIA line (it's usually fairly
close anyway...it is the default because inertia measurements are rather rare).

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

Fig. – Case closed. Actually no, because the Tech Preview DID HAVE sparks.

I read it was also about car-to-car contact that they left them out, because it wouldn’t look right. But with vfx in the trailer it’s cheating! Kunoooooooos...

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.

QUESTION [2]: How can I estimate the vehicle’s fuel consumption in a crazy way? I’m desperate.
ANSWER [2]: 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 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.

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

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 to be considered a percentage of throttle input, where
1=100%, so 0,8=80%.
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?

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.

Centre of gravity (CoG)

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.
(wip)

Vehicle CoG and handling properties

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

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.

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

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

(wip)

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

259
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. Figure 6.6 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).

260
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 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. It is advisable to use just one that goes the front
tyres to the rear tyres, but to be honest, there are no specific rules about where you have to place them, so the limit is just your creativity. The cost is always
the computational performance.
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.
The reference point of the values below is the car’s CoG (center of gravity).
[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]
CENTRE=0 ,-0.18 ,-0.48
SIZE=1.4 ,0.15 ,0.3
GROUND_ENABLE=1

LITTLE EXPLANATION

- In Fig. we have some examples of collider models in the official content.

Fig. 4.7 – The Ferrari 312T by Kunos has three colliders (the red boxes) in addition to the collider.kn5 (the rainbow-coloured mesh).

Fig. 4.8 – The Ferrari F138 by Kunos has 6 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 the halo’s collider may be added.

261
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%)

You can make things like the exhaust (or 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

CURIOSITIES AND AMENITIES

- Why a good simulator with a physically based damage model doesn’t exist out there?

The problem is not the manufacturers not wanting 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). But then ask Kazunori Yamauchi.

The real trouble is the amount of calculations required to make a good damage model. You don't want to simulate sponges like in BeamNg, which reminds
me a lot of Algodoo, a simpler 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

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

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

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.

263
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.
[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.

[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

264
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

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.

265
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 steering lock. Changing it can only break the driver visuals.

% ▲ 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

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

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

267
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. Input example: 4.363

[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

268
USE_ON_CHANGES=0 ; Use the autoclutch on gear shifts even when autoclutch is set to off. Values: 1, 0.

% ▲ 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.
269
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.
[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

ctrl_awd_center_lock.ini
This file controls the centre differential preload torque, in [Nm].
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.

eg: setup 50 = drivetrain 0.5

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

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.

270
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

[DEACTIVATION]
LIMIT_G=0.5

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

271
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: 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.

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

272
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=power.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.

% ▲ Non implemented function in vanilla AC, won't affect turbos/engine as it should. Altitude effects have been implemented for a while for cars using
extended physics (CSP). For example cphys cars have altitude sensitive aero. When you enable extended physics the patch will take into account air
density according to altitude. It is not used for cars without extended physics since it’d cause online compatibility issues.

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]
DEFAULT_TURBO_ADJUSTMENT=0.8 ; Default turbo amount when using adjustable turbos. Example: 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.
% 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]
FILENAME=coast.lut ; Defines the LUT loaded for the coasting torque curve.

% ▲ Input may be invalid without an existing file. Commonly coast.lut is used. Unsure if functional. Needed to load engine.ini.

[TURBO_0] ; SYNTAX: [TURBO_ID]. Turbo identifier. A car can have as many turbos as necessary. ID starting from zero.

% ▼ 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.

% ▼ 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.

LAG_UP=0.995 ; Amount of filtering interpolation lag used while spinning up the turbo

% ▼ 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).

LAG_DN=0.99 ; Amount of filtering interpolation lag for the turbo when spooling down the turbine.

% ▲ 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.

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.
% ▲ Refer to “car physics” app to troubleshoot in-game boost pressure.
% Formula: T*(1.0 + boost). When pressure is 1.0, torque is 2.0.
Example: 100*(1.0 + 1.0) = 200.

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.

% The gamma 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.

COCKPIT_ADJUSTABLE=0 ; If the turbo boost is adjustable in-cockpit with number digits on keyboard; 0= off and 1= on.

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

% ▲ This 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. 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.

RPM_DAMAGE_K=1 ; Amount of damage per second when over RPM_TRESHOLD. Depends on (rpm-threshold).

273
LITTLE EXPLANATION
- Assetto Corsa isn't 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 defines with X-Y coordinates the torque curve of our car. Units in power.lut are revolutions per minute [RPM] and torque in [Nm] at the
wheels after drivetrain loss. power.lut is unfortunately misnamed in the official vehicles, it should have been named torque.lut, but this is what we’ve got. Try
avoiding misunderstandings.

It is worth noting that the file for power/torque isn't actually always called "power.lut", as its filename is defined within engine.ini (under POWER_CURVE).

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 kg*m (kilogram * meter); 1 kg*m is equal to 9,81 N*m.

The engine power you can see with the red colour in Fig. below (from Content Manager, which uses Nm and BHP as units instead of Nm and kW, so the
curve won't necessarily match dyno graphs) is calculated FROM the torque curve at the wheels.

Fig. -

- 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 [HP] (Y axis) depending on the engine speed in [RPM] (X axis). This is
important: always pay attention to the units!

274
Fig. – These are actually three curves because each is for a different engine. Let’s focus on one curve only.

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:
= (1.8)
∙

Now, it is important to input our data with the correct units, so here is the final torque equation we’re going to use:

∙ [ ] ∙ [ ]
[ ]= = (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 fraction has just moved to the numerator of the formula, thanks to math’s power.

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 is the one AC uses, so we won’t change (1.9), we’ll convert instead any type of HP, imperial (mechanical) and 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)

At this point, as you may be wondering, you’ll encounter many types of power graphs, so to understand them we need to distinguish power at the wheels
from engine power, which are similar concepts but often misunderstood.

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 axle or the wheels. This is the power the whole vehicle delivers when
we drive.

275
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 have to put it in a simple formula it would be something like
this:

P engine (bhp) = P wheels (hp) + Losses

(frictional losses between bearings and gears)

After the engines have been selected for a vehicle, they are tested to check how
much power it is delivering. The power delivered by ONLY engine is calculated by
a device called as dynamometer. In the setup, brakes are applied to the crankshaft
end to measure the torque at a
certain RPM; look at Fig. for example.
While performing the test, torque and RPM are 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.

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 keep in mind when you search for an engine/vehicle power/torque graphs. As long as you want your car mod to be
realistic.

Fig. – How HP is measured (on the left) vs how BHP is measured (on the right).

If you have the power curve (HP) of your vehicle, you can to convert it directly to torque using in order (2.0) or (2.1) and (1.9), then input the values in
power.lut, while if you have the BHP curve of the engine, you’ll need to convert power to torque like before, but then you have to multiply it by the various
ratios of the transmission and calculate the loss due to mechanical friction to obtain the torque at the wheels; here’s how you can do it:

Wheel torque can be calculated function of engine torque if the parameters and status of the transmission are known:

This method can be applied to any powertrain architecture (front-wheel drive or rear-wheel drive) but, for an easier understanding of the components, we
are going to use a rear-wheel drive (RWD) powertrain.

First of all we’re going to assume that there is no slip in the clutch or torque converter, the engine being mechanically linked to the wheels.

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.

276
 ∙ (2.3)
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.
= ∙ (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.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)

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

formula will have the general form of:

= (2.7)

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.

Now you need to calculate the loss due to friction; it depends on the efficiency of the powertrain, and unless you have very specific data, you can only
estimate it.

To convert actual engine power to wheel power, subtract 10-15% for road cars, 15-19% for race cars (yes racing drivetrains are less efficient but more
robust), and as much as 20-22% for vintage cars. But be wary on manufacturer estimates for the cars, as they can be lower/higher than in reality.

- Until now, we worked with imperial measure units ([hp] and [bhp]), but if you have dyno graphs with SI units, the distinction between engines and wheels
may be difficult, as you will work directly with watts [W] as power measure unit, both at the crankshaft and at the wheels (Fig.).

Fig. – As you can see, this engine power graph (it is written on it) has got 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.

Different torque for different gear. WIP

- What’s the relationship between throttle percentage (%) and output torque at any given rpm? In AC, it is calculated by default with a linear interpolation;
however, you can change the shape of the curve with throttle.lut.

277
- 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 damping of the cars
when stopped.

- Adding turbos:
The only way to have a correct turbo power curve, is to start with a turbo engine dynamometer sheet, and match that run in power.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” 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
power.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.

- 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 power.lut, as Kunos did for example with the Lotus
Elise SC. If you have a supercharged vehicle dyno sheet just type the values into power.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,
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.

ABOUT RELATED FILES

Controllers:

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

278
ctrl_wastegate0.ini

LUTs:
power.lut
This is the engine torque curve. The numbers on left are RPM, those ones on right are torque in [Nm] at the wheels, including any drivetrain losses.
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
7000|79
7500|49
8000|20
8500|0

throttle.lut
This is the throttle response curve. It is the only LUT that doesn't need a reference in the config files.
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

CSP ADDITIONS
CSP maybe?
[THROTTLE_RESPONSE]
“RPM_REFERENCE” controls RPM where “LUT” curve is in effect.

“LUT” controls LUT curve used by 2D throttle map. Linear interpolation between throttle.lut and LUT is done until RPM_REFERENCE. Refer to log for table.
Example: throttle2.lut.
LUT example:
0|0
50|50
100|100

NOTE: throttle.lut controls first throttle curve and is required. Throttle.lut may also be used alone without [THROTTLE_RESPONSE] section. Input is %|%
in full values.
LUT example:
0|0
50|75
100|100

FAQ
Q1. There is no modification of horsepower in Engine.ini, only Power.lut, I don't know how to modify it.

(WIP)

20. ers.ini

Hgk
[HEADER]
VERSION=1

[KINETIC]
CHARGE_K=0.00014 ; Charge as function of brake torque (include engine) and rotation speed
TORQUE_CURVE=kers_torque.lut ; Torque curve Nm/RPM
COAST_CURVE=kers_torque_coast.lut ; Coast Torque curve Nm/RPM
DISCHARGE_TIME=87000 ; Time in ms to discharge the kers when used to deliver torque
HAS_BUTTON_OVERRIDE=1
MAX_KJ_PER_LAP=10000000 ; KJ
DEFAULT_CONTROLLER=0
BRAKE_REAR_CORRECTION=1 ; Torque removed from rear axle as function of kinetic recovery

[HEAT]
CHARGE_K=0.002 ; Charge as function of turbo boost %
TORQUE_PERC=10 ; % of torque the Heat is able to generate from the kinetic motor

[COCKPIT_CONTROLS]
RECOVERY=0
DELIVERY_PROFILE=1
MGU_H_MODE=0

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

At the end of every vanilla AC session this camera enables automatically, whether you’re still on the track or you’re in pits. If you press F7 you can enable
the free camera, thus deactivating it temporarily, but doing this is not very useful to look around since the view is covered by the AC end race GUI (Fig.).

Fig. – The camera in the vanilla session end screen is managed by escmode.ini.

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.

280
Fig. –

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 of the flame (Red, Green, Blue) + emissive 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

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

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 (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

282
[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):

 f2.dds
 f3.dds
 f4.dds
 f#.dds (additional numbers)

TAIL (hence the l prefix; that’s an L):

 l3.dds
 l4.dds
 l6.dds
 l#.dds (additional numbers)

MAIN (every prefix except f and l):

 x0.dds
 x1.dds
 x5.dds
 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]

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.

QUESTION [2]: Is there an easy way to adjust the flames positions after adding them to the script? I copied them from another car.
ANSWER [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 configuration 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.

283
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

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

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

CSP – CUSTOM SHADERS PATCH

New flames brought by CSP ignore vanilla params.

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

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.

286
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 a 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.

287
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)

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

288
29. proview_nodes.ini

This .ini is for AC 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.

289
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 0 when you want 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. The colours refer to the NULLs of Chapter 2.
[NODES]
WHEEL_LF=0
____RIM_BLUR_LF=0
________polymsh_detached131=0
____RIM_LF=0
________Cerchione_Anteriore=0
____TYRE_LF=0
________g_Tyre_RF001=0
WHEEL_RF=0
____RIM_BLUR_RF=0
________polymsh_detached133=0
____RIM_RF=0
________Cerchione_Anteriore1=0
____TYRE_RF=0
________g_Tyre_RF4=0
WHEEL_LR=0
____RIM_BLUR_LR=0
________polymsh_detached132=0
____RIM_LR=0
________polymsh_detached129=0
____TYRE_LR=0
________g_Tyre_RF2=0
WHEEL_RR=0
____RIM_BLUR_RR=0
________polymsh_detached134=0
____RIM_RR=0
________polymsh_detached130=0
____TYRE_RR=0
________g_Tyre_RF3=0
SUSP_LF=0
____GEO_HUB1=0
SUSP_RF=0
____GEO_HUB=0
SUSP_LR=0
____GEO_HUB2=0
SUSP_RR=0
____GEO_HUB3=0
DISC_LF=0
____GEO_DISC_LF=0
DISC_RF=0
____GEO_DISC_RF=0
DISC_LR=0
____GEO_DISC_LR=0
DISC_RR=0
____GEO_DISC_RR=0
COCKPIT_HR=0
____STEER_HR=0
________GEO_STEER=0
____________LED_0=0
____________LED_1=0
____________LED_2=0
____________LED_3=0
____________LED_4=0
____________LED_5=0
____________LED_6=0
____________LED_7=0
____CINTURE_ON=0
____CINTURE_OFF=0
____DOOR_R1=0
________GEO_Door_R1=0
____DOOR_L1=0
________GEO_Door_L1=0
____GEO_Vetro_interno=0
____SHIFT=0
________SHIFT2=0
____________polymsh_detached1=0
________polymsh_detached135=0
____SHIFT1=0
________polymsh_detached5=0
____SHIFT3=0
________SHIFT4=0
____________polymsh_detached4=0
________polymsh_detached2=0
____DISPLAY_DATA=0
____LED_LIGHTS=0
____LED_RPM_0=0
____LED_RPM_1=0
____LED_RPM_2=0
____LED_RPM_3=0
____LED_RPM_4=0
____LED_RPM_5=0
____LED_RPM_6=0
____LED_RPM_7=0
____LED_RPM_8=0
____LED_RPM_9=0
____LED_FUEL=0
____GEO_cockpit_HR=0
________Extra_Mirror=0

290
COCKPIT_LR=0
____STEER_LR=0
________GEO_Steer_LR=0
____GEO_cockpit_LR=0
DOOR_R=0
____GEO_Door_R=0
____DAMAGE_GLASS_RIGHT_2=0
________polymsh_extracted13=0
DOOR_L=0
____GEO_Door_L=0
____DAMAGE_GLASS_LEFT_2=0
________polymsh_extracted14=0
WIPER=0
____polymsh9=0
____WIPER1=0
________polymsh_detached=0
DAMAGE_GLASS_RIGHT_1=0
____polymsh_detached120=0
DAMAGE_GLASS_CENTER_2=0
____polymsh_detached119=0
DAMAGE_GLASS_REAR_1=0
____polymsh_extracted9=0
DAMAGE_GLASS_LEFT_1=0
____polymsh_detached121=0
DAMAGE_GLASS_CENTER_1=0
____polymsh_extracted11=0
DAMAGE_GLASS_FRONT_1=0
____polymsh_extracted12=0
WING=0
____GEO_RearWing=0
GEO_BODY_Trasp=0
FRONT_LIGHTS=0
____FRONT_LIGHT_2=0
____FRONT_LIGHT_1=0
____FRONT_LIGHT_3=0
REAR_LIGHTS=0
____REAR_LIGHT_REAR=0
____REAR_LIGHT_BRAKE=0
____REAR_LIGHT_BRAKE_CENTRAL=0
FRONT_BUMPER=0
____GEO_FRONTBUMPER=0
REAR_BUMPER=0
____GEO_REARBUMPER=0
____LIGHT_RAIN=0
MOTORHOOD=0
____GEO_Motorhood=0
EXHAUST1=0
EXHAUST2=0
Mtore=0
GEO_Body=0
FLYCAM_L_0=0
FLYCAM_L_1=0
FLYCAM_L_2=0
FLYCAM_L_3=0
FLYCAM_L_4=0
FLYCAM_L_5=0
FLYCAM_R_0=0
FLYCAM_R_1=0
FLYCAM_R_2=0
FLYCAM_R_3=0
FLYCAM_R_4=0

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.

291
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
POS_X=0.5
POS_Y=5
HELP=HELP_HF_WHEELRATE

[SPRING_RATE_LF]
NAME=Wheel rate LF
POS_X=0
POS_Y=1
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
POS_X=1
POS_Y=1
HELP=HELP_RF_WHEELRATE

[SPRING_RATE_LR]
NAME=Wheel rate LR
POS_X=0
POS_Y=7
HELP=HELP_LR_WHEELRATE

[SPRING_RATE_RR]
NAME=Wheel rate RR
POS_X=1
POS_Y=7
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

292
POS_X=1
POS_Y=2
HELP=HELP_RF_RODLENGTH

[ROD_LENGTH_LR]
NAME=Height LR
POS_X=0
POS_Y=6
HELP=HELP_LR_RODLENGTH

[ROD_LENGTH_RR]
NAME=Height RR
POS_X=1
POS_Y=6
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]
POS_X=1
POS_Y=0
HELP=HELP_RF_BUMP_STOP_RATE

[BUMP_STOP_RATE_LR]
POS_X=0
POS_Y=8
HELP=HELP_LR_BUMP_STOP_RATE

[BUMP_STOP_RATE_RR]
POS_X=1
POS_Y=8
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]
POS_X=1
POS_Y=1
HELP=HELP_RF_TRAVEL_RANGE

[PACKER_RANGE_LR]
POS_X=0
POS_Y=7
HELP=HELP_LR_TRAVEL_RANGE

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

[CAMBER_RF]
NAME=CAMBER_RF
POS_X=1
POS_Y=0
HELP=HELP_RF_CAMBER

[CAMBER_LR]

293
NAME=CAMBER_LR
POS_X=0
POS_Y=8
HELP=HELP_LR_CAMBER

[CAMBER_RR]
NAME=CAMBER_RR
POS_X=1
POS_Y=8
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
POS_X=1
POS_Y=1
HELP=HELP_RF_TOE

[TOE_OUT_LR]
NAME=Toe LR
POS_X=0
POS_Y=7
HELP=HELP_LR_TOE

[TOE_OUT_RR]
NAME=Toe RR
POS_X=1
POS_Y=7
HELP=HELP_RR_TOE

/////////////////////////////////////////////////////
;DAMPERS LF
/////////////////////////////////////////////////////

[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

[DAMP_FAST_BUMP_LF]
SHOW_CLICKS=2
TAB=DAMPERS
NAME=FST Bump
MIN=500
MAX=3380
STEP=120
POS_X=0
POS_Y=1
HELP=HELP_LF_DAMPER_FBUMP

[DAMP_REBOUND_LF]
SHOW_CLICKS=2
TAB=DAMPERS
NAME=Rebound
MIN=1000
MAX=5560
STEP=190
POS_X=0
POS_Y=2
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LF]
SHOW_CLICKS=2
TAB=DAMPERS
NAME=FST Rebound
MIN=500
MAX=3380
STEP=120
POS_X=0
POS_Y=3
HELP=HELP_LF_DAMPER_FREBOUND

% ▼ 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
/////////////////////////////////////////////////////

[DAMP_BUMP_RF]
POS_X=1
POS_Y=0
HELP=HELP_RF_DAMPER_BUMP

[DAMP_FAST_BUMP_RF]
POS_X=1
POS_Y=1
HELP=HELP_RF_DAMPER_FBUMP

[DAMP_REBOUND_RF]
POS_X=1
POS_Y=2
HELP=HELP_RF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RF]
POS_X=1
POS_Y=3
HELP=HELP_RF_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS LR

294
/////////////////////////////////////////////////////

[DAMP_BUMP_LR]
POS_X=0
POS_Y=5
HELP=HELP_LR_DAMPER_BUMP

[DAMP_FAST_BUMP_LR]
POS_X=0
POS_Y=6
HELP=HELP_LR_DAMPER_FBUMP

[DAMP_REBOUND_LR]
POS_X=0
POS_Y=7
HELP=HELP_LR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LR]
POS_X=0
POS_Y=8
HELP=HELP_LR_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS RR
/////////////////////////////////////////////////////

[DAMP_BUMP_RR]
POS_X=1
POS_Y=5
HELP=HELP_RR_DAMPER_BUMP

[DAMP_FAST_BUMP_RR]
POS_X=1
POS_Y=6
HELP=HELP_RR_DAMPER_FBUMP

[DAMP_REBOUND_RR]
POS_X=1
POS_Y=7
HELP=HELP_RR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RR]
POS_X=1
POS_Y=8
HELP=HELP_RR_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS HF ; KEEP IN MIND THAT THESE ARE DIFFERENT FROM THE DAMPERS ABOVE
/////////////////////////////////////////////////////

[DAMP_BUMP_HF]
SHOW_CLICKS=2
TAB=HEAVE DAMPERS
NAME=Bump
MIN=2000
MAX=6560
STEP=190
POS_X=0.5
POS_Y=0
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HF]
SHOW_CLICKS=2
TAB=HEAVE DAMPERS
NAME=FST Bump
MIN=500
MAX=3380
STEP=120
POS_X=0.5
POS_Y=1
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HF]
SHOW_CLICKS=2
TAB=HEAVE DAMPERS
NAME=Rebound
MIN=2000
MAX=6560
STEP=190
POS_X=0.5
POS_Y=2
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HF]
SHOW_CLICKS=2
TAB=HEAVE DAMPERS
NAME=FST Rebound
MIN=500
MAX=3380
STEP=120
POS_X=0.5
POS_Y=3
HELP=HELP_HF_DAMPER_REBOUND

% ▼ The lines similar or identical to DAMPERS HF will be skipped. There are no lines missing apart from those.

/////////////////////////////////////////////////////
;DAMPERS HR
/////////////////////////////////////////////////////

[DAMP_BUMP_HR]
POS_X=0.5
POS_Y=5
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HR]
POS_X=0.5
POS_Y=6
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HR]
POS_X=0.5
POS_Y=7
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HR]
POS_X=0.5
POS_Y=8

295
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
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
/////////////////////////////////////////////////////

/////////////////////////////////////////////////////
;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

296
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 value in your setup.ini does not have the correct range, it will limit the default value 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°.
So always double check and verify that your setup.ini has the correct range of values to fit the default physics values.

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 happen to find obsolete sections in the sound configs of 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

297
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 before AC used the FMOD audio engine and employed
directly the audio samples. Those lines of code can be deleted. Another relic of the development past of our simulator.

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.
[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. below.

[ARB] ; Anti-Roll-Bar. (explanation)

FRONT=100 ; WHEELRATE (stiffness) of the front ARB. [N/m]
REAR=100 ; WHEELRATE (stiffness) of the rear ARB. [N/m]

[FRONT]
TYPE=STRUT ; The suspension type used. Inputs are DWB, STRUT, ML.
BASEY=0.014 ; The height that is 0 for all suspension components. [m]

% ▲ Distance of the CG from the center of the wheel, referenced from the suspension design height. It is the CG height 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 is RADIUS – BASEY, and the RADIUS value comes from tyres.ini.
So if the CG is 0.4m up and the wheels are 0.3m radius, BASEY is -0.1 since it has to go down 0.1 from 0.4m to get to the axle.

Front Wheel Radius+BASEY=front CoG. Actual CG height =(FWR+FBasey)+(RWR+Rbasey))/CG_LOCATION%.

Bear in mind that the loaded tire radius should be used for accuracy.
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. (not sure if correct)

% Look at Fig. below for a simple explanation of the BASEY value.

298
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 says how the
WHEELBASE is split up between front and rear, so a higher number means more wheelbase behind the CG.

RIM_OFFSET=0 ; Wheel offset.

% ▲ Effectively, it adds the amount to the X coordinates of the suspension linkages.

Take care to adjust TRACK after adjusting RIM_OFFSET if the intention is to “change wheels”. 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.

% 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?

HUB_MASS=54 ; Mass of the unsprung portion for one wheel. [Kg]

% ▲ With AXLE, it controls the portion 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.

% 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.
Refer to Car Analyzer.

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 ; Coordinates of the suspension arm
WBCAR_BOTTOM_REAR=0.35,-0.1,-0.37 ;
WBTYRE_BOTTOM=0.1,-0.10,0.0
WBCAR_STEER=0.667,-0.175,-0.16
WBTYRE_STEER=0.135,-0.175,-0.11
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 stifness. 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]

299
% ▲ 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 ; Vertical movement of the wheel, until impacting the rebound rubber. [m]

% ▲ 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.

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.

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 traveling slower than the
DAMP_FAST_BUMPTHRESHOLD value. [N/m/s]

DAMP_FAST_BUMP=1 ; Wheel damping rate for bump travel when the wheel is traveling 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.

[REAR] ; Same as above. NO, it won’t be the same

TYPE=AXLE ; 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

% ▼ The rear has more linkages than the front.

WBCAR_TOP_FRONT=0.28, 0.01, 0.72

WBCAR_TOP_REAR=0.30, 0.06, -0.01
WBCAR_BOTTOM_FRONT=0.33, -0.20, 0.77
WBCAR_BOTTOM_REAR=0.47, -0.232, -0.01
WBTYRE_TOP=0.14, 0.10, 0.01
WBTYRE_BOTTOM=0.15, -0.20, 0.0015
WBCAR_STEER=0.47,-0.232, 0.10
WBTYRE_STEER=0.15,-0.220, 0.10
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=0

% ▼ These lines are for the AXLE and ML suspension types. For the AXLE suspension only, the lines 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.

J0_CAR=0.36,-0.08,0.43 ; The suspension linkage inputs

J0_AXLE=0.27,-0.1,0.0
J1_CAR=-0.36,-0.08,0.43
J1_AXLE=-0.27,-0.1,0.0
J2_CAR=0.0,-0.03,0.97
J2_AXLE=0.0,0.06,0.0

[AXLE] ; Add this section only if you’re using the AXLE suspension TYPE.
LINK_COUNT=3 ; 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.0 ; 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

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

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

[FRONT]

RIM_OFFSET=0.01
TYPE=DWB
TRACK=1.660 ; Track width in meters (from pivot 3D placement of the 3d model of a wheel)
ROD_LENGTH=0.01203135 ; push rod length in meters. positive raises ride height, negative lowers ride height.
TOE_OUT=0.00040 ; Toe-out expressed as the length of the steering arm in meters
STATIC_CAMBER=-3.1 ; Static Camber in degrees. Actual camber relative to suspension geometry and movement, check values in
game

SPRING_RATE=170258
PROGRESSIVE_SPRING_RATE=0 ; progressive spring rate in N/m/m
BUMP_STOP_RATE=70000 ; bump stop spring rate
BUMPSTOP_UP=0.055 ; meters to upper bumpstop from the 0 design of the suspension
BUMPSTOP_DN=0.055 ; meters to bottom bumpstop from the 0 design of the suspension
PACKER_RANGE=0.033 ; Total suspension movement range, before hitting packers
DAMP_BUMP=15887 ; Damper wheel rate stifness in N sec/m in compression
DAMP_FAST_BUMP=3517
DAMP_FAST_BUMPTHRESHOLD=0.04
DAMP_REBOUND=10256 ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND=3791
DAMP_FAST_REBOUNDTHRESHOLD=0.02

DAMP_BUMP=13282 ; Damper wheel rate stifness in N sec/m in compression

DAMP_FAST_BUMP=4046
DAMP_FAST_BUMPTHRESHOLD=0.038
DAMP_REBOUND=11655 ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND=6571
DAMP_FAST_REBOUNDTHRESHOLD=0.017

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.

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

- 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 via an X, Y, Z coordinate system, referenced from the wheel center of one corner. For example 0.100,
0.050, -0.250.
The suspension coordinates are relative to the wheel 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.).

301
Fig. – An example of a rear suspension linkage for a Lamborghini Gallardo. You can clearly see where the origin (0, 0, 0) of the coordinates is.

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.

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.

NOTE: The AXLE suspension type references the points from the center of the axle instead of the wheel.

- For a quick visualization of the most important suspension 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.

302
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)

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

- Guide to suspension types in AC:

Currently there is 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.

DWB suspension

The example car (Fig.) uses DWB.

Looks like this when you get the susp app working, minus all the labels. I wrote in cyan 0,0,0 the origin, which is where the other points are measured in
reference to - +X brings them inboard, +Y brings them upward, +Z brings them forward, all relative to the center of the wheel.
The end points should be in the same place as the ball joints on the car.
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. The tie rod is VERY important.

STRUT suspension

looks like this:

303
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.
[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.

304
- 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

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

ksSusEditor, a basic suspension geometry viewer which is compatible with DWB and STRUT layouts. AXLE is buggy.

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). It’s 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

https://www.racedepartment.com/downloads/suspensions-test-track.6770/

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.

305
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

306
 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.

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.

307
33. tyres.ini

With this script you can control the parameters for the load and slip characteristics, stiffness, damping, resistances, heating etc. of the tires for your car. This
is probably the most important part of our simulation, as tires are the base of every interaction the car has with the tarmac. Don’t be surprised if modifying
these values changes completely the behaviour of your vehicle. 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 some measures; we’ll see how to
proceed in the following pages.
controls.
Assetto Corsa uses a semi-empiric tire model, meaning that you must input parameters and pre-determined look-up tables and the model will generate
behaviour from them. You do not however 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.
[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.

[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 ; Whether to use load or not in wear calculations (0= no, 1= yes).

% ▲ Toggles load effects for “virtual kilometers”, which is a function of tire slip distance. That is, it’s used for wear effects. The recommended input
is 1.

% Normal load of the tire stopped being considered in the wear calculation after a certain tire model iteration. This parameter adds it back (as it
should be).

[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=N ; Display name of the set of tires 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. [m]

% ▲ Doesn’t affect physics but the visual representation of the wheel 3D model and skid marks. When in doubt, input tire section width.
% The vanilla AC’s tire model has 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. [m]

% ▲ Bear in mind that real tires may differ from the theoretical specs. RADIUS is just visual and does not control any physical characteristics such as
stiffness or flex.

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 (if applicable). 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 ; Rotational inertia of rim + tire + brake disc assembly. [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 below are not used from tire model V5 and onwards, but still likely required for loading in game.
are outdated load sensitivity values used in old tire models. They are necessary to be included for the tire to load properly, but are unused in the
current suggested version.

DY0=1.9270 ; Unused since tire model V5 and onwards - still likely required for loading
DY1=-0.220 ; “ “ “ “ “ “ “
DX0=1.9770 ; “ “ “ “ “ “ “
DX1=-0.239 ; “ “ “ “ “ “ “

WEAR_CURVE=wcurve_conti.lut ; Lookup table to call (vKM | grip multiplier)

308
% specifies the look-up table to be used for wear characteristics. The format is vkm | grip percent, 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 ;DESCRIPTION

"Relaxation length is simply the space needed to reach 63% of the total build force.
It's basically a ""lag"" in the tyre response. One interesting fact about relaxation length is that camber doesn't seem to be 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."

controls the relaxation length input used by the complex interaction of the tire model. It is not comparable to real-world relaxation length values.
Typical values range around 0.0700 to 0.1200. The input is in meters.

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 ; No longer used since v5. Required anyway for loading.

% ▲ Tire profile flex. 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.

% ▲ 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.

% ▲▼ 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:

= ( ) [
(3.5)
_ ∙ _ ∙( ) ]
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:

∙ % %
_0 = _1 = )∙
(3.6)
[( % )∙ ] [( %
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).

FRICTION_LIMIT_ANGLE=10.5 ; Optimal slip angle of the tire at FZ0

% ▲ controls the peak lateral slip angle at nominal values to attain maximum grip. 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. Input is in degrees.

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

% ▲ Nominal cold pressure of the tire. Actual cold pressure will vary based on temperature conditions. RATE is referenced from this pressure. Input is in
psi.

PRESSURE_SPRING_GAIN=3580 ; INCREASE IN N/m per psi

309
% ▲ controls the springrate gain of the tire from the PRESSURE_STATIC value for every one psi. Value is in N/m.

PRESSURE_FLEX_GAIN=0.5 ; INCREASE IN FLEX per psi

% ▲ 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 pressure for grip

% ▲ controls the optimal pressure for grip and is referenced by many lines. The input is in psi.

% ▼ AC has 2 ways to handle the load sensitivity of the tire: lookup based and exponential formula based.

The formula based is the system that Kunos cars usually have. 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. 3 parameters in the INI are
used:

- FZ0 - The reference load

- LS_EXPY (and LS_EXPX) - The exponent used in the formula
- DY_REF (and DX_REF) - The D level at FZ0

A "MULT" parameter is calculated:

MULT = (DY_REF*FZ0) / FZ0^LS_EXPY

Then, at runtime, the D value as function of load (Fz) is the calculated as:

D = Fz^LS_EXPY * MULT / Fz

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 behavior, 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 formula based load sensitivity.

LS_EXPY=0.67 ; The exponent used in the formula

% ▲ lateral load sensitivity exponential parameter used by formula based 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.

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.

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

[…]

[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]
SURFACE_TRANSFER=0.018
PATCH_TRANSFER=0.00027
CORE_TRANSFER=0.00406
INTERNAL_CORE_TRANSFER=0.00090
FRICTION_K=0.03420
ROLLING_K=0.19
SURFACE_ROLLING_K=0.75
PERFORMANCE_CURVE=tcurve_conti.lut
GRAIN_GAMMA=1.2
GRAIN_GAIN=0.6
BLISTER_GAMMA=1.2
BLISTER_GAIN=0.6
COOL_FACTOR=0.940

% ▼ Below are the lines for the 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.

[FRONT_1] ; next set of front tires.

[…]

[REAR_1] ; next set of rear tires.

[…]

[THERMAL_FRONT_1] ; thermal model of the front tires.

[…]

311
[THERMAL_REAR_1] ; thermal model of the rear tires.
[…]

CSP ADDITIONS
[EXPLOSION]
TEMPERATURE=200 ; Temperature the tire should pop/explode at. [°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=20
PRESSURE_TEMPERATURE_GAIN=0.1
CAMBER_TEMP_SPREAD_K=1.4

LITTLE EXPLANATION

- Assetto Corsa is for a huge part, but not all, an empirically based tire load and slip simulator. Slip curves are generated dynamically inside AC, depending
on various factors. The tire is a hybrid brush model with currently a single load and slip contact point determined by a radius from the center of the tire
dimensions. The tire has a spring and damping rate and there are various parameters to control the behaviour of the tire which we will go over later. The tire
can also wear and manifests a thermal behaviour, which can be expanded with the use of Custom Shaders Patch.

- 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 curve would not cut it. It is not the curve that defines the tire characteristics, but the rest of the values that define a dynamic curve and
characteristics.

- 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. As you’ll see later in the physics,
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.

- "Flex" in sim 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.

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

- Assetto Corsa’s tire model has one main benefit over many other real-time simulation models, namely that the amount of inputs is relatively low but the
behaviour generated is quite dynamic and appropriate in most situations. A classical type of 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.

- Heat is probably the weakest part about vanilla AC tires. 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 each car has 4 tires and only runs code for those ones. That's very hardcoded.

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

For completeness, every set of wheels should come with a tyres.ini that has correct radius/width of the tires in the mesh. In practice it's probably fine to just
leave a default one unless you want a specific stance look, since most tunes will only change the rim size and leave tires about the same overall radius as
the original. (unclear)

- Single contact point

The wheel is not a flat plane, it's a single point straight "down" from the center of the tire (in the direction of the overall car's downward direction.

312
Since the tire's modeled as a spring vertically, doing a more complicated collision mesh wouldn’t be very easy.

- About vanilla tire compounds:

The tire ranges are not perfect ranges but a min max range that you might not be able to understand a difference in tyre grip. Temperatures are also vary
quite widely from straight to inside a turn, so optimally you need a tyre 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. Not so 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 for tyre temperatures, 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.

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.
Optimum 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.
Optimum 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).
Optimum 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 slicks (Zonda R and 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.

Vintage F1 67 tires:
AC provides just one compound for such tyres, although during that period 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.
Optimum 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.

INFLATION PRESSURE CONVERSION:

PSI to BAR: divide by 14.5
BAR to PSI: multiply by 14.5
RACE TYRE MARKINGS
Size markings, e.g. 280/675-18 show nominal tread width (mm), overall tyre diameter (mm) and bead diameter (in inches). Dimensions
being taken from an inflated tyre 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.
N.B Certain rules call for maximum overall width to include rims.

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, 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 encounter it in the data files.
[FRONT_0]

313
NAME=Front tyre
SHORT_NAME=S
WIDTH=0.300
RADIUS=0.325
RIM=0.2413
SOFTNESS=1.7
SIDE_STIFFNESS=0.5

[REAR_0]
NAME=Rear tyre
SHORT_NAME=S
WIDTH=0.310
RADIUS=0.355
RIM=0.2413
SOFTNESS=1.7
SIDE_STIFFNESS=0.7

[FRONT_1]
NAME=Front tyre
SHORT_NAME=SS
WIDTH=0.300
RADIUS=0.325
RIM=0.2413
SOFTNESS=1.7
SIDE_STIFFNESS=0.5

[REAR_1]
NAME=Rear tyre
SHORT_NAME=SS
WIDTH=0.310
RADIUS=0.355
RIM=0.2413
SOFTNESS=1.7
SIDE_STIFFNESS=0.7

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

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.

QUESTION [2]: How can I find real-life tire specifications?

ANSWER [2]: 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:
 tyre and rim dimensions;
 the code for tyre 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 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.

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 sidewall of a tire is the size number, indicated by 1 . To see the format of the size number, an example is shown in
Fig. and their definitions are explained as follows.
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
sT .sT =hTwT× 100 (1.1)
Generally speaking, tire aspect ratios range from 35, for race car tires, to 75 for tires used on utility vehicles.

314
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 diameter. This is a number in [ in] to indicate diameter of the rim that the tire is designed to fit on.
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.
Table 1.1 shows some of the most common load indices and their loadcarrying capacities. The load index is generally valid for speeds under 210 km/ h (≈
130 mi/ h).
H Speed rate. Speed rate indicates the maximum speed that the tire can sustain for a ten minute endurance without breaking down.

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 E 4 = tyre fulfils the 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

315
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.
If you take things too quickly here you won’t comprehend anything, unless you already know how car physics work. Some theoretic concepts may require
not only the knowledge of mathematic operations like derivatives and integrals, but also basic physics principles, like fields and vectors, to be fully
understood, but don’t worry too much about them (at least for now). At the end of juicy paragraphs will be a short summary of the things you need to
remember. If you’re a physics nerd, like me, you will have fun either way. I SHALL WRITE A BRIEF EXPLANATION OF THE BASIC PHYSICS CONCEPTS

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.

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

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

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

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

317
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 wheel11. 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.

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 body12, 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 field13.
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 upward14. The unit vectors marking the positive directions are (i, j, k), as shown in Fig. t.2.

11
A rigid wheel is essentially an axisymmetric convex rigid surface. The typical rigid wheel is a toroid. Imagine a donut.
12
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.
13
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.
14
Sw is the system recommended by ISO (International Organization for Standardization).

318
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)

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 rim15, 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

− = ℎ (− + )+ ℎ − =

= ℎ − ℎ′ + ℎ + ℎ′

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)
= = +

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;

15
In the SAE terminology, it is that is called spin velocity.

319
 (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.

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.

320
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
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**/)

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

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

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

323
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

This makes the tire more flexible radially, which reduces rolling resistance and improves cornering capability. Fig. ** (left) 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.

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.

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

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

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

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

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

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.

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

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

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.

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

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

332
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)

34. wing_animations.ini

Thsdfa
[ANIMATION_0] ; Wing animation identifier. SYNTAX: [ANIMATION_ID], ID starting from zero.
WING=3
FILE=WING_L.ksanim ; Specifies which animation file to use for the specific wing.
MIN=0
MAX=80

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

333
CHAPTER 7 – ADJUSTMENTS DURING 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.

7.1 – AC DEBUG CONSOLE COMMANDS (LIVE FIX)

Lights (front, rear, brakes), flames, digital instruments, display panels and the ground collider can be adjusted real time in-game 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 one of the commands below to enter edit mode, where AC will display real time adjustments.
 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 are case sensitive.

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

Some people may want to use Reshade; just avoid binding the HOME key to the opening of the shaders configuration window, because the AC console will
open and it will make a small mess, unless you deactivated it in the CSP settings. Nothing dangerous, it’s just annoying.

Are there any other commands? Probably yes, but Kunos didn’t reveal nor document them.

334
7.2 - APPS
What are apps in Assetto Corsa?

Apps are part of the UI and HUD in any race session of our simulator.

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.

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

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

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

6. Graphics stats
Parameters:

 UPD:
 REND:
 HUD:
 PHYS:
 CPU:
 AUDIO:
 DIFF:

336
7. Render stats
APP for physics

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)

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

AI app

While in the car in Ctrl-C mode edit your ai.ini parameters directly live in-game.

Where do I find the ai app while being in the car in Ctrl-C mode?

Camera editor

337
Fig. – car with packed data.acd

Edit vehicle cameras with the app

-save dash only appears if you unpack data

Car physics
Parameters:

SM:
CGH: sprung mass CG (center of gravity) height from ground; (GH, ground height)
DY F: tire grip level (front of the vehicle)
DY R: tire grip level (rear of the vehicle)
LD0: lift to drag (L/D) ratio; aerodynamic related
LD1: lift to drag (L/D) ratio; aerodynamic related
LD2: lift to drag (L/D) ratio; aerodynamic related
LD3: lift to drag (L/D) ratio; aerodynamic related
DISTR:
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:
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:
BOOST: turbo boost pressure
GRAIN F: tire wear related
GRAIN R: tire wear related
BLISTER F: tire wear related
BLISTER R: tire wear related
FLAT L:
FLAT R:
KERS:
KERS_KJ:
CONS: fuel consumption of the vehicle
NCP:
RPM: rotational regime of the vehicle’s engine in [RPM], rotations per minute
FSPEED:

338
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 #:

FINAL RATIO:

wheelAngularSpeed #:

slipAngle #:

slipRatio #:

load #:

tyreDirtyLevel #:

suspensionTravel #:

ndSlip #:

339
Suspensions

GRAPHS (left and right): Slip angle; if violet line is perpendicular = none

SA: Slip angle

SR: Slip ratio
C: Camber relative to the road surface; T: Toe; STR: Steering angle
Slip ratio graph (red=100% slip)

Tire temps 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: Inner / middle / outer tire temperatures

I: Vertical load on the tire
P: Pressure
CP:

Vertical white graph: Rear bumpsteer. It is toe gain on bump and rebound.

Fig. –

Using 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

Tyre debug

Fig. -

Tyre tester

340
Fig. -

Wings app

NAME: Name of the wing, as specified in aero.ini.

GH: Height in mm of the element relative to ground. The front splitter and the rear diffuser perform
differently depending on the height.

CL: Coefficient of lift (downforce). This number is pulled from the aero files and will vary
depending on angle for rear wing and body. It will vary depending on angle and height for front
splitter and diffuser.

CD: Coefficient of drag. Same as lift but it's drag force.

°: Angle of the wing in degrees.

On the bottom 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 between front and rear axle in %.

EFF: The aero efficiency: lift divided by drag. This value usually stays around 3.0 for GT cars. The
higher the better.

Fig. – The Wings app.

341
7.3 – 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.

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

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

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

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

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

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

345
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

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

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

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.). Then the speed decreases
dramatically and rises again near the Villeneuve variant.

Fig. -

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.), due to the fact that we braked more gently and with less intensity
than on our fastest lap.

347
Fig. -

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

Fig. -

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

348
Fig. -

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

At the Villeneuve variant our best performance is marked by 30% braking on entry compared to 19% on the second lap (Fig.) and 44% braking on the
change of direction (compared to 31% on the second lap), leading towards Tosa. 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.), 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.

349
Fig. –

Fig. -

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.), then rose
noticeably to 44% when, on our other attempt, we were already letting off the brakes and letting our Ferrari slide.

350
Fig. -

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.). In
our hotlap, on the other hand, we disconnected later and with a slightly higher intensity of 76 percent.

Fig. -

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.

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

Fig. -

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.). Looking at what happened immediately afterwards, the difference at this point is particularly important: 80% throttle use against 53%.

352
Fig. -

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

Conclusions
We have come to the end of this installment on telemetry in simracing: we have seen what is offered by the software present on Assetto Corsa, which
provides us with a very basic but, at the same time, important analysis to understand the fundamentals of telemetry systems. Basically, the graphs we
studied show lines that oscillate up and down and can be observed simply by hovering over them with the mouse pointer. In 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

353
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!

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

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

354
2 - Comparing Laps

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

355
4.7 - Logging Suspension Travel

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

356
CHAPTER 8 – SOUND
One of the most overlooked aspects of a driving simulation is sound. The audio signal gives feedback both about the vehicle state and the surrounding
environment. Depending on the experience of the driver, audio queues affect speed judgment, urgency, operator performance, alertness, and fatigue. As we
drive we use many audio clues for making decisions, such as using the pitch of the engine sound to decide to change gears.

Particular cases, such as low frequency (infra) sound (Sandberg, 1983) or combinations of sound and vibrations (Ihs, Andersson, Kircher, & Bolling, 2010)
have shown to affect driver behaviour in earlier simulator studies. One of the key requirements of a simulated environment is to achieve what is generally
called “presence”, i.e. the feeling of “being there” (Larsson, Västfjäll, & Kleiner, 2004). For auditory information this means providing a realistic sound field
allowing our hearing to perceive the expected spatial nature of the surroundings (Blauert, 1997). The more realistic the sound is the better the experience
will be for the driver and, perhaps more importantly, the more reliable the inference from experiments.

In a simulation out of place and inaccurate sounds can also distract a participant and negatively affect results.

In the past, sound engines have mostly been based on proprietary DSP (Digital Signal Processing) based solutions. Consumer PC based hardware simply
did not have the real-time signal processing capabilities to support a 3D sound engine. However over the last decades the capabilities of consumer sound
hardware have greatly increased. Today, 3D sound has become a standard feature of most computer video games; this has lead to a large number of 3D
sound API’s.

In terms of software APIs Assetto Corsa developers chose FMOD, by the Australian based Firelight Technologies (www.fmod.org). FMOD offers functionality
to handle 3D sound placement and Doppler shifts. Also it provides a node based DSP engine with important functions such as pitch shifting, white noise
and sine wave generation, signal filtering, and supports geometry based wave tracing to calculate reverb, obstruction and occlusion.

In the next chapters you will learn some general basics, the bare minimum to let you understand the theory and the practice behind a good sound. You will
be able to navigate in the world of audio better than before, especially if you don’t know anything. Then we will apply what you will learn to our beloved
simulation.

If you think you know everything about sound, you may skip paragraphs 8.1 and 8.2, as they contain some of the most important principles. Par. 8.3 is
useful for those who still haven’t decided which audio setup they will use. You can go directly to par. 8.4 if you want to learn how audio queues work in AC.

8.1 - LECTURES ON APPLIED ACOUSTICS

Can you hear me?

8.1.1 - EMISSION, PROPAGATION AND RECEPTION OF SOUND

Acoustics is the science that studies the following three components of sound:

 Emission: a mechanism by which a sound source causes an oscillatory motion in an elastic medium.
 Propagation: the motion is transmitted and diffused through the medium.
 Reception: the oscillation is revealed and transformed into a physiological stimulus (human ear) or a measurable signal (measuring instrument).

The analysis according to the emission-propagation-reception scheme is very useful in setting up the study of characteristics of:

 The sources that emit sound. For example: primary sources, such as the human voice, musical instruments, the means of transportation, working tools,
etc.; secondary sources (which reproduce the sound produced by the primary sources) such as loudspeakers.
 Waves that carry the energy transferred from the source to the propagating medium. For example: sine waves (pure tones), periodic complex waves
(harmonic sounds), random aperiodic complex waves (noises).
 Sound perception. For example: psychoacoustics, i.e., auditory effects produced on the human auditory system (ear + brain), measurement of sound
perception with acoustic instrumentation, microphones.

Let's explore this system in more detail.

Emission
Objects that emit sound are called sources, which always consist of vibrating masses. Typical examples:

 Oscillating solid bodies: stringed instruments, percussion instruments, cones/diaphragms of loudspeakers, machinery
 Oscillating air columns: wind instruments, organs
 Bodies in rapid movement: propellers, whips
 Gases in rapid exit from containers: rockets, jet engines, exhausts from industrial plants
 Rapid increases in pressure: detonations

Propagation
As an object vibrates, it sets the surrounding air in motion, sending alternating waves of compression and rarefaction radiating outward from the object.
Sound information is transmitted by the amplitude and frequency of the vibrations, where amplitude is experienced as loudness and frequency as pitch.

357
Sound is then an undulatory phenomenon, propagating in an elastic material medium, fluid or solid, consisting, as will be seen in detail below, of a series of
compressions and expansions of the propagating medium.

Physical quantities involved in propagation:

 Displacement of the particles in the medium from the equilibrium position;

 Vibration velocity of the particles
 Speed of wave propagation
 Local pressure change in the medium due to wave propagation

8.1.2 -
8.1.3 - WAVES
The familiar movement of an instrument string is a transverse wave, where the movement is perpendicular to the direction of travel (Fig.). Sound waves are
longitudinal waves of compression and rarefaction in which the air molecules move back and forth parallel to the direction of wave travel centred on an
average position, resulting in no net movement of the molecules. When these waves strike another object, they cause that object to vibrate by exerting a
force on them.

The forces that alternatively compress and stretch a spring (Fig.) are similar to the forces that propagate through the air as gas molecules bounce together.
Air molecules are in constant motion as a result of the thermal energy we think of as heat. (Room temperature is hundreds of degrees above absolute zero,
the temperature at which all motion stops.) At rest, there is an average distance between molecules although they are all actively bouncing off each other.
Regions of compression (also called condensation) and rarefaction (expansion) radiate away from a sound source in proportion to the movement of the
source. It is the net force exerted by the moving air that acts on our ears and on transducers like microphones to produce the sensation of hearing and the
electrical signals that become sound recordings. The same physics that describe oscillating mechanical systems like springs can be used to describe the
behaviour of gases like air: the equations derived to describe weights on springs can also be used to describe acoustics. Since a force implies a certain
quantity of energy, here transferred to the medium (usually air), we can also measure the quantity of heat that a sound generates, and most of the time it’s
infinitesimal and definitely negligible. Furthermore, electrical circuits exhibit similar behaviour and can be described using very similar mathematical
equations. Springs are even used to simulate reverberation, particularly in guitar amplifiers. This helps unify the field of sound recording, since mechanical,
acoustical and electrical systems are all employed in the recording of sound.

Fig. shows how energy is interchanged between kinetic and potential energy in an oscillating system.

358
Potential energy is energy that is capable of doing work, while kinetic energy is the result of active motion. As a mass suspended on a spring bounces up
and down, it exchanges the potential energy of a raised mass and tension stored in a spring with the kinetic energy of the moving mass back and forth until
friction depletes the remaining energy. At the top of its vertical motion, the mass has only potential energy due to the force of gravity while the spring is
relaxed and contains no energy. As the mass falls, it acquires kinetic energy while tension builds in the spring. At the mid-point of its fall, the mass reaches
its maximum velocity and then begins to slow as the force exerted by the spring’s expansion builds to counter the force of gravity. At the bottom of its travel,
the mass stops moving and therefore no longer has kinetic energy while the spring is maximally stretched and its potential energy is at its maximum, pulling
the mass back upwards. Since air has both mass and springiness, it behaves much the same way as the mechanical spring and mass.

Fig. shows how the time-varying characteristics of a sound wave may be measured. The amplitude can be measured as either pressure, velocity, or particle
displacement of the air. Pressure is often used because it is predominantly what is perceived by the ear and by many microphones. Peaks of increased
pressure and troughs of reduced pressure alternate as they radiate away from the source. Their wavelength and period can be used to describe the flow of
the wave. The reciprocal of the time between peaks or troughs is the frequency (f) in cycles/second or Hertz (Hz). The distance between peaks as they move
outward is the wavelength (l). The two quantities are related by the speed of sound (c), about 340 m/s or 1130 ft/s.

The pressure variations associated with sound are extremely small compared to the average air pressure. Barometric pressure at sea level is about 101 kPa
[Pa (pascal) = N/m2] or 14.7 lb/in2. The pressure variation considered the threshold of audibility is 20 µPa, on the order of one billionth of atmospheric
pressure! The sensitivity of the ear is quite impressive. This also begins to explain why sound transmission is so hard to control. Further, any device used to
convert sound into electricity must be similarly sensitive and able to respond over a huge range of pressures and frequencies.

As a vibrating object begins to move, it forces the air molecules in contact with its surface to move. Thus, the air is accelerated by the sound source, causing
a net increase in particle velocity. Particle velocity refers to the movement of a hypothetical small mass of air rather than to the turbulent individual air
molecules that vibrate locally with extreme velocities but only over infinitesimal distances. (Volume velocity is also used to describe the velocity component -
it’s the flow of bulk fluid - air in this case.) The dimensions of nitrogen and oxygen molecules are on the order of about 3 Angstroms (10-10 m). This is
many orders of magnitude smaller than wavelengths of sound so considering air as a bulk mass is sensible. As the movement continues outward from the
source, the molecules are forced together, increasing the local pressure. Very near a sound source, most of the energy is contained in the form of particle
velocity while far from the source the energy is transmitted predominantly in the form of pressure (Fig.)

Close to a small source, the sound wavefront expands in two dimensions as the spherical surface area grows with the square of the distance from the origin
(Fig.) Far from the source, the wavefront is practically planar and the energy radiates through the same area as it flows outward hence there is no decrease
in sound pressure due to geometric dispersion. This distinction affects how sensors respond to the sound, as some are sensitive only to pressure while
others are sensitive to the velocity of the sound wave that is driven by the pressure difference along the axis of movement.

359
The ear functions mainly as a pressure sensor as do omnidirectional microphones, designed as pressure sensors.

Other types of microphones are sensitive to the air pressure gradient (often called velocity microphones.) These behave differently than pure pressure
sensors, as we will see when we examine microphone design and performance. The core of this difference depends on the fact that pressure is a scalar
quantity while velocity is a vector quantity. [A scalar quantity has only a magnitude while a vector has both magnitude and direction.] In order for a
microphone to respond differently with respect to the direction from which a sound originates, it must be at least somewhat sensitive to the velocity vector
while pressure microphones respond only to the pressure of a sound wave and not to the direction from which it originates.

In directional microphones, it is the pressure difference between two points (the front and back of the microphone), the pressure gradient, that is
responsible for the forces that are converted to electrical signals in the transducer. While some directional microphones do respond to the velocity directly,
like dynamic and ribbon microphones, others use multiple pressure-sensitive elements to produce a signal proportional to the pressure difference without
actually moving at the equivalent velocity. For this reason, it is preferable to refer to directional microphones in general as pressure-gradient microphones.

Air is a gas mixture, predominantly nitrogen and oxygen. The molecules are in constant motion. The hotter the gas, the more frequent and energetic the
molecular collisions. The kinetic energy of the gas exerts a force on other objects in contact with the air, which we call pressure. The relationship between
the pressure and volume occupied by the gas in a closed system is reflected in the basic law of gases, Boyle’s Law:

where P is pressure, V is volume, n is the amount of gas in moles, R is a constant and T is the absolute temperature. The most important aspect of this
relationship is that the product of pressure and volume is constant – if one goes up, the other goes down. (Related changes in temperature may complicate
this relationship slightly.)

The pressure goes up when the gas is compressed by reducing the volume it occupies because the molecules are forced closer together where their
collisions become more frequent. The compressibility of air can be observed using a syringe. With the plunger half-way into the syringe body, block the
open end of the syringe and push or pull on the plunger. When you release the plunger, it returns to its original position much like air molecules do during
a passing sound wave.

There is plenty of confusion about how to measure sound amplitude. Sound intensity is the product of pressure and velocity and reflects the power
(energy/time) of the sound wave:

Intensity = pressure x velocity = power / area

Near the sound source, intensity decreases with the square of the distance from the source. Intensity measures the total power of the sound wave - its ability
to do work. What we hear as loudness is more closely related to the pressure of the sound wave, which decreases linearly with distance from the source.
When we are concerned with our perception of loudness, we need to consider the sound pressure level rather than the intensity. We can also consider only
the pressure when we use omnidirectional pressure microphones. When using directional microphones, however, we will need to also consider the velocity
component of the sound wave.

Directional microphones have the ability to respond differently to sounds originating from different directions because they are sensitive to the sound wave
pressure gradient, which changes as a function of the angle from which the sound originates. It is more complicated to measure the velocity of a sound
wave than it is to measure its pressure, therefore most audio systems use sound pressure as a measure of amplitude. Most often, amplitude is measured as
sound pressure level (SPL).

The distinction between spherical and plane waves is of practical importance because it explains how different microphone types respond depending on
their distance from the sound source. For spherical waves, the intensity decreases with the square of the distance but the sound pressure level decreases
linearly with distance.

360
A spherical wave sound pressure decreases by 1/2 or 6 dB for a doubling of distance. In a more distant plane wave, any decrease in sound pressure is due
to absorption and scattering rather than geometric considerations.

In theory, plane wave pressures do not decrease with distance as they do for spherical waves. Equations for spherical and plane waves are presented below.
These equations show how pressure p and velocity u change as a function of both time and distance from the source and as a function of wavelength.

8.1.5 –
8.1.2 - THE SINE WAVE
As the sine wave is so useful it will be treated here in detail. Fig. 2.5 shows a constant speed rotation viewed along the axis so that the motion is circular.
Imagine, however, the view from one side in the plane of the rotation. From a distance only a vertical oscillation will be observed and if the position is
plotted against time the resultant waveform will be a sine wave. Geometrically it is possible to calculate the height or displacement because it is the radius
multiplied by the sine of the phase angle.

Fig. 8.4 - A sine wave is one component of a rotation. When a rotation is viewed from two places at right angles, one will see a sine wave and the other will see a cosine wave. The
constant phase shift between sine and cosine is 90 ° and should not be confused with the time variant phase angle due to the rotation.

The phase angle is obtained by multiplying the angular velocity ω by the time t. Note that the angular velocity is measured in radians per second whereas
the frequency f is measured in rotations per second or Hertz [Hz]. As a radian is unit distance at unit radius (about 57°) then there are 2π radians in one
rotation. Thus the waveform at a time t is given by sin( ) or sin(2 ).

Imagine a second viewer who is at right angles to the first viewer. He will observe the same waveform, but at a different time. The displacement will be given
by the radius multiplied by the cosine of the phase angle. When plotted on the same graph, the two waveforms are phase shifted with respect to one
another. In this case the phase shift is 90 ° and the two waveforms are said to be in quadrature. Incidentally the motions on each side of a steam locomotive
are in quadrature so that it can always get started (the term used is quartering).

Note that the phase angle of a signal is constantly changing with time whereas the phase shift between two signals can be constant. It is important that these
two are not confused.

The velocity of a moving component is often more important in audio than its displacement. The vertical component of velocity is obtained by differentiating
the displacement. As the displacement is a sine wave, the velocity will be a cosine wave whose amplitude is proportional to frequency. In other words the
displacement and velocity are in quadrature with the velocity lagging. This is consistent with the velocity reaching a minimum as the displacement reaches a
maximum and vice versa.

8.1.4 – COMMON WAVE TYPES

At this point we'll look into the main waveforms that are usually adopted as the basic ingredients of any respectable sound lab. You can easily generate most
of them with the Audacity software for your audio mixes.

Sine wave

361
You have already gotten acquainted with it in the previous paragraph. You have learned, for example, that this type of waveform is the simplest of all; it’s a
basic and isolated sound, involving no harmonic nor in-harmonic sounds, and its frequency determines the pitch of the sound in question. As you will see,
the sine wave is at the origin of all the other waveforms listed in this chapter.

Pro tip: If you’re looking to create a smooth sub bass sound that doesn’t interfere with the feel of the vehicle, then deploy a sine wave to create a beautiful
deep tone. I recommend a low intensity and frequencies up to 150 Hz. Anything below 100 Hz is perfect for interior sound in modern, well-isolated vehicles.

Square wave
The square wave differs from the sine wave in that, besides the fundamental frequency, it also contains odd harmonics. The sum of these harmonics and the
fundamental give it its square shape. Its cycle is equally divided into two alternating constant amplitudes above and below the baseline. That’s why it’s called
a symmetrical wave and, thus, a true square wave. Otherwise, if the time the wave is above the baseline differs from the time below the baseline, the wave is
not symmetrical and it’s called a “rectangular” wave.

A square wave sounds richer and buzzier. You can make aggressive, crunchy kick drums. But for cars it’s probably not very useful.

Pulse wave
The pulse wave is derived directly from the square wave. It’s a wave where the second part of the cycle is replaced by absolute silence. So it’s not a
symmetrical square wave. The time it spends above the baseline is called duty cycle.

The pulse wave is applied a lot in electronics, for example in the circuits of dimmers for LED lights, where the duty cycle is modified in real time by means
of Pulse Width Modulation (PWM). This technique is widely used.

Triangle wave
The triangle wave is comparable to the square wave in that it contains a fundamental sound plus odd harmonics. However, the power of each harmonic in
the triangle wave is twice as low as their counterparts in the square wave. Thus, the power of the harmonics in the triangle wave is reduced twice as fast as
in the square wave.

A triangle wave can be more or less symmetrical. It sounds clearer, maybe even brighter than a sine wave.

Sawtooth wave
The sawtooth is the most extreme asymmetrical triangle wave. It can adopt two shapes: A progressively increasing ramp followed by an abrupt drop, or a
sharp rise followed by a progressive descent.

When it comes to frequency, the sawtooth is the richest in terms of harmonics ─ it has them all! This richness makes it particularly interesting for subtractive
synthesis, which is when you construct a sound by filtering out frequencies, rather than adding them on.

362
8.1.1 - PERIODIC AND APERIODIC SIGNALS
Sounds can be divided into these two categories and analysed both in the time domain in which the waveform is considered, or in the frequency domain in
which the spectrum is considered. The time and frequency domains are linked by transforms of which the most well-known is the Fourier transform.

Fig. 8.0 (a) shows that a periodic signal is one which repeats after some constant time has elapsed and goes on indefinitely in the time domain.

Fig 8.0 - (a) Periodic signal repeats after a fixed time and has a simple spectrum consisting of fundamental plus harmonics. (b) Aperiodic signal such as noise does not repeat and has
a continuous spectrum. (c) Transient contains an anharmonic spectrum.

In the frequency domain such a signal will be described as having a fundamental frequency and a series of harmonics or partials which are at integer
multiples of the fundamental. The timbre of an instrument is determined by the harmonic structure. Where there are no harmonics at all, the simplest
possible signal results which has only a single frequency in the spectrum. In the time domain this will be an endless sine wave.

Fig. 8.0 (b) shows an aperiodic signal known as white noise. The spectrum shows that there is equal level at all frequencies, hence the term ‘white’ which is
analogous to white light containing all wavelengths. Transients or impulses may also be aperiodic. A spectral analysis of a transient (Fig. 8.0 (c)) will contain
a range of frequencies, but these are not harmonics because they are not integer multiples of the lowest frequency. Generally the narrower an event in the
time domain, the broader it will be in the frequency domain and vice versa.

8.1.3 - PROCESSING SIGNALS: THE FOURIER TRANSFORM (wip)

An audio signal is a complex signal composed of multiple single-frequency sound waves (basically sine waves) which travel together as a disturbance
(pressure change) in the medium. When sound is recorded, we only capture the resultant amplitudes of those multiple waves. Fourier Transform is a
mathematical concept that can decompose a signal into its constituent frequencies. Fourier transform does not just give the frequencies present in the
signal, it also gives the magnitude of each frequency present in the signal (Fig.).

363
The inverse Fourier Transform is just the opposite of the Fourier Transform. It takes the frequency-domain representation of a given signal as input and does
mathematically synthesize the original signal (Fig.).

Fig. - Graphical representation of a signal (red line) that is obtained via the Fourier Transform. The input is a sawtooth wave (black lines), and the output is obtained by varying the
number of secondary harmonics (in violet), for a maximum of 20, that approximate it in the sum.

Fourier transforms are not as useful for analysing transient signals, compared to time-domain analysis or even wavelet analysis. Transient signal analysis is a
complex endeavour. However, keep in mind that all the information in the signal is retained in the Fourier transform, albeit in a quite hard to interpret form.
So it’s possible to use it, it’s just more difficult. A better tool should be able to display any transient features more apparently at its output, which Fourier
transform will not; unlike the case where it displays the periodicity information so well.

8.1.4 - FREQUENCY RESPONSE AND LINEARITY

The sine wave is extremely useful in testing audio equipment because of its spectral purity. It is a goal in sound reproduction that the timbre of the original
sound shall not be changed by the reproduction process. There are two ways in which timbre can inadvertently be changed, as Fig. 8.1 shows.

Fig. 8.1 - Why frequency response matters. Original spectrum at (a) determines timbre of sound. If original signal is passed through a system with deficient frequency response (b), the
timbre will be changed (c).

In (a) the spectrum of the original sound shows a particular relationship between harmonics. This signal is passed through a system (b) which has an
unequal response at different frequencies. The result is that the harmonic structure (c) has changed, and with it the timbre. Clearly a fundamental
requirement for quality sound reproduction is that the response to all frequencies should be equal.

Frequency response is easily tested using sine waves of constant amplitude at various frequencies as an input and noting the output level for each
frequency.

Fig. 8.2 shows that another way in which timbre can be changed is by non-linearity. All audio equipment has a transfer function between the input and the
output which form the two axes of a graph. Unless the transfer function is exactly straight or linear, the output waveform will differ from the input.

364
Fig. 8.2 - Non-linearity of the transfer function creates harmonics by distorting the waveform. Linearity is extremely important in audio equipment.

A non-linear transfer function will cause harmonic distortion which changes the distribution of harmonics and changes timbre. As the sine wave is spectrally
pure, the creation of harmonics by a non-linear process is at its most obvious. Consequently the use of a sine wave test signal and a spectrum analyser is a
useful way of testing for harmonic distortion.

At a real microphone placed before an orchestra a multiplicity of sounds may arrive simultaneously. The microphone diaphragm can only be in one place at
a time, so the output waveform must be the sum of all the sounds.

An ideal microphone connected by ideal amplification to an ideal loudspeaker will reproduce all of the sounds simultaneously by linear superimposition.
However, should there be a lack of linearity anywhere in the system, the sounds will no longer have an independent existence, but will interfere with one
another, changing one another’s timbre and even creating new sounds which did not previously exist. This is known as intermodulation. Figure 2.4 shows
that a linear system will pass two sine waves without interference. If there is any non-linearity, the two sine waves will intermodulate to produce sum and
difference frequencies which are easily observed in the otherwise pure spectrum.

Fig. 8.3 - (a) A perfectly linear system will pass a number of superimposed waveforms without interference so that the output spectrum does not change. (b) A non-linear system
causes intermodulation where the output spectrum contains sum and difference frequencies in addition to the originals.

8.1.4 - ROOT MEAN SQUARE MEASUREMENTS

Let’s approach the power of the sound. Fig. 8.5 (a) shows that according to Ohm’s law, the power dissipated in an electric resistance (here the coil of an ideal
speaker) is proportional to the square of the applied voltage.
∙
The measure unit of electric resistance is the Ohm, [Ω], and it is defined by the aforementioned law as Ω = = = = . A resistor has a
∙
resistance of 1 Ohm when a potential difference of 1 volt at its ends generates a current of intensity equal to 1 ampere.

365
Fig. 8.5 – (a) Ohm’s law: the power developed in a resistor is proportional to the square of the voltage. Consequently, 1 mW in 600 Ω requires 0.775 V. With a sinusoidal alternating
input (b), the power is a sine square function which can be averaged over one cycle. A DC voltage which would deliver the same power has a value which is the square root of the
mean of the square of the sinusoidal input.

This causes no difficulty with direct current (DC), but with alternating signals such as audio it is harder to calculate the power. Consequently a unit of voltage
for alternating signals was devised. Fig. 8.5 (b) shows that the average power delivered during a cycle must be proportional to the mean of the square of the
applied voltage. Since power is proportional to the square of applied voltage, the same power would be dissipated by a DC voltage whose value was equal to
the square root of the mean of the square of the AC voltage. Thus the volt rms (root mean square) was specified. An AC signal of a given number of volts
rms will dissipate exactly the same amount of power in a given resistor as the same number of volts DC.

Fig. 8.6 (a) shows that for a sine wave the rms voltage is obtained by dividing the peak voltage by the square root of two. However, for a square
wave (b) the rms voltage and the peak voltage are the same.

Fig. 8.5 - (a) For a sine wave the conversion factor from peak to rms is p2. (b) For a square wave the peak and rms voltage is the same.

Most moving coil AC voltmeters only read correctly on sine waves, whereas many electronic meters incorporate a true rms calculation. On an oscilloscope it
is often easier to measure the peak-to-peak voltage which is twice the peak voltage. The rms voltage cannot be measured directly on an oscilloscope since it
depends on the waveform although the calculation is simple in the case of a sine wave.

8.1.5 - THE DECIBEL (dB)

The first audio signals to be transmitted were on telephone lines. Where the wiring is long compared to the electrical wavelength (not to be confused with
the acoustic wavelength) of the signal, a transmission line exists in which the distributed series inductance and the parallel capacitance interact to give the
line a characteristic impedance. In telephones this turned out to be about 600 Ω. In transmission lines the best power delivery occurs when the source and
the load impedance are the same; this is the process of matching.

366
It was often required to measure the power in a telephone system, and one milliWatt (mW) was chosen as a suitable unit. Thus the reference against which
signals could be compared was the dissipation of one milliWatt in 600 Ω. Fig. 8.5 showed that the dissipation of 1 mW in 600 Ω was due to an applied
voltage of 0.775 V rms. This voltage is the reference against which all audio levels are compared.

The deciBel is a logarithmic measuring system and has its origins in telephony where the loss in a cable is a logarithmic function of the length. Human
hearing also has a logarithmic response with respect to sound pressure level (SPL). In order to relate to the subjective response audio signal level
measurements must also be logarithmic and so the deciBel was adopted for audio.

Fig. 8.6 shows the principle of the logarithm. To give an example, if it is clear that 102 is 100 and 103 is 1000, then there must be a power between 2 and
3 to which 10 can be raised to give any value between 100 and 1000. That power is the logarithm to base 10 of the value, e.g. log10 300=2.5 approx.
Note that 100 is 1.

Fig. 8.6 - (a) The logarithm of a number is the power to which the base (in this case 10) must be raised to obtain the number. (b) Multiplication is obtained by adding logs, division by
subtracting. (c) The slide rule has two logarithmic scales whose length can easily be added or subtracted.

Logarithms were developed by mathematicians before the availability of calculators or computers to ease calculations such as multiplication, squaring,
division and extracting roots. The advantage is that armed with a set of log tables, multiplication can be performed by adding, division by subtracting.

Fig. 8.6 shows some examples. It will be clear that squaring a number is performed by adding two identical logs and the same result will be obtained by
multiplying the log by 2.

The slide rule used a lot by engineers back in the day (and still used) is an early calculator which consists of two logarithmically engraved scales in which
the length along the scale is proportional to the log of the engraved number. By sliding the moving scale, two lengths can easily be added or subtracted and
as a result multiplication and division is readily obtained.

The logarithmic unit of measurement in telephones was called the Bel after Alexander Graham Bell, the inventor. Formula (4514f56s4d) shows that the Bel
was defined as the log of the power ratio between the power to be measured and some reference power. Clearly the reference power must have a level of 0
Bels since log10 1 is 0.
1
1 = ; 1 = ⇒ ( ) = 10 ∙
10

The Bel was found to be an excessively large unit for many purposes and so it was divided into 10 deciBels, abbreviated dB. Consequently the number of
dB is 10 times the log of the power ratio. A device such as an amplifier can have a fixed power gain which is independent of signal level and this can be
measured in dB. However, when measuring the power of a signal, it must be appreciated that the dB is a ratio and to quote the number of dBs without
stating the reference is about as senseless as describing the height of a mountain as 2000 without specifying whether this is feet or metres. To show that the
reference is one milliWatt into 600 Ω, the units will be dB(m). In radio engineering, the dB(W) will be found which is power relative to one Watt.

And this is where the confusion begins: there are a lot of types of decibels! Suffixes are commonly attached to the basic dB unit in order to indicate the
reference value by which the ratio is calculated. In cases where the unit value of the reference is stated, the decibel value is known as "absolute". If the unit
value of the reference is not explicitly stated, as in the dB gain of an amplifier, then the decibel value is considered relative. This form of attaching suffixes to
dB is widespread in practice, albeit being against the rules promulgated by standards bodies (ISO and IEC), given the "unacceptability of attaching
information to units" and the "unacceptability of mixing information with units". Outside of documents adhering to SI units, the practice is very common as
illustrated by the following examples. There is no general rule, with various discipline-specific practices. Sometimes the suffix is a unit symbol
("W","K","m"), sometimes it is a transliteration of a unit symbol ("uV" instead of μV for microvolt), sometimes it is an acronym for the unit's name ("sm" for

367
square meter, "m" for milliwatt), other times it is a mnemonic for the type of quantity being calculated, or otherwise a general attribute or identifier about the
nature of the quantity. The suffix is often connected with a hyphen, as in "dB‑Hz", or with a space, as in "dB HL", or enclosed in parentheses, as in
"dB(sm)", or with no intervening character, as in "dBm" (which is non-compliant with international standards). It’s not worth explaining all of them, it’s easier
to understand which one you’re working with by yourself.

Although the dB(m) is defined as a power ratio, level measurements in audio are often done by measuring the signal voltage using 0.775 V as a reference in
a circuit whose impedance is not necessarily 600 . Figure 2.9(b) shows that as the power is proportional to the square of the voltage, the power ratio will be
obtained by squaring the voltage ratio. As squaring in logs is performed by doubling, the squared term of the voltages can be replaced by multiplying the
log by a factor of two. To give a result in deciBels, the log of the voltage ratio now has to be multiplied by 20.

Whilst 600  matched impedance working is essential for the long distances encountered with telephones, it is quite inappropriate for audio wiring in a
studio. The wavelength of audio in wires at 20 kHz is 15 km. Most studios are built on a smaller scale than this and clearly analog audio cables are not
transmission lines and they do not have a characteristic impedance. Consequently the reader is cautioned that anyone who attempts to sell exotic analog
audio cables by stressing their transmission line characteristics is more of a salesman than a physicist.

In professional audio systems impedance matching is not only unnecessary it is also undesirable. Figure 2.11(a) shows that when impedance matching is
required the output impedance of a signal source must be artificially raised so that a potential divider is formed with the load. The actual drive voltage must
be twice that needed on the cable as the potential divider effect wastes 6 dB of signal level and requires unnecessarily high power supply rail voltages in
equipment. A further problem is that cable capacitance can cause an undesirable high-frequency roll-off in conjunction with the high source impedance.

In modern professional audio equipment as shown in Figure 2.11(b), the source has the lowest output impedance practicable. This means that any ambient
interference is attempting to drive what amounts to a short circuit and can only develop very small voltages. Furthermore shunt capacitance in the cable has
very little effect. The destination has a somewhat higher impedance (generally a few k ) to avoid excessive currents flowing and to allow several loads to be
placed across one driver.

In the absence of a fixed impedance it is now meaningless to consider power. Consequently only signal voltages are measured. The reference remains at
0.775 V, but power and impedance are irrelevant. Voltages measured in this way are expressed in dB(u); the commonest unit of level in modern systems.

Most installations boost the signals on interface cables by 4 dB. As the gain of receiving devices is reduced by 4 dB, the result is a useful noise advantage
without risking distortion due to the drivers having to produce high voltages. In order to make the difference between dB(m) and dB(u) clear, consider the
lossless matching transformer shown in Figure 2.12. The turns ratio is 2:1 therefore the impedance matching ratio is 4:1. As there is no loss in the
transformer, the power in is the same as the power out so that the transformer shows a gain of 0 dB(m). However, the turns ratio of 2:1 provides a voltage
gain of 6 dB(u). The doubled output voltage will develop the same power in to the quadrupled load impedance.

In a complex system signals may pass through a large number of processes, each of which may have a different gain. Figure 2.13 shows that if one stays in
the linear domain and measures the input level in volts rms, the output level will be obtained by multiplying by the gains of all of the stages involved. This is
a complex calculation.

The difference between the signal level with and without the presence of a device in a chain is called the insertion loss measured in dB. However, if the input
is measured in dB(u), the output level of the first stage can be obtained by adding the insertion loss in dB. The output level of the second stage can be
obtained by further adding the loss of the second stage in dB and so on. The final result is obtained by adding together all of the insertion losses in dB and
adding them to the input level in dB(u) to give the output level in dB(u). As the dB is a pure ratio it can multiply anything (by addition of logs) without
changing the units. Thus dB(u) of level added to dB of gain are still dB(u).

In acoustic measurements, the sound pressure level (SPL) is measured in deciBels relative to a reference pressure of 2 ð 105 Pascals (Pa) rms. In order to
make the reference clear the units are dB(SPL). In measurements which are intended to convey an impression of subjective loudness, a weighting filter is
used prior to the level measurement which reproduces the frequency response of human hearing which is most sensitive in the mid-range. The most
common standard frequency response is the so-called A-weighting filter, hence the term dB(A) used when a weighted level is being measured. At high or
low frequencies, a lower reading will be obtained in dB(A) than in dB(SPL).

8.1.6 - AUDIO LEVEL METERING

There are two main reasons for having level meters in audio equipment: to line up or adjust the gain of equipment, and to assess the amplitude of the
program material.

Line up is often done using a 1 kHz sine wave generated at an agreed level such as 0 dB(u). If a receiving device does not display the same level, then its
input sensitivity must be adjusted. Tape recorders and other devices which pass signals through are usually lined up so that their input and output levels are
identical, i.e. their insertion loss is 0 dB. Line up is important in large systems because it ensures that inadvertent level changes do not occur.

In measuring the level of a sine wave for the purposes of line up, the dynamics of the meter are of no consequence, whereas on program material the
dynamics matter a great deal. The simplest (and cheapest) level meter is essentially an AC voltmeter with a logarithmic response. As the ear is logarithmic,
the deflection of the meter is roughly proportional to the perceived volume, hence the term Volume Unit (VU) meter.

In audio recording and broadcasting, the worst sin is to overmodulate the tape or the transmitter by allowing a signal of excessive amplitude to pass. Real
audio signals are rich in short transients which pass before the sluggish VU meter responds. Consequently the VU meter is also called the virtually useless
meter in professional circles.

368
Broadcasters developed the Peak Program Meter (PPM) which is also logarithmic, but which is designed to respond to peaks as quickly as the ear responds
to distortion. Consequently the attack time of the PPM is carefully specified. If a peak is so short that the PPM fails to indicate its true level, the resulting
overload will also be so brief that the ear will not hear it. A further feature of the PPM is that the decay time of the meter is very slow, so that any peaks are
visible for much longer and the meter is easier to read because the meter movement is less violent. The original PPM as developed by the BBC was sparsely
calibrated, but other users have adopted the same dynamics and added dB scales, Fig. shows some of the scales in use.

Fig. - Some of the scales used in conjunction with the PPM dynamics. (After Francis Rumsey, with permission).

In broadcasting, the use of level metering and line up procedures ensures that the level experienced by the listener does not change significantly from
program to program. Consequently, in a transmission suite, the goal would be to broadcast tapes at a level identical to that which was obtained during
production. However, when making a recording prior to any production process, the goal would be to modulate the tape as fully as possible without clipping
as this would then give the best signal-to-noise ratio. The level would then be reduced if necessary in the production process.

8.1.7 - AUDIO CABLING and GROUND LOOPS

Balanced line working was developed for professional audio as a means to reject noise. This is particularly important for microphone signals because of the
low levels, but is also important for line level signals where interference may be encountered from electrical and radio installations. Figure 2.18 shows how
balanced audio should be connected. The receiver subtracts one input from the other which rejects any common mode noise or hum picked up on the
wiring. Twisting the wires tightly together ensures that both pick up the same amount of interference.

The star-quad technique is possibly the ultimate interference rejecting cable construction. Figure 2.19 shows that in star-quad cable four conductors are
twisted together. Diametrically opposite pairs are connected together at both ends of the cable and used as the two legs of a differential system. The
interference pickup on the two legs is rendered as identical as possible by the construction so that it can be perfectly rejected at a well-engineered
differential receiver.

The standard connector which has been used for professional audio for many years is the XLR which has three pins. It is easy to remember that pins 1, 2
and 3 connect to eXternal, Live and Return respectively. External is the cable screen, Live is the in-phase leg of the balanced signal and Return is self-
explanatory. The metal body shell of the XLR connector should be connected to both the cable screen and pin 1 although cheaper connectors do not
provide a tag for the user to make this connection and rely on contact with the chassis socket to ground the shell. Oddly, the male connector (the one with
pins) is used for equipment signal outputs, whereas the female (the one with receptacles) is used with signal inputs. This is so that when phantom power
(see Chapter 5) is used, the live parts are insulated.

When making balanced cables it is important to ensure that the twisted pair is connected identically at both ends. If the two wires are inadvertently
interchanged, the cable will still work, but a phase reversal will result, causing problems in stereo installations and preventing the continuity of absolute
phase through any system.

In consumer equipment differential working is considered too expensive. Instead single-ended analog signals using coax cable are found using phono, DIN
and single pole jack connectors. Whilst these are acceptable in permanent installations, they will not stand repeated connection and disconnection and
become unreliable. Very expensive gold-plated phono connectors are available which are advertised as being hand polished by Peruvian virgins or some
such, but, however attractive they may look, they have absolutely no effect on the sound quality.

369
Effective unbalanced transmission over long distances is very difficult. When the signal return, the chassis ground and the safety ground are one and the
same as in Figure 2.20(a), ground loop currents cannot be rejected. The only solution is to use equipment which is double insulated so that no safety
ground is needed. Then each item can be grounded by the coax screen. As Figure 2.20(b) shows, there can then be no ground current as there is no loop.
However, unbalanced working also uses higher impedances and lower signal levels and is more prone to interference. For these reasons some better quality
consumer equipment will be found using balanced signals.

8.1.10 - TYPES OF REPRODUCTION

The first audio systems were monophonic (from the Greek ‘single sound’), invariably abbreviated to mono. There was one loudspeaker fed by a single signal.
Whatever the position of the original sound sources, all of the sound would appear to come from one place, i.e. the loudspeaker. However accurate the
reproduction of the sound waveform by a mono system, the spatial representation is clearly completely incorrect.

Stereophonic (from the Greek ‘solid sound’) systems attempt to reproduce spatial attributes of the sound. Early experiments involved large numbers of
microphones, each feeding an independent speaker. Clearly this would be expensive and the technology of the day did not permit the recording or
broadcasting of multiple channels.

Today’s practical stereo systems are derived from the work of Alan Blumlein who showed that an infinity of virtual sound sources can be created at any
points between only two loudspeakers fed by two separate signals as shown in Fig. 7.0(a).

Fig. 7.0 – (a) The stereo system invented by Blumlein created virtual sound sources at arbitrary positions between only two loudspeakers needing only two channels. (b) A dummy head
connected to headphones gives realistic spatial effects but signal format is incompatible with (a).

The signal representing each virtual source is fed simultaneously to both speakers and its location is determined by the relative intensity in the two channels.
This is known as intensity stereo and it is a fundamental requirement that coincident directional microphones are used so that only intensity differences are
obtained. Loudspeakers must be used for reproduction as both ears must hear both speakers for the effect to work.

Intensity stereo recordings cannot be reproduced accurately on headphones as the sound appears to be in the centre of the listener’s head.

An alternative is shown in Fig. 7.0(b) where microphones are fitted in a dummy head and connected to headphones worn by the listener. This is known as
binaural stereo. The realism obtained is very high because the listener’s ears have been projected into the original sound field. However, as soon as the
listener turns his head the effect is lost. Another problem is that binaural signals cannot be reproduced directly on loudspeakers because the signals to each
ear cannot be kept separate.

The spatial coding of intensity stereo and binaural stereo is fundamentally different and incompatible with one another and with mono, and standards
conversion is required to interchange program material between standards.

Conversion to mono is achieved by adding the two stereo channels as shown in Fig. 7.1(a).

370
Fig. 7.1 – (a) Intensity stereo of Fig. 7.0(a) can be converted to mono reasonably well by adding left and right signals. (b) Mono signals can be reproduced on intensity stereo speakers
by supplying an identical signal to both channels. A central sound image results. (c) A sound image from a mono source can be moved or ‘panned’ by changing relative proportion of
signals fed to left and right speakers. (d) Pop record production pans many different mono signals into an artificial stereo image.

Intensity stereo gives good results as the spatial information simply collapses without affecting the tonality. As there are no phase differences in intensity
stereo, adding the channels and dividing by two is always the correct procedure to obtain a mono equivalent without a level change.

Adding the two channels of a binaural signal gives very poor results as the spacing between the microphones produces timing and phase differences
between them. Depending on the direction and frequency of the original sound, adding the channels may result in reinforcement or cancellation and this
causes a serious change in tonality as well as loss of spatial information. It is not clear what gain factor should be used to avoid a level change. This poor
mono compatibility is the main reason why broadcasters primarily use intensity stereo.

Mono signals can be reproduced on stereo systems simply by feeding both channels equally as in Fig. 7.1(b). The result is a central image with no spatial
information as might be expected. Mono signals from single instruments can be positioned within the stereo image by varying the relative intensity of the
signal fed to the two channels using a panoramic potentiometer or panpot (Fig. 7.1 (c)).

Today most pop records are made by panning a number of different mono signals into different locations in the stereo image (Fig. 7.1(d)).

Fig. 7.2 shows that in order to listen to intensity stereo on headphones a device called a shuffler must be used. This electronically simulates the missing
paths from each speaker to the opposite ear and moves the virtual sound sources to their correct forward location.

Fig. 7.2 - A standards converter known as a shuffler is necessary to listen to intensity stereo signals using headphones. This replicates electronically the fact that both ears hear both
loudspeakers.

One might be forgiven for thinking that personal stereo systems using headphones should incorporate such a device. In practice hardly any do and most
give a disappointing inside-the-head image.

Transaural stereo attempts to reproduce binaural stereo on loudspeakers by simulating the unwanted crosstalk between each speaker and the opposite ear
and adding it in anti-phase to the signals. The listener then obtains, over a limited area, an approximation to the original binaural waveform at each ear.

The transaural stereo processor is essentially an inverse shuffler. The above stereophonic techniques give reasonably accurate spatial representation of the
sound sources. Other techniques are used, such as spaced omnidirectional microphones, which produce both phase and intensity differences between the

371
two channels. These are quite incapable of reproducing the spatial information in the original sound field, but instead a diffuse spacious effect is obtained.
This is preferable to the point source of mono but it is only an effect.

Stereophonic systems only give accurate spatial information in an arc between the two speakers. Surround sound systems attempt to encircle the listener
with sound sources. Many of these use only two signal channels so that existing stereo recording and transmission equipment can be used. The two signals
are encoded in such a way that the decoder can determine the direction from which the dominant sound source is coming. The sound is then steered to the
appropriate speaker(s). Dolby Surround Sound and UHJ both work in this way.

In the late 1960s quadraphonic consumer equipment was made available in which four independent channels were conveyed. The technology of the day was
not adequate and the system was a commercial failure. Recently with digital techniques it has become possible to multiplex an arbitrary number of audio
channels into one transmission without crosstalk. This makes possible true surround sound.

8.1.11 - DIRECTIONALITY IN HEARING

Much greater spatial realism is obtained by using more than one loudspeaker. Generally, a reproduction system having some spatial realism will be
preferred to a technically superior monophonic system.

The human listener can determine reasonably well where a sound is coming from. An understanding of the mechanisms of direction sensing is important for
the successful implementation of spatial illusions such as stereophonic sound.

As Fig. 7.3 shows, having a pair of spaced ears allows a number of mechanisms. At (a) a phase shift will be apparent between the two versions of a tone
picked up at the two ears unless the source of the tone is dead ahead (or behind). At (b) the distant ear is shaded by the head resulting in reduced response
compared to the nearer ear. At (c) a transient sound arrives later at the more distant ear.

Fig. 7.3 - Having two spaced ears is cool. (a) Off-centre sounds result in phase difference. (b) Distant ear is shaded by head producing loss of high frequencies. (c) Distant ear detects
transient later.

If the phase-shift mechanism (Fig. 7.3(a)) is considered, then it will be clear that there will be considerable variation in this effect with frequency. At a low
frequency such as 30 Hz, the wavelength is around 11.5 metres. Even if heard from the side, the ear spacing of about 0.2 metres will result in a phase shift
of only 6 ° and so this mechanism must be quite weak at low frequencies.

At high frequencies such as 10 kHz, the ear spacing is many wavelengths and variations in the path-length difference will produce a confusing and complex
phase relationship. The problem with tones or single frequencies is that they produce a sinusoidal waveform, one cycle of which looks much like another
leading to ambiguities in the time between two versions. This is shown in Fig. 7.4(a).

Pure tones are extremely difficult to localize, especially as they will often excite room-standing waves which give a completely misleading impression of the
location of the sound source. Consequently the phase-comparison mechanism must be restricted to frequencies where the wavelength is short enough to
give a reasonable phase shift, but not so short that complete cycles of shift are introduced. This suggests a frequency limit of around 1500 Hz which has
been confirmed by experiment.

Phase differences are only useful at low frequencies and shading only works at high frequencies. Fortunately real-world sounds are timbral or broadband
and often contain transients, especially those sounds which indicate a potential hazard. Timbral, broadband and transient sounds differ from tones in that
they contain many different frequencies. A transient has a unique aperiodic waveform which Figure (b) shows has the advantage that there can be no
ambiguity in the inter-aural delay (IAD) between two versions.

372
Fig. 7.4 – (a) Pure tones cause ambiguity in timing differences. (b) Transients have no ambiguity and are easier to localize.

The inter-aural phase, delay and level mechanisms vary in their effectiveness depending on the nature of the sound to be located. A fixed response to each
mechanism would be ineffective. For example, on a low-frequency tone, the time-of-arrival mechanism is useless whereas on a transient it excels. The
different mechanisms are quite separate on one level, but at some point in the brain’s perception a fuzzy logic or adaptive decision has to be made as to how
the outcome of these mechanisms will be weighted to make the final judgement of direction.

8.1.12 - THE STEREOPHONIC ILLUSION

The most popular technique for giving an element of spatial realism in sound is stereophony, nowadays abbreviated to stereo, based on two simultaneous
audio channels feeding two spaced loudspeakers. Fig. 7.5 shows that the optimum listening arrangement for stereo is where the speakers and the listener
are at different points of a triangle which is almost equilateral.

Fig. 7.5 – Theoretic configuration used for stereo listening on the left, plausible setup on a desk on the right.

Stereophony works by creating differences of phase and time of arrival of sound at the listener’s ears. It was discussed above (par. 7.1.2) that these are the
most powerful hearing mechanisms for determining direction.

Fig. 7.6(a) shows that this time of arrival difference is achieved by producing the same waveform at each speaker simultaneously, but with a difference in the
relative level, rather than phase. Each ear picks up sound from both loudspeakers and sums the waveforms. The sound picked up by the ear on the same
side as the speaker is in advance of the same sound picked up by the opposite ear. When the level emitted by the left loudspeaker is greater than that
emitted by the right, it will be seen from Fig. 7.6(b) that the sum of the signals received at the left ear is a waveform which is phase advanced with respect to
the sum of the waveforms received at the right ear. If the waveforms concerned are transient the result will be a time-of-arrival difference. These differences
are interpreted as being due to a sound source left of centre.

373
Fig. 7.6 - (a) Stereo illusion is obtained by producing the same waveform at both speakers, but with different amplitudes. (b) As both ears hear both speakers but at different times,
relative level causes apparent time shift at the listener. ∆ = inter-aural delay due to loudspeaker; ∆ = inter-aural delay due to virtual source.

The stereophonic illusion only works properly if the two loudspeakers are producing in-phase signals. In the case of an accidental phase reversal, the spatial
characteristic will be ill-defined and lack images. At low frequencies the two loudspeakers are in one another’s near field and so anti-phase connection
results in bass cancellation.

As the apparent position of a sound source between the two speakers can be controlled solely by the relative level of the sound emitted by each one, stereo
signals in this format are called intensity stereo. In intensity stereo it is possible to ‘steer’ a monophonic signal from a single microphone into a particular
position in a stereo image using a form of differential gain control.

Fig. 7.7 shows that this device, known as a panoramic potentiometer or panpot for short, will produce equal outputs when the control is set to the centre. If
the panpot is moved left or right, one output will increase and the other will reduce, moving or panning the stereo image to one side.

Fig. 7.7 - The panpot distributes a monophonic microphone signal into two stereo channels allowing the sound source to be positioned anywhere in the image.

In audio preamplifiers and amplifiers usually this device is represented by the balance knob (Fig. 7.8).

374
Fig. 7.8 – The typical balance control in Hi-Fi audio equipment (in this example located on a stereo amplifier).

If the system is perfectly linear, more than one sound source can be panned into a stereo image, with each source heard in a different location. This is done
using a stereo mixer in which monophonic inputs pass via panpots to a stereo mix bus. The majority of pop records are made in this way, usually with the
help of a multitrack tape recorder with one track per microphone so that mixing and panning can be done at leisure.

It is important that your speaker system is correctly balanced for a correct sound reproduction. You can use a mono audio input to check whether your setup
is good or not. If the apparent source is not exactly in front of you, but off-centred to the left or to the right, the balance control can be adjusted to fix the
problem. This is fundamental when you cannot place your speakers following the aforementioned triangle shape.

8.1.13 - HEARING IN REVERBERANT CONDITIONS

We live in a reverberant world which is filled with sound reflections. If we could separately distinguish every different reflection in a reverberant room we
would hear a confusing cacophony. In practice we hear very well in reverberant surroundings, far better than microphones can, because of the transform
nature of the ear and the way in which the brain processes nerve signals.

When two or more versions of a sound arrive at the ear, provided they fall within a time span of about 30 ms, they will not be treated as separate sounds,
but will be fused into one sound. Only when the time separation reaches 50 60 ms do the delayed sounds appear as echoes from different directions.

As we have evolved to function in reverberant surroundings, reflections do not impair our ability to locate the source of a sound. The fusion will be impaired

if the spectra of the two sounds are too dissimilar. A moment’s thought will confirm that the first version of a transient sound to reach the ears must be the
one which has travelled by the shortest path. Clearly this must be the direct sound rather than a reflection. Consequently the ear has evolved to attribute
source direction from the time of arrival difference at the two ears of the first version of a transient. Later versions which may arrive from elsewhere simply
add to the perceived loudness but do not change the perceived location of the source.

This phenomenon is known as the precedence or Haas effect after the Dutch researcher who investigated it. Haas found that the precedence effect is so
powerful that even when later arriving sounds are artificially amplified (a situation which does not occur in nature) the location still appears to be that from
which the first version arrives. Fig. 7.9 shows how much extra level is needed to overcome the precedence effect as a function of arrival delay.

Experiments have been conducted in which the delay and intensity clues are contradictory to investigate the way the weighting process works. The same
sound is produced in two locations but with varying relative delay and shading dependent level. The way in which the listener perceives an apparent sound
direction reveals how the directional clues are weighted.

Fig. 7.9 - The precedence effect is powerful. This curve shows the extra level which is needed in a later sound to overcome it.

375
Within the maximum inter-aural delay of about 700 µs the precedence effect does not function and the perceived direction can be pulled away from that of
the first arriving source by an increase in level. Fig. 7.10 shows that this area is known as the time-intensity trading region. Once the maximum inter-aural
delay is exceeded, the hearing mechanism knows that the time difference must be due to reverberation and the trading ceases to change with level.

Fig. 7.10
It is important to realize that in real life the hearing mechanism expects a familiar sound to have a familiar weighting of phase, time of arrival and shading
clues. A high-quality sound reproduction system must do the same if a convincing spatial illusion is to be had. Consequently a stereo system which
attempts to rely on just one of these effects will not sound realistic. Worse still is a system which relies on one effect to be dominant but where another is
contradictory. Time-intensity trading is an interesting insight into the operation of the hearing mechanism, but it cannot be used in quality sound
reproduction because although the ear is fooled, it knows it is being fooled because it is attempting to resolve conflicting stimuli and the result is inevitably
listening fatigue.

In the presence of an array of simultaneous sound sources the hearing mechanism has an ability to concentrate on one of them based on its direction. The
brain appears to be able to insert a controllable time delay in the nerve signals from one ear with respect to the other so that when sound arrives from a
given direction the nerve signals from both ears are coherent. Sounds arriving from other directions are incoherent and are heard less well. This is known as
attentional selectivity but is more usually referred to as the cocktail-party effect. Monophonic systems prevent the use of this effect completely because the
first version of all sounds reaching the listener come from the same loudspeaker. Stereophonic systems allow the cocktail-party effect to function in that the
listener can concentrate on specific sound sources in a reproduced stereophonic image with the same facility as in the original sound.

One of the most frustrating aspects of hearing impairment is that hearing loss in one ear destroys the ability to use the cocktail-party effect. In quiet
surroundings many people with hearing loss can follow what is said in normal tones. In a crowded room they are at a serious disadvantage because they
cannot select a preferred sound source.

Laterally separated ears are ideal for determining the location of sound sources in the plane of the earth’s surface, which is after all where most sound
sources emanate. Our ability to determine height in sound is very poor. As the ears are almost exactly half-way back on each side of the head it is quite
possible for sound sources ahead or behind, above or below to produce almost the same relative delay, phase shift and shading resulting in an ambiguity.
This leads to the concept of the cone of confusion where all sources on a cone with the listener at the vertex will result in the same IAD.

There are two main ways in which the ambiguity can be resolved. If a plausible source of sound can be seen, then the visual clue will dominate. Experience
will also be used. People who look up when they hear birdsong may not be able to determine the height of the source at all, they may simply know, as we all
do, that birds sing in trees.

A second way of resolving front/back ambiguity is to turn the head slightly. This is often done involuntarily and most people are not aware they are using the
technique. In fact, when people deliberately try harder to locate a sound, they often keep their head quite still making the ambiguity worse.

Intensity stereo recordings (see par. 7.1.1) are fundamentally incompatible with headphone reproduction. A further problem with headphones is that they
turn with the wearer’s head, disabling the ability to resolve direction by that means.

The direction-sensing ability has been examined by making binaural recordings using miniature microphones actually placed down the ear canals of a
volunteer. When these are played back on headphones to the person whose ears were used for the recording, full localization of direction including
front/rear and height discrimination is obtained. However, the differences between people’s ears are such that the results of playing the recording to
someone else are much worse. The same result is obtained if a dummy head is used.

Whilst binaural recordings give very realistic spatial effects, these effects are only obtained on headphones and consequently the technique is unsatisfactory
for signals intended for loudspeaker reproduction and cannot used in pre-recorded music, radio or television.

8.1.14 – HEARING LOSS (unsure if to be kept)

Noise-Induced Hearing Loss, or NIHL, happens when you listen to loud sounds. These sounds can last a long time, like listening to a concert, or they can
be short, like from gunfire. Three factors put you at risk for NIHL:

 How loud the noise is

 How close you are to the noise
 How long you hear the noise

Sound-level meters measure noise levels. We record noise levels in decibels, or dBA. The higher the noise level, the louder the noise. You can listen to
sounds at 70 dBA or lower for as long as you want. Sounds at 85 dBA can lead to hearing loss if you listen to them for more than 8 hours at a time.

Sounds over 85 dBa can damage your hearing faster. The safe listening time is cut in half for every 3-dB rise in noise levels over 85 dBA. For example, you
can listen to sounds at 85 dBA for up to 8 hours. If the sound goes up to 88 dBA, it is safe to listen to those same sounds for 4 hours. And if the sound
goes up to 91 dBA, your safe listening time is down to 2 hours.

The World Health Organization and International Telecommunication Union 2019 document, WHO-ITU Global Standard on Safe Listening Devices and
Systems, recommends that manufacturers equip devices like smartphones and personal audio players with information that explains safe listening (for
adults, a total of 40 hours of weekly exposure to volume levels no higher than 80 dB is recommended; for children, the level is 75 dB); usage warnings and

376
tracking information; cues for taking safe listening actions; options for limiting volume levels; and volume limiters expressly for parents to use. The
recommendations would also have safe listening information appear on external product packaging and advertising, as well as on manufacturers' websites.

Signs That Noise Is Too Loud

You probably don't always carry a sound level meter with you. So how can you know if noises are too loud? Here are some signs:

 You must raise your voice to be heard.

 You can't hear or understand someone 3 feet away from you.
 Speech around you sounds muffled or dull after you leave the noisy area.
 You have pain or ringing in your ears after you hear the noise, called tinnitus. It can last for a few minutes or a few days.

How do loud noises hurt your hearing? It may help to first understand how you hear:

Sound goes into your ear as sound waves. The louder the sound, the bigger the sound wave.

The outer ear, which is what you see on the side of your head, collects the sound wave. The sound wave travels down the ear canal toward your eardrum.
This makes your eardrum vibrate.

The sound vibration makes the three middle ear bones move. The movement makes the sound vibrations bigger.

The last of the three middle ear bones moves the sound vibrations into the inner ear, or cochlea. The cochlea is filled with fluid and has tiny hair cells along
the inside. The vibrations make the fluid in the inner ear move. The fluid makes the hair cells move, too. The hair cells change the vibrations into electrical
signals that travel to your brain through your hearing nerve.

Only healthy hair cells can send electrical signals to your brain. We recognize sounds in our brains and use that information to figure out how to respond.

You may lose some of your hearing if the hair cells get damaged. How does this happen?

 Hair cells are sensitive to big movements. If sounds are loud, they move the fluid in the inner ear more, and that can damage the hair cells.
 Hair cells that are damaged by loud sounds do not send signals to the brain as well as they should. The first hair cells that are hurt are those that send high-pitched
sounds to the brain. This can make sounds like /t/ in "tin", /f/ in "sin", or /k/ in "kin" harder to hear.
 Short, loud noises - like a firecracker or an explosion - can damage hair cells. Listening to loud sounds for a long time, like when you are at a rock concert, also
damages hair cells.

Ringing in your ears, or tinnitus, is an early sign of noise-induced hearing loss. There is no way to fix damaged hair cells. Hearing aids or other devices can
help you hear better, but your hearing will not come back on its own.

Protecting your hearing

Knowing how noise impacts you is the key to protecting your hearing. You've taken that first step by reading this information.

The next step is to avoid loud noise whenever possible. Remember, if you have to shout to be heard, it is too loud. You should get away from the noise or
find a way to protect your ears.

Here are some things you can do:

1. Wear hearing protection. Cotton in the ears will not work. You can buy things that protect your hearing, like earplugs or earmuffs, at the store or online.
 Earplugs go into your ear so that they totally block the canal. They come in different shapes and sizes. An audiologist can make some just for your ears. Earplugs can
cut noise down by 15 to 30 decibels.
 Earmuffs fit completely over both ears. They must fit tightly to block sound from going into your ears. Like earplugs, earmuffs can reduce noise by 15 to 30 dB,
depending on how they are made and how they fit.
 Earplugs and earmuffs can be used together to cut noise down even more. You should use both when noise levels are above 105 dB for 8 hours or more. You
should also use both if you might hear impulse sounds that are more than 140 dBP.
2. Do not listen to loud sounds for too long. Move away from the loud sound if you don't have hearing protection. Give your ears a break. Plug your ears with your fingers
as emergency vehicles pass on the road.
3. Lower the volume. Keep personal listening devices set to no more than half volume. The World Health Organization recommends a total of 40 hours of weekly exposure
to volume levels no higher than 80 dB for adults and 75 dB for children on personal listening devices. Don't be afraid to ask others to turn down the volume of their
devices if you can hear them. Ask the movie theater manager to turn down the sound if the movie is too loud.
4. Be a good consumer. Look for noise ratings on appliances, sporting equipment, power tools, and hair dryers. Buy quieter products. This is especially important when
buying toys for children.
5. Be a local advocate. Some movie theaters, health clubs, dance clubs, bars, and amusement centers are very noisy. Speak to managers about the loud noise and how it
may hurt hearing. Ask that they turn the volume down.

Don't be fooled by thinking your ears are "tough" or that you can "tune it out"! Noise-induced hearing loss is usually slow and painless. But, it is permanent.
The hair cells and hearing nerve cannot be fixed. If loud sounds don't bother you, you may already have some hearing damage.

You can avoid noise-induced hearing. Protect your hearing for life.

377
8.2 – THE AUDIO EQUIPMENT
One important thing to keep in mind is that the sound synthesis process will only be as effective as the devices (mostly the speakers) used to playback
everything during the analog/digital mastering (still recording on tape?), the digital sampling and the final mixing. Let’s dive into this for a bit.

8.2.1 - SOUND SYSTEMS

There are many different uses for audio equipment and the performance criteria are quite different. Here some typical audio systems are outlined. A
distinction commonly made is between professional and consumer equipment.

In general professional equipment is a tool which someone uses to do his or her job. Failure or inconsistent performance is unacceptable as it could cause
loss of income or a damaged reputation. Rugged construction is desirable for reliability.

Before making a purchase most professionals insist on a demonstration or even a loan of the products under consideration so see how they function under
the intended conditions. It is not unusual for manufacturers to take prototypes into the field to gauge reaction and obtain the views of skilled
listeners.

A great deal of consumer equipment is purchased on its appearance without test. A number of low-cost loudspeakers are produced by injection moulding
and many of these have imitation tweeters and reflex ports which are completely non-functional but give the appearance of a more sophisticated unit. No
mass manufacturer displays prototypes as consumers would not understand why they were imperfect.

Consumer equipment is for entertainment and is mostly produced at low cost to variable standards. The common user will generally have little technical
knowledge and the equipment installation will often be compromised by poor loudspeaker placement.

8.2.2 - PORTABLE CONSUMER EQUIPMENT

Despite political correctness these portable units have come to be known almost universally as ‘ghetto blasters’ or ‘boomboxes’ (Fig. 7.11).

Fig. 7.11 – I’m touching grass too. Boomboxes have a bad reputation, but there are a bunch of better-than-average products (which aren’t necessarily the ones in the pictures above).

A constant problem with portable products is that battery power is extremely limited. Battery life is usually extended by failing to reproduce low frequencies
and by having very light cones in the speakers to improve efficiency. These are then insufficiently rigid and the results are almost always disappointing. With
the high cost of batteries, most of today’s products contain an AC power supply or can be used with an external power supply. A mechanical switch
disconnects the batteries when the external power connector is fitted.

There is no audiophile boombox, leastwise not an old one. They weren’t and aren’t by their very nature, sacrificing pretty much every potential positive
characteristic for portability. Most old ones objectively are bad, and even the best that can be done with modern tech is bad in comparison to real
loudspeakers.

The huge compromise in terms of sound fidelity is obvious, given the common audible distortion. Most of the times these devices don’t have an audio input
too, so they aren’t useful for our work.

The difficulties of portable loudspeaker reproduction are overcome in personal players which are designed only to drive headphones, but those usually don’t
have inputs either.

378
8.2.3 - FIXED HI-FI CONSUMER EQUIPMENT
Fixed equipment gives much better quality than portable units. The traditional component high-fidelity system can be seen in Fig. 7.12.

Fig. 7.12 – A standard fixed audio setup. We’re interested in the yellow path, as we’ll work with a PC. You should connect it to your setup (if you have one). Single unit Hi-Fi places
every function in one enclosure. Performance is often compromised because the cost of performing every function well would make the unit price high.

A preamplifier acts as a signal selector and has volume and tone controls as well as determining which signals will be recorded/played back. The
preamplifier drives the power amplifier which is connected to a separate loudspeaker. Each signal source is in a separate box.
Signal sources include radio tuners, cassette or open reel tape decks, vinyl disk players and CD players. In stereo systems the same units are present, but
there are two loudspeakers and every circuit is duplicated (to have a separate path for each channel). A balance control is added to adjust the relative level of
the two channels.
The advance of microcircuitry has meant that the bulk and cost of domestic electronics has shrunk dramatically. A lot of hi-fi components are literally
near-empty boxes with a few microchips in the corner. It is not unknown for the manufacturer to incorporate a thick steel plate to make the unit feel more
substantial. An early result of circuit miniaturization was the receiver (US) or tuner amplifier (UK), containing a radio tuner, preamplifier and power amplifiers.

As Fig. 7.12 shows, this requires external speakers and has connections for external units such as tape decks, CD players and vinyl turntables.
The receiver approach was followed by the single unit hi-fi in which everything except the speakers is in a single box. In principle there is no reason why
such a unit should not sound as good as a component system, provided that the same circuitry is used. In practice few people will pay what appears to be a
high price for one box and so these integrated units are normally built to a price rather than to a standard and the loudspeakers are usually marvels of penny
pinching. A dramatic improvement can usually be had by discarding the standard speakers and using better models.
The traditional hi-fi sports a forest of control knobs and is difficult for nontechnical users to wire up and operate. The appearance of a typical system is
unimaginative, especially the loudspeakers which are usually box shaped. The lifestyle audio system has evolved for people who prefer equipment which is
easier to use and which has a more imaginative appearance. Lifestyle systems usually have dramatic styling, few knobs, immaculate standards of surface
finish and “intelligent” remote-control systems.

8.2.4 - HIGH-END HI-FI

The high-end hi-fi market caters for the obsessive customer who often spends more time tinkering and comparing than actually listening for enjoyment.
High-end products are frequently over-engineered, employing massive chunks of expensive materials for reasons which do not withstand scrutiny. Often
a particular shortcoming is ruthlessly eliminated by some expensive technique. Whilst this improvement may be genuine, it is often at the expense of
serious neglect in other areas. Consequently, most high-end installations are unbalanced because too much attention is concentrated in a few places and
because each unit is ‘perfected’ without considering how it will operate in a system. A common failing is that too much has been spent on the electronics
and not enough on the loudspeakers. Precise signals are generated which the loudspeakers cannot reproduce. Despite the high cost of these systems their
ergonomics are usually very poor and they represent extremely poor value for money although the high cost is usually sold as imparting exclusivity. The
alleged quality of these products is not worth the price, that often exceeds the cost of professional equipment.

A small industry has sprung up producing accessories for high-end hi-fi, many of which appear to defy the laws of physics and all of which operate in the
area of diminishing returns. Naturally magazines are available to cater for the tastes of high-end hi-fi fans. In general these are difficult to read because the
technical terms they contain often mean what the writer wants them to mean rather than what the skilled person would understand them to mean. The term
pseudoscience has been coined to describe this kind of thing. Let’s not talk about the audiophile placebo effect and the sound of cables! The take-away is
not that audiophiles are crazy, it's that one needs to have restraint and know when enough is enough. And trying different equipment in person instead of
only reading colored reviews is really the most important part. Blind tests often debunk all the myths.
379
8.2.5 – PROFESSIONAL AUDIO: STUDIO MONITORS
Finally some juice. Studio Monitors are a type of loudspeaker with a linear frequency response. It’s mostly flat, so they’re really useful if you want to get a
sound faithful to the characteristics of the input source. The response in the mid and high portion of the audible spectrum can often be adjusted too, based
on the mixing room/desk layout.

These products fall in the professional category as they are employed in recording studios, and also used by audiophiles who want the cleanest sound
possible. A pair of monitors, if correctly set up, can sound better than a system worth thousands of dollars (or euros). I recognize that they are not cheap,
but still quite affordable (the price range goes from 100 to 1000 bucks more or less, depending on size and brand).

We don’t want to be nit-picky as audiophiles can be (there’s nothing wrong about it, but it’s a rather expensive hobby), so I will give you just an example of a
good pair of speakers, the JBL 4311 Control Monitors (Fig. 7.13).

Fig. 7.13 – Truly vintage; they were made since 1974 (this is the first version of the 4311). They won’t be elegant without the black covers, but they show off in terms of audio fidelity.
These are professional speakers in all respects. You can find the manual with the specifications of this model (of this version) here:
https://www.cieri.net/Documenti/JBL/Documenti%20tecnici/JBL%20-%204311%20(1974)%20-%20User's%20Manual.pdf

They require a good amount of power to be driven, so at least a decent amplifier is required. Nothing too pretentious anyway.

Why did I choose this as an example? Well, because I own a pair of these 4311s and I’ve had a long story with them. This doesn’t mean you have to buy
anything expensive16, and I’m not here to discuss which one is the best speaker in the world. But these JBL 4311 were very popular in professional studios,
and are still considered a reference point.

If you want a newer alternative, maybe less expensive, you can buy another model of Studio Monitors. There are also consumer models from JBL, like the
L-100 which has the same drivers as the 4311’s. Quite a few revisions have been made of the same 4311 model, so you may find the 4311B, C, G, SE, etc.;
the whole 43 series includes pro speakers from JBL. I would suggest to buy the later models, as the sound quality did improve over the years (Fig. 7.14).

Fig. 7.14 – The JBL 4312G. As you can see they maintained almost the same style over time. Good things never change.

16
And don’t get scammed on used markets, where people always want to finance their damn bank loans with easy money.

380
These speakers are made to last, not like disposable products with planned obsolescence. The drivers in the later models have passive radiator canals to
cool down the magnets (heat can damage them) when used at full power and the electronics inside (the crossover filter) are minimal as possible.

This is not advertisement though, so feel free to choose another speaker type or manufacturer if you want. This is a suggestion based on personal
experience and on the fact that JBL created the standard for Studio Monitors back in the seventies. It’s part of the history.

Nothing will stop you from using the Logitech LS11 (the new model is the Z150) or the Logitech Z120 speakers for your PC (Fig. 7.15):

Fig. 7.15 – My suggestion is to avoid such cheap artifacts. They’re not completely scrapped and some can actually be improved with a few fixes17, but they lack a lot of bass and
power18. If speakers are out of your league, use headphones instead. They need to be good though, and that will be another problem for your wallet.

What you have to be aware of is that the average house speakers or the “home theatre” HiFi loudspeakers are DESIGNED to make just about everything
sound good. If you’re mixing/recording on them and the sound needs more bass or treble, you’re not going to hear what the audio source really needs to be
good at an absolute level, because the speakers are lying to you. They’ve actually been designed to boost the intended frequencies (in order to reduce the
resonance of the wooden/plastic enclosure and to give them a particular “feel”, see Fig. 7.16), so your mix may sound good on those specific speakers, but
when you go play it on another system (like your car, or at your friend’s house) that’s going to sound totally different (and probably bad).

Fig. 7.16 – Frequency response of different speakers. The scale of the plots is not the same, however I tried to align them as much as possible without distortion. On the left, the
Yamaha MSP5 Studio Monitors, on the right the Celestion G12P-80 guitar speakers. You can see how the treble takes most of the dynamic range on the blue graph. The monitors’
delta stays in a ±2.5 dB range instead. This doesn’t mean that the product on the right is bad, just that it’s been tuned, for a particular instrument in this case; it will probably make your
guitar sound very “warm”. This is obviously a design choice by the manufacturer. You can’t do anything about it, other than buying a product that suits your needs.

That’s why studio monitors exist, to reproduce the source with the highest degree of fidelity.

Also, small speakers can have an excellent sound resolution. This means that the detail is there even at low volume levels. Professional audio is not louder
nor expensive like people usually think. It’s more accurate, and with accuracy you notice defects!

Bigger doesn’t necessarily mean better, but for bass going smaller comes with compromises and disadvantages. When I listen to music I’m not a bass lover,
but cars and particularly engines do have a lot of low frequency sounds, so choose your equipment wisely!

Pro tip: Always check the dimensions of the speakers you want to buy/use: they may be too big for the space at your disposal!

In the end, it doesn’t really matter what you mix on (to some extent). To be honest, you can use a hardware equalizer (for a pro reference, see the Behringer
DEQ2496) or a software EQ to compensate the natural tuning of your speakers, bringing them to a somewhat flat sound. This won’t improve their resolution
nor their power.

It’s important to learn which are the audio characteristics of your speakers. Exporting your audio mix and test it on various different systems before finalizing.
Test on your HiFi system, on your earbuds, on your headphones, on your car, etc. What’s important is creating as much as possible with what you can
afford. Do the best you can on what you have and build on it from there. Also, prioritize your investments. If you’re working with a crappy old computer, you
should probably get a new one before buying any other hardware. Take into consideration also buying a PCI-express audio card (even if nowadays
motherboards already have good built-in audio chipsets). Your PC is by far your most valuable asset, because without it you can’t create.

17
How do I know? I own two pairs of the Logitech LS11 speakers. I damped the screws of one couple with paper (you can use rubber too) on the holes inside, tightened them more, and it’s
slightly better than the other ones without dampening. You can also try putting some fiberglass inside too, to make them sound bigger. Spending a couple euros to modify them may be worth it.
18
Don’t even bother searching for the frequency response graphs of these products. They simply do not exist. What do you expect from something made in China?

381
8.2.6 – HEADPHONES (wip)
There’s a lot of confusion on this topic. People tend to generalize different devices with the generic term “headphones”, but that’s not always correct. Let this
guide make some light.

First of all,

AKG 240 mkII [used by Kunos devs too!! What a damn coincidence]

382
8.3 - THE PRINCIPLES OF VEHICLE SOUND SYNTHESIS
In-car noises come primarily from three separate sources: road/tire noises, wind, and engine/power train. Most of the inputs into our sound engine are
based on accurate vehicle dynamics simulation. For example the engine model uses RPM and torque values from an engine simulation. Without a good
physical simulation of the driving environment it would be impossible to create a realistic audio.

Most audio simulators use a sample-based synthesis approach, also known as a wave table approach. This technique uses a collection of sound samples
that are manipulated and/or mixed to simulate some sounds.

An integral part of our simulation is the use of graphs. The graphs are simply a lookup table that matches input values to output values. Points in between
defined points on the graph are linearly interpolated. The graph files are loaded at run-time; this allows us to change the characteristics of our audio without
rebuilding the sound engine.

8.3.1 – THE SURROUND SOUND AND ASSETTO CORSA

Assetto Corsa uses a 7.1 mix as baseline, and you will need to set it properly before you export from the FMOD Studio editor.

If you want to listen to your audio the best way possible, a 5.1 or a true 7.1 speaker setup will be the choice, because it will let you listen and control
completely your mix; for example, you can adjust the LFE (Low Frequency Effects) channel. Such surround technology can be expensive though, and it is
actually difficult to balance properly in a specific room (Fig. 7.18), so you’d have to learn a lot about how it works (which implies some calculations, and it
can sometimes be a challenge also for sound engineers).

Fig. 7.18 – Simulation of the acoustic pressure field in a room with a quadrophonic setup. Sound reflects all over the place, thus creating interference and distortion.

In most cases our audio sources will be stereo or even mono (usually being videos/samples from the net) even if you can record your sounds from the real
car with a mic, so a stereophonic setup will do the job fine, especially if you learn comparing your audio with the reference standard by Kunos, or with
popular sound mods, and you may be able to obtain even better results if you have good source material. A quadrophonic setup can be used too, but at this
point you may use only the front speakers.
The most important thing during the whole process will be our attention to detail for each sound.

Since most of the interior car noise is in the low frequency range, it is important to have a good low frequency response in any system used. A subwoofer
can come in handy here. This doesn’t mean boombox-like sound. It is important to properly set the equalization, delays and other relevant settings to insure
proper playback. A setup with good loudspeakers and a dedicated amplifier will be a huge step up for audio editing, so if you own HiFi equipment, keep it
ready for use at this point.

Headphones may be used too, but sincerely I prefer the old school approach with loudspeakers. The professional standard doesn’t force you to choose, it’s a
personal preference, but it’s recommended to check the sound you get on both.

8.3.2 – MEANS OF VEHICLE SOUND SIMULATION

In simulators as well as in computer games it is common to represent the sound from a vehicle engine by snippets of recorded sound played in a loop,
where the snippet recorded at a speed of revolution close to the current virtual engine speed of revolution is continuously chosen. While this is a perfectly
valid method for representing sound inside a vehicle, there are some limitations that may become problematic.

383
First, obtaining the sound snippets themselves is a challenge in itself since the recorded sound is relatively complex. A pure sine tone, which is as simple as
a sound can be, can be divided into snippets by identifying where the recorded sound wave is at its minima, so that the onset and offset of sound coincides
with the sound wave boundaries. As soon as the sound is becoming complex such natural boundaries are difficult if not impossible to identify (Fig.).

Fig. - Simple sine tone (left) compared to complex recorded sound snippet (right).

This means that the onset and offset of the sound will be audible as a repeating click. To hide such clicks the sound snippet needs to be slowly faded in and
out, and to avoid silent periods while the sound is being faded another copy of the same sound is started just before the previous has ended, thus cross-
fading between the two.

Second, if the properties of the simulated vehicle are changed, a corresponding change of engine sound requires a cumbersome repetition of the process of
identifying new sound snippets. When their amount is smaller, fewer physical properties that can be portrayed in the generated environment, due to lack of
variety.

8.3.3 - ENGINE SOUNDS (special thanks to Fonsecker and to SHR Modding, www.youtube.com)
Engine sounds are generally not as loud as road noises when driving, although you tend to notice engine sounds more, especially in sport cars which don’t
have any form of acoustic insulation. Engine noises also tend to be more interactive. In many instances the driver tends to use audio queues for deciding
when to change gears. It is important that our sound model performs fairly accurately, and that matches the vehicle that is being simulated. If the car you’re
driving a McLaren it should actually sound like a McLaren.

Do different cars have different sounds? Yes, but actually no.

Each propulsor has a typical tone that most of the times depends on the frequency of the pistons moving inside the engine block, and their number is a key
factor in determining what type of noise will be produced: we can group engines into these categories:

 Multiples of three
 Multiples of four

wip

How engine sounds can be made in FMOD

The engine sound synthesis mostly uses a wave table technique; Our samples are recorded at set RPM levels. During playback, the samples are cross-faded
depending on their own specific RPM level. In other words, if the current RPM level from the engine model is outputting 1650 RPM, samples taken at 1500,
and 2000 would be played at 70% and at 30% respectively. Each sound sample has its own chart that measures RPM input vs. sound output. The sum of
the engine outputs from each sample should sum to 100% while fading. Each individual sample would also be frequency shifted by a factor of:

Usually recordings are taken from the manifold and the exhaust. The manifold samples tend to contain more high frequency components, while the exhaust
sound tends to have more of a lower frequency sound. The mixture between manifold and engine sounds is done “by ear” for each cab in professional
simulators.

384
As we can see in the example schematic of Fig., a pure
tone (sine wave) using the pulse frequency can be
added (this is not present in original Kunos-standard
content, but it can help us improve our sound), we’ll
see why. The pulse frequency for a 4-cycle piston
engine is equal to:

= ∙
120
The amplitude of the pure tone is determined through
an RPM versus amplitude chart. The pure tone can be
used to give an additional tone where the mixture of
samples is found lacking. For instance some sound
sample sets have a lot of the low frequency sound cut
out. So for lower RPM levels a large pulse frequency
tone can be added in, and as RPM levels increase, the
pulse tone amplitude decreases.

To make the pure tone you can use the sample

generator in Audacity, or ETG (Expression Tone Generator). The latter is also useful if you want to make an engine sound from scratch, with mathematic
functions. An example of a low-rev sound made with ETG is in Fig..

Fig. – With this small software you can create any sound you want from basic trigonometric functions, like sin(x), cos(x) and tan(x). Try copying the formula shown here
and listening to it, that should be a really basic example of an interior engine sound.

You can change the duration of the samples. It is also possible to export the waves obtained with this software in the .wav format. It’s pretty easy to use if
you know the basics of mathematics.

Overall the pitch of the engine sound is affected only by the RPM level, while the amplitude shouldn’t. The amplitude of the engine is controlled by a
combination of throttle position and the torque output. Both the throttle position and engine torque are compared to a lookup tables for a multiplier. If the
torque output is not available a window function is used to filter the throttle position to prevent the amplitude from increasing too fast (not sure if this
happens in the Ac project).

8.3.4 - PASSING VEHICLE NOISES

Passing vehicles sounds are composed of three components: aerodynamics noises, engine/power train noises, and road noises. These sounds also have a
Doppler shift applied to them. Fortunately, FMOD has functionality for handling the Doppler Effect.

Assetto Corsa provides the speed, direction, and position of the listener and sound source and FMOD performs the necessary frequency adjustments.

For simplification, a much simpler model for the road and engine sounds is used. For the engine sound, each vehicle is given an engine sound and an
adjustment value for the engine volume. The engine samples are usually taken from vehicle exhaust and generally match the vehicle type. The amplitude of
the engine sound is adjusted using the speed of the vehicle.

Tire sounds are handled similar to engine sounds. A simple generic road sound is used for passing car sound. The volume of the road sound component is
adjusted by the size and speed of the vehicle (again, needs to be verified, however you can use directly the sounds already in the kunos Fmod project).

Aerodynamic sounds are adjusted for the speed and size of the vehicle. The speed for the wind sound is calculated as the relative speed of the vehicle from
the participant’s vehicle. A “sound cone” is used; it is a directional sound source supported by FMOD.

385
The programmer can specify a degree and width that the sound is projected from the sound source. The sound cone can be placed slightly ahead of the
passing car and projected towards it. This gives the effect of the interaction of the turbulent wave of the passing vehicle.

8.3.5 - WIND SOUNDS

Wind sounds come from aero-acoustic interaction of the vehicle with the atmosphere. In a typical passenger car, these sounds tend to be transmitted into
the cab from the windshield, passenger windows, and from the front A-pillar. Automotive designers tend to spend a lot of time trying to reduce the amount
of wind noise a car produces as well as ways to reduce how much of the noise is transmitted into the cab.

Automotive designers tend not only worry about the amount of noise that is produced, but also the harshness. A highly irregular wind noise that frequently
changes pitch and amplitude, caused by say buffeting, can cause a much greater level of annoyance to the driver than a noise with a consistent sound.

Aerodynamic sounds produced by automobiles are a very complicated subject. They are complicated fluid-dynamic events; as on-coming cars pass each
other their turbulent wakes interact. Modelling these systems in real-time would not be practical. Given these limitations, AC devs decided to use two
recorded samples of wind sound at different pressures for each car, taken at an unknown speed (for now). Look at Fig.

Fig..

Typically, recordings of in-car wind sounds are done within a wind tunnel. We don’t know if vanilla AC wind sounds come from one of those facilities.

We can also consider that a shotgun microphone pointed at the windshield or side windows during a real world drive with a passenger car could have been
used. The alternative, which is also the most plausible option within official sounds, is creating a reasonable sound with randomly generated noises.

For the random noise we can simply take a white noise generator
and apply a low-pass filter with at around 600Hz with the Q value
set at 1. The Q value affects the steepness of the roll-off slope.
The higher the Q value the steeper the slope. FMOD’s low-pass
filter supports Q values from 1 to 20. The frequency of the low
pass filter is gradually increased with speed of the vehicle, up to
a maximum of about 700Hz. Also a random value between -50 to
50 will be added to the low-pass filter at the rate of 120 Hz. This
randomization helps to simulate turbulence, and harshness.

The amplitude of the wind sound is increased at an exponential

rate with the speed of the vehicle. Through wind tunnel testing
with a typical passenger car, in-car wind sounds generally
increase by about 4db per 20 km/hr or approximately 12.5 mph.
Also a car traveling at 120 km/hr (74.5 mph) presents a sound
pressure level of around 73 db (A). Generally try to match that
value. Look at the graph in Fig. for the generic output of wind
sound generated by the audio engine, with the use of white noise.

The result should have the same tone of a brown noise. In audio engineering, electronics, physics, and many other fields, the color of noise or noise
spectrum refers to the power spectrum of a noise signal, produced by a stochastic process (a random function). Different colors of noise have significantly
different properties. Brown noise is not actually named after the color; the name comes from the fact that the signal mimics the “random walk” pattern
produced by Brownian motion, or the random movement of particles in liquid.

The practice of naming kinds of noise after colors started with white noise, a signal whose spectrum has equal power within any equal interval of
frequencies. The United States Federal Standard 1037C, titled “Telecommunications: Glossary of Telecommunication Terms”, defines white, pink, blue, and
black noise.

White noise:

White noise is a signal (or process), named by analogy to white light, with a flat frequency spectrum when plotted as a linear function of frequency (e.g., in Hz). In other
words, the signal has equal power in any band of a given bandwidth (power spectral density) when the bandwidth is measured in Hz. For example, with a white noise audio
signal, the range of frequencies between 40 Hz and 60 Hz contains the same amount of sound power as the range between 400 Hz and 420 Hz, since both intervals are 20 Hz
wide.

386
Brown noise:

3. Sound Recording Process

USEFUL TOOLS IN FMOD (WIP)

The loudness meter of FMOD. It can be used to check the audio levels.

(wip)

At this point you have two alternatives: make the soundbank almost from scratch, or copy it from a pre-existing car. We’ll consider both options.

8.6 – RECORDING SAMPLES

How to record audio from a car? I think there will surely be people interested about this, especially if the car mod being created is the owned vehicle. It’s just
easier sometimes to record samples if you already have it available every day, as too often the sources online don’t offer a decent enough quality (or they do
not have the specific sound you’re searching for at all).

8.6.1 – RECORDING DEVICES

We’re going to talk about recordings, acknowledging that there are various ways to do it, either with analog (tape/cassette) or digital devices, so we’ll take for
granted that after an analog recording you’ll have to use an A/D (analog-to-digital, also ADC) converter to obtain actual samples.

PCs have ADCs incorporated in the sound cards. If your machine has one, you will be able to connect your tape/cassette deck (or any other analog source)
and record from it with a program like Audacity.

Large desktop or office Windows machines typically come with a sound card integrated in the motherboard and connections such as coloured jacks.

Fig. -

- Green is generally stereo Line Out. High level stereo sound comes out of this jack and you can connect it to small stereo speakers, earbuds, stereo
headphones, or a lead to the "AUX IN" on your large stereo sound system, or larger amplified computer speakers.

- Blue is the next and it's usually stereo Line In. This is the connection that will accept sound from a high-level stereo sound device such as a stereo mixer,
cassette or reel-to-reel player, the analog connections of a USB turntable, the headphone output of an MP3 Player or even a CD or DVD player - portable or
not. Microphone preamps and guitar pickups fall into this group even though they're not stereo.

Both Line-In and Line-Out can be connected to other sound equipment with a stereo jumper cable or a stereo adapter cable or other adapters as needed.

- Pink is last and is usually Mic In. It's mono, not stereo, it carries special internal wiring and is designed to be sensitive to the very low level, delicate
signals coming from a microphone such as an analog headset.

387
If you plug something powerful and stereo intended for the blue jack into the pink jack, you can be missing the right channel of the stereo music and the left
channel has a good chance of being too loud, horribly distorted, crackly, popping or crunchy. There is no recovery. Because of the way microphone
connections work, you usually can't simply adjust your way out of trouble and there are no Audacity tools to repair the damage. You may never get the right
channel of music recorded at all.

It's common for Windows laptops to be missing the blue jack (Fig.).

Some laptops have a blue jack and some laptops have the ability to switch one jack between stereo and mono, but those are not common. Consult your
computer instructions. Another recent arrival is the "Mic Line-In." That's usually just another name for the pink Mic-In jack. Read your instructions.

You can artificially create a "blue jack" or high level stereo input with an external USB sound device such as the Behringer UCA-202.

if there’s at least one input (line/microphone) jack (Fig.), if you don’t have one you’ll need an audio card or a capture card (fig.).

To connect the PC to your sound system (if you have any) you can use a 3,5mm jack to RCA adapter (Fig.) and proper cables.

Fig. – Both work fine. I prefer the second one, as it gives me slightly more freedom of movement, and the jack is usually of a better quality.

8.6.2 – SOUND RECORDING PROCESS

Since the end product of any sound reproduction system can only be as good as the original recording19, emphasis has to be placed on creating the highest
quality samples possible.

The samples that would be required for the new system break down naturally into two main areas of interest: cab-specific sounds (such as engine and
power train) and external sounds (such as road noise, autonomous vehicles, and environmental audio). While the cab-specific recordings would be tailored
to specific vehicle types, external sounds would be generic recordings that could be used in any scenario.

The tendency is to use stereo miking, as close-miking in mono can result not only in an unnatural-sounding magnification of detail, but also in tonal
imbalances such as overly bright tones, sibilance, boominess.

8.6.3 – ENGINE SOUND

19
Don’t forget about the playback devices though! See paragraph 7.1.1.

388
Using two pairs of microphones and a portable digital recorder, samples can be taken at the exhaust pipe and engine manifold of specific target vehicles.
These two sample sets are combined at playback to create a realistic reproduction of engine noise.

Ideally, engine samples would be recorded using a vehicle mounted on a load cell dynamometer. A commercial dynamometer is not always available, so in
such a situation, all engine sounds have to be recorded using a stationary vehicle in neutral, with load to be induced artificially at playback.

RPM levels can be captured at 500 RPM intervals, from idle through max RPM, using two recording “nodes” (each comprising of a discrete left and right
channel) and a portable recorder.

At each recording node, a pair of matched microphones are set up in an ORTF configuration. ORTF combines the characteristics of volume difference
(provided as sound arrives on- and off-axis at two cardioid microphones spread to a 110 angle) with timing difference (provided as sound arrives at the two
microphones spaced 17 cm apart). Since the cardioid polar pattern of each microphone rejects off-axis sound, less of the ambient environmental
characteristics are picked up, thus creating an accurate representation of isolated sound in less-than-ideal surroundings.

Fig. - An Illustration of the ORTF stereo recording technique

Normally the mixing and mastering phases involve transferring all four channels via an AES/EBU link to an audio workstation. You will do it with your PC.
Using an off-the-shelf audio editing program, the left and right channels are combined and normalized into two sets of looped, stereo WAV files; one set for
manifold sounds and another set of corresponding exhaust sounds. As necessary, equalization is applied to compensate for anomalies.

Fig. 7. - The signal path for recording engine sounds.

8.6.4 – EXTERNAL SOUNDS

External sounds are very straightforward to record. Depending on the source and circumstance, multiple techniques can be used.

It is possible to record the large majority of environmental recordings (such as ambient sounds) with various omnidirectional microphones, since specific
positioning and orientation information were not required. Recorded channels are transferred to the DAW, where multiple channels are mixed, bounced
down to a single track, looped, normalized, and saved as a stereo 48 kHz WAV file.

Specific external sounds (such as tire/surface interaction, passing vehicles, etc) can be captured, again utilizing two KM 184 microphones in an ORTF
configuration to maintain a good stereo image. Similar to the recording of engine sounds, specific external audio is recorded on two discrete monaural
channels, looped (if necessary), normalized, and mixed into a single stereo 48 kHz WAV file.

8.7 – EXTRACTING AUDIO SAMPLES FROM A SOURCE (special thanks to Fonsecker)

8.8 - CREATE A CUSTOM VEHICLE SOUND WITH SAMPLES

FMOD is a sound engine that can greatly enhance the audio compartment of our simulator. It is also quite difficult and complicated to start with. That's why
the AC dev team has prepared and shared with the modding community a complete project with additional instructions on how to work.

389
The following paragraphs will explain how to build a sound bank, starting from the aforementioned example. The knowledge about the basic functions of
FMOD Studio is important, so it is recommended to read the official FMod Manual; however, the most important features for our job will be illustrated here
too for completeness.

8.8.1 - STARTING WITH FMOD

Use only FMOD 1.08.12, as recommended at the beginning of this manual. To be fair, it works with 1.08.13 too, but newer releases of the software lack
some plugins required by AC (Fig. 7.).

Fig. 7. – Plugins missing in newer Fmod releases (on the left).

If you don’t use the correct FMOD release, you may encounter an error (Fig. 6.2).

Fig. 6.2 – This error is due to the missing Distance Filter plugin (see Fig. 6.1).

Open the AC project file

wip

Setting the proper Project Platform:

Go in the “Edit” menu and select “Preferences”. Check that the “Desktop” platform is configured like the picture below:

390
8.8.2 – EVENTS AND PARAMETERS
FMod Studio works with Events and their Parameters. Some are mandatory for Assetto Corsa in order to make the sound bank work, some are optional and
depend of the car type. For example, a Lotus 98T (Fig.) has no doors, horn and so on, so the related Events can be omitted.

Fig. – The Lotus 98T as portrayed by AC.

The project example brought to you includes all the Events supported in AC, so you can make practice and experiment different methods to achieve the
same result.

The first thing to remember is that some Events work as "global", because they are common for every car, original and modded ones. In order to make the
sound set as much customizable as possible. Many events are car specific, such as the skid sound, brake whistle, wind and tyre rolling noise, transmission,
turbo, rev limiter, traction control and so on. Just as an example, you have the freedom to assign a different tyre squealing sample depending of the car.

There are several ways and techniques in FMod that allow you to achieve the same results; some are better, some are easier. It's up to you to find the way
that meets your tastes and needs, but above all, keep it simple!

In Fig., you can see all the global events made by Kunos’ sound designers.

The events are divided in three folders, for better reading and organization. Taking surfaces as an example, you can easily
understand that kerb, grass, extraturf and sand are global sounds that are applied to all the cars in the game, even the ones
made by 3rd party / modders.

The showrooms deserves a separate discussion: modders will be able to add their own soundtrack for a new showroom.
We'll see how to achieve this, at the end of this guideline.

IMPORTANT: Please take extreme care of the names syntax and folder structure, an error will make the game crash trying to
load the related sound bank.

Fig. -

The following table contains the whole list of Events, with related Parameters and short description. It is also indicated which Events are mandatory (required
by the audio engine to work). The other are optional.

391
 EVENT NAME EVENT DESCRIPTION EVENT PARAMETER PARAMETER DESCRIPTION RANGE MANDATORY
rpms engine rpms 0 .. as needed yes
throttle gas pedal position 0 .. 1 yes
engine_ext exterior engine sound
Distance (built-in) 0 .. as needed yes
Event cone angle (built-in) 0 .. 180 yes
rpms engine rpms 0.. as needed yes
engine_int interior engine sound
throttle gas pedal position 0 .. 1 yes
bodywork car body sound susp_travel_speed suspension travel speed 0 .. 1 yes
gear_ext exterior gearshift sound state down / up 0/1 yes
gear_int interior gearshift sound state down / up 0/1 yes
speed car speed 0 .. as needed yes
wind wind noise
air_pressure air pressure on the car 0.8 .. 1.5 yes
brake brake pedal position 0 .. 1 yes
wheel tire rolling noise speed car speed 0 .. as needed yes
inflation tyre inflation (puncture) 0 .. 1 yes
skid_int tire skid sound for gameplay views yes
skid_ext tire skid sound for track camera views (F3) yes
gear_grind sound when miss shift no
backfire_ext exterior backfire throttle gas pedal position 0 .. 1 no
backfire_int interior backfire throttle gas pedal position 0 .. 1 no
horn car horn no
door car doors state close / open 0/1 no
tractioncontrol_ext exterior TC sound decay no
tractioncontrol_int interior TC sound decay no
drivetrain_speed drivetrain speed 0 .. as needed no
transmission transmission sound
throttle gas pedal position 0 .. 1 no
boost boost (in bar) 0 .. as needed no
turbo turbo sound
bov blow off valve pressure 0 .. 1 no
limiter rev limiter sound decay no
Tab. X

FMod's built-in parameters are always optional and are well explained in the official FMod manual.

Sound emitters position

Each event in tab.X is related to an emitter with respect to the vehicle. It’s basically a “sound source”. In Fig., each emitter position related to the car is
described.

392
Fig. - The Tatuus FA01 is taken as example.

393
Before proceeding with the project, please define the engine position through the related parameter located in the data\sounds.ini script:
[ENGINE]

% ▲▼ 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.

The above is required in order to set the correct emitter position regarding the engine sounds. Important note about the “rear” engine emitter position: as
reported in Fig., it is located 0,5 meters ahead of the rear axle, in order to cover reasonably both cases of mid-engine and rear-engine vehicles.

8.8.3 – THE AC FMOD PROJECT

IMPORTANT!

Don’t modify the existing sound set example in the project, but create a new folder under “cars” event folder.

Right click on the “tatuusfa1” folder, select Duplicate and start your work on the new generated folder (Fig.).

Fig. – Pay attention to the name you give to your copy of the event folder. It must be identical to the mod’s FIN folder name we talked about in par. 1.2.

This will create different GUIDs.txt strings, so modders will not overwrite sounds each other as happened in old AC versions due to identical GUIDs strings.

Now let's start working on the FMOD Studio project. The example in the SDK provides the Tatuus FA01 project, with transmission and turbo noises
emphasized on purpose and with fictional backfires, so you can experiment all the events available in Assetto Corsa (exception made for the gear grinding,
as this car has a semi-automatic gearbox).

In the Event list there's a parent folder named cars (Fig.) that is mandatory in order to make the sound bank work once
built.

It is necessary that the car's events folder is equal to the car folder name located in Assetto Corsa/content/cars path.

For a better understanding, start from the interior engine samples. The operation is very easy: each sample is triggered
in the rpms parameter and needs an autopitch automation related to their own natural rpm reference. Volume between
engine load and coast is made by a throttle volume curve.

The other events basically work in the same way. Experiment with the provided example project, the operation is very
intuitive.

Do not edit priorities and polyphony of the events. Wrong settings could end in disappearing or stuttering sound.

Fig. -

394
The following picture (Fig.) shows how the engine_int event is structured. There are two tracks, named "fa01 load" and "fa01 coast". The first one contains
the sound samples when the gas pedal is pressed, the second one when the gas pedal is off.

Fig. –

(replace pics)

Pro tip: the interior engine volume for official cars usually peaks to -9dB in the output mixer (Mixer window). Exterior sounds are a little bit louder
(+1/1.5dB, depends of the car). In order to have a consistent behaviour between official and modded cars, please take this in account.

8.8.4 – BUILDING THE SOUND BANK

In order to make your project working in game, it is necessary to create and build a sound bank. The creation of a bank, as reported in the FMod manual, is
very simple: select all the events of your new car, open the context menu with right click, select "Assign to Bank", then "New Bank" and confirm (Fig.).

395
Fig. -

Remember that the bank must have the same name of the car folder.

In the Banks tab, the result will be like in Fig..

Fig. – FIX PICTURE

Then open the File menu and select "Export GUIDs...". The result file "GUIDs.txt" is located in the "Build" subfolder of the FMod project.

Now is time to build the sound bank: open the File menu (or right click on the related car bank in the “Banks” tab) and select "Build..." and the building
process will start.

The bank file will land in the "Build/Desktop" subfolder of the FMod project (Fig.).

Fig. – FIX PICTURE

Please note: a *.strings.bank file is also generated, but it is not needed unless you need to use the FMOD profiler in order to monitor channels.

8.8.5 - EDITING THE GUIDs

The generated “GUIDs.txt” contains ALL the events, the mixing groups and other settings of the FMOD project, but only the ones related to your car (plus
the “bus” lines) are needed.

Please open the file with a text editor and remove the unneeded lines. At the end, it should appear like in Fig..

396
Fig. – The lines are not folder names, they just refer to the events that a car generates. So AC loads the bank with the right filename, then uses GUIDs.txt to associate events with the
sounds in that bank. For example, a car named mazda_mx5 will play mazda_mx5/shift_up when it shifts. The GUID itself refers to the sound bank.

As you can see, all the lines related to “showroom”, “surfaces”, “collisions” and so on were removed because it is supposed that they are not modified by the
modder. Done that, please save the file.

Copy both files (the modified "GUIDs.txt" and "your_car.bank") in the related "sfx" folder of the car and check that the new sound works in game.

AC only loads sound banks that are in the folders of cars you use in the race session; if you only load two cars together then it'd be fine to share identical
GUIDs across them (eg. have mazda_mx5_s2/shift_up use the same GUID as mazda_mx5/shift_up), but then if you don't load the "base" version, you won't
get sounds. That’s why each car must have its own .bank file with the corresponding GUIDs.

8.8.6 – MIXER
Fmod's mixing is very powerful, but at the same time it can be painful as the project grows up and becomes complicated. Try to keep it as simple as
possible.

397
 The necessary Mixer Groups are already provided in the example project. Keep the original mixer structure for your audio
project, otherwise sound will not work in game. Don't remove any of the existing mixer groups and don't change their name.

Looking at Fig., it is straight-forward that you can change every single group volume by just selecting it and tweak the
related volume slider. This is very useful if your project contains multiple cars. According to this design, an interesting idea
is to distinguish wheel and wind noise between open and closed cockpit/wheels cars. Since the provided one is an open car,
its wind and wheel events volumes are managed in the appropriate mixer groups. If you are building a closed cockpit car,
you can assign its “wheel” and “wind” events to the proper “grp_wheel_closed” and “grp_wind_closed” mixing groups, in
order to manage both volumes separately.

Surfaces, showroom and other “common” events are out of any group (so they are in the "Master Group").

When you make your project, please double check that the events are routed in the right mixer group as reported in picture.
This is very important.

Fig. -

8.9 - USE AN EXISTING SOUND FROM ANOTHER VEHICLE

I mean, you really want to skip everything huh? I guess you don’t have much time, but if every car in AC had the same sound people would’ve complained a
lot, right? You should make a custom sound for your vehicle in the future. I’m not here to judge anybody though, so let’s get to it!

The whole process is pretty quick and easy. We’ll start in a completely vanilla way; using Content Manager everything will be even faster. Both methods are
included in this manual for completeness and because I can.

8.9.1 - FULLY VANILLA METHOD

This method is dedicated to people with vanilla AC, so no CM and mods. No special software is required; the MS Windows system tools will do the job fine.

The steps are:

1. Open the MS Windows File Explorer (there are many ways to copy files from a folder to another and the command prompt can be used too, but I think
that would just be an unnecessary complication).
2. Choose the car you want to take the soundbank from. You should pick a vehicle with a similar engine configuration. Keep in mind that official cars don’t
have some types of engines, like 8 cylinders (If this is false I will fucking kill myself), so you’ll have to do some compromises.
3. Open the GUIDs.txt file text editor and

8.9.2 - CONTENT MANAGER METHOD

This method is so quick you’ll be able to change 30 sounds in a minute if you want.

Be careful not to replace the sound of cars you wanted to leave untouched! Doing things too quickly can lead to errors, and you don’t want to reinstall
everything just because you accidentally overwritten your Porsche 911 Carrera Turbo sound by mistake.

8.10 – HOW TO INSTALL SOUND MODS FOR VEHICLES

398
CHAPTER 9 - RELEASING A MOD
If you think of sharing your mod with other people on the internet, please read CHAPTER 8 in its entirety. Knowledge doesn’t hurt, right?

9.1 - PACK YOUR FINAL MOD

At this point of your journey, you’ll need to archive your mod into a single file, ready to be uploaded and shared; you may have already packed the data
folder into the data.acd file (more info at chapter ), even though that’s not mandatory.

In order to do this, you can choose any software you like that creates and manages compressed files/folders; some are mentioned under THE TOOLS YOU
WILL NEED, see pag.; for our example below, we will use 7-zip.

These are the main steps:

1. Create a folder in your Documents (or where you’re comfortable the most on your PC) dedicated to your mod. In this example the path will be called Documents\YOUR
CAR ARCHIVE.
2. Make sure one last time that your vehicle works in the simulator. You can also check whether it’s compatible with vanilla AC or not, in case you used CSP features, by
disabling the patch temporarily. If it is not compatible, you should specify it afterwards in the README.txt file of step 7.
3. If the mod works, make a backup copy of the FIN folder (we talked about it at par. 1.2) anywhere you want. This is not mandatory but it’s a precaution due to the next step.
Actually, always backup your work often, you never know when you may lose your data. Prevention is the remedy to any issue.
4. Remove from the FIN folder any file that isn’t required as obsolete, considering your development history; this includes things you made in the past that you consider
wrong or simply outdated, like multiple versions of data files you have been working on, for example drivetrain.ini.old, tire_v75.lut.old, brakes.ini_v3.old,
old_neon_lights.ini, or unused textures and skins. This is also your last chance to fix (or hide???) any mistake you made. You can move the obsolete files in another path
if you want to keep them, but it must be located outside of the mod’s folder you want to share. This is basically a clean-up operation to reduce the final archive size to the
bare minimum.
5. Check again if the mod is still driving fine in Assetto Corsa.
6. Copy the FIN folder you just cleaned under the path mentioned in step 1; see Fig. 9.0, where we continue from our example at par. 1.2.

Fig. 9.0 – These are the contents of your definitive archive. You can choose any name you want for the folder in your documents, but keep things simple and recognizable.

7. You can add a README.txt file where you put the mod’s credits or other instructions (Fig. 9.0). It can be created with any of the suggested text editors.
8. If you want to add extras, for example manuals, brochures or other documents in the .PDF format, along with pictures, it is recommended to create an EXTRAS folder for
them (Fig. 9.0). This way you increase the size of the archive though. It is not advised to include extra files for a total bigger than 20MB.
9. Pack the entire folder in a compressed archive. If you have 7-zip installed with the File Explorer context menu, you can follow Fig. 9.1. If you don’t have the context menu
enabled, just open the software, navigate to the folder and click on Add. With other programs it’s almost identical.

Fig. 9.1 – If you choose Add to archive…, you will be asked few parameters (which you can leave to default) and you will be able to add a password or change the compression
method and the name of the archive before its creation. The other two options, highlighted in red, create the archive directly with the name of the folder. Choose the .ZIP format instead
of .7z if you want to offer more compatibility with other (and older) programs.

10. You obtained your archive. Share it anywhere you want.

11. If you want to be extra careful, you can test your mod on another system with an AC install (the PC of your colleague, brother, friend, etc.). Otherwise, you can ask people
if they want to be your beta testers. This part depends on whether you want to make your unfinished product public or not.

Many files can be left missing with tunes and custom versions of official content, where you already have the vanilla models, while only the data files have
been heavily edited or recreated from scratch (Fig. 9.2). This can be done in order to reduce the download size, and to avoid sharing official content illegally.

This may create some trouble for people who do not own all the DLCs, but this manual is for the Ultimate Edition of AC, and technically it’s an end-user
problem, so mod creators should ignore those people. Sharing official content is worse than trying to satisfy everyone’s requests, especially when the
majority of users has already got the full version of the simulator.
399
Fig. 9.2 – On the left is a customized version of a vehicle that was originally part of the official content. This kind of mod requires you to copy the 3D models from the original
Alfa Romeo 33 Stradale by Kunos in order to work. This is good because the models don’t have to be shared illegally online. However there are some things wrong: the
brand, the logo and the power curve (the car has a higher power spec but the graphs and the torque values are identical); the author credits are almost right, next time write
Kunos instead of ks.

400
9.2 - YOUR BOUNDARIES AS A MOD CREATOR
Thank you fellow reader for getting this far in my guide. The following paragraphs are here to clarify some of the mechanisms that trigger when you share
your mods with other people. I have done some research on what you will read, however take it critically.

9.2.1 – COPYRIGHT, LICENCES AND MODEL RIPPING (CONVERSIONS)

Let’s talk about game assets and copyright now. It may be interesting, as there are a few things you should keep in mind before releasing your mods to the
public.

According to the World Intellectual Property Organization (WIPO), intellectual property:

“…refers to creations of the mind, such as inventions; literary and artistic works; designs; and symbols, names, and images used in commerce."

It is a blanket term for a variety of assets created by the mind otherwise classified as intangible property. The rights to the intellectual property can be
claimed exclusively by the creator or recipient of ownership transfer and covers the expression of an idea rather than the idea itself.

Intellectual Property law includes ways to protect the creative expressions of the intellect that carry commercial and moral value. There are several types of
intellectual property including:

 Trademarks
 Patents
 Industrial designs
 Copyright

First, copyright is the protection extended to the creator of an original work. It provides the sole rights to the use and distribution of the work and normally
ends after a specific period of time. As the creator of your work, you have the right to control all the different ways it’s put out into the world – and a license
is simply the permission you give to another person to use your creations and to define the boundaries of how they may use your work.

Strictly speaking, permission is required anytime someone uses something you have created. Many of these licenses are informal- a friend asks to use a
picture on his website and you say okay; or implied- someone uses an image in an article about you and you make no objection. These informal agreements
or uses are okay because under copyright law, the rights holder is not obligated to act in every case of infringement, and failing to act does not jeopardize
the copyright holder’s status as the rights holder. Unlike other forms of intellectual property, copyright is not a “use it or lose it” right. Other licenses,
however, are very structured and tracked with written documentation.

On the other hand intellectual property is protected by laws specific to the expression of an idea. Copyright is the law specific to the expression of ideas in
visual or audio form. Unlike a trademark that indicates a specific item or design is protected, copyright covers a different expression of thought.

The term copyright contains within it the meaning of the term: the right to the copy. Copy is anything written, photographed, drawn, painted, or otherwise
produced as an audible, written, or visual piece of intellectual property.

You cannot compare copyright with intellectual property (Fig. 9.3); copyright is a form of intellectual property. Defending a copyright requires different
expertise from defending a trademark.

Fig. 9.3 – There’s a reason why different symbols exist. It’s because different types of intellectual property exist.

Back to Assetto Corsa: let’s consider that you started making your mod from zero.
In terms of the car’s 3d models and physics models; this is all your own work. Sim racers like to think they are driving the real car, only sucked into some
kind of TRON neon-retro-futuristic environment. This is not the case, you are driving a 3D thingy in a computed mathematical model.
401
Part of the simulation is made possible by the game engine, which “allows” mods to be added, part of it by the modder trying to replicate the car “feel” as
good as possible using often very vague reference data.

This, along with the building of the 3d model, is a lot of work, which is recognised by most intellectual property laws as the work of the artists and
considered 3D art, at least until you make an actual mod with OEM data and trademarks.

The licenses video game developers need to buy are for the use of logos and names, which are trademarks, and they need to get various permissions to
make tracks too. The vehicle physics are made with data that usually comes from the car manufacturers themselves. It’s not an easy thing at all for them. So
there aren’t licences in the game for your “artistic” 3D representation and for some “scattered” (pretty ironic here) config files defining the handling of your
vehicles, unless you actually pay the car manufacturers or Kunos buys your mod (which happened in the past a few times). The build process of vehicles is
not protected though, unless patented, and most automotive solutions are not patented but kept secret and as a patent expires the innovation ends up in the
public domain.

3D art is, well, art. An artist is free to make and sell his art, manage his copyright and rights, and profit, if it’s just a computer-generated model/render/image
of a car. And it can be a very good piece of art too (Fig. 9.4).

Fig. 9.4 - The comparison between 3D art and a complete mod. The main difference is that 3D art comes only with a model, or a picture, while a mod is able to work in the simulator,
and can be surrounded by OEM data files, depending on which sources the physics use.

3D Modelling is as valid as a profession as anything else, people pay good money for talented modellers – in other words it has value. The problems come
when you convert art into a mod for AC. Two completely different issues. So how to public your mod if there are copyright issues?

Every asset you create and share, unless you pay to have a licence for trademarks from the original authors and owners (we’re talking about car
manufacturers, body designers, sponsors etc.) and you made an explicit agreement with the game developers’ company (for Assetto Corsa: KUNOS
Simulazioni Srl), has to be considered under the Fair Use terms (unless otherwise specified) if the purpose of making it available to the public is any of the
following: education, criticism, commentary, scholarship, research, reportage, review, satire and parody.

Fair use is the worst part of copyright law due to its terrible vagueness. For those who don't know - Fair Use allows certain uses or the edit of copyrighted
work without permission of the copyright owner for purposes deemed "Socially Beneficial". The nature of the work, the amount and substantiality of the work
can weigh in as well. Then there's the impact on the commercial value of the work. Please search and read the Section 107 of the US Copyright Act about
Fair Use, and the DMCA laws (or the laws currently active in your country) in order to avoid complications. In addition to the above, other factors may also
be considered by a court in weighing a fair use question, depending upon the circumstances. Courts evaluate fair use claims on a case-by-case basis, and
the outcome of any given case depends on a fact-specific inquiry.

So just because a mod is scratch made it doesn't mean it is legal.

If you created a car mod from scratch, don’t expect to be able to sell it in a legal way if you don’t have any licence for trademarks and logos, unless you are
under the terms of Fair Use, or otherwise specified (yeah, Fair Use doesn’t force you to release your contents for free, but this happens for rare, very specific
cases, and depends on many factors decided in court, so don’t take it as granted). Most of the times a non-licenced, fully working mod should be free of
charge, and having to pay for such assets is unfair for the final user (which finds himself in possession of the so-called “grey area” assets, that means not
properly regulated).

Things like what you see in Fig. 9.5 are not valid by any means.

402
Fig. 9.5 - Aside from grammar errors this didn’t age well. You do not own any rights on Kunos’ assets nor those from any other game. Ignore the statements that some modders put in
their credits. You don’t need any permission from them, unless they have the authorizations and licences from the real-world owners, which is not the case here. Obviously NEVER pay
for things like these, if they are priced; you should not be forced to join any Discord server either, especially if you don’t trust it 20.

The model will never be completely “yours” because it cannot be separated from the brand's intellectual property it depicts, unless it consists of your own
interpretation of a specific vehicle design and thus it can be considered 3D art (or, yeah, you guessed it, otherwise specified); this implies the removal of any
trademarked logos and brands (Fig. 9.6). Sharing it with official logos on web outside the Fair Use rules/context without trademark licences is illegal. Do car
manufacturers have the time and the energy to stop you from doing it? Most likely not, as the Internet is a place “where everything ends lost in time and
space”, but this is not a reason to break the law. You may receive a letter of cease and desist from Porsche though.

Fig. 9.6 - The differences between the real vehicle, the game developers’ work and the modders’ work.

You may be asking: how can you bring back the official logos on an unbranded mod? You use skins (Fig. 9.7). But separately from your product, and it’s
better if someone else does it on your behalf. Keep in mind that we’re still talking about scratch-made and authorized content.

Fig. 9.7 - How skins can be used to bring real manufacturer logos to an unbranded mod. https://www.racedepartment.com/downloads/pessio-garage-scorpion-1000-tc-gr-5-real-factory-skins.34310

In addition, when a developer brings your model into a game licenced by the car manufacturer without paying you the rights, he has all the rights to do it, if
your model was not legally protected. It might be morally wrong for the modder who put the real effort, but it’s legal (this depends on many factors though).
This already happened with AC mods, be aware of it, because again, if you plan to make an un-licensed mod of a racing car, instantly recognizable due to
shape/design, with branding from third-party companies (also un-licensed), un-licensed logos, and sound (where do you get the sound from? You may ‘rip’
it from a copyrighted source), you can’t go anywhere outside the Fair Use terms if you don’t have a licence (except for the application of a different
legislation).

20
Discord is actually a dangerous social platform, and you should think twice before joining it. If you’re not careful, you can be doxxed (private info leaked), blackmailed, swatted (police called on
you for no reason), and there are a lot of other crimes committed by malicious users. Being full of underage people, generally I prefer avoiding Discord and its chats altogether. As usual, stay safe.

403
If you do have a licence agreement with a real brand though and copyrighted your work, making something for free doesn't equal to "anyone can take it and
use it as they please". If someone takes your copyrighted assets and reposts them without asking, or sells them as his own, they’re violating your rights and
the intellectual property of the brand.

If you designed and licenced/copyrighted your own car instead and a game/software company uses it in their game without your permission, that would
constitute intellectual property and copyright infringement.

The problem with conversions: you didn’t make the assets, so you may be violating the copyright, plus if you don’t have any trademark licence
to distribute them after you’ve edited them you may be violating intellectual property too.
You’re basically taking (ripping) 3d models from other games or sources to bring them into Assetto Corsa.

Then you have “doubled” the trouble:

1. To avoid damaging intellectual property, you need to pay (and a lot) to get a licence from the car manufacturer(s), unless you keep your content under
the requirements of Fair Use (or any similar legislation you must observe in your country).
2. To avoid damaging the copyright owner(s) (the developers of the game you ripped assets from, or the 3D artists of the model you got from another
source), you still need to ask for permission before you can edit and redistribute the assets. Editing doesn’t make them yours and even owning a copy
of the game you took them from does not give you the right to share them, unless under Fair Use purposes\context (however this may change due to
various factors, for example the quantity of content you copied).

If the author of the mod you’re editing doesn’t have the licences too, but he’s under the Fair Use (or similar legislation) terms\context, mentioning him is
morally the least you can do to appreciate his work (unless he’s breaking laws).

Taking all of this into consideration, if the intent of sharing the assets is non-commercial, educational, and involves only a few assets, but not the entirety of
the game is shared, it's likely Fair Use as it does serve a beneficial purpose to the public without significantly impacting the value of the source material.
Selling copies on the other hand, that's just wrong. Just to be clear however, there is no formula to ensure that a predetermined percentage or amount of a
work may be used without permission.

Ripping the assets from a game is much like opening a toy to get a look at how it works, if you just do it for non-commercial purposes.
Downloading/exporting a file in order to fiddle around with it in 3DsMax or Blender is completely legal, as it could easily be explained as "for use in
educational purposes". A teacher can even demonstrate to a class how models are made.

Fair use allows you to use the works from a game in the ways mentioned above, and if you can make a serious case in any one of those areas then you are
fine, but if not then you should just attempt to get a permission\licence (and it’s not always possible).

Ripping game assets for your own personal use is considered fair use, redistributing outside of a Fair Use context definitely isn’t. While one person may use
the model for educational purposes, you cannot distribute the model to the open public due to the fact that you cannot possibly guarantee that it will be used
for educational purposes only.

What about roads?

All the concepts explained in the previous pages are valid for maps too! You need a permission to create a legal model of a racing circuit. Many tracks are
owned by private associations, while game assets are fictional but still property of the respective authors.

There are some track mods that have been authorized from the authors, for example the conversion to AC of the Blackwood circuit models from Live For
Speed has been allowed by the LFS development team (Fig. 9.8).

Fig. 9.8 - Peace is always an option, sadly it’s rare to be found.

404
The conclusions:
As the author. Whenever you’re making a mod, and you share it, do it at your own risk and accept any consequence of your actions, unless you adopt\get
legal protection for your content, or rely on third parties to protect it. Complaining that your rights have been violated afterwards is futile if you release your
mods under Fair Use terms (or similar legislations), because in this case you generally can’t make any profit and the damage you receive is only moral.

As the final user. Always check if modders are providing trademarked / copyrighted / patented / authorized-by-the-original-owners content, and if the
permits and licences are not clearly written, never pay; they may be non-licenced mods, an those are just a fraud. Keep in mind that the vast majority of
mods for Assetto Corsa are not licenced and legalized. Without a licence or a written permission from the original owners (if models are ripped or converted,
the car designers/manufacturers and the 3d artists), the mod author(s) should not be allowed to sell anything, and if they do, it’s illegal. Also, never
encourage people who use content from others without giving them any credit, it is proof of a poor moral conduct. NEVER BUY ANYTHING FROM SUCH
INDIVIDUALS!!!

Mods should not be more expensive than the base game, whose price is most of the times very low nowadays. A mod is just a small fraction of the entire
software. If mods are overpriced, never buy them, as there are no regulations on the current market and every creator sets his own fair or unfair prices. Do
your calculations then. In the end the money is yours, so look at the price of AC, then look back at the price of the mod you want. Compare them. Is it really
worth that much when it's only a small part of the game? Think about it. Try getting it from free if you understand or come to know that it's a non-licenced
mod. You won't be committing a crime with respects to the mod author. You will probably commit a crime against the original owners of the content, but
you’re only the final user, what can they do about it? It doesn’t have any sense to pursuit the end user.

DISCLAIMER: Do not take anything written above as legal advice, ask a lawyer if you need it; if you require legal advice on a copyright issue, make sure the
attorney you select understands your particular needs. Just because someone is a patent lawyer does not mean he or she can knowledgeably defend your
copyright.

9.2.2 – DISCRIMINATION OF CONTENT CREATORS

In any community individuals tend to discriminate each other, based on differences in wealth, abilities and health.

The Assetto Corsa community is not different from any other association of people: some modders and groups are appreciated, some aren’t.

Usually the factor that plays a major role in determining if you’re a “good” or a “bad” author is seen by others in your abilities, and the logic is pretty obvious:
you make good mods, you’re loved, you make bad mods, you’re hated. Just to be clear, we are not talking about people that commit frauds here.

Obviously there always are subjects who unconditionally love or hate someone, just for fun. Discrimination is also due to reasons of sympathy/antipathy,
lack of confidence and self-esteem. It happens everywhere after all, and humans will always be humans. There’s very little me and you can do about it.

Ostracizations can occur, too. Some groups and associations can ban or exile members, given fair or unfair and logic or illogic reasons. Often emotions are
crucial for success in a creator’s career. This is because after all modding is most of the time a hobby, and when people judge your work, whether in a
positive or a negative way, you are always touched in the feels, even if you think you’re insensitive. It gets even worse if you’re making mods as a job, and
the opinion of the public becomes heavier, stressful and overwhelming. Defamation can be really damaging in this case.

We are not invincible, made of steel; our mind cannot protect ourselves forever from the damage that comes with the environment around us. Similarly to
our skin, our brain is like a sponge. Our subconscious is always active and filters everything. There is always something lingering in our thoughts, unless we
are in a condition of apathy. All kinds of things happen to your identity when you expose it to others. Men shape each other.

Discrimination can be really hurting, however don’t take it personally too often, do it only when it’s necessary. If you’re not very skilled, be open to
suggestions and criticism, but not to the point where people actually damage your individuality, because respect is an important part of being in public. It is
the medium that allows every social interaction to happen in a civil way.

You may feel bad at the beginning: you can accept criticism, but if you perceive that there’s an abuse in your respects, return it to sender. One's freedom
ends where another's begins, and the public must learn to have some mercy and let individuals improve themselves. Everyone deserves a second chance.

I wouldn’t care about being banned from a community if you defended your dignity against disrespectful subjects. For you that association has harmful and
negative individuals inside; it means that it’s unhealthy and you shouldn’t waste your time there. Move on and keep pushing your projects on some other
place that deserves your attention and dedication.

If, with time, you become a well-known author, try being humble and don’t look at others from top to bottom. This will open the doors for a proactive
climate.

In any case no one should arrogate the right to condemn or glorify your skills as a modder. Yeah, it goes both ways. This is wrong especially if you start
making a list of who’s the hero and who’s the villain (Fig. 9.9). Often people don’t realise that discriminating they’re not only hurting you, but also themselves.
Why, you may be asking. The answer is that they’re blocking the progress of an individual, and that individual is part of the community, so in the end that
whole, collective entity is slowed down. Also, not to be sexist, but modders in the gaming world are mostly males, and generally males are highly
competitive when positively stimulated. Ambition pushes a man beyond his boundaries. Thus, the observation here is that the negative influence of one
person is more powerful than you may think, considering that psychologically we tend to remember more intensely our sad, hurting or anger experiences.

405
Fig. 9.9 - I analysed a bit this webpage. My conclusions may seem fussy but you have to look at this as an example of a merciless and disrespectful behaviour from
“modders” to modders. The AC community is not roses and flowers, and this shall make you understand it.

My suggestion is: if you want to preserve yourself, avoid the public, and avoid other creators. If you’re a sensible person and you don’t want to be judged,
it’s better if you keep your mods to yourself. People can be aggressive, depressing and hard on you for no reason at times. Trust me.

406
9.2.3 - ABOUT VANILLA ENCRYPTION
People often tend to ignore or forget the origins of the Assetto Corsa modding world. Things weren’t supposed to be free and open as they’re today. The
main proof of this is in the simulator’s assets. They’re encrypted formats.

There are two categories of files that are encrypted within the assets regarding vehicles in the Assetto Corsa folders:

 Models, consisting of .kn5 files (this is valid also for tracks)

 Car data, consisting of .acd files (the extension stands for Assetto Corsa Data, if it wasn’t obvious)

Why do we usually say that we’re “unpacking” files? Well, it’s just a nice and “foggy” way to say that you’re decrypting something. Obviously for development
and educational purposes, never forget this part (do you feel the irony?).

I believe that the original plan of Kunos developers was to explain modders how to make autonomously their data files (which already happened), while
keeping the official content secluded and protected from modifications and theft of licenced information.

During 2013 you could get permanently banned in the official forum just for mentioning the editing of licensed AC files. Only a few people had the
possibility to decrypt such assets, and they were smart enough to not mention it often, and not even consider uploading anything property of Kunos without
permission. The problem is that someone managed to “crack open” the official encryption of the models and released a python code for it (Fig. 9.10).

Fig. 9.10 - Look at the date. I bet someone still has that little tool (obsolete anyways).

Anyway I'm sure there is no encryption that can't be cracked open, so it would’ve happened sooner or later.

Meanwhile, regarding vehicle physics, modders weren’t showing contents of the ACD files, they were re-encrypting the data so that it was no more
accessible than the original, thus not revealing and compromising anything, following the suggestions from the staff (Fig. 9.11).

Fig. 9.11 – A post by Aristotelis Vasilakos (Kunos development team) about the decryption of data of the official vehicles.

By the end of 2013 and during the whole 2014 however, as the general public started to access the files inside the ACDs due to leaks, it became too late for
Kunos to repair the damage, even after blocking users (Fig. 9.12). Changing the encryption wouldn’t have helped when the data had already been exposed.

Fig. 9.12 – How Kunos responded to the editing of official files.

Not to mention the conversions of models from other games and third-party sources.

It was necessary to put a remedy to the situation, at least on the official forum.
407
You see, Italian laws specify that on a moderated and private (i.e. needs account registration) forum, the owners are co-responsible for the content of the
posts of the forum users. The Kunos team has its base on an amazing country, famous for its culture, art, nature and... food. But at the same time also
famous for its bureaucracy, complex law system and confusing law decisions. So when they get complaints from other big titles about converted material in
their forums, or when they see illegal mods in their forums, or when they’re asked to make the referee between mod teams wars, stolen material, personal
issues and such, then it is time for them to take action.

It's not a matter to simply moderate, because even if they had the time to do it (which they didn't have), they would have been still in a very grey area that
couldn't always be dealt with. So due to some community members’ behaviour and legal uncertainty, they decided to close the subforums where people
could post almost freely their content, in order to avoid illegal content to be posted there (Fig. 9.13).

Fig. 9.13 – Explanation from the KS dev team of their decision.

Also, quoting a post by Stefano Casillo:

“There was a basic misunderstanding about the role and the meaning of the "3D Models" and "Tracks" subsections of the modding forum. This is mainly a support forum and
not a community forum. It is supposed to be a place where people interested in either fixing a problem with AC, or doing something with AC come to find information. Sadly
those forums turned into showcases of stuff instead of places to ask questions regarding mods, it was simply not the intended use of a tool that we wanted to offer. In the
future we'll either re open those forums or open new ones with the clear intent of offering support to those with questions regarding modding and not as an artist showcase. I
understand the decision will make some people happy, and I am totally fine letting you vent your disappointment in this thread (as long you are able to keep it civilized)... but
I am pretty sure your lives will be fine just as they were fine before AC came out. People wanting to showcase their works will have to find another place on the internet,
luckily, there are very good candidates available... I am confident the new support forum for modding will remain a great reference for those looking to create content or AC. I
apologize for the abrupt decision, but it was one of those things that it was going to hurt more the more it was going to be allowed to go on, this is a learning process for us
and we're always trying to do what we think is the best for the project. Tutorials and relevant info threads WILL NOT BE DELETED. That is the ENTIRE point of having those
forums. If somebody thinks this decision will want to make them stop using AC then good luck to them for their future endeavors, it was a great pleasure to have you here.”

The way I see it is this: the official forum is owned by Kunos, and tied to Assetto Corsa and to KS as a company, therefore KS is responsible for what is
posted and hosted there and can also be held legally accountable for it, i.e., hate speech or illegal content. That's why there are rules against those things.

A month later, on the 26th Aug 2016, AC would have been released for Play Station 4 and Xbox One in Europe. Modding continued on other places.
Unregulated and unrestrained. But this time the KS team was free from its chain.

After all, outside of their official forum, lawyers can’t blame them for what people are doing. AC kept having encrypted files to make checksums work for the
online multiplayer (to prevent cheaters), and to protect the licenced data (even if that effort had already become pointless).

Editing copyrighted data is still wrong to this day. Luckily websites like RaceDepartment check if you’re using ripped models or physics for your mods.

In the end we have to thank Stereo for his little leak. I think that AC wouldn’t have gotten so far without him (and some other people that won’t be mentioned
here). Back then the CSP mod and tools like CM didn’t exist. Modding was really harder and not intuitive at all.

9.2.4 - THE SITUATION WITH CSP NOWADAYS: THE UNOFFICIAL ENCRYPTION

Custom Shaders Patch can encrypt too. Models with unofficial encryption work only in Assetto Corsa with CSP installed, or, optionally, with the Custom
Showrooms of Content Manager.

The comparison between how unofficially encrypted models look in vanilla vs AC modded with CSP is in Fig. 9.14.

Fig. 9.14 – That’s a huge difference. An unofficially encrypted model, on the right displayed with vanilla AC, on the left with CSP. The meshes are “crystallised” because AC cannot deal
with the unofficial encryption.

408
The CSP unofficial encryption has been made by modders to control people, aka other modders. This creates loads of problems.

Keep in mind that at the beginning of AC the modding procedures were somehow “legal” and “moral” because they were officially created, controlled and
limited by the software developers, who were keeping the patented and copyrighted files encrypted. You could only create your files, or at least copy the
given generic project examples and templates. That’s why the data folder exists, to let modders mess with physics without interfering with protected content
(.acd files). The same principle was applied to 3D models (.kn5 files).

The information about how scripts work was taught, not leaked. At least that was the plan. There was a sort of principle of authority. Kunos ruled.
Nevertheless, today anyone can edit protected AC vehicle and track files (for development purposes, obviously…?).

Considering AC mods, Kunos is not an active intermediary anymore, since they’re working on ACC. This doesn’t mean that they disappeared. They’re
passive but still exist. As a consequence, everything that claims to take the place of the developers is to be considered illegal or immoral, as not regulated by
any law. The new encryption brought by CSP has not been allowed explicitly by Kunos (any agreement about it does not exist), nor has a legal value or a
tangible impact on the assets, due to its unknown and unclear strength and entity. It cannot be classified as a preventive measure, as the assets themselves
can be retrieved anyway, with methods that differ from the canonical AC modding practices. And a single private citizen (the creator of CSP) can decrypt the
mods anytime, because he owns all the encryption keys, and having created it he knows perfectly how it works. This unofficial encryption is not a process
performed in Kunos’ interest, so what is it? I will let your imagination run free.

We don’t know the true reason why it was introduced, but we can look at the consequences it brought.

1. It makes mod authors believe that their mods are “protected” from editing, when the truth is that they aren’t. The hypocrisy is that most of the times said authors do not
own any rights on the assets themselves (see par. 8.2.1), but for whatever reason they think they’re defending “their” copyright; we aren’t talking about scratch-made
content, we’re talking about fully working mods with ripped models and OEM data. The amount of work inherent in the process of a conversion is minimal. There is no
reason to consider the mod an original work when the only thing that has been done is to follow the rules for correct physics (config files, LUTs, ...) and models (e.g.
shaders, textures, etc.). There is not an imagination or originality input from the modder. It is a mere process of copying. So there is not even a moral reason to lock such
contents.
With scratch-made content the deal is different, but it’s still not really justified. Locking assets based only on the fact that you put your effort is a backwards logic, because
you can always learn from people, both in positive and in negative. If you’re in doubt I suggest to not release anything, it’s always the best choice for that case.
2. Other modders cannot edit assets easily. This puts a limit on the modding community. But with skills and time it is possible. It’s just a laziness problem, often caused by
the hope of finding a better mod to replace the unofficially encrypted one. Anybody can still get the original models with textures using certain tools to directly intercept
data from the GPU (but don’t worry, there are also other transversal ways). If you’re encrypting someone else’s content without permission, the original authors might get a
decryption software for “your” ripped models and do whatever they want with them.
3. Players, the end users, cannot customize their mods with little and simple edits, an example is creating skins.
4. Often encryption is used to hide bad mods. I’d say this happens 99.9% of the time. Thus you can’t even fix them. People that make good mods do usually show off their
work instead of locking it, this way people know that they’re capable of delivering good content and everyone will get back to them for more.
5. Strange enough, CSP itself offers some workarounds to edit unofficially encrypted mods. This is inherently contradictory. (check)

Now, there are different versions of the CSP model encryption: V1, V2 and V3.

When everyone commits a crime, it becomes a legal activity. Only that’s not true.

Do not support or endorse the work of modders who lock contents with the UNOFFICIAL, unauthorized encryption brought by CSP, in particular assets
consisting of RIPPED / CONVERTED content from licenced and copyrighted sources (third-party authors or game devs). Do not pay for such mods!

Unless the aforementioned authors prove that they have a valid licence for their content, they’re wrong while saying that you’re not allowed to edit their mods
(Fig.). You’re allowed to do anything you can (within the laws in your country) with their content if it’s not licenced or copyrighted by them (and most AC
mods aren’t).

Just the fact that mods with encryption don’t work in vanilla AC (Fig.) should allow you to edit them. But this last sentence is just my opinion.

WTBC? Why The Blue Crystals? CSP and Reshade do very similar things to the game, alter or replace its shaders. CSP can deal with
encryption, Reshade can’t, that’s why the weird blue crystals on the model.

409
CHAPTER 10 - CAR MODS FROM THE COMMUNITY
You probably know that thousands of vehicle mods are available for Assetto Corsa.

You can download them online from websites & forums; that’s the easy part, you still have to install them to be able to drive them in the simulator, and that’s
even easier! We can also talk about how you can edit mods from other authors, so there’s plenty of things you can learn here.

10.1 - HOW TO INSTALL CARS

If you read CHAPTER 8, you may be aware that mods are packed in a compressed archive, so you just have to extract the contents inside it with the tools
mentioned at the beginning of this manual.

Let’s look at the whole process then, working with 7-Zip (granted that you already installed this or a similar tool on your PC).

After you downloaded your car mod, you have different ways to install it:

A. FASTEST: Click on the file in the Downloads tab of your browser and the archive will open automatically in 7-Zip; select only the main car folder (you
can recognize it because it’s the FINAL folder, page), then drag and drop it in one of the following paths (which you will have to open in a File Explorer
window), depending on the type of AC installation you have:
- STEAM default: C:\Program Files (x86)\Steam\steamapps\common\assettocorsa\content\cars
- STEAM default if you installed AC in a different (secondary) drive: [Drive letter]:\SteamLibrary\steamapps\common\assettocorsa\content\cars.
- STEAM custom: You changed the path during the AC install process. To locate it use the method shown in par. 2.2 of the AC User Guide (pag.).
- Pirated version: Locate the respective assettocorsa main folder (may be named Assetto Corsa) and extract the mod under ~root\content\cars; if you
don’t remember where it is, right click on the AC icon you should have on your desktop and select “Open file path”.
B. PRECISE: Click on the “Show in folder” menu/drop-down menu/icon next to the downloaded file in your browser. Your downloads folder will pop up
and you will be able to open the archive from there. Then in 7-Zip, click on the Extract button and change the destination folder to one of the paths in
option A. Otherwise directly open your downloads folder, and do the same.
If you enabled 7-Zip integration with MS-Windows drop-down menus, you can also right-click on the file and select 7-Zip > Extract the files… >
choose the path.
Why is option B precise? Because dragging & dropping files can be glitchy and buggy, especially when rushing things. I know from personal
experience. You may find your files inside the wrong folders if you’re not careful.
C. SECURE: Same as B, but before opening or extracting the archive, scan it with your anti-virus software of choice.

Sometimes authors put in their package manuals and other kinds of stuff. Don’t copy those files in your AC assets, if you want to keep them just create a
special folder in your documents. In some case however, cars come with custom driver models, fonts and shaders, so you need to copy those (unless you
already have them). Be curious and look at what’s inside each folder. That’s the spirit.

Do not install mods automatically with Content Manager. It has an auto-install feature but it’s often buggy. You will avoid mistakes and errors with the
methods recommended here (A, B and C).

10.2 - HOW TO UPDATE CAR MODS

You re-download the new version of the mod, delete the old mod version from your AC folder and copy the new one in. Overwriting files is generally not
recommended, especially for cars and tracks.

10.3 - HOW TO EDIT CARS

The basic principle around editing is that you aren’t the original creator of the mod. You want to obtain a custom or a better product for either yourself or the
community. Remember, always give credit to the authors of the assets you’re modifying.

You can use some tools to edit cars in either destructive or non-destructive ways.

10.2.1 – EDITING MODELS

Our goal here is to be able to alter the visual part of the vehicle. This includes changing the geometry, swapping parts, changing textures and editing
shaders. (WIP)

METHOD 1:

Use the QuickBMS tool (currently 0.11 release). It doesn’t require CM and CSP, as it is a small standalone software.

410
Fig. – 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 script (assetto_corsa.bms), required specifically for AC models, 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 and quick, after extracting the tool’s package in any folder you like:

1. Double-click on quickbms.exe;
2. Select the script for the type of archive you want to extract/decrypt, in our case assetto_corsa.bms;
3. Select the input archive or multiple files, so at this point you will select the model in the mod’s folder.
4. Select the output folder where the files will be extracted. This time you will have to create the data folder from File Explorer.
5. Watch the progress status of the extraction and the final message.
6. 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.

With QuickBMS you cannot rebuild the .kn5 model from a .fbx file.

METHOD 2:

Use CM.

10.2.2 – EDITING DATA

WIP

411
10.3 - HOW TO TAKE NICE SCREENSHOTS
Yeah, you will probably have some fun in the community posting pictures of your favourite mods. This has almost become an art, anyway in the next pages
let’s talk about how to improve your skills for a nice composition of your shots.

Let's look at a bad example first (Fig.).

Fig. – An image taken with really low to none effort.

This is mainly what's wrong with it (prioritizing the most important things):

1. Really dull composition; I'll be talking more about this later.

2. Overused Bokeh, you may call it aesthetic, but it's actually just bad.
3. The graphics look weird and low-quality in general.
4. You can see that there's no AO (Ambient Occlusion) on the radiator. It seems lit from upside down.
5. There is no motion blur at all but the car is actually moving.

Below there are a couple other examples (Fig.).

Fig. – On the left the scene is too dark, you can’t see anything. On the right you lose the sense of depth: everything is compressed on the screen, and the exposure is wrong.

So, how do we start making passable (and possibly nice) screenshots?

The basics:

1. Use CM (Content Manager) to work with AC; you can find more info under THE TOOLS YOU NEED, at the beginning of this manual. Please do not skip
this passage, as this launcher is a lot better than the original Kunos launcher. Chances are if you play AC frequently, you already have it.
2. Some stock game settings need to be changed. Press the Settings button on the top right corner. Then press Assetto Corsa and System tab. In here,
you should enable Allow Free Camera and disable Orbit mode for F5 camera.
3. Download CSP from CM, try the newest first. Do not skip this as you will need it.
412
4. There are many graphical settings for CSP. I suggest you just get a preset that takes care of everything. I'll be talking more about this in a bit.
5. Install a graphical mod called Sol. It is an excellent thing, and you'll need this too, as it brings custom weather with new beautiful skyboxes. Download
it here: https://www.racedepartment.com/downloads/sol.24914
6. Get PP Filters (Post-Processing Filters). They are like photo filters that run in real-time and drastically alter your scene’s look. Stock Kunos PP Filters
are old and won't do the best job. Just search online; you can also make one by yourself if you’re curious enough. You can view filters in CM too,
under Content > Miscellaneous > PP Filters. The folder containing all the stock AC PP filters is under %root%\assettocorsa\system\cfg\ppfilters. This is
also where you will install new ones you download from the web.
7. DO NOT use showrooms for your screenshots. This is because showrooms do not have CSP implementation and everything is wrong. For example,
refractions. Just take your pictures in a race session.
8. DO NOT use Assetto Corsa’s stock photo mode (the one available during replays). Instead, use the Photo Mode app from CSP.
9. If you want to share your screens on social platforms like Discord, better change their format to PNG, as Discord will not load heavy JPGs.

What you do during a session:

Simply drive; while you can take a screenshot any time, I recommended you take pictures in the replay screen so you have better control of the scene.
Travel a bit and pause the game, then hit the replay button.

There are two camera modes that you should use, F5 cam and F7 cam. F5 cam tracks the car, so it can be used for rolling shots. If you want you can also
use another app called BoxCam, made by Stereo, which has a different tracking behaviour, which you can also adjust. You can get it here: asdgfasdfhdasfhj

F7 cam does not track the car, so you cannot use it for rolling shots, but you have better control of the camera, including zoom, use this for stationary shots.

The default FOV is 45. The general advice is that you should reduce the FOV for easier composition as most people do not know what to do with the "wide"
frame. As you can see on Fig. the main subject is small, and most of the photo is filled with blank uninteresting road. Very ugly.

However, you should keep in mind that high FOV is not equal to a bad screenshot, see Fig..

Fig. - This screenshot is taken with a relatively high FOV, higher than the default.

Some general tips on photo making:

I can't tell you exactly how to compose your shots; you can read articles online but don't expect to read them and became a photo master in an hour. You'll
need plenty of practice to get good. I will give you some tips though.

 You need to fill the frame with something (Fig.).

A common mistake is that people have a car and absolutely nothing else in their shots. This is a no-no. However, don't put too many things in your
picture, otherwise it becomes a chaotic mess. You should make it balanced, as all things should be.

413
Fig. - The car is very small in this photo, but there are plenty of things to fill the frame.

 Pick a location that complements the car.

Different terrains and settings will work better for different cars. If you’re photographing a Jeep that does well off the beaten path, you might want to take
it onto some rocky terrain. On the other hand, a car built low to the ground might look best on a smooth city street or in front of an old brick wall by a
factory.
The color of the car will also help determine the best setting for the shoot. Black and white cars are really the only ones that you can take pretty much
anywhere. If you’re dealing with a special color, those get tougher. I’d say the hardest paint coat on a car is probably purple. Purple is a really challenging
color to capture. You have to find the right lighting.
Aim for a background that offers contrast to the car’s hue and shade. Darker cars look great against brighter backgrounds. If I’m shooting cars that are
brighter, like an orange car, I would shoot in a darker spot, either during sunset or where there’s a shadow.

 Plan your shoots for golden hour.

The time of day can make a big difference. As with most types of outdoor photography, direct sunlight can lead to glare, drastic shadows, or washed-out
colors. Shoot cars during golden hour — the hour after sunrise and before sunset — to limit the intense glare and shadows caused by midday sun. If
you want to shoot midday, work around harsh light with the help of trees and buildings that provide shade over the car.

 Be ready to capture all the angles.

Make sure to get the classic car “poses” before you get creative. Shoot the car from straight on at eye level, get side views, and capture shots at 45-
degree angle views of each corner of the car. Every car looks best at a three-quarters angle. That’s kind of like the go-to shot. You can practice with any
car, it doesn’t even have to be a fancy car.
Once you’ve captured good angles of the entire vehicle, move on to cropped shots. You can shoot the side of the car from a low angle that starts at the
front wheel, for example. Next, dive into the detail shots like close-ups of the headlights, front badge, arrow bits, side skirt, and mirrors - get in tight on
any details that make the car unique.
If the location isn’t right or is affecting your ability to follow the rule of thirds (or other photo composition best practices), play around with where and
how the car is positioned. Keep the scenery and your composition in mind. Just because your subject isn’t human, it doesn’t mean you can’t have it work
with you to get the right pose.

 Work with colour.

The overall colour of your scene will definitely have a huge impact on the result, and can make the difference between a good and a bad job.
In the following example (Fig.), I tried to recreate a shot I had taken months before with a different post-process filter.

It is important to play with ppfilters then; you should find one that behaves well for most of the locations.

414
Fig. – In my opinion the first shot (image on top) is much better, in terms of colour but also contrast wise. Also, the sense of depth is really there, and the slight roll gives dynamism.
The bottom image is washed out, still it’s pretty decent. This demonstrates that not all the shots you will take in your life will be perfect: you can have bad days too!

 No matter where you position the car, you should think about its surroundings. People usually put their car in the center of the frame, which is fine if you
plan your shot around it. Ideally, you should at least try to come up with some interesting car placement. If you want to do a low effort shot that's
passable, just position your car slightly left or right from the center, but don't overdo it.

415
Fig. - A standard low effort car to right shot. It works.

 Consider the foreground, adds layers to your photo (Fig.).

Fig. - A shot with foreground also highlights the speed of the car.

 Avoid excessive roll.

 There's no need to edit the photo; of course, you can, but you may end up ruining the shot.
 Don't use the Resolution multiplier if you don't want ugly artifacts in your photo. Keep it to 1x. You can find this in CM under Settings > Custom Shaders
Patch > Nice Screenshots.
 When people criticize your picture, don't come up with all kinds of excuses, just take the criticism.
 Just try different things. Who said that you have to shoot only cars? Tracks are so beautiful...

This should be all you need to know about how to make a passable photo in Assetto Corsa.

416
417
 PART 3:
TRACK MODDING

418
INTRODUCTION (#2, if the first one wasn’t enough)
Making tracks is not like making cars. Usually, if not always, it is easier. In this manual then between PART 1 and PART 2 some things will be similar, some
won’t, so we’ll organise our content following a linear path like before: if you read PART 1 already you may definitely have some knowledge about which are
the steps of making a mod for AC: drawing your model, using a correct naming for its objects and eventually adding empties for specific functions, then
textures, materials and shaders, and finally creating the data for a proper (faithful) simulation.

When you want to start creating mods for any game or simulator, beginning with roads can be less challenging and will teach you many things, from
modelling to null/mesh hierarchies and much more, much faster.

My advice is start small if you are going to try. Create something little and learn the basics of getting it to work in AC before you try some 40+ mile epic
monster adventure track. One step at a time, because you don't want to go far and then realize how much things you'll have to redo. Prepare the best
possible references for modeling. Watch out for dimensions and scales.

What you see, DOES matter. But some things are hidden.
The most important thing about a map is visuals; if your aspiration is to make something really good, you don’t have to be an environment designer, but
learning how to make a good landscape will definitely improve your skills. Don’t worry, you will manage to create something.

We cannot ignore another aspect of our “beautiful sceneries”: collisions. Yeah, the rock-bottom phenomenon. You don’t want to hit a wall and be launched
like a projectile, then maybe noclip (= fall through) into the ground and fly in the empty space (Fig. 0.1).

Fig. 0.1 – Falling into the void. On the left with vanilla AC, on the right with artefacts introduced by CSP. Will you ever get to the backrooms?

These aren’t happy accidents, but actual mistakes. Proper collider meshes will have to be created and applied to walls, ensuring proper behaviours.

Tracks can have some configuration files around the 3d model, for example to give every surface a different behaviour, from the vibrations on curbs, to the
rolling resistance offered by the physical road; this means you’ll have to type some numbers (or copy them) sooner or later.

This time we will talk less about NULLs and more about meshes and their proper naming. How you will call a mesh will change its function, so our attention
will be focused on that part.

Generally speaking, a lot of tracks have been made and/or converted to AC, including some of the best historic recreations of
Nürburgring, Monaco, Monza, Imola, Fuji, Hockenheim, Le Mans, and many other modern and vintage maps and roads.

419
Fig.

420
TABLE OF CONTENTS:
These are the steps to make a track mod. You can go to each respective chapter of PART 3 – TRACK MODDING for its discussion:

1. Prepare and populate the folder structures;

1.1 – Create a development (DEV) folder; p.23
1.2 – Create the final (FIN) folder; p.
1.3 – Add some common files to your mod p.

2. Modelling phase: with your 3D software (Blender, 3DS Max, Maya, etc): p.
2.1 - Make the actual track meshes with a good workflow (skip for conversions, you already have the model); p.
2.2 - Use the correct 3D coordinate system; p.
2.3 - Respect the dummy naming; p.
2.4 - Respect the scene structure and the hierarchy between dummies and mesh; p.
2.5 - Animate your model p.
2.6 - Add materials and textures; p.
2.7 - Create LODs for your final product to achieve better in-game performance; keep in mind also the poly budget; p.
2.8 - Make a collider for the physics engine; p.
2.9 - other stuff p.

3. Export to FBX up to 2014/2015 format (2016 is unsupported); p.

4. Transfer phase: With ksEditor.exe: p.

4.1 - Import the track .fbx model(s); p.
4.2 - Define the shaders/materials; p.
4.3 - Export to .kn5; p.

5. Data entry phase: edit some files for every surface behaviour, physics, etc. p.
5.1 - Data configuration & physics p.
5.2 - Use the debug tools p.

6. In-game adjustments: p.
6.1 - Use apps to fix some things p.
6.2 – Track limits p.

7. Make ‘em sound! Yes, you can add sound to your tracks. (CSP features?) p.

8. If you want to release your mod to the public, think about it a little first. p.
8.1 - Pack your files p.
8.2 - Understand your boundaries as a mod creator p.

9. Track mods from the community. p.

9.1 - How to install track mods p.
9.2 - How to edit track mods (possible with skins?) p.

Page numberssss

WIP

421
CHAPTER 1 - FOLDER STRUCTURES
If you read PART 2 - CAR MODDING, you will already know some of the basics. We’ll start from zero again though, it may be easier for you.

According to the size of your project, building a track might take from an hour to a few months. It's up to you to set the limits.

In order to work as neatly as possible, you need to create 2 separate folders for your track mod: a project development (abbreviated DEV) folder wherever
you want in your PC, with all the main reference data, the 3d models and their textures, and a definitive, "final" (also called FIN here) folder in the
assettocorsa\content\tracks path, which will contain the assets that are actually used by the game engine.

1.1 - PROJECT FOLDER STRUCTURE (DEV)

Fig.

1.2 - FINAL FOLDER STRUCTURE

Pay attention: there are naming restrictions for track folders, from shared memory definitions you have:

Max length - track folder name: 32 characters

Max length - additional track layout folder name: 15 characters

\yourtrackname.kn5
the main track file, containing track's geometry, materials and textures

We’ll see what .kn5 files are and how they’re created later on; at the moment you can ignore them.

We have some folders:

\ai
This folder contains the data for the path the AI will use to drive on your track. It can be left empty, but the virtual opponents won’t work.
You can usually find these files inside:

♦ fast_lane.ai, which is the trajectory that AIs follow on the track lap. It can be opened with ksEditor

♦ pit_lane.ai, which is the trajectory that AIs follow on the pitlane.

If however, you wish the AI at this point, see THIS thread on how to do it.

\data
Here you'll be able to define specific surfaces to be used in your track (should you wish so), edit the cameras, to define specific
lightning, to define specific audio sources and more. Two possible scenarios:
1- If you are building a basic track (and usually it's the case for the first one), you can just create this folder and leave it empty (or you
could copy a data folder from an existing track, and only modify the files you might wish to look into).
2- If you plan on customizing your track further, here is an explanation of (some of) the files contained in DATA folder:
♦ audio_sources.ini - used to link audio events to audio dummy emitters placed in your scene

♦ cameras.ini - used to define camera sets (TV type); you can define it manually or in SDK Editor. It needs the AI line to automatically
switch from one camera to another; otherwise it will remain blocked on the first camera in the set. You can define as many sets as you
like, just name them cameras.ini, cameras_1.ini, cameras_2.ini, etc.

♦ crew.ini - used to define the position of the PIT guy to the left (1) or right(-1) side of your car.

♦ groove.ini - used to define the behavior of the groove overlay. How fast it gets darker and by how much.

♦ lightning.ini - used to define the pitch and angle of the sun

♦ surfaces.ini - probably the most important, because you can use it to define new types of surfaces.

\ui
In this folder there are files that define the basic data displayed in the game UIs:
422
♦ preview.png, which is the preview image of the map, shown in the selection menu;

♦ outline.png, an image with the track layout, created from the road meshes, that will be overlayed over preview.png in the UIs;

♦ ui_track.json; This file contains basic info about the track;

Example from Imola:
{
"name": "Imola", ; Name of the circuit.
"description": "Autodromo Enzo e Dino Ferrari", ; Description of the track (short).
"tags" : ["circuit","original","Italy"],

% ▲ Tags can be different, but I suggest you to stay true to the official ones instead of creating new. Tags are used as filters in the selection menus,
so if you are faithful to vanilla it will be easier for people to manage their mods and sort them for a race.

"geotags": ["lat", "lon"], ; You can add geotags, the latitude and the longitude of your map, if it is real.
"country": "Italy", ; Country of the circuit.
"city": "Imola",
"length": "4909", ; Length of the specific track layout. [m]
"width": "15", ; Average width of the circuit. [m]
"pitboxes": "24", ; Number of pitboxes available for the specific layout.
"run": "anti-clockwise" ; Global travel direction on the circuit, can be clockwise or anti-clockwise.
}

♦ map.png is the image used by the track map app(s) in the driving sessions.
\subfolder for skins/layouts

423
CHAPTER 2 - MODELING PHASE
the road mesh can have up 64k tris, maximum length 1km
if its not visible and you have an extra (lower detail) mesh for visible road, you can make is as detailed as you want

424
2.2 - FINDING THE SOURCE MATERIAL TO DRAW ANY TRACK

Google Maps why not?

Google Earth may have historic variations

Topography

2.2.4 – LASER SCANS

To create the 3D models of the official tracks, the developers of AC laser scanned the real-world circuits as 3D point clouds, which provide the locations,
orientations, and dimensions of the road and the trackside objects (Fig.). Guided by this laser-scanned data, the devs constructed polygonal models of the
track surface, crash barriers, marker boards, trees, and buildings, and placed those objects in the 3D virtual world. They also texture mapped these objects,
to approximate closely the real-world counterparts.

How are Laser-scans made for tracks?

This process requires to drive onto the circuit with a special vehicle (Fig.) equipped with

Fig. – These are images from the Nürburgring Nordschleife laser-scans by Kunos back in 2014.

425
Fig. – Some of the laser-scans from Spa Francorchamps by Kunos, compared side by side with the 3D model. In the bottom right image is the scan of the Eau Rouge corner.

426
Fig. – The setup used by Kunos to laser-scan Spa Francorchamps back in 2013.

2.2.5 – BEING FAITHFUL TO REALITY

WIP

Fig. – This is what I call being true to real life. The track is Vallelunga. Example of sun position calculated in realtime, depending by geographical coordinates of the track and
by the sun curve according to time and date.

Not even Kunos tracks are completely faithful: see the missing chicane from Monza 1966.

427
2.3 - MODELING RULES FOR AC TRACKS
JKLLM
2.3.1 – COORDINATE SYSTEM: THE TRACK IN THE 3D SPACE (=how to extend your mind to the horizon)

2.4.2 - MODELING BUDGETS

The original Kunos pipeline 2.0 doesn’t say anything about track models. However, we know that they are on average around 200 MB in size. For circuits
like the Nordschleife, it goes to more than 400 MB.

To check whether your model is performing well or not, you just have to test in a race session, because the scene is not visible all at once. There is the
rendering distance limit.

2.3 – SET UP THE SCENE: COORDINATE SYSTEM

The nearer to 0,0,0 the better;

the problems at a far distance and 32 bit physics.

The CSP fix with 64 bit physics.

2.4 – NAMING RULES FOR TRACKS

A track is not only made of concrete or tarmac, right? We have different surfaces and objects. Giving a different name to each one of them will make the
difference between driving on the Silk Road and throwing your car in the haybales of the nearest barn.

2.4.1 – NAMING RULES FOR SURFACES

The AC physics engine takes into account the naming of your track’s meshes in order to give them physical properties. The syntax is as follows:

<ID#><label><optional_suffix>

Where:

1. ID# is a number; it must be > 0 (greater than 0, so 1, 2, 3, …) if you want the mesh to have some physical properties. It can be 0 or missing, and the
object will be only a graphical asset. You can also start from 01 instead of 1.
2. label is the name of your object/mesh, used as identifier for the surface type;
3. optional_suffix – as the name says, you can use it if you need, but has no impact on the object properties.
4. The separator between the label and the suffix can be anything, or missing.

The label parameter is very important and deserves some more explanation, as it will be used to define both the rolling surfaces and the collision meshes.

For rolling surfaces, there are pre-defined keywords that you can use as labels, being basic surface types already defined in surfaces.ini inside the folder
assettocorsa\system\data. They are:

1. ROAD (will make the chosen mesh driveable; acts like tarmac);
2. GRASS (offroad, grass areas out of the road boundaries, really bouncy and very slippery);
3. KERB
4. SAND (pretty obvious, the surface acts like the sanded areas in circuits, slowing down the car quite heavily; quite bouncy);
5. PIT (driveable, for the pitlane only)

Here are some examples, with basic and custom surfaces (see also Fig.):
01ROAD; 3SAND; 22PIT993; 58KERB_west; 33GRASS_green_darktone_325; 01TARMAC-IMA011; 17CONCRETE005

428
Fig. – This example uses basic surfaces (3D software used: Blender). You can manage any section of your track by giving a different name to each one of them.

If you want, you can adopt a custom surface name, for example 1CONCRETE or 05GRAVEL but you’ll have to define the characteristics of each label, like
friction, FFB behaviour, etc. in the dedicated surfaces.ini of your track (we’ll talk about it later).

For collision meshes instead, WALL is a mandatory label. There are no custom alternatives. The syntax is the following:

<ID><WALL><optional_suffix>

Where:

1. ID# is a number; it must be > 0 (greater than 0, so 1, 2, 3, …) if you want the mesh to be collidable. It can be 0 or missing, and the object will be only a
graphical asset without collision detection. You can also start from 01 instead of 1.
2. WALL is the label used as identifier for the collision surfaces;
3. optional_suffix – as the name says, you can use it if you need, but has no impact on the object properties.
4. The separator between the label and the suffix can be anything, or missing.

Here are some examples:

1WALL_fence; 04WALL_building; 2WALL-pole; 15WALLprotection12; 67WALL23

- It is possible to quickly define an object as an obstacle (fence, building, pole, barrier, …) just by naming that object using the WALL label, but this is not
correct. Here's the right way:

Model and name your objects as you see fit, and then add an invisible and as-simple-as-possible mesh around them. Call this mesh with the WALL label.
This will assure the best behaviour.

Don't exaggerate with polycount with walls. Never call a complex object like the armco barriers, guardrails or tire walls as the actual WALL collision mesh.
Any physical object should be as simple as possible (Fig.), so draw a simple collision mesh and make it not renderable by setting Render to false in
ksEditor.

429
Fig. - As you can see here the barrier is simply visual. The actual WALL collision mesh is the highlighted box around it.

For WALLs you can technically use boxes, flat planes or polygons. The fewer faces the better, so you can remove top and bottom faces. (Fig.)

Fig. – These are valid examples of what you can use for track colliders.

Try to keep parallel faces far away from each other: you can get stuck in them if the back face is too close to the front face and you hit the collider too hard
with your vehicle (Fig.).

In any case avoid using solid objects as much as possible, and employ flat planes/surfaces for the most, with the normal vector of the faces pointing to the
track. That’s what AC is checking, if the normal of a wall should point outside you collide, if the normal points inside, you can drive through (Fig.).

For conversions from games/other sources: if you just rename existing objects to #WALL, you will get mixed results; rFactor tracks for example tend to have
weird normals, so the best way is to make new colliders around the track.

2.4.2 – NAMING RULES FOR SPAWN OBJECTS (CIRCUITS)

Spawn objects are special meshes which, given a correct name, determine various locations on the track where you’ll spawn at the beginning of a session,
for example in the pitlane, or at the starting line.
These meshes must be kept as simple as possible, and the shape must be cubic (a box, Fig.). They will not be rendered (invisible), so their position is the
most important thing; just remember to map them with a material (no need to create a unique material, just use any that you already have in the scene) in
your 3D editor of choice.
There's no need to make spawn cubes invisible (AC_PIT, AC_START – etc.), they will not be rendered automatically based on their name.
You can also use dummies (3DsMax) or empties (Blender) and in that case you no longer need to worry about materials. But it is easier with boxes.

430
Fig. – Example of spawn objects (3D software used: Blender). Many of the cubes you can see, once named correctly, will determine the positions of the cars in the pitlane.
In general, anything related to a position must follow this rule: the Y axis of the pivot point must point UP and the Z axis must point forward and will
determine the orientation of the car. This is very important for 3DsMax users, where usually Z axis is UP and Y axis is forward, beware.

The boxes that determine the positions of the pit-stop areas and of the spawn in the pitlane (for each car) must be named:
AC_PIT_# (# must be 0, 1, 2, 3, …, etc.). DO NOT add zeros before the numbers, for example AC_PIT_01 is incorrect (01 is different from 1).

The meshes in the starting grid positions must be named:

AC_START_#

The Hotlap start position must be named:

AC_HOTLAP_START_0

AC_PIT_0 must always be present. If you put only AC_START_0, the session will crash.

2.4.3 – NAMING RULES FOR TIMING OBJECTS (CIRCUITS)

Timing objects are slightly different from spawn objects. They’re still cubes with a material applied, but they work as the extreme points of a segment, which
the cars cut, determining the lap time or the time with respect to a specific checkpoint. You can think of this like an invisible line (Fig.).

431
Fig. –

These objects don't need the axis orientation like the spawn objects:
AC_TIME_0_L must be placed on the LEFT side of the start/finish
AC_TIME_0_R must be placed on the RIGHT side of the start/finish

To create an intermediate checkpoint, follow the same rule about left and right. Keep in mind that you can place only 2 intermediates.
The number 1 will be the first checkpoint.
AC_TIME_1_L
AC_TIME_1_R

Use the number 2 for the second intermediate.

AC_TIME_2_L
AC_TIME_2_R

The trigger will be a line drawn from the center of the object to the other side (not visible obviously).

2.4.4 – NAMING RULES FOR POINT A TO POINT B TRACKS

What are point A to point B tracks? Most of the times they are roads, where you compete to be the fastest to reach point B, starting with your car from point
A. There are a lot of events, often rally ones, that take place on these types of tracks. Famous roads are part of this category too, like the Romanian
Transfagarasan, or the Colorado’s Pikes Peak Hill Climb (Fig.). Both (and other maps of the same kind) have been recreated in AC if you want to enjoy them.
An example from the official content is the Trento-Bondone hillclimb course map, which Kunos brought directly from their old NetKar Pro simulator.
Probably only old school gamers will remember it.

Fig. – The Pikes Peak Hill Climb is really dangerous; you can definitely feel it in AC.

These are pretty challenging experiences, often the distance you have to travel is pretty long, and that’s part of the fun! You can also take them slowly and
enjoy the trip.

Keep the same naming rules for the pit spawn points as the circuits. Keep the same naming also for the hotlap start spawn point. There is no starting grid.

The starting line (point A) uses the following names for the objects:
AC_AB_START_L
AC_AB_START_R

The finish line (point B) uses:

AC_AB_FINISH_L
AC_AB_FINISH_R

432
2.4.6 – OTHER NAMING RULES

AC_POBJECT_suffix - use this format as name if you'd like to have collidable/movable objects in your scene (cones, for example). In order to avoid
unexpected issues, they work best when used on objects with simple geometry, and devs recommend not having too many (not more than 15 iirc). Even
though you could get away with more.

TREES:
It's not mandatory to be used, but there is a system to manage trees: model a tree, any shape you like. Make the front and back face, you can also weld
nearby vertices (don't think about normals). Place the pivot point on the center of the object.
Name it KSTREE_GROUP_"anyname"_"a number"
example: KSTREE_GROUP_A_1
Let's say you make 10 of them you'll call them
KSTREE_GROUP_A_1
KSTREE_GROUP_A_2
KSTREE_GROUP_A_3
...
KSTREE_GROUP_A_10

When you'll import the scene, the editor will point the normals of each tree in the opposite
direction of the pivot point (if it's in the center, the normals will be like a sphere)
AND will join all the trees of the same GROUP in a single object named "anyname" (A in the case of the example). This will let you the freedom to move
easily the trees in the cad, or change them or rotate them etc etc. but ingame they'll be much more optimized as drawcalls and reaction to light. (the
example above will create a single object named A containing 10 trees).

2.5 - MODELLING GENERIC PARTS OF A TRACK

2.5.1 – TREES (WIP)

You can make horizontal planes for the trees so they have shadows around 12 noon.
This is a normal set of trees at 12 noon

This is with the horizontal plane in place. Now in my case I just used a single shadow texture for all of them since none of my trees are real close to the
track. But if yours are right on the road edge you may want to use 4 or so different shadow textures so they don't all look the same like these do.

433
So here is how you do it.

First off on my trees I have my pivot points all on the bottom of the object. if you didn't do this that is fine. but in the future I suggest you do that as it makes
it much easier to apply a random scale to you trees so they all aren't the same size.

So the first step is you need to make a texture. It is basically the same as a normal tree texture except you set the opacity of the main layer to 1%. You will
need PS for this as the DDS exporter for gimp does not seem to make the texture properly

This is what it looks like at 100%. Just set the opacity to 1% and then export to DDS DXT5. Attached below is the actual working DDS found on my track and
shown above. You may use it as you wish.

So now that you have the texture you must make the plane and then get that plane to be in place on each existing tree. What you do is select all the trees
you want to have this shadow and then duplicate them BUT DON'T MOVE THEM. Just duplicate them in place and hit the M key and select an empty layer in
your blender file. Now you have the trees duplicated and sent over to a separate layer from your main trees.
434
In the new layer duplicate a single tree and move it away from the rest and single it out. Also make sure it is perfectly vertical and not tilted in any way.

Next create a plane and position it over the tree you singled out. Now would be a good time to map your texture to it. The plane can be single sided but the
texture MUST FACE DOWN.

Now you want to join the plane to the tree object

Once joined go into edit mode and delete all the parts of the original tree.

Now you have a plane with the correct pivot point of the original tree.

435
Now comes the simple part. Select all your trees but make sure the plane is active

Hit CTRL+L and choose "Object Data" and you will get this.

Now your plane is in place of the original trees with the correct scale and angle of the original tree.

2.5.1 – GRASS (WIP)

Vanilla grass is a transparent texture on polygons, so not just a shader. Hand placed, or rather via randomised functions of the 3D modelling tools.

2.6 - NULLs & SCENE STRUCTURE

2.9 - LODs AND TRIANGLE / OBJECT BUDGET

Do tracks have LODs?

436
CHAPTER 3 – SHOWROOMS (keep it here?)

A showroom is actually just a normal model (export as 'track' from the ksEditor), the panorama's just a regular texture mapped to whatever object makes
sense for it. (Kunos ones are basically a hemisphere above a flat plane, with some of the details visible in the panorama modeled in around the seam)

One unusual thing in the Kunos ones is that it uses a floating point dds format so the panorama's an HDR image with an all-real brightness scale.

You'll need at least 8000x4000 to get a decent in-game appearance, possibly larger.

Considering tracks have easily 3 million triangles in sight at any given time, you can go quite crazy with a modeled showroom.

437
CHAPTER 5 - TRACK DATA, CONFIGURATION FILES AND PHYSICS
You will definitely notice how things here will be much, much shorter with respect to vehicles. Circuits are just surfaces, nothing more, and we can easily
work with mean measurements and a statistic mathematical approach. Knowing the principles of static and dynamic friction is fundamental, so we will
elaborate on these later.

5.1 - HOW TO CREATE DATA FOR YOUR TRACK

5.2 – DATA FILES AND EXAMPLES (with ANALYSIS)

The following paragraph contains the list of all the data files for tracks; to make a basic track work you need none of them if you configured your 3D model
correctly (NULLs, object names, etc.). It’s very unlikely that without any of these files the track will not load and the game will crash, but many features may
(and will) not work. Tracks are probably one of the most reliable things in AC if you know how to make them.

This should not be necessary, but please note that if you’re using CSP you might encounter errors and crashes anyway.

5.2.1 - CONFIGURATION FILES (.ini) (page numberssss)

1. ai_hints.ini
2. audio_sources.ini
3. camera_facing.ini
4. cameras.ini
5. cameras_#.ini (cameras_1.ini, cameras_2.ini, etc.)
6. cameras_start.ini
7. crew.ini
8. drs_zones.ini
9. groove.ini
10. lighting.ini
11. map.ini
12. overlays.ini
13. sections.ini
14. semaphore.ini
15. startinglights.ini
16. surfaces.ini
17. EXTRA…

CSP files?

5.2.2 - OTHER FILES

AGFHSDH

down5m.csv
down10m.csv
ideal_line.ai
up10m.csv

438
5.2.3 - EXPLANATION AND ANALYSIS OF EACH .ini SCRIPT

dafsdasfasd

1. ai_hints.ini

sjhasklg
[BRAKEHINT_0]
START=0.070
END=0.134
VALUE=0.92 ; Percentage of throttle for AI opponents (1=100%). Can exceed 1, up to 1,2 (120%).

2. audio_sources.ini

This script can be used to add special reverb zones to your track, for example if you have a tunnel, near a wall or under a bridge. You can use the
Nordschleife as a template. You insert objects into the track at the respective tunnel and then fine-tune the reverberation.
[REVERB_0]
ENABLED=1
NODE=AC_PIT_0 ; The name can be anything you like, just use uppercase text and underscore instead of spaces.

% ▲ The nodes can be dummies or meshes (uses object pivot/origin), but it’s more practical to use empties.

MINDISTANCE=175 ; Distance from the NODE for the reverb area where reverb will play at 100% effect. [m]
MAXDISTANCE=225 ; Distance from the NODE for the reverb area where reverb will cutoff. [m]

% ▲ MINDISTANCE and MAXDISTANCE are gradient values. Reverb works in a sphere, where the center (the NODE) is where your distance starts. You could use
spheres to visualize it. For example, if you use 5m as MINDISTANCE and 10m as MAXDISTANCE, from 5-10m the reverb effect will get weaker and at 10.01m it
will stop.

PRESET=CUSTOM

% ▲ SEWERPIPE

DECAY_TIME=2750
EARLY_DELAY=50
LATE_DELAY=250
HF_REFERENCE=4500
HF_DECAY_RATIO=75
DIFFUSION=100
DENSITY=100
LOW_SHELF_FREQUENCY=250
LOW_SHELF_GAIN=0
HIGH_CUT=4000
EARLY_LATE_MIX=80
WET_LEVEL=-16

[REVERB_1]
[REVERB_2]
[...]

LITTLE EXPLANATION

How does the reverb work?

- If you are setting up reverb zones against a wall you could use 1 or many reverb nodes, depending on how you need it set up (Fig.).

Fig. - If you have 2 lanes of traffic, yet you only want the lane closest to the wall to hear the reverb, you might need something like on the left, if you only have 1 lane or do not care
about the effects on the second lane you could create something like on the right.

- You could set the reverbs each with MINDISTANCE=MAXDISTANCE, but then there would be no sound build-up.

CURIOSITIES AND AMENITIES

In AC, before release 1.3, it used to be possible to add audio generators to a track. They were almost the same as the spawn objects, only that they emitted
audio. The naming was like this: AC_AUDIO_anyname
It used to work in conjuntion with the audio_sources.ini script in the track’s data folder:
[AC_AUDIO_amb1]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb2]
VOLUME_SCALE=7

439
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb3]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb4]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

These sections are deprecated and rare to find anywhere. For any object you had to specify a wave file (mono 44.1 kHz) to be played. It worked like a
speaker so the sound always had a direction (not really suitable for ambient sounds).

You could use it to place external audio sources at various positions on track. Example: sound of water near a river, sound of crowds near grand stands,
sound of birds near a forest...
After the release 1.3 the developers disabled this feature because it caused issues. Shared sounds are used as ambience (the ones under common in the
FMOD project, and you can’t change them, since they are hardcoded). However, some models of official tracks still have the AC_AUDIO objects, that’s why
explaining this is useful. Today, you can add ambience sounds to your tracks with CSP.

3. camera_facing.ini
[CAMERA_FACING_0]
SURFACE=camerafacing_1_KSLAYER3
ELEMENTS=2000
SIZE=0.8,1.4
TEXTURE=content/texture/people_sit.dds
TEXTURE_ROWS=3
TEXTURE_COLUMNS=7
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_1]
SURFACE=camerafacing_2_KSLAYER3
ELEMENTS=2000
SIZE=0.8,1.4
TEXTURE=content/texture/people_sit.dds
TEXTURE_ROWS=3
TEXTURE_COLUMNS=7
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_2]
SURFACE=camerafacing_3_KSLAYER5
ELEMENTS=850
SIZE=0.8,1.4
TEXTURE=content/texture/people_sit.dds
TEXTURE_ROWS=3
TEXTURE_COLUMNS=7
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_3]
SURFACE=camerafacing001_KSLAYER5
ELEMENTS=100
SIZE=0.7,1.9
TEXTURE=content/texture/people_stand.dds
TEXTURE_ROWS=2
TEXTURE_COLUMNS=11
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_4]
SURFACE=camerafacing_KSLAYER5
ELEMENTS=70
SIZE=0.7,1.9
TEXTURE=content/texture/people_stand.dds
TEXTURE_ROWS=2
TEXTURE_COLUMNS=11
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_5]
SURFACE=camerafacing_4_KSLAYER4
ELEMENTS=1800
SIZE=0.8,1.4
TEXTURE=content/texture/people_sit.dds
TEXTURE_ROWS=3
TEXTURE_COLUMNS=7
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

4. cameras.ini

To create cameras you have to make the AI line first. And if you change it, you'll have to reconfigure attack (in) and detach (out) points again.
[HEADER]
VERSION=3
CAMERA_COUNT=14
SET_NAME=Tv 1

[CAMERA_0]
NAME=1
POSITION=-177.531 ,54.7903 ,-791.639
FORWARD=-0.464872 ,-0.0699428 ,0.882612
UP=-0.0325944 ,0.997552 ,0.0618844
MIN_FOV=2
MAX_FOV=10

440
IN_POINT=0.83585
OUT_POINT=0.909733
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=250
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_1]
NAME=3
POSITION=-80.5131 ,67.3688 ,-1045.9
FORWARD=-0.438474 ,-0.0599639 ,0.896744
UP=-0.0263401 ,0.9982 ,0.0538699
MIN_FOV=3
MAX_FOV=12
IN_POINT=0.909733
OUT_POINT=0.954706
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=300
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_2]
NAME=4
POSITION=2.46151 ,65.1328 ,-849.565
FORWARD=-0.146259 ,-0.0200003 ,-0.989048
UP=-0.00292588 ,0.9998 ,-0.0197843
MIN_FOV=2
MAX_FOV=12
IN_POINT=0.954706
OUT_POINT=1
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=300
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_3]
[...]

5. cameras_#.ini

[HEADER]
VERSION=3
CAMERA_COUNT=11
SET_NAME=Tv 2

6. cameras_start.ini

7. crew.ini

AFDGHJAG
[HEADER]
SIDE=-1 ; 1 = left, -1 = right

8. drs_zones.ini
[ZONE_0]
DETECTION=0.642
START=0.738
END=0.871

[ZONE_1]
DETECTION=0.925
START=0.979
END=0.096

9. groove.ini
441
[HEADER]
GROOVES_NUMBER=12

[GROOVE_0]
NAME=groovegp
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_1]
NAME=groove_gp001
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_2]
NAME=groove
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_3]
NAME=grooveb
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_4]
NAME=groovebgp
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_5]
NAME=groove_gp
MIN=0
MAX=1
MULT=1

[GROOVE_6]
NAME=groove2gp
MIN=0
MAX=1
MULT=1

[GROOVE_7]
NAME=Object76373
MIN=0
MAX=1
MULT=1

[GROOVE_8]
NAME=groove2b
MIN=0
MAX=1
MULT=1

[GROOVE_9]
NAME=groove2
MIN=0
MAX=1
MULT=1

[GROOVE_10]
NAME=groove3b
MIN=0
MAX=1
MULT=1

[GROOVE_11]
NAME=groove3
MIN=0
MAX=1
MULT=1

10. lighting.ini

Vanilla AC just simulates a fixed sun trajectory, customizable for every track. lighting.ini defines this fixed trajectory.
[LIGHTING]
SUN_PITCH_ANGLE=25 ; Defines the highest zenith for the day. Values range from 0 to 90. [deg]

% ▲ A value equal to 0 means that the sun is at 90°, so straight above you. A value of 90 means it’s at the horizon. Pretty backwards logic here. (check)

SUN_HEADING_ANGLE=45 ; Calibrates the sun to the track with respects to the geographical north.

% ▲ Not every track is headed to the north, while it is created. This line lets you adjust that.

CSP ADDITIONS

- The old vanilla sun trajectory model can still be used, if you set "If no date is set, use original sun trajectory" in the CSP/CM options. WeatherFX (what is
it?) does that.
For more realism and with this option deactivated, WeatherFX generates the real sun trajectory via the tracks position, timezone, date and time. Part of this
data comes from geotags in the ui_track.json file inside the your_track\ui folder. SUN_HEADING_ANGLE gets ignored. Therefore it’s no longer possible to
fake/set the sun position freely.
These new functions need to be set per track. You can see it in the CSP files, specifically inside extension\config\data_track_params.ini.

11. map.ini
[PARAMETERS]
WIDTH=600.604
HEIGHT=1565.46

442
MARGIN=20
SCALE_FACTOR=1.2
X_OFFSET=422.16
Z_OFFSET=1034.46
DRAWING_SIZE=10

12. overlays.ini
[MAIN]
OVERLAYS_COUNT=3

[CHECKPOINT_0]
WORLD_POSITION=-4.86199 ,63.9383 ,-760.247
OFFSET=-4.08257 ,3 ,0
WIDTH=15
HEIGHT=1.5
ORIENTATION=-0.0049426 ,0.00524384 ,-0.999974

[CHECKPOINT_1]
WORLD_POSITION=-11.4411 ,49.4285 ,77.5357
OFFSET=1.98687 ,3 ,0
WIDTH=15
HEIGHT=1.5
ORIENTATION=-0.485433 ,0.00904065 ,-0.874227

[CHECKPOINT_2]
WORLD_POSITION=-78.8248 ,48.7335 ,111.375
OFFSET=2.89969 ,3 ,0
WIDTH=15
HEIGHT=1.5
ORIENTATION=0.450846 ,-0.0157044 ,0.892464

13. sections.ini

This is the config file that contains the turn names. There is an app (Fig.) that visualizes them while you’re driving on the different sections of the circuit.
[SECTION_0]
IN=0.117
OUT=0.139
TEXT=Yokohama S

[SECTION_1]
IN=0.149
OUT=0.225
TEXT=Mercedes Arena

[SECTION_2]
IN=0.539
OUT=0.606
TEXT=Michael Schumacher S

[SECTION_3]
IN=0.691
OUT=0.729
TEXT=Bilstein Kurve

[SECTION_4]
IN=0.769
OUT=0.818
TEXT=Advan Bogen

[SECTION_5]
IN=0.872
OUT=0.902
TEXT=Veedol Chicane

14. semaphore.ini

This script its meant to be used for drag racing tree semaphore lights (Fig.). It will turn on the light with an EMISSIVE= the intensity value you've set, again,
and again.
In order for any lights to show up you have to create an object and name it AC_SEMAPHORE_RED, AC_SEMAPHORE_YELLOW or
AC_SEMAPHORE_GREEN (but any other name can do the job, as long as they correspond to what you specify in the NAME field).
If you wish to use this config with other lights/lamps you probably can, but they will be linked to the ready/start state (meaning they will be "red" in the ready
period and then switch to "green" state after race start).
[GROUPS]
DISQUALIFIED=1
READY=3
START=1

[COLOR]
INTENSITY=2.2

[OBJECT_0]
TYPE=1 ; Light type on the semaphore. Input can be 0, 1, 2.

% ▲ There are different light types: 0=DISQUALIFIED, 1=READY (usually yellow/red), is ON before the beginning of the race; 2=START (usually green light),
is on after the race started.

NAME=AC_SEMAPHORE_YELLOW_1
ORDER=0 ; it's the first of its set to be turned on

[OBJECT_1]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_4
ORDER=0

[OBJECT_2]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_5
ORDER=1

443
[OBJECT_3]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_2
ORDER=1

[OBJECT_4]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_6
ORDER=2

[OBJECT_5]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_3
ORDER=2

[OBJECT_6]
TYPE=2
NAME=AC_SEMAPHORE_GREEN_2
ORDER=0

[OBJECT_7]
TYPE=2
NAME=AC_SEMAPHORE_GREEN_1
ORDER=0
INTENSITY=2.2

[OBJECT_8]
TYPE=0
NAME=AC_SEMAPHORE_RED_2
ORDER=0

[OBJECT_9]
TYPE=0
NAME=AC_SEMAPHORE_RED_1
ORDER=0

15. startinglights.ini

The following lines are for the configuration of regular track semaphore lights at the beginning of the race (Fig.). They produce a different behaviour from
semaphore.ini, as are lit up the meshes with the naming KS_STARTLIGHT_# (where # is a number, starting from 0, 1, 2... etc). (section for track meshes)
[SETTINGS]
EMISSIVE=255,0,0,255
INTENSITY=2
DIFFUSE=0.3

16. surfaces.ini
[SURFACE_0] ; Surface identifier
KEY=CONCRETE ; Custom surface type label.
FRICTION=0.96 ; Friction coefficient
DAMPING=0.01
WAV= ; Surface sound, leave empty for no sound.
WAV_PITCH=0
FF_EFFECT=NULL ; Force-Feedback effect
DIRT_ADDITIVE=0 ; Multiplier applies dirt on vehicles.
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0 ; If the surface has to be considered as pitlane. This activates the pit limiter.
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_1]
KEY=CARPET
FRICTION=0.65
DAMPING=0
WAV=extraturf.wav
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0.1
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_2]
KEY=PITS-IMA

% As you can see, this is definitely a weird label for a surface, but if set properly it works. Let’s take a look at the corresponding mesh naming in
Fig. below.

444
Fig. -

FRICTION=0.97
DAMPING=0
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=1
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_3]
KEY=CUTGRA
FRICTION=0.6
DAMPING=0
WAV=grass.wav
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=1
IS_VALID_TRACK=0
BLACK_FLAG_TIME=15
SIN_HEIGHT=0.03
SIN_LENGTH=0.5
IS_PITLANE=0
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_4]
KEY=CUTCONC
FRICTION=0.96
DAMPING=0.01
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0.01
IS_VALID_TRACK=0
BLACK_FLAG_TIME=5
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_5]
KEY=TARMAC-IMA
FRICTION=0.98
DAMPING=0
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_6]
KEY=TARMAC-IMB
FRICTION=1
DAMPING=0
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0

445
IS_PITLANE=0
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_7]
KEY=OUT
FRICTION=0.95
DAMPING=0.013
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0.05
VIBRATION_LENGTH=0.4

[SURFACE_8]
KEY=KERB
FRICTION=0.92
DAMPING=0
WAV=kerb.wav
WAV_PITCH=1.3
FF_EFFECT=1
DIRT_ADDITIVE=0
BLACK_FLAG_TIME=0
IS_VALID_TRACK=1
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0.4
VIBRATION_LENGTH=1.5

[SURFACE_9]
KEY=KRB2CUT
FRICTION=0.92
DAMPING=0
WAV=kerb.wav
WAV_PITCH=1.3
FF_EFFECT=1
DIRT_ADDITIVE=0
BLACK_FLAG_TIME=5
IS_VALID_TRACK=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0.3
VIBRATION_LENGTH=0.6

[SURFACE_10]
KEY=KRBCUT
FRICTION=0.92
DAMPING=0
WAV=kerb.wav
WAV_PITCH=1.3
FF_EFFECT=1
DIRT_ADDITIVE=0
BLACK_FLAG_TIME=3
IS_VALID_TRACK=1
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=0
VIBRATION_GAIN=0.5
VIBRATION_LENGTH=0.6

CURIOSITIES AND AMENITIES

446
CHAPTER 6 - LIVE ADJUSTMENTS DURING A SESSION
6.1 – THE AI TRAJECTORY
Our opponent in single player is the machine, with virtual drivers coded to challenge us.

AI APP

The red line is the track boundary line and is defined by valid race track surfaces during recording. Look at official tracks with AI app open and study the
lines. Basically any surface inside the white lines should be valid. Anything outside should be invalid.

How do you edit these red lines?

They can be changed in the editor but it is a royal pain to do it that way. It is easiest to properly define the valid racing surface and record the line again.

6.1.1 – TRACK LINE (fast_lane.ai)

WIP
FAQ
AI SPLINE:

PROBLEM: What causes AI cars to weave down straights when I make the ai for my track? The spline is straight but the ai weaves back and forth full
lock left and right.

SOLUTION: Sounds like ai line is broken. Just re-record it.

6.1.2 – PIT LINE (pit_lane.ai)

6.1.3 – IDEAL LINE (ideal_line.ai)
I guess ideal line is for that arcade ideal line app in game, without it it uses fastlane from ai folder. But I haven't tried yet.

6.2 – TRACK LIMITS

These lines should be created / edited by the creator of the mod (who has the original project), otherwise you have to edit them with a text editor point by
point (and you don’t want to do that, trust me).

The track maker has only to produce 2 files called "side_l.csv" and "side_r.csv" (in track/data).
side_l for the left side, side_r for the right side, looking at driving direction.
As soon as the loading page of AC shows up (after pressing start on the launcher), just press SHIFT (and keep pressing it until the end of
loading) and the 2 files will be added to fast_lane.ai
Lines will be rendered in yellow when using AI app.
the 2 csv files are simple XZY (watch out Max users) coordinate points (look at the example file provided). Coordinates are not
interpolated so give a reasonable number of points, there's no rule, these lines will be used by the sim to re-create track limits (red line
of AI app)

shift must be pressed when loading the track you're doing the lines for... each time you want to change them. Once loaded, the lines
are “baked” into fast_lane.ai so they can be deleted from data.

in some quick testing I do not appear to need to hold the SHIFT key to load the CSV data into the AI line. It seems as long as the CSV file
is in the data folder it auto loads.

There is a system in place that compare dates on those files and updates if necessary but [we always found it a bit unreliable] so it's
better to hold the shift to be sure. [If the file timestamps match it won't load it. But the shift key forces it to regardless].

Just edit the main line and let the CSV file define the edges.

Also this method of edge line creation is really only for track creators/converters. You need to have the track inside a 3D program like
Blender or 3DS max to work with this.
447
About track limits

FAQ
QUESTION 1: Some tracks, Spa for example, will disallow a lap for the smallest transgression. Others, Laguna Seca for example, allow
you get away with all sorts of off-track excursions. In the first case 40% of my laps may be no good while it is less than 10% in the latter,
even though I feel it should be the opposite. Does anybody know how the program makes those decisions?

ANSWER 1:

QUESTION 2: If I edit the edges file csv will it affect the online multiplayer?

ANSWER: All these files are only used by the single player AI, editing them will not cause a mismatch on online sessions in any way.

QUESTION 3: Is partial track border replacement possible or I must create a full line?

ANSWER 3: Before you had to remake the full line, but now you can use an app (man why don’t you… I know)

QUESTION 4: Do left and right limits need the same number of points? Which density should they have?

ANSWER 4: They Don’t need to have the same amount of vertices. It doesnt matter how many they are in the .csv. AC will rebuild ai line
just based on line and actual boundaries. However a spacing from 30cm to 1m is pretty much fine.

Road surfaces are set to valid or invalid according to their 3D model names. While the valid/invalid can be edited
(/tracks/trackname/surfaces.ini > IS_VALID=0/1), this will give you a checksum error for online racing.

The surface names are hardcoded into the 3D model and cannot be changed.

Upside down track

AC used to reset to the pits after 3 seconds if the car was upside down

There is an option in the .ini files that lets you turn that off - that option used to be bugged but it works now. AUTOFLIP_RECOVERY=0
in assettocorsa/system/cfg/options.ini

In the respect of aero, yes, there are loads of cars that produce more than their mass in downforce at certain speeds. But in terms of
the driveable surfaces working in AC at 180°? Not sure, never tried it.

I'm pretty sure AC does no ground collision above ~50° angles. There is/was half a loop on stereos testpad track, and you would just fall
through it halfway up.

AC simply will not register a driving surface past a certain angle. You will never even get close to 90° no matter if it is a loop or a tunnel.

There also is a problem with traction. Even if you have more (now inverse) downforce than weight, you would need to maintain a very
high speed, overcoming the air drag. You might not have enough tire contact to do so. Tiny bumps will also have something of a "moon
effect", have you floating over (now under) the surface much longer than normal. If during such time drag slows you down too much
you drop. Underbody and rear diffuser downforce would drop severely on bumps.

I've tried doing it on a barrel roll style track in another sim and the problem (with an F2004, so rwd) is that you need enough grip to
overcome drag easily. Otherwise the rear tires have high slip ratio and when your car goes up onto the vertical bank it starts to spin
out. So just having more downforce than the car's weight isn't close to enough, you need downforce to exceed weight + drag by a
decent margin.

Doing a vertical loop has the obvious problem that the smaller it is the heavier vertical G's you get (and front/rear of the car dig into the
surface) but the larger it is the more you decelerate on the way up it.

So ideally you want a car that hits 'more downforce than its weight' at a speed where it's still accelerating easily. I don't think any real
world cars get near that. Maybe boost turned up group C when they had full underbody tunnels allowed.

Probably the easiest way to do it IRL is to have the car riding upside down on a cart with its wheels against the ceiling and then have
the cart drop away, it skips trying to get it up there, problems with the engine running upside down, etc.

Late Group-C could probably do it. 850 kg with a driver and fuel, 8+ coefficient of lift, and 5-6:1 L/D ratio...the speed at which mass
equals downforce is quite low, so maintaining something a decent amount faster would be pretty manageable.
448
CHAPTER 7 - SOUND
I recommend the reading of Chapter 8 of PART 2 - CAR MODDING to learn the creation process of a good sound. There are also all the
main principles of acoustics, if you don’t know or remember them.

Sound for tracks is for the most part related to ambience, attenuation and reverb:

 Ambience consists of background noise, and can be divided in two types: natural and artificial.
 Attenuation and reverb are physical phenomena: their existence is intrinsic with respect to the environment.

(wip)

7.3 - TRACK CAMERAS SOUNDS

A detailed mention is necessary when using track cameras (F3 view): the distance attenuation range of some exterior sounds is
multiplied by a value named DISTANCE_SCALE, expressed in meters, located in the following path:

Assetto Corsa/system/cfg/camera_track.ini
[CAMERA_SETTINGS]
DISTANCE_SCALE=7 ; PLEASE DON’T CHANGE IT
UPWARD_OFFSET=0
CAMERA_WOBBLING_SPEED=0.001
CAMERA_WOBBLING_STRENGTH=0.04 ; located

This is for gameplay purposes: imagine you're racing against 10 opponents with their own engine_ext playing. If the distance scale of
engine_ext is too short (e.g. from 1 to 20 meters), the sound will be not audible from the track cameras. If it's too large (e.g. from 1 to
750 meters), opponents will be audible from far away while you're racing against them.

With this "trick" you can find a good compromise about exterior sounds volume, in gameplay cases (driving among a pack of
opponents) and watching a replay with many cars involved.

The events that interact with the multiplier above are the following:

 engine_ext
 backfire_ext
 tractioncontrol_ext
 skid_ext
 limiter
 wheel
 wind

Note: the DISTANCE_SCALE multiplier is a global parameter, so its value is not configurable per car. The multiplier works only in track
cameras and free camera view (F3-F7) and only with the Events reported above. For any other exterior sound event, please use the
built-in distance scale and attenuation curves of the FMod deck.

This means that if you're using the car cameras (as said before, the F1 views and other "car attached" cameras), the multiplier is
switched off (technically, it's always set to 1 by code) and you can manage the distance scale and volume attenuation of the above
events using the original 3d panner (Fig.).

Fig. -

Back to the engine_ext and its 3d panner (picture above) of the example project, the maximum volume is reached at 6 meters and the
minimum is set at 350 meters, for gameplay cameras (F1 or F6).

Switching to track/free cameras (F3 or F7), those values are multiplied by the above DISTANCE_SCALE parameter, so the resulting
distance range is:

449
6 x 7 = 42

350 x 7 = 2450

This means that switching to track cameras view, the maximum volume is reached when the sound emitter (the car engine) is at 42
meters far (and below) from the sound listener (the camera position). Following the same reasoning, the volume goes to the minimum
(e.g. the event channel is released) when the car is 2450 meters far.

REVERB

In the new Fmod project we removed the “snapshot” reverb, because it led to episodes of bad implementation by some modders,
making the whole sound stage sounding like in a church using the track cameras. We reworked the whole code and when you drive
your car in a reverb zone, now the reverb is made by exterior sounds only (as expected in real life). Of course, skilled modders can add
snapshots to their own project if needed. Please refer to the Fmod official manual for further info.

7.5 - CUSTOM SHOWROOMS SOUNDTRACKS

The procedure is exactly the same of building a car bank. As reported in the first picture, remember to create an event folder named
"showrooms" and a new event with the same name of the showroom folder in the Assetto Corsa game folder. Put the soundtrack in
the timeline and set a region loop, then proceed to build the GUIDs and bank files.

Note: for showroom banks, please set the format to Vorbis.

450
CHAPTER 8 - TRACK MODS FROM THE COMMUNITY
You can find hundreds of track mods Assetto Corsa. Most of them are conversions, but they’re really fun nonetheless.

You can download them online from websites & forums; that’s the easy part, you still have to install them to be able to drive them in the simulator, and that’s
even easier! We can also talk about how you can edit mods from other authors, so there’s plenty of things you can learn here.

8.1 - HOW TO INSTALL TRACKS (copied from cars, modify)

If you read CHAPTER 8, you may be aware that mods are packed in a compressed archive, so you just have to extract the contents inside it with the tools
mentioned at the beginning of this manual.

Let’s look at the whole process then, working with 7-Zip (granted that you already installed this or a similar tool on your PC).

After you downloaded your car mod, you have different ways to install it:

A. FASTEST: Click on the file in the Downloads tab of your browser and the archive will open automatically in 7-Zip; select only the main car folder (you
can recognize it because it’s the FINAL folder, page), then drag and drop it in one of the following paths (which you will have to open in a File Explorer
window), depending on the type of AC installation you have:
- STEAM default: C:\Program Files (x86)\Steam\steamapps\common\assettocorsa\content\tracks
- STEAM default if you installed AC in a different (secondary) drive: [Drive letter]:\SteamLibrary\steamapps\common\assettocorsa\content\tracks.
- STEAM custom: You changed the path during the AC install process. To locate it use the method shown in par. 2.2 of the AC User Guide (pag.).
- Pirated version: Locate the respective assettocorsa main folder (may be named Assetto Corsa) and extract the mod under ~root\content\tracks; if you
don’t remember where it is, right click on the AC icon you should have on your desktop and select “Open file path”.
B. PRECISE: Click on the “Show in folder” menu/drop-down menu/icon next to the downloaded file in your browser. Your downloads folder will pop up
and you will be able to open the archive from there. Then in 7-Zip, click on the Extract button and change the destination folder to one of the paths in
option A. Otherwise directly open your downloads folder, and do the same.
If you enabled 7-Zip integration with MS-Windows drop-down menus, you can also right-click on the file and select 7-Zip > Extract the files… >
choose the path.
Why is option B precise? Because dragging & dropping files can be glitchy and buggy, especially when rushing things. I know from personal
experience. You may find your files inside the wrong folders if you’re not careful.
C. SECURE: Same as B, but before opening or extracting the archive, scan it with your anti-virus software of choice.

Sometimes authors put in their package manuals and other kinds of stuff. Don’t copy those files in your AC assets, if you want to keep them just create a
special folder in your documents. In some case however, cars come with custom driver models, fonts and shaders, so you need to copy those (unless you
already have them). Be curious and look at what’s inside each folder. That’s the spirit.

Do not install mods automatically with Content Manager. It has an auto-install feature but it’s often buggy. You will avoid mistakes and errors with the
methods recommended here (A, B and C).

8.2 - HOW TO EDIT TRACKS

The basic principle around editing is that you aren’t the original creator of the mod. You want to obtain a custom or a better product for either yourself or the
community. Remember, always give credit to the authors of the assets you’re modifying.

You can use some tools to edit cars in either destructive or non-destructive ways.

451
 PART 4:
CLASSIFIED

452
CLASSIFIED… for now, it’s a bit too early… why are you here?

453
CHAPTER CLASSIFIED: Getting started with Assetto Corsa application development (WIP)
Starting with Assetto Corsa application development is not hard, but it is harder than it needs to be. The common wisdom seems to be to read the sample
applications that come with Assetto Corsa (in /apps/python/, there is a Chat and gMeter application), or to read the code behind some of the applications
being shared on the forums.

This certainly works, and is how I learned, but it takes more guess-and-test than should be necessary. For example, early on in reading the forum I heard of
something called py_log.txt, but it wasn't clear where to find it.

In this document, I pull back the curtain and explicitly show the basics. I assume you already know some Python. Other than a small note about Python's
treatment of global variables, I do not cover any Python.

Often, I will type AC as shorthand for Assetto Corsa.

I'm going to develop below an application called appName. You should, of course, name your application something more descriptive.

Preliminaries

Locations of interest
There are two folders you should be aware of:
 The Assetto Corsa installation directory. This is most likely to be found in your Steam directory. On Windows, this look like C:\Program Files
(x86)\Steam\steamapps\common\assettocorsa. You may have chosen to install AC elsewhere, and I trust you can find where that is.
 The Assetto Corsa documents directory. On Windows, this looks like C:\User\My Documents\Assetto Corsa\, where Useris replaced with your Windows
account name.

Each of these contains at least one subfolder of interest:

 In the installation directory, the interesting subfolder is /apps/. This is where the application is placed.
 In the documents directory, the subfolder of interest is /logs/. In this directory you will find both log.txt and py_log.txt.
log.txt is where AC logs everything about the execution of AC itself. Sometime this will contain relevant information about your application that AC logs
automatically.
py_log.txt is where AC places strings explicitly requested to be logged by running applications.

Basic workflow
The workflow of testing an application isn't the best. It can be slow going when you're making a lot of changes, especially if you make syntax or logical
mistakes. Try to be careful and ensure the code you're attempting to run is correct. You might want to look into something like pylint so you can find errors
in the code without having to run Assetto Corsa.

If something is wrong with your code, and error message might show up automatically in the in-game console or in py_log.txt. It will always show up in
log.txt. The best way to find an error in log.txt is by search for your application name, in this case appName, and reading the surrounding output.

I call an on-track event a session. I usually test in practise mode around a short track like silverstone-international, but it shouldn't matter what you choose.

Here is how I test my application:

 I edit the source code, then run AC and start a session.

 If there are no errors and the application was previously active on the screen, it will still be so. If something went wrong, it will have disappeared and
there will be a message somewhere as to why. If an error has occurred, I end the session. Otherwise, I continue.
 I do what I need to in order to test the application behaviour.
 When I find that I need to make changes, I end the session.

In either case - an error or a desired change - you don't have to exit Assetto Corsa. Instead, you can alt-tab out, change the code, and then start a new
session. This is faster than continuously starting and exiting the main Assetto Corsa application. It's still a bit of a drag having to exit and restart sessions, so
as I noted before try to be careful that at least the syntax of your code is correct before testing it. Otherwise, you wait around while starting a session only to
find out your application has failed to load.

It's a habit of mine to always check the console at the start of a session. If something in my application is wrong, there is likely to be a message in the
console about what went wrong. It's also often the case that the message in the console contains the line number in my application where the error was
found. If this is not the case, the error might instead be in py_log.txt orlog.txt. Again, you have a good change of finding a specific line number there, or at
worst a helpful error message.

Getting an application running

Create a folder in /apps/python/ with the name appname. Inside /apps/python/appname/, create a file appname.py. Open the file for editing.

454
A most basic application
First, note that a barebones application still needs a few imports. I won't keep embedding these in the code snippets below, so be aware that every
application should start off with the following imports:

import sys
import ac
import acsys

The most basic applications only takes a few lines of code. The AC plugin architecture will automatically execute certain functions in which it expects to find
your code. To begin an application, you must define a function as follows:

def acMain(ac_version):
...

The code for your application will go in place of the ellipses. For now, we'll insert the bare minimum code:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)
return "appName"

Actually, the bare minimum is probably just the return statement, but that application is not at all interesting.

If you run Assetto Corsa and start a session, you will find in the application sidebar an entry named appName. If you activate this, you will see a very basic
widget consisting of a 200x200 application window with the name appName at the top. Here is what you should see in the application sidebar:

ac.log and ac.console

The function ac.log writes to the file py_log.txt which I mentioned earlier.

The function ac.console writes to the Assetto Corsa console. To bring up the console, hit the Home key on your keyboard. Hit the key again to dismiss the
console.

The way you might use these functions is quite similar, so think of it this way:
 Use ac.log when you want the text to persist after the session has ended. This is helpful if you want to debug the application through lots of printed
statements.
 Use ac.console when you might want to read the output during the session. By bringing up the in-game console you can immediately view the
messages. Yes, you can alt-tab out and view the py_log.txt while the session is still running, but it's not nearly as pleasant.
These functions are both good targets to dump information that you're not quite sure about. Use them to figure out exactly that a piece of code is doing.

Extending the basic application

Let's change the code to the following:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")
return "appName"

Start a new session, and check that you see the text Hello, Assetto Corsa console! in the console when you hit the Homekey on your keyboard. Additionally,
ensure that Hello, Assetto Corsa application world! has shown up in the filepy_log.txt.

Unsurprisingly, both should be the case. There were no tricks here. One important thing to note is that your application does not have exclusive usage of
either the console or python log file. Other applications you have installed might also be sending text to the console or python log. You can either disable all

455
other application, or prefix all message with a unique string, e.g.*** Message from appName: so that you can quickly find the output from your application.

Adding labels to your application window

If you have an application window on your screen, you probably want to display some information within it. To do so, we can add labels to the window:

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)

Remember, your application windows is a 200x200 widget. Some of this space is taken up by the header, where the appNamelabel automatically appears.
This is why I set the label at position 30 vertically. I set it at 3 horizontally to offset it slightly from the border.

The code should now look like this:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)
return "appName"

and the application window should look like this:

Moving towards a more realistic application

So far, our application consists only of the application window and a static label. Let's add some dynamic behaviour.

The function acMain has setup our application window. To do something with it, we must use an additional functionacUpdate.

One important thing to note is that we're going to need to access the label l_lapcount from within acUpdate if we want to place dynamic information into it.
So far, the label has been a variable local to acMain. Since we're not the one callingacUpdate, we can't pass the label along to it as a parameter. Instead, we
must make l_lapcount a global variable. To do so, define it outside of acMain. Then, within acMain we must inform the function that l_lapcount is a global
variable. If we forget to do so, we'll create a local variable l_lapcount within acMain which will shadow the global variable, and any changes we make within
acMain will not be visible outside of it. Most importantly, if we forget to do this the actual label we placed in the application window in acUpdate would not
be available from acUpdate.

We'll also add a global variable lapcount which only needs to be accessible within acUpdate. The code should look like so:

l_lapcount=0
lapcount=0

def acMain(ac_version):
global l_lapcount

appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)
return "appName"

def acUpdate(deltaT):
global l_lapcount, lapcount
laps = ac.getCarState(0, acsys.CS.LapCount)
if laps > lapcount:
lapcount = laps
ac.setText(l_lapcount, "Laps: {}".format(lapcount))

acUpdate takes a parameter that is ???(Guess: ?milli?seconds since it was called last).

Note that within acUpdate we make a call ac.getCarState(0, acsys.CS.LapCount). This might look confusing at first since I never explained anything about it,
but it's just another function made available through our import of ac and acsys. I don't want to duplicate the official documentation, so please look at the
resources section at the end of this guide for a link to the official documentation. Eventually, you should read it so that you know what has been made

456
available for application development by the Assetto Corsa developers, but it's not important at the moment. You can continue on with this guide.

Now, after completing a lap your application window will look like this:

and so on as you complete laps.

You could, of course, also log this information to the console or the python log:

ac.log("{} laps completed".format(lapcount))

ac.console("{} laps completed".format(lapcount))

Additional functions called by Assetto Corsa

One additional function to note is acShutdown, which is called when the session is ended.

def acShutdown():
# ...
return

You'll want to add within acShutdown any code that should be completed before your application exits. For example, if there are outstanding database
modifications, you want to make sure you commit them and safely close the connection to the database.

You can also register callbacks for certain events. Two that I am aware of are ac.addOnAppActivatedListener andac.addOnAppDismissedListener. For
instance, you might define a function on_activation and register it by calling

ac.addOnAppActivatedListener(appWindow, on_activation)

It seems that acUpdate is always called, even when the application is dismissed. If this is not desirable, the idiom would be to check a flag within acUpdate
that is set in the callback registered with ac.addOnAppActivatedListener, so that you only run code when the application is activated.

Accessing Shared Memory

The Python API gives us access to some nice stuff, but there is a lot more than you might need access to in order to make your app. To get to this
additional information, you must access the shared memory structure made available by Assetto Corsa. Here is a quick tutorial on doing so:
 Add a directory within /apps/python/appname/ with a name of your choice. I use third_party.
 Add into this directory _ctypes.pyd and sim_info.py.
See Shared memory for Python applications (sim_info.py) for AC v0.20 for where to obtain these files.
 Insert the third_party directory into the python environment before using the import statement:
sys.path.insert(len(sys.path), 'apps/python/appname/third_party').
 Import from sim_info.py using from sim_info import info.
After doing so, you can get to any of the shared memory information using e.g. info.physics.fuel.

Exercise: Add an additional label to the application window and fill it with the current fuel in the tank. Update the value dynamically throughout the session
with a period shorter than once-per-lap.

If you can complete this, you have understood everything I tried to communicate by writing this document.

Enough, for now

That should cover the basics, and get you started writing Assetto Corsa applications. There is still a lot that you'll need to learn to make a non-trivial
application, but a good starting point is always helpful.
Also, please note that this is just one way to do it. In programming, like in everything else there are many solutions to the same problem, so feel free to
experiment your own ideas once you get the hang of it. There is nothing you could break.

457
CHAPTER CLASSIFIED: AC Python documentation
We’re decrypting info from the enemy. Everything is going as planned sir.
Jokes aside, the documentation was in a pretty rough state when I got my hands on it, many things aren’t clear. Also, the grammar doesn’t
help, I know. But for now, enjoy.

import ac
The following functions are available when you import “ac” module inside your python document.

ac.getCarState(<CAR_IDENTIFIER>, <INFO_IDENTIFIER> , /*OPTIONAL*/<OPTIONAL_IDENTIFIER>):

returns the <INFO_IDENTIFIER> type of information associated to car <CAR_IDENTIFIER>. The optional identifier can be omitted, it is used for special info
where they require a specific tire, as described in the following section. The <OPTIONAL_IDENTIFIER> and it can be one of the following values:
On the left a synthetic description is given using blue color:

FL, Front Left

FR, Front Right

RL, Rear Left

RR, Rear Right

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a scalar value:

SpeedMS, Current speed using Meters/Seconds [0, …]

SpeedMPH, Current speed using Miles/Hour [0, …]
SpeedKMH, Current speed using Kilometers/Hour [0, …]
Gas, Pression on the Gas pedal [0,1]
Brake, Pression on the Brake pedal [0,1]
Clutch, Pression on the Clutch pedal [0,1]
Gear, Current Gear [0,max gear]
BestLap, Best Lap in milliseconds [0, …]
CGHeight, Height of the center of gravity of the car from the ground [0, …]
DriftBestLap, Best Lap points in Drift mode [0, …]
DriftLastLap, Last Lap points in Drift mode [0, …]
DriftPoints, Current Lap points in Drift mode [0, …]
DriveTrainSpeed, Speed Delivered to the wheels [0, …]
RPM, Engine’s rotations per minute [0, …]
InstantDrift, Current drift points in Drift Mode [0, …]
IsDriftInvalid, Current Drift is valid/invalid in Drift Mode {0,1}
IsEngineLimiterOn, Engine Limiter On/Off {0,1}
LapCount, Current Session Lap count [0, …]
LapInvalidated, Is current Lap invalidated (by going out on the grass) {0, 1}
LapTime, Current LapTime in milliseconds [0, …]
LastFF, Last Force Feedback signal sent to the Wheel [0, …]
LastLap, Last Lap in milliseconds [0, …]
NormalizedSplinePosition, Position of the car on the track in normalized [0,1]
PerformanceMeter, Projection of how many seconds is the current time far from the current best lap [0, …]
Steer, Radians of steer rotation [2pi,2pi]
TurboBoost, Turbo gain on engine torque for specific vehicles [0,...]
Caster, Caster Angle in radians

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a 3D vector (with x,y,z

components):

AccG, Gravity acceleration on the vehicle’s GC x,y,z = [0, …]

LocalAngularVelocity, Get the angular velocity of the car, using the car as origin x,y,z = [0, …]
LocalVelocity, Get the velocity using the car as origin x,y,x = [0, …]
SpeedTotal, Get all the speed representation x= km/h, y = mph, z = m/s
Velocity, Current velocity vector x,y,z = [0, …]
WheelAngularSpeed, Current Wheel angular speed x,y,z = [0, …]
WorldPosition, Current Car Coordinates on map x,y,z = [0,...]

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a 4D vector (with w,x,y,z components):

CamberRad, The camber angle in Radiants for each tyre

CamberDeg, The camber angle in Degree for each tyre
SlipAngle, Slip angle, angle between the desired direction and the actual direction of the vehicle [0, 360], degrees.
458
SlipRatio, Slip Ration of the tyres x,y,z,w = [0,1]
Mz, Self Aligning Torque x,y,z,w = [0, …]
Load, Current load on each tyre x,y,z,w = [0,...]
TyreRadius, Radius of any Tyre x,y,z,w = [0,...]
NdSlip,
TyreSlip,
Dy,
CurrentTyresCoreTemp, Current core temperature of the tyres °C x,y,z,w = [0,...]
ThermalState, Current temperature of the tyres °C x,y,z,w = [0,...]
DynamicPressure, Current pressure of the tyres psi x,y,z,w =[0, …]
TyreLoadedRadius, Radius of the tyre under load x,y,z,w =[0, …]
SuspensionTravel, Suspension vertical travel x,y,z,w =[0, …]
TyreDirtyLevel, Quantity of dirt on the tyres x,y,z,w =[0, 10)

Using the following <INFO_IDENTIFIER>s combined with the <OPTIONAL_IDENTIFIER> ac.getCarState returns a 3D vector (with x,y,z components) related
to the <OPTIONAL_IDENTIFIER> wheel:

TyreContactNormal, Normal vector to tyre’s contact point (z)

TyreContactPoint, Tyre contact point with the tarmac
TyreHeadingVector, Tyre Heading Vector (x)
TyreRightVector, Tyre Right Vector (y)

Using the following <INFO_IDENTIFIER>s combined with the <OPTIONAL_IDENTIFIER> ac.getCarState returns a scalar vector (with x,y,z components)
related to the <OPTIONAL_IDENTIFIER> index O:

Aero , o=0 drag Coefficient

Aero, o=1 lift Coefficient front
Aero, o=2 lift Coefficient rear

Example : ac.getCarState(0,TyreContactPoint,FR). On failure ac.getCarState returns 0.

GENERAL INFO:

ac.getDriverName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the driver’s name of the <CAR_ID> car.
This function returns the car name on success, 1 otherwise.

ac.getTrackName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the track’s name where <CAR_ID> is running.
This function returns the track’s name on success, 1 otherwise.

ac.getTrackConfiguration(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the track’s configuration where <CAR_ID> is running.
This function returns the track’s name on success, 1 otherwise.

459
ac.getCarName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the car’s name of the <CAR_ID> car.
This function returns the car name on success, 1 otherwise.

ac.getLastSplits(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a Python List the car’s last splits of the <CAR_ID> car.
This function returns the Python list with the splits on success, 1 otherwise.

ac.isCarInPitline(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car.
This function returns 1 if the car is currently in the Pitline

ac.isCarInPit(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car.
This function returns 1 if the car is currently in the Pitbox

ac.isConnected(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns 1 if the car is currently connected

ac.getCarBallast(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns the ballast value of the car

ac.getCarMinHeight(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns the minimum height of the car

ac.getServerName()
This function returns the name of the joined server

ac.getServerIP()
This function returns the IP of the joined server

ac.getServerHttpPort()
This function returns the Http port of the joined server

ac.getServerSlotsCount()
This function returns total number of occupied slot in the server

ac.getCarsCount()
This function returns the session’s max number of cars.

ac.getCarLeaderboardPosition(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns position of the car on the Leaderboard

ac.getCarRealTimeLeaderboardPosition(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns position of the car on realtime

ac.getCarFFB()
This function returns the FFB Gain value for the player current car

ac.setCarFFB(<VALUE>)
<VALUE>is the value taht will be added to the current FFB gain
This function sets the FFB Gain value for the player current car

CAMERA MANAGEMENT

ac.setCameraMode(<INFO_IDENTIFIER>)
<INFO_IDENTIFIER> can be (CM):
Cockpit
Car
Drivable
Track
Helicopter
OnBoardFree

460
Free
Random
ImageGeneratorCamera
Start

ac.getCameraMode()
This function returns a <INFO_IDENTIFIER> above

ac.isCameraOnBoard(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns 1 on success, 1 otherwise.

ac.setCameraCar(<CAMERA_ID>,<CAR_ID>)
<CAMERA_ID> must be the F6 camera index
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns 1 on success, 1 otherwise.

ac.getCameraCarCount(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This function returns the number of F6 cameras, 1 otherwise.

ac.focusCar(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car
This method get switch the actor to the selected car
This function returns 1 on success, 1 otherwise.

ac.getFocusedCar()
This method get the selected car index

DEBUG

ac.log(<VALUE>):
<VALUE> must be a string
Use ac.log if you want to send some text to the AC log.txt file
The function returns 1 on success

ac.console(<VALUE>)
<VALUE> must be a string
Use ac.console to send a string to the AC console
The function returns 1 on success

GENERAL APP MANAGEMENT:

ac.newApp(<VALUE>)
<VALUE> must be a string
Creates a new app and returns the corresponding Identifier.
returns the App ID on success, 1 otherwise

ac.setTitle(<CONTROLO_IDENTIFIER>,<TITLE>)
<TITLE> must be a string, <CONTROL_IDENTIFIER> must be a form
This function will set the title of the specified App by <CONTROL_IDENTIFIER>.
The function returns 1 on success, 1 otherwise

ac.setSize(<CONTROLO_IDENTIFIER>,<WIDTH>,<HEIGHT>)
<WIDTH>,<HEIGHT> must be a floating point numbers
This function will set the size of a control specified by <CONTROL_IDENTIFIER> .
The function returns 1 on success, 1 otherwise

ac.addLabel(<CONTROL_IDENTIFIER>,<VALUE>)
<VALUE> must be a string
It is possible to add a label to a Window, we need to pass the Window to ac.addLabel and the label name.
The function returns 1 on success, 1 otherwise

ac.setPosition(<CONTROLO_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers
Use ac.setPosition to set the control's position specified by <CONTROL_IDENTIFIER> in the app.
The function returns 1 on success, 1 otherwise

461
ac.setIconPosition(<CONTROLO_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers, <CONTROL_IDENTIFIER> must be a form
Use ac.setPosition to set the new icon’s position instead of the default one.
The function returns 1 on success, 1 otherwise

ac.setTitlePosition(<CONTROLO_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers, <CONTROL_IDENTIFIER> must be a form
Use ac.setPosition to set the new title’s position inside the app.
The function returns 1 on success, 1 otherwise

ac.getPosition(<CONTROLO_IDENTIFIER>)
<CONTROL_IDENTIFIER> is the identifier of a control
Use ac.getPosition to get the control's position in the parent window, this function returns a python tuple width,height.
The function returns the position as a tuple x,y on success, 1 otherwise

ac.setText(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string, <CONTROL_IDENTIFIER> is the control that we want to set the text to
Set the text of the control specified by <CONTROL_IDENTIFIER>, with the <VALUE> text passed as an argument.
The function returns 1 on success, 1 otherwise

ac.getText(<CONTROLO_IDENTIFIER>)
<CONTROL_IDENTIFIER> is the control that we want to get the text from
Use ac.getText to get the control's text.
This function returns the coordinates x,y of the control on success, 1 otherwise

ac.setBackgroundOpacity(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a floating point value between 0 and 1
Use ac.setBackgroundOpacity to change the alpha channel of the desired control.
The function returns 1 on success, 1 otherwise

ac.drawBackground(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1
Use ac.drawBackground to set the background visible (1)(DEFAULT) or transparent (0)
The function returns 1 on success, 1 otherwise

ac.drawBorder(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1
Use ac.drawBorder to draw the border of the desired control (1) (DEFAULT) or not (0)
The function returns 1 on success, 1 otherwise

ac.setBackgroundTexture(<CONTROL_IDENTIFIER>, <PATH>)
<PATH> starts from Assetto Corsa root folder, <CONTROL_IDENTIFIER> must be a control identifier
Use ac.setBackgroundTexture to draw a specified texture stored in the path specified by <PATH> as background image for the control specified by
<CONTROL_IDENTIFIER>.
The function returns 1 on success, 1 otherwise

ac.setFontAlignment(<CONTROL_IDENTIFIER>, <ALIGNMENT>)
<ALIGNMENT> is one of the following strings:
“left “
“right”
“center”
Use ac.setFontAlignment to set the font alignment of the control text as specified by the <ALIGNMENT> string.
The function returns 1 on success, 1 otherwise

ac.setBackgroundColor(<CONTROL_IDENTIFIER>, <R>,<G>,<B>)
<PATH> starts from Assetto Corsa root folder
Use ac.setBackgroundColor to set the background color of the window as specified by the R,G,B values
The function returns 1 on success, 1 otherwise

ac.setVisible(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1
It is possible to hide the object using the function ac.setVisible with VALUE set to 1.
The function returns 1 on success, 1 otherwise

ac.addOnAppActivatedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script, <CONTROL_IDENTIFIER> must be an app.

462
This method set the <VALUE> function as callback function for the event of app selection on the task bar.
The function returns 1 on success, 1 otherwise

ac.addOnAppDismissedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script, CONTROL_IDENTIFIER> must be an app.
This method set the <VALUE> function as callback function for the event of app deselection on the task bar.
The function returns 1 on success, 1 otherwise

ac.addRenderCallback(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
This method set the <VALUE> function as callback function for the finished rendering event.
The function returns 1 on success, 1 otherwise

ac.setFontColor(<CONTROL_IDENTIFIER>,<R>,<G>,<B>,<A>)
<CONTROL_IDENTIFIER> must be a Controlidentifier, <R>,<G>,<B>,<A> are the color value scaled from 0 to 1
This function returns 1 on success, 1 otherwise

ac.setFontSize(<CONTROL_IDENTIFIER>, <VALUE>)
This method set <VALUE> as new new size of the control’s font.
The function returns 1 on success, 1 otherwise

ac.initFont(0, <FONTNAME>, <ITALIC>, <BOLD>)

This method loads the font in memory (stored as font+italic+bold). Should be used at the initialization of the application. The font needs to be saved in the
“content/fonts” folder.
<FONTNAME> must be the name of the base font (real name, not filename, so it can be “Arial”) <ITALIC> must be a 0 for nonitalic font, 1 for italic font
(instance will be “Arial Italic”) <BOLD> must be a 0 for nonbold font, 1 for bold font (instance will be “Arial Bold” or “Arial Italic Bold” is also italic)
The function returns 1 on success, 1 otherwise

ac.setCustomFont(<CONTROL_IDENTIFIER>, <FONTNAME>, <ITALIC>, <BOLD>)

This method create or replace the font of a control. Should not be done without calling “iniFont”. The font needs to be saved in the “content/fonts” folder.
<CONTROL_IDENTIFIER> is the control owner of the font <FONTNAME> must be the name of the base font (real name, not filename, so it can be “Arial”)
<ITALIC> must be a 0 for nonitalic font, 1 for italic font (instance will be “Arial Italic”) <BOLD> must be a 0 for nonbold font, 1 for bold font (instance will be
“Arial Bold” or “Arial Italic Bold” is also italic)
The function returns 1 on success, 1 otherwise

SPECIFIC CONTROL MANAGEMENT:

Button:
ac.addButton(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string, <CONTROL_IDENTIFIER> must be a form
The function adds a Button to the window specified by <CONTROL_IDENTIFIER>
The function returns the Button ID on success, 1 otherwise

ac.addOnClickedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined in this file
It is possible to associate the button with an event to trigger when it is clicked using this function
The function returns 1 on success, 1 otherwise

Graph:
ac.addGraph(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string
The function adds a Graph to the window specified in <CONTROL_IDENTIFIER>
The function returns the Graph ID on success, 1 otherwise

ac.addSerieToGraph(<CONTROL_IDENTIFIER>, <R>,<G>,<B>)
<R>,<G>,<B> must be floating point numbers between 0 and 1
To plot some data it is necessary to add a Serie. A serie is a succession of points to plot on the graph.
When adding a serie you must specify the color of the serie as argument
The function returns 1 on success, 1 otherwise

ac.addValueToGraph(<CONTROL_IDENTIFIER,<SERIE_INDEX>,<VALUE>)
<SERIE_INDEX> is the Serie ID in the graph that where <VALUE> will be added.
The function returns 1 on success, 1 otherwise

ac.setRange(<CONTROL_IDENTIFIER>,<MIN_VALUE>,<MAX_VALUE>,<MAX_POINTS>)
<MIN_VALUE>,<MAX_VALUE>,<MAX_POINTS> must be floating point numbers

463
In order to plot the data inside the Graph it is necessary to specify the amplitude of the ordinates and the maximum number of points to store in memory
The function returns 1 on success, 1 otherwise

Spinner:
ac.addSpinner(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string
It is possible to add a Spinner using the function
The function returns the Spinner ID on success, 1 otherwise

ac.setRange(<CONTROL_IDENTIFIER>, <MIN_VALUE>,<MAX_VALUE>)
<MIN_VALUE>,<MAX_VALUE> must be floating point numbers
It is possible to set the min and max values of the Control:
The function returns 1 on success, 1 otherwise

ac.setValue(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be floating point number
This function set the "value" parameter of the specific Control if this is an available parameter.
This function affects controls like Spinner, Progress Bar or Check Box
The function returns 1 on success, 1 otherwise

ac.getValue(<CONTROL_IDENTIFIER>)
<VALUE> must be floating point number
This function returns the "value" parameter of the specific Control if this is an available parameter.
The function returns the value on success, 1 otherwise

ac.setStep(<CONTROL_IDENTIFIER>,<VALUE)
<CONTROL_IDENTIFIER> must be a Spinner ID <VALUE> must be floating point number
Set the value added or subtracted when the + or button is pressed in a Spinner controller.
The function returns 1 on success, 1 otherwise

ac.addOnValueChangeListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
It is now possible to associate the spinner with an event to trigger when one of the two buttons is pressed
The function returns 1 on success, 1 otherwise

Progress Bar :
ac.addProgressBar(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string
It is possible to add a Progress Bar using the function
The function returns the Progress Bar ID on success, 1 otherwise

Input Text :
ac.addInputText(<CONTROL_IDENTIFIER>, <VALUE>)
ac.addTextInput(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string
It is possible to add an Input Text Field using the function
The function returns the Input Text ID on success, 1 otherwise

ac.setFocus(<CONTROL_IDENTIFIER>, <FOCUS>)
<CONTROL_IDENTIFIER> must be an Input Text, <FOCUS> must be 0 or 1
If FOCUS is 1, this function sets the Input Text as first responder.
The function returns 1 on success, 1 otherwise

ac.addOnValidateListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
It is possible to associate the <CONTROL_IDENTIFIER> with an event to trigger when the enter key is pressed
The function returns 1 on success, 1 otherwise

List Box :
ac.addListBox(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> must be a window identifier
This method adds a List Box to the window specified by CONTROL_IDENTIFIER
The function returns the ListBox ID on success, 1 otherwise

ac.addItem(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> must be a ListBox identifier

464
This method adds a List Box item to the List Box specified.
The item's label is specified by the Name string.
This function returns the ListBox Item ID on success, 1 otherwise

ac.removeItem(<CONTROL_IDENTIFIER>,<ID>)
<CONTROL_IDENTIFIER> must be a ListBox identifier
This method removes from the List Box the item with ID as identifier
This function returns the size of the List Box on success, 1 otherwise

ac.getItemCount(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier
This function returns the size of the List Box on success, 1 otherwise

ac.setItemNumberPerPage(<CONTROL_IDENTIFIER>,<NUMBER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <NUMBER> is the number of element to be displayed desired for each page
This function sets the number of element displayed for each page in a List Box.
This function returns 1 on success, 1 otherwise

ac.highlightListBoxItem(<CONTROL_IDENTIFIER>,<ID>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ID> is the element to be selected
This function sets the list box item with <ID> as identifier as selected.
This function returns 1 on success, 1 otherwise

ac.addOnListBoxSelectionListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
Control identifier must be a List Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of item SELECTION inside a ListBox.
The callback function receives as input parameters the Item's NAME and its ID (his position inside the listbox).
The function returns 1 on success, 1 otherwise

ac.addOnListBoxDeselectionListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
Control identifier must be a List Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of item DESELECTION inside a ListBox.
The callback function receives as input parameters the Item's NAME and its ID (his position inside the listbox).
The function returns 1 on success, 1 otherwise

ac.setAllowDeselection(<CONTROL_IDENTIFIER>,<ALLOW_DESELECTION>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ALLOW_DESELECTION> must be 0 or 1
Passing true as a parameter, when the user clicks on a selected item the item is deselected.
In this way there could be 0 or 1 selected item at a given time.
If also ac.setAllowMultiSelection is set as true there can be more than 1 selected items at a given time.
This function returns 1 on success, -1 otherwise

ac.setAllowMultiSelection(<CONTROL_IDENTIFIER>,<ALLOW_MULTI_SELECTION>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ALLOW_MULTI_SELECTION> must be 0 or 1
Passing true as a parameter, when the user clicks on a different item the item is added to the selected item list.
In this way there could me more than one selected items at a given time
This function returns 1 on success, 1 otherwise

ac.getSelectedItems(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier
This method returns the list of the selected items at a given time.
This function returns a Python list of Long on success, 1 otherwise

Check Box : ac.addCheckBox(<CONTROL_IDENTIFIER>,<VALUE>)

<CONTROL_IDENTIFIER> must be a form ,<VALUE> must be the form’s name
This function adds a checkbox to the current form passed as <CONTROL_IDENTIFIER>.
The function returns the checkbox created on success, 1 otherwise

ac.addOnCheckBoxChanged(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script
Control identifier must be a Check Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of checkbox SELECTION or DESELECTION inside a ListBox.
The callback function receives as input parameters the CheckBox's NAME and its value, 1 if selected, 1 otherwise.
The function returns 1 on success, 1 otherwise
465
Text Box :
ac.addTextBox(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> form identifier, <NAME> text box name
This method adds a text box (scrollable if the text is longer than the textbox, to the current form.
THIS CONTROL IS NOT CURRENTLY WORKING YET, so no set text has been exposed

GRAPHICS AND RENDERING :

ac.newTexture(<PATH>)
<PATH> must be a string, the path is considered from AC installation directory.
This method loads in memory the texture specified by path.
This method returns the texture identifier on success, 1 otherwise.

ac.glBegin(<PRIMITIVE_ID>)
<PRIMITIVE_ID> must be an int corresponding to the following ints:
0 : Draw lines
1 : Draw lines Strip
2 : Draw triangles
3 : Draw quads.
Begin a rendering of the specified type.
This function returns 1 on success, 1 otherwise

ac.glEnd(void)
Finishes the render of a previous specified primitive
This function returns 1 on success

ac.glVertex2f(<X>,<Y>)

<X>,<Y> must be a floating point numbers

Adds a 2d point to the rendering queue.
This function returns 1 on success, 1 otherwise

ac.glColor3f(<R>,<G>,<B>)

<R>,<G>,<B> rgb coordinates scaled from 0 to 1, must

be a floating point numbers set the current rendering color to <R>,<G>,<B> color. This function returns 1 on success, 1 otherwise

ac.glColor4f(<R>,<G>,<B>,<A>)

<R>,<G>,<B> rgb coordinates scaled from 0 to 1,

<A> alpha component from 0 to 1, all the values must be a floating point numbers set the current rendering color to <R>,<G>,<B> color, with <A> as
transparency. This function returns 1 on success, 1 otherwise

ac.glQuad(<X>,<Y>,<WIDTH>,<HEIGHT>)

<X>,<Y>,<WIDTH>,<HEIGHT> must be a floating point numbers draw a quad quickly without using glBegin, … , glEnd This function returns 1 on success, 1
otherwise

ac.glQuadTextured(<X>,<Y>,<WIDTH>,<HEIGHT>,<TEXTURE_ID>)
<X>,<Y>,<WIDTH>,<HEIGHT> must be a floating point numbers, <TEXTURE_ID> is the id of the texture previously loaded. draw a quad quickly without
using glBegin, … , glEnd This function returns 1 on success, 1 otherwise
new in this document as of 2020:
ac.isAcLive() as bool
ac.restart()
ac.isCarInPitlane() as bool # same as ac.isCarInPitline()
ac.getCarSkin(carID) as string
ac.getDriverNationCode(carID) as string
ac.getCurrentSplits(carID) as List
ac.getTrackLength(carID) as float
ac.getWindSpeed() as float
ac.getWindDirection() as float
ac.isAIControlled() as bool
ac.getCarEngineBrakeCount() as int
ac.getCarPowerControllerCount() as int
ac.freeCameraSetClearColor(r, g, b, alpha)
ac.freeCameraMoveForward(float)
ac.freeCameraMoveRight(float)

466
ac.freeCameraMoveUpWorld(float)
ac.freeCameraRotatePitch(float)
ac.freeCameraRotateHeading(float)
ac.freeCameraRotateRoll(float)
ac.sendChatMessage(string_msg)
ac.addOnChatMessageListener(ac_WindowID, callBackFunction)
also changed wrong ac.a ddInputText( ) to ac.addTextInput() on page 11.
CustomShadersPatch adds more python funtions, see https://github.com/ac-customshaders-patch/acc-extension-
config/wiki/Python-Apps-%E2%80%93-New-functions

The conclusion I believe

That being said, it's not rocket science. It all depends on how much time and energy you wish to put into this. You will encounter difficulties, or even be
stuck at times. Just don't give up, and you'll manage.

467
CREDITS

468
THE CREDITS WILL BE UPDATED SLOWLY
Author, editor, designer and producer of this manual:
A&M (aka brotto marco on RaceDepartment; known as A_M on GtPlanet) - community member, modder and mechanical engineering student
(I have to at least take some credit for my work, yeah, let’s make it bigger, bigger, bigger! The Moon is almost rising…)

From Kunos Simulazioni SRL, developers of AC, authors of various posts in the official forums and creators of the Kunos AC Pipeline 2.0:
Stefano Casillo (@stefanoCasillo) - creator of AC and founder of Kunos Simulazioni SRL
Aristotelis Vasilakos (@aris) - lead physics modeling
Gergő Panker (@pankykapus) - lead 3D artist, vehicle production management
Gianluca Miragoli (@yashugan) - lead 3D artist, technical lead
Manuel Darin (@6S.Manu) - staff programmer, beta testing management
Marc Orphanos (@the_meco) - external 3D artist, driver rig

- Greetings to Simone Trevisiol (@Si3v - lead 3D artist, tracks creation) for his old tutorial on the SDK editor: https://www.youtube.com/watch?v=qj3z_yzdwbs
- Also, special thanks to Giovanni Romagnoli (game core programmer) for the old AC Python documentation: https://docs.google.com/document/d/13trBp6K1TjWbToUQs_nfFsB291-
zVJzRZCNaTYt4Dzc/pub and to fughettaboutit aka leBluem for his corrections on that source.

Forums:
Keep in mind that the sources listed may have inaccuracies, errors and discrepancies, between them and with respect to the contents of this book. It is a consequence of the philologist’s work.

Threads from www.assettocorsa.net, the official AC forums by Kunos:

 AC system requirements: https://www.assettocorsa.net/forum/index.php?faq/assetto-corsa-minimum-requirements.1
 AC keyboard shortcuts: https://www.assettocorsa.net/forum/index.php?faq/keyboard-shortcuts.18/
 AC tire model v10: https://www.assettocorsa.net/forum/index.php?threads/tyre-model-v10-specs.36686/
 Car materials/shaders: https://www.assettocorsa.net/forum/index.php?threads/car-materials-shaders-modelling-stuff-add-your-knowledge-here.19704
 Track materials/shaders: https://www.assettocorsa.net/forum/index.php?threads/track-materials-shaders.10174/
 Analog/digital instruments and lights: https://www.assettocorsa.net/forum/index.php?threads/analog-digital-instruments-lights-q-a-request-official-support-here-check-first-post.12249
 Techniques for track making: https://www.assettocorsa.net/forum/index.php?threads/proper-technique-in-track-making-plus-tips.27180
Threads from www.racedepartment.com (RD):
 “Assetto Corsa - FAQ & Game Description”: https://www.racedepartment.com/threads/assetto-corsa-faq-game-description.91105
 “AC: Stuttering reduction”: https://www.racedepartment.com/threads/ac-stuttering-reduction.88597
 “Making new and correct colliders is easy - PDF tutorial”: https://www.racedepartment.com/threads/making-new-and-correct-colliders-is-easy-pdf-tutorial.208067
 “How to MOD! (Links & ref)”: https://www.racedepartment.com/threads/how-to-mod-links-ref.141062
 “Explanation of values in tyres.ini”: https://www.racedepartment.com/threads/explanation-of-values-in-tyres-ini.167883
 “The "What Are You Working On?" Thread”: https://www.racedepartment.com/threads/the-what-are-you-working-on-thread.126119/page-604
 “Change a car Mod‘s aero drag”: https://www.racedepartment.com/threads/change-a-car-mod%E2%80%98s-aero-drag.200328
 “Any Aero.ini, lut experts? building wings from scratch”: https://www.racedepartment.com/threads/any-aero-ini-lut-experts-building-wings-from-scratch.191889
 “Skin "Priority"..what is that priority value for ??”: https://www.racedepartment.com/threads/skin-priority-what-is-that-priority-value-for.127910

- The following users will be mentioned due to the useful posts and info they provided: AccAkut, LilSki, mantasisg, garyjpaterson, Ben O’Bro, Stereo, mclarenf1papa,
Brownninja97, Sven Hielscher, DanTDBV, peterboese
- Also, special thanks to Navigator for letting me know of the existence of the Fmod Bank Tools.
Threads from www.assettocorsamods.net:
 “Basic Guide - Your FIRST car in Assetto Corsa” by Luchian: https://assettocorsamods.net/threads/your-first-car-in-assetto-corsa-basic-guide.1019
 Editor layout/resolution debug help by Luchian: https://assettocorsamods.net/threads/loading-track-in-game.881/#post-4102

Other sources:
- AC system requirements: https://www.assettocorsa.it/system-requirements
- About the AC 1.16.4 update:
https://steamcommunity.com/app/244210/discussions/0/2794999575659541610/?ctp=4#c2794999575672291339
https://steamcommunity.com/app/244210/discussions/0/2794999575672538035

- Various definitions and articles:

https://en.wikipedia.org/wiki/Modding
https://en.wikipedia.org/wiki/Central_processing_unit
https://en.wikipedia.org/wiki/Graphics_processing_unit
https://web.archive.org/web/20060324123541/http://management.silicon.com/government/0%2C39024677%2C39117891%2C00.htm
https://en.wikipedia.org/wiki/Software_bug
https://en.wikipedia.org/wiki/Graphical_user_interface
https://en.wikipedia.org/wiki/HUD_(video_gaming)
https://en.wikipedia.org/wiki/Texture_mapping
https://en.wikipedia.org/wiki/Virtual_reality
https://en.wikipedia.org/wiki/Video_post-processing
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/DirectX
https://en.wikipedia.org/wiki/Head-up_display
https://en.wikipedia.org/wiki/Frame_rate

469
https://en.wikipedia.org/wiki/Computer_graphics
https://en.wikipedia.org/wiki/Virtual_private_network
https://en.wikipedia.org/wiki/Downloadable_content
https://en.wikipedia.org/wiki/Assetto_Corsa
https://www.gamersnexus.net/dictionary/7-game-graphics-settings/41-v-sync

- All credits for text and illustrations of paragraph “4.7 - Driving techniques” of PART 2 belong to Rick Haslam, Nick Stokes and Sarah Warburton, authors of the Grand Prix 2
user manual – a game by Geoff Crammond. All rights © 1995 MicroProse
- About mesh topology/optimization:
https://sites.stat.washington.edu/wxs/Siggraph-93/siggraph93.pdf
https://blenderbasecamp.com/home/what-is-mesh-topology-in-3d-modeling/
https://www.avalab.org/shoequest-ii-box-model/

- About the making of 3D colliders with 3DsMax: tutorial “How to make car collider | Assetto Corsa” by M9mentum (YouTube): https://www.youtube.com/watch?v=Wo7ncL_MYzg
- Additional physics information: Girellu, repository about Assetto Corsa by archibaldmilton: https://github.com/archibaldmilton/Girellu
- A lot of info from the official AC Custom Shaders Discord server. The following users will be mentioned due to the useful info they provided: JPG_18; Stereo; peterboese
- “Sound Modelling Tutorial #1 - Honing Your Attention to Detail Pt.1” by SHR Modding – Link of his tutorial: https://www.youtube.com/watch?v=tS-H-CGn--
s&list=PLVycee5B29McufS3nLwfHsgbbulVVgQFb
Sound: Citations
World Health Organization, WHO-ITU global standard for safe listening devices and systems, 2019. Retrieved from https://www.who.int/deafness/make-listening-
safe/standard-for-safe-listening/en/.

U.S. Environmental Protection Agency, Office of Noise Abatement and Control. (1974, March). Information on levels of environmental noise requisite to protect public
health and welfare with an adequate margin of safety. Retrieved from https://nepis.epa.gov/Exe/ZyPDF.cgi/2000L3LN.PDF?Dockey=2000L3LN.PDF [PDF].

Bibliography:
Photos and illustrations:
Front cover:
- Alfa Romeo 33 Stradale, official content by Kunos Simulazioni SRL, on the Shutoko Revival Project track by Soyo; image shot by A&M
- Audi Sport Quattro S1 E2, official content by Kunos Simulazioni SRL, on Black Cat County track by Kunos; image shot by A&M
- Ferrari SF15-T, official content by Kunos Simulazioni SRL, on the Drag 2000m track by Kunos; image shot by A&M
Title covers:
- “Garden of Books”, AI-generated image, created by A&M with Dream.ai – Wombo
- “Forgotten Nature”, AI-generated image shown in the titles of PART 1, created by A&M with Dream.ai – Wombo
- Alfa Romeo P2 Biposto, mod by A&M, shown in the titles of PART 2, on the Industrial showroom by Kunos; image shot by A&M, mod currently WIP, not publicly released
- Lamborghini Miura P400 SVR, mod by Velo, shown in the titles of PART 3, on the Nurburgring 1967 track mod by WilliamRiker (aka WilliamTRiker); image shot by A&M
- “The Arc of Decay”, AI-generated image shown in the titles of CREDITS, created by A&M with Dream.ai - Wombo
Back cover:
- Auto Union Type C, mod by Gary Paterson (garyjpaterson on RaceDepartment) on the Test Pad track mod by Stereo; image shot by A&M
Illustrations:
- Safety Car mod shown in Fig. 0.3 (top left) by Gary Paterson (on RaceDepartment); image shot by A&M
- Lego Hot-Rod #2 mod shown in Fig. 0.3 (top right) by PenguinActually (on RaceDepartment); image shot by A&M
- Ape Proto "Terrorcarro" mod shown in Fig. 0.3 (bottom left) by Pessio (on RaceDepartment); image shot by A&M
- Test Plane mod shown in Fig. 0.3 (bottom right) by the_meco (on RaceDepartment); image shot by A&M
- Ferrari 250 GTO Series II mod shown in Fig. 1.2 by Legion & AC Legends; image shot by A&M
- Abarth 500 EsseEsse shown in Fig. 1.4 & 2.10 by Kunos
- Delage 2LCV 1923 mod shown in Fig. 1.7 & 1.8 by Liam aka Nicecuppatea (on RaceDepartment); image shot by A&M

A special thanks goes to these people for their support and participation to this project:
Ben O’ Bro (RD) Navigator (RD) Graham Botha (RD) Sven Hielscher (RD)

470
“I will achieve my goals, even if some people don’t believe in me because they’re too self-centred to try and do it. I will be the last one to laugh, and I definitely won’t hear the echo of my voice.
Never mess with Italians!”

“I’m only licenced to die, like us all”

A&M

Disclaimer. Safety & Copyright Notice

Included within the resources of this manual may be copyrighted material, the use of which has not always been specifically authorized by the copyright owner(s). The author believes this
constitutes a ‘fair-use’ of any copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the contents of this manual are
distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes. If you wish to use copyrighted material from this
manual for purposes of your own that go beyond ‘fair use’, you must obtain permission from the copyright owner(s). Any copyright logo, watermark or reference in this manual, unless belonging to
the respective owners mentioned in the CREDITS, is not registered, and its purpose is to act only as a deterrent against copy.

The material and information contained on this manual is for general information purposes only. You should not rely upon the material or information on the manual as a basis for making any
business, legal or any other decisions. Whilst the author endeavours to ensure that accurate information is disseminated through this medium and to keep said information up to date and correct,
he makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability or availability with respect to the manual or the information,
products, services or related graphics contained on the manual for any purpose.

The user assumes all responsibility and risk for the use of this manual. The author accepts no liability or responsibility to any person as a consequence of any reliance upon the information
contained in this manual. Under no circumstances, including negligence, shall anyone involved in creating or maintaining this manual be liable for any direct, indirect, incidental, special or
consequential damages, or loss profits that result from the use or inability to use the manual and/or any website linked to this manual. Nor shall they be liable for any such damages including, but
not limited to, reliance by a reader on any information obtained via the manual; or that result from mistakes, omissions, interruptions, deletion of files, viruses, errors, defects, or failure of
performance, communication failure, theft, destruction or unauthorised access. States or Countries which do not allow some or all of the above limitations of liability, liability shall be limited to the
greatest extent allowed by law.

471
“Happiness is when you win a race against yourself. If you follow another you’re always behind.”

© 2023 A&M. All rights reserved.

472