1. General information
Configuration files in the sense of OMSI are pure text files that define the interaction of model (3D files, often also called mesh), textures and scripts. They can be opened with standard text editors, Notepad++ (free of charge) has proven itself here. Basically it can be said: All the information that can be converted into plain text (except scripts) is defined in configuration files.
The file extension (cf. file formats) of configuration files varies, the "classic" extensions are cfg, sco, sli, bus and ovh.
2. Keywords
Similar to programming languages, there are keywords in configuration files, which vary depending on the file type. There can be any number of different keywords per file (according to the expected format). Almost all keywords are enclosed in square brackets (exceptions e.g. in the farm file). Everything outside keywords or blocks belonging to keywords is ignored by OMSI (cf. Comment out).
OMSI recognises keywords case-sensitively, which means that the upper and lower case of the keywords must also match exactly!
As a general convention, it has been established that at least one line should always be left blank before and after keywords to make it clear which blocks belong together:
The following types of keywords exist:
2.1. Stand-alone
They occur on their own and do not require any further specification.
2.2. Fixed number of parameters
Keywords that require additional information, for example, file names, values, etc. Such parameters can be characters, strings and/or floating point numbers (with decimal point!). The number per keyword is always fixed. Strictly speaking, stand-alone keywords are a special case of this type (0 parameters).
A keyword with a string parameter:
[mesh]
MyMesh.o3d
A keyword with 4 floating point parameters:
[profilepnt]
1.5
0.1
1
-0.1
A keyword with 4 parameters of different types:
[char]
A
242
262
02.3. Variable number of parameters
For certain keywords, the length of the block is dynamic. In this case, the first parameter of the keyword determines the number of subsequent entries.
A keyword followed by 3 parameters:
[stringvarnamelist]
3
script\IBIS_stringvarlist.txt
script\Rollband_stringvarlist.txt
script\cockpit_stringvarlist.txt
In rare cases, it may also be necessary not to pass any parameters to the keyword at all:
[global_strings]
02.4. Explicit END Command
For keywords that contain longer text (e.g. descriptions for the player), the previously mentioned method makes little sense. Here, the end of a block is marked with an explicit [end].
[description]
Technische Daten:Length: 11,490 mm
Width: 2500 mm
Height 4060 mm
Engine: MAN D2566MUH, 141 kW at 2100 rpm
Transmission: Voith D851
Maximum speed: 75 km/h
Unladen weight: 10700 kg
Permissible total weight: 16,000 kg
Seating capacity upper deck: 47
Seating capacity lower deck: 34
Standing room: 8
[end]3. Structure
The following always applies: The keyword must stand alone in a line. Thus, there must be no space or other characters before or after the keyword. However, if this is done, the command is considered commented out and thus has no meaning (see commenting out). Comments can be written before, between or after the keywords.
In this example:
- [keyword]: 3 more lines will be read out.
- [absheight]: 0 more lines are read out
- [description]: up to the command [end].
- [script]: one more line. This number then determines how many more numbers are read out
This is a comment
This is a comment
[Keyword]
0.1
envmap.bmp
3
This line is again a comment, as only 3 further lines are read out from the keyword onwards
comment
[absheight]
This is a comment because the keyword is stand-alone.
[description]
This bus is... and can ...
Length: ...
Height: ...
...
Here is NO comment, because no [end] command followed yet.
[end]
Here are comment lines again
[absheight]
^ This is not a valid keyword because the line starts with a tab.
[Keyword]
^ This is also not a keyword, because the line starts with a space. Thus, the following three lines are also ignored.4. use of configuration files
Configuration files are used for the following:
- AI lists
- global.cfg files for maps
- Signal routes
- Timeline files for maps
- Money configurations
- texture configurations
- model files
- Seat configurations
- Path configurations
- cloud configurations
- envir.cfg
- Options
This list is by no means complete. As described before, in OMSI almost all data that are neither scripts (.osc), model files (.x, .o3d) nor image/sound files are considered configuration data.
