The main priority of this tutorial is to give those learning the modding scene the best possible start. At the same time we would like to provide experienced users with an understanding of additional features new to rFactor.
If you are new to modding, please take a few minutes to go through some general tips.
To get started, we will take a look at rFactor from a hierarchical point of view.
The above diagram shows rFactor from a text file dependancy point of view.
Let's start with the configuration file (config.ini) located in your
main rFactor directory. The config.ini contains entries that define
directories where particular files are stored for the executable file.
This file rarely needs to be changed when creating new mods, however it
has been left possible for you to create own configuration files. The
config file allows the use of different directory structures. Note: Using
a different circuits directory is not recommended in most circumstances.
If you do this, you are likely to consume significantly more HDD
space. To help reduce the need for this, new to rFactor are some extra
features which enable more independence with current folder structures. In
turn we hope that this will translate to an increased number of mods which
will now be executable from the main shortcut, thus increasing convenience
for the player, and simultaneously reducing HDD consumption.
Regarding circuits, we would like new tracks to follow some
conventions.
As per ISI Mike D's recommendation the following format
should be used. Let's use Daytona for this example. When building a new
track it is best to model the entire circuit, including all variants in
the main folder. As a subfolder we can then have different layouts and
sponsored versions. However, all the track pieces and textures should be
contained in the DAYTONA.MAS and DAYTONAMAP.MAS files. Now, in the Daytona
folder, there would sub-folders. These would corespond to different events
held at the track. See Diagram:
TRACKS
___|
___|___DAYTONA
___|___|
___|___|___Daytona500
___|___|___BudShootout
___|___|___Pepsi400
___|___|___Rolex24hrs
___|___|___ect.
___|___|___ect.
In each of those folders there would be a .scn file, an .aiw file, a .cam file, and a .gdb file that would call the proper pieces and set up the proper format for the race listed.
Now, if someone wants to make a new event, they just add a new event folder to the Daytona Track folder. They could even throw in a new mas file if they wanted different textures or to add cones or barricades, and just order the scn file properly in order for them to override the default textures.
I'd like to see things move away from the whole "I changed the textures lets call this a new track" concept, because that leads to confusion. rFactor is designed to be the next step in racing sim/mod platforms...it's probably a good time to maybe think about advancing some of the concepts that govern the mod community end as well.
The next file dependency for rFactor is the *.PLR player file. The player file maintains records of all player settings/configurations. By default, this file is located in the UserData folder. Again, this for the most part does not require alterations when creating mods. Regarding rFactor, we have separated multiplayer and controller configurations as new multiplayer.ini & controller.ini files. This should allow users to exchange preferences which they find optimal. Controller preferences can be used by pasting them into your UserData\CONTROLLER folder. These can then be loaded from the menu. rFactor no longer requires alterations to the player file when increasing field sizes either. The maximum field size limit is no longer hard-coded into the game. Instead, it is now adjustable in the *.RFM file. By default the *.rFm is located in the rFm folder.
All mods containing a unique championship will require changes to the *.RFM file. For those familiar with older ISI products, you will realise the *.RFM file as the replacement for season *.GDB files in rFactor. The RFM defines the details of the championship including tracks available, season order of tracks, vehicles participating and so forth. There are still *.GDB files in rFactor; however these are now exclusively used for tracks.
The next file, the SCN file describes the properties of tracks used in
rFactor. These details and properties include locations and useages of MAS
files, light emitters, model files, etc. Everything to do with tracks is
described in either the SCN file, the AIW file, the GDB file, the CAM
file, or the terrain.tdf file.
Track
Creation & Conversion.
The SCN (Scenery) file contains;
- Details to the locations of permitted MAS files
- References to, and properties of GMT model files
- Draw distances
The AIW (Artificial Intelligence Waypoint) file contains;
- AI Waypoints
- Grid/Pit lane locations
- AI speed
- Fuel consumption estimate
- Track fog air color/density, etc.
GDB (Game DataBase) file contains;
- Track descriptions and details
- Pit lane speeds, session times and durations
- Geographical location, latitude & facing direction, time of year date, start line altitude???
- Lighting levels at night, morning, etc.
- Default vehicle setup names
CAM (Camera) file contains details of locations and actions of trackside cameras.
Terrain.tdf (Terrain Definition File) contains all of the road surface grip and bump levels and details for useage of graphic effects such as spray, dust, rain droplets, etc.
The next file description is of the *.Veh (Vehicle) file. The veh file is the main vehicle file. The veh file contains all references to the car and where to find all the required files. It contains locations to physics, graphics, sounds file references, and more. This is where to start when creating a new automobile for the game. Category= is a filter which determines which vehicles will be useable in the race. Classes is a subcategory of this. Classes permits class winners for categories. As an example lets look at the BPR 1995 championship. The category could be considered BPR 1995, the classes inside of this were GT1 & GT2 classes, with their own seperate regulations. Essentially Category= is a filter to allow only a specific list of cars and tracks when selecting a particular mod and vehicle. Only if the *.rFm file Vehicle Filter is equal to Category = defined in the *.veh will the car be selectable in that season. DefaultLivery= Describes which paint scheme is to be used by default. Track discriminate entries can also be added for championship rounds where different liveries can be applied. Pit crew liveries can also be defined here.
The first file reference in the VEH file is the physics HDV
(High Detail Vehicle) file. This file can be
considered the overlord of physics files; it accepts most of the physics
input variables directly and contains all references to all other physics
files.
Graphics= Next is the GEN
(Generate?) file. This file describes where to retrieve the model
files and textures from, it also describes LoD's (Levels of
Detail). In rFactor the upgrade parts can visually change the look
of the vehicle, these GMT files are written in the same *.gen file. Any
head/brake light illumination is also defined in the Gen file. We now have
a different Gen file just for the spinner, this allows the user to create
more independant and graphically intense model display.
GenString= is
used to define the car's model in the *.gen file. We previously used this
to enable exchange of models between different cars and teams. The
characters here are used as token's by the gen file. Note that you no
longer need to use a different GenString and model files to create team
mates, as was the case in F1C. You can simply change the defaultlivery,
thus allowing smaller *.MAS file sizes. In fact, GenStrings are really not
essential at all. We have begun phasing out the use of these.
Cameras= A blank entry defaults to default.cam in the
\GameData\Vehicles\ directory. You can define all new camera
positions/orientations specifically for each vehicle.
This brings us
to the *.SFX (Sound FX) file. All sounds generated by the
car are obtained from the list in this file. Engine sounds, horns, tyre
squeals, gear shifts, etc.
HeadPhysics= Changes visual head (camera)
movement in cockpit view and nothing else, it does not affect physics.
Generally, this file does not require alterations.
Cockpit= Vehicle
cockpit information. Lists onboard camera positions, instrument details
such as display RPM range & temperature range, graphic textures to
use, etc.
Upgrades= The upgrades file allows users to create purchaseable
vehicle upgrades. The possibilities are practically endless; you can
change sounds, models, anything physics related, etc.
AIUpgradeClass=
Upgrades that this vehicle has installed by default. The AI will always
use these upgrades and only these upgrades, the player car will start with
these upgrades. The player still has the ability to improve the car beyond
this point by purchasing better parts, assuming they are available. The
upgrade class is defined in the upgrades file, these are used to define
different models of vehicle.
For more information on the *.Veh file please visit the Vehicle Creation page.
Check out the other sections for some more detailed descriptions depending on what you wish to mod. As always have fun!