AI traffic - from ailists, cars and humans

1. General principles

For moving traffic, people (pedestrians and passengers), parked vehicles, drivers, AI-controlled vehicles (if specified), timed and location-based traffic control, and AI traffic number plates, several configuration files are needed (see file types). All configuration files can be opened and modified with an editor. These files are located in the corresponding map subfolders [..\Omsi\maps\mapname]. In this way, the vehicle and person selection can be designed differently, individually with each map.

1.1. File overview

(All text files mentioned here and the configuration file are located in the main folder of a map under OMSI\maps\map)

• humans.txt
  A list of all humans that can walk around on this map. Usually the file can be copied from existing maps.
• drivers.txt
  Like humans.txt, but only refers to the drivers of vehicles that support it (buses, trams).
• parklist_p.txt
  List of all vehicles that replace the so-called "Car Parks" (special objects in the OMSI editor). Depending on the selected density in the OMSI settings, randomly parked cars are generated at these locations.
• registrations.txt
  List with possible registration numbers for cars etc., if no registration number is given.
• ailists.cfg
  The "core" of the AI traffic. In this file the above mentioned groups are defined for a map (except pedestrians). This file represents only the moving vehicle part of a map.
• unsched_trafficdens.txt
  Defines the traffic density of unscheduled vehicles according to days of the week and time of day. This can be defined separately for each group.
• unsched_vehgroups.txt
  Defines classes for groups. This facilitates the exclusive or inclusive assignment of paths to a certain group in the OMSI editor.

For all the following mentioned files applies:

1.1.1. Error representation

Incorrect entries manifest themselves in different ways:

• Humans.txt
• Drivers.txt
• parklist_p.txt

Omsi can no longer load the map. The error message that the last memory point is damaged appears when a memory point is to be loaded.

If a new map is created without buses, Omsi stops loading and returns to the menu.

• ailist.cfg

For individual transport, Omsi gives the error message that certain vehicles can no longer be loaded or were not found. If a link for a bus file is faulty, Omsi does not give an error message until the bus is called. Omsi usually continues to run normally in the background, but the screen freezes. Error messages are then only entered in the logfile.txt.

2. Structure of the individual text files

2.1. People in Omsi

Passers-by and passengers also count as AI in the broadest sense.

All animated persons are listed in Omsi under "Humans". The object files, definition files and the textures are located in OMSI\Humans. The file humans.txt contains a list with links to the definition files (file extension '.hum') of the AI humans. One link to an AI human is entered there per line. The same applies to the drivers.txt file. The frequency of certain pedestrians can be increased by multiple entries.

The files of existing maps (e.g. Berlin-Spandau) can be used as a reference.

2.2. Bus drivers

Bus drivers (drivers) are only the AI humans that Omsi puts (or places) in the driver's seat of buses and vehicles that are configured for this purpose. As with the passers-by, the object files, definition files and textures, are listed in the folder "Humans". Thus, all persons in Omsi, whether wearing bus driver's clothing or civilian clothes, can be used as passers-by or as drivers. If you put several people in the driver list as drivers, they will be assigned to all buses with a driver's seat in turn. You cannot assign certain drivers to certain buses. In the map folders, the drivers are listed in the Drivers.txt file.

2.3. Parking Vehicles

The so-called Parklists are responsible for this. As with pedestrians, references are to be entered here. These are static objects (.sco) without animations, light points and number plates, which have mostly been created in a resource-saving way in order to preserve performance when used en masse (e.g. in car parks). Vehicles that support this also change colour dynamically. It is also possible to set mobile vehicles, but this is at the expense of performance. Parked vehicles do not generate any light points, even if they are also set. Number plates can be included, but this has a direct negative effect on performance and there is a possibility that several vehicles will have the same number plates.

It is possible to use several parking lists. The standard parklist is given the file name parklist_p.txt, further lists are given an index, e.g. parklist_p_1.txt. The index is then entered as a caption in the OMSI editor of the respective parking box. In this way, certain vehicle types can be placed in certain areas of the map (e.g. car dealerships, eastern block vehicles, trucks, buses, trains, parking spaces for suppliers or company-owned parking spaces). To convert mobile vehicles as static vehicles, it is sufficient to copy the definition files and rename them. This removes all entries for the number plate, light points and all animations. However, the number of polygons should be taken into account.

Here, too, the frequency is controlled by multiple entry, existing maps (e.g. Berlin-Spandau) can also be used as a reference. Here there is an additional park list for the eastern part (Land Brandenburg) with satellites.

2.4. Registration numbers for AI vehicles

In the file registrations.txt all usable licence plates for a map are entered. It is possible to enter registration numbers for one region (city, district) or for several regions. It makes sense to have a large number of local licence plates, a medium number of neighbouring regions and a small number of distant regions. All licence plates are entered in the registration file one after the other, whereby only one licence plate may appear in each line. The order depends on the desired appearance. Omsi assigns a number plate to each vehicle, if the vehicles have been equipped with a createable number plate (text textures). The order from the registration file is assigned to each vehicle in the order in which it appears on the map, not when it is in sight of the player. It makes sense to have a repeating, mixed order of entries.

As an example for Berlin:

• 25 licence plates for the city of Berlin
• 15 licence plates for directly bordering districts and towns (Barnim, Oranienburg, Bernau, Erkner, Königs Wusterhausen, Potzdam, Havelland, Nauen etc.)
• 7 licence plates for more distant districts and cities (district of Oberspree, Straußberg, Magdeburg, etc.)
• 3 licence plates for other regions (from Bavaria, Hamburg, Cologne, Aachen, Dresden, etc.)

This sequence (in this case 50 number plates) is then repeated several times (10 times results in 500 number plates), whereby the number plates change. The larger the number of licence plates, the less frequently they appear. Once all the licence plates have been assigned, Omsi retrieves the new licence plates from the top of the list.

3. Mobile traffic

In Omsi there is an Ai list in which all moving vehicles are entered. Further text files, such as the unsched_trafficdens.txt and the unsched_vehgroups.txt, are then intended for the temporal assignments or the punctual path assignment.

3.1. General information about the AI list

The AI traffic is set by the map builder using configuration files of a map. The traffic therefore varies from map to map (e.g. there are different buses, cars of today, different repaints or a differentiated traffic density). Crucial for this is a logical categorisation of the vehicles into so-called groups, which are treated separately from each other. The following would be possible, for example:

• Passenger cars (often referred to as NormalCars in existing maps).
• Commercial vehicles (cars and Sprinters with advertising and company stickers, often labelled Commercials in existing maps)
• HGVs (these may not always be allowed to drive (Sunday driving ban) or everywhere (service road, restrictions on width, height, length, weight, etc.))
• Cars with special rights (e.g. taxis and electric cars, which in many places are also allowed to drive on bus lanes).
• Other vehicles with special rights granted by the authorities (police, fire brigade, etc.)
• Regular service vehicles, which can be further subdivided if necessary:
  • Single deckers and double deckers
  • Solo vehicles and vehicles with articulated or double-articulated buses
  • Small vehicles and large vehicles
  • Single and double deckers
  • older and modern vehicles
  • Trams
  • Trains
• Water vehicles (e.g. boats, ships)
• Aircraft (helicopters, planes, etc.)

This arrangement in groups is basically map-specific and does not always have to be the same. If necessary, there are further regulations that must be implemented for maps that are played outside of Germany. The division of the different vehicles into groups is necessary in order to make certain areas of maps, times, roads or lanes accessible to vehicle types.

The special feature of this file is the type of file and the associated structure, but also the diverse possibilities. The Ai list is not a text file, but a configuration file. This means that not only the file paths to the vehicles are entered, but also additional control options such as frequencies, deployment data or repaints. In addition, the chronological deployment can also be controlled with this file if several groups are subdivided.

Together with the setting options in the editor, the amount of work is very time-consuming if you want to exploit all the available possibilities. But the effort is worth it if you want to represent a map realistically.

3.2. Structure of the AI list

In the AI list, all drivable vehicles of a map are entered and divided into groups. The structure is repeated in places, depending on the type of vehicles, whether individual traffic or timetable-related traffic. Omsi only distinguishes between these two groups. Individual traffic is randomly assigned according to frequency and stubbornly follows the paths that have been set. This includes all vehicles that should or must not follow a fixed timetable. This includes all cars, trucks, coaches, aircraft, special vehicles or watercraft.

There are two basic representations for the body. Firstly, there is the body for individual transport. This contains the following characteristics:

• Name of the group for identification in other AI files and in the map editor.
• Name (not file name, but display name!) of the .hof file if available, otherwise leave empty
• Per vehicle: Path to the vehicle's .bus or .ovh file or .train file if it is a team and optional indication of a frequency factor, separated from the path by a tabulator.
• The group is concluded with an [end] command, which can be followed by other groups.

On the other hand, schedule-controlled vehicles are further subdivided, such as yard affiliation, period of use, registration number and repaints. In addition, these vehicle groups are assigned to a yard file. These individual points are explained in the following section.

Groups are defined in the ailists.cfg file with the following keywords:

• [aigroup]- deprecated!
• [aigroup_2]
• [aigroup_depot]
• [aigroup_depot_typgroup_2]

The order of the groups is irrelevant. According to general convention, the group of cars is the first, followed by special rights and trucks, and finally the groups marked _depot.

3.2.1. Timetable-free traffic

First comes the general structure, for individual transport.

Each individual group is provided with an entry. Several vehicles of the same type can then be grouped together. The order of the groups or the sequence of the file paths is irrelevant.

After this, all following groups will be entered, following the same structure.

The frequency factor indicates how often a certain vehicle appears on the map in relation to all other vehicles of a group. The factor (operand of a multiplication) is calculated in the ratio of all vehicles to 100%. The repaints assigned to the vehicle are then used randomly. This makes it possible to have certain vehicles (e.g. US cars, historic vehicles, authority vehicles without special rights or other rare vehicles with low numbers) appear less frequently on the maps than modern and current vehicle models.

Please note:

• The frequency factor must always be separated from the link to the vehicle file by a tabulator if such a factor is entered. Otherwise the link counts as wrong. The factor can contain whole numbers or numbers with a decimal point (0.3), which is written as a dot.
• Several group names can be defined, which then contain different vehicles. In this way, different vehicle groups can be used on a map, which change in the time frame. With the chronology function, a group is then assigned to each time frame.
• There is no limit to how many file paths can be entered in the list. A high number of different vehicles causes more variety in the traffic seen, but has a direct negative effect on the performance of the map (depending on the polycount of the vehicles).
• Buses can also be used, which then move around the map without a timetable (e.g. coaches). These buses then count as part of the general AI traffic. The use of coaches should be well considered, as these buses drive everywhere where other cars are also on the road (small narrow side streets). In addition, the high polycount of the buses must also be taken into account if they are mobile buses.
• It is also possible to enter groups that only contain buses. Then these groups can be set to specific paths.

Timetable-bound vehicles do not need a frequency factor, as the frequency is determined by the timetable.

Examples of groups:

Any number of groups can be created. The group names are freely selectable. If you use your own group names than the default ones, this Ai-List cannot be used on other maps if these group names have not been assigned to the paths in the editor.

The more groups are created for the vehicles, the more differentiated the vehicle classes can be adapted to the paths. The AI list should be created first so that the vehicle groups can be assigned to the individual paths later in the editor.

3.2.2. Timetable-bound traffic

As the name suggests, timetable-bound traffic is controlled by means of timetables. It is therefore not necessary to set a frequency factor, as the timetable specifies a frequency according to takt. In addition, this traffic can also call at points (stops). This makes sense if certain vehicles are to follow a fixed course and stop at certain points. This does not only apply to scheduled buses, but also to other vehicles such as refuse collection, parcel services or delivery vehicles. Here, the stop cubes from the editor are used as stopping points, whereas no persons are set for other vehicles that do not carry passengers.

In addition, in the AI list you can assign all timetable-related vehicles, number plates, repaints and line displays and also control the time of appearance, depending on the date. In the timetables, the frequency of appearance on the map is controlled and the fixed route is specified.

The creation of the AI list is explained here using buses as an example, but it applies equally to all other timetabled vehicles. For example, you can have certain refuse collection vehicles drive on certain days or have certain lorries with advertising drive to fixed points. Thus, a furniture van will also drive to the furniture store instead of to the discounter.

If only the vehicle type or the vehicle file was specified in the above command, it is possible to define each vehicle individually. This is the recommended way for depots with buses that have a fixed repaint and number plate. In the same way, it is possible to assign certain depots to certain vehicle types or to different depot files that do not have all map destinations.

A command [aigroup_depot] followed by name and .hof file (without end command!) is followed by one or more [aigroup_depot_typgroup_2] entries. This in turn consists of a reference to the .bus (preferred) or .ovh file, followed by a list with the following properties (separated by tabs, one vehicle per line):

• Wagon number
• Registration number - if not defined, a dynamic registration number (depending on the defined preference from the vehicle registration file) is selected.
• Repaint display name (not file name!) - if not defined, the default repaint is selected.
• Start date (incl.) from which this vehicle can be on the road on the map.
• End date (incl.) from which this vehicle is out of service and should no longer appear on a map.

Here, too, the list is closed with [end]. All properties are optional; only the separation by tabs is important. Several tabs in a row skip entries.

When setting up, the command [aigroup_depot] follows first, with which all following vehicle entries are assigned to a group (depot or line). This command is valid until it is changed by a repetition, which then assigns all following vehicle types to the new group.

General structure

Explanations:

First, a wagon number is assigned. If a bus/vehicle can display regenerative wagon numbers, these are also displayed. Omsi uses this number to identify a specific vehicle, so that the same vehicle always appears the same during a round trip. A wagon number must therefore always be entered.

The registration number is optional. Omsi creates a registration number according to the specifications in the .bus file under the command [registration_automatic] and the wagon number noted here. If the vehicle is to have a registration number that differs from the wagon number, this can be entered here. If no registration number is entered here, Omsi uses a registration number from the bus's own registration file.

The name of the repaint can be found in the texture subfolder "Repaints" or "Advertising". In each model file, only one subfolder can be assigned in which the repaints can be located. There is at least one text file (.cti) in which the repaints are assigned. These are entered as follows:

Directly under the command [item] is the name for the corresponding repaint. This name is then also entered in the Ai list for assignment. If no repaint is assigned, Omsi uses the standard repaint. The name of the standard repaint is entered in the BUS file.

The start time determines from which date a vehicle/repaint/wagon number may run on the map. In this way, it can be specified on a map that a certain bus can only be put into circulation from the date of manufacture / date of procurement. Together with the repaint entries, a bus (if this has been implemented) can be equipped with a number box using the command [setvar] in GDR times, but June 1990 with cash register and D-Mark and from 2002 with Euro cash register. As already mentioned, a bus with a certain wagon number can also be equipped with a temporal repaint.

The end time then determines until when a certain repaint may be in circulation.

The data is entered in complete data numbers without separators. Only the format YearMonthDay applies here. Thus, an entry for a temporal colour change in the Ai list would look as follows:

These entries would mean that the bus can only be seen on a map after 9 November 86 and runs until 31 May 1990 without advertising and with GDR number plates. But from 1 June 1990, the bus runs with Omsi advertising and a different number plate. From 1 January 2002, the bus has a reapint of the WebDisk and a new registration number.

3.3. Traffic density and temporal traffic volume

As already described in the section "Timetable-free traffic", in Omsi 2 it is possible to control road traffic in terms of time. With the help of group names it is possible to specify certain types of vehicles only on certain roads. In addition, it is also possible to control the timing of certain vehicles. With the chronology function, you can make certain groups of vehicles drive or disappear from a certain date. You can also control the volume of traffic in Omsi.

In the options of Omsi 2, you can set the traffic density globally for all vehicles. The set traffic density applies equally to all vehicles and groups entered in the AI list, depending on the frequency factor set. Thus, the 100% of the traffic volume is set globally. However, it is also possible to set the traffic volume for specific vehicle groups in terms of time. Here, Omsi offers a simple way to increase, decrease or completely exclude the traffic density of vehicle groups at certain times of day or on certain days of the week. In the editor, you only have to define on which paths certain vehicle groups are allowed to travel. With the two additional files [unsched_trafficdens.txt] and [unsched_vehgroups.txt], it is possible to realise commuter, night, weekend and holiday traffic on certain weekdays, but also to implement a temporal driving ban (weekend driving ban, night driving ban).

3.3.1. unsched_vehgroups.txt

This is the simplest file. Here it is specified that the entered vehicle groups should be treated separately and whether they should run from the beginning or whether the corresponding paths of the splines must first be enabled.

The command [group] has only two strings that can be read out. Further entries below this are not taken into account by Omsi. Therefore, this command does not have to be closed with an [end]. There are also only the two possibilities of entering numbers:

0 = Not allowed to drive, paths must be enabled for this group.

1 = May drive freely, group has normal traffic density.

Here all groups are entered one after the other, whereby of course only timetable-free groups are entered. Non-existent groups or groups with a timetable are recognised as errors.

3.3.2. unsched_trafficdens.txt

After the groups have been defined as individual groupings, the next step is to set the traffic density for each group according to the times and days of the week.

There are several commands for this, with a precisely defined number of strings is not closed with [end]. These commands are:

• [group]
• [set_day_of_week]
• [trafficdensity]

In this way, the traffic density for each group can be set to the minute. If you want a vehicle group to appear more often in certain map areas than in other areas, you have to enter the same vehicles of a group again under a new group name. In this way, for example, you can have emergency vehicles appear more often at events (festivals, Christmas markets, demos) than on the rest of the map, or you can have trucks drive more often in industrial areas.

The basic structure is repeated again and again. You name a group, assign it the days of the week and determine the traffic volume for this group according to the time of day.

The structure looks like this:

• [group]
  • [set_day_of_week]
  • [trafficdensity]
  • [trafficdensity]
  • [set_day_of_week]
  • [trafficdensity]
  • [trafficdensity]
• [group]
  • [set_day_of_week]
  • [trafficdensity]
  • [trafficdensity]
  • [set_day_of_week]
  • [trafficdensity]
  • [trafficdensity]

The commands are quickly explained:

Erklärung der Eintragungen

Beginn der Einstellung für eine neue Gruppe

Festlegung der Wochentage

Beginn der Änderungen der Verkehrsdichte

The command [group] should be clear. The following command [set_day_of_week] refers, as the name suggests, to the individual days of the week. Here Omsi is relatively flexible. With the days of the week, Omsi does not recognise holidays that lie within its week. In addition, Omsi does not distinguish between the weekdays from Monday to Friday. The days of the week are indicated with numbers, whereby the addition of the individual values, captures the days:

There are a total of the following possibilities:

• 0 = All days
• 1 = Monday-Friday
• 2 = Saturday
• 3 = Monday-Saturday (1+2)
• 4 = Sunday
• 5 = Monday-Friday+Sunday (1+4)
• 6 = Saturday+Sunday (2+4)

The last command to appear is [trafficdensity], which now determines when the entered traffic density is to be changed. In the text file it now looks like this:

nun wie folgt aus:

The entries for the command [traffincdensity] seem strange at first glance. Omsi cannot do anything with clock times or certain value specifications. Omsi calculates the time of day for each day individually, starting to count the individual seconds at midnight (0:00). Until 23:59:59 Omsi then counts up to 86400 seconds and then starts again. Here the time is displayed differently. Each hour has the value 1, so one hour is divided into 1000 units. The maximum value is then 24,000. The values in between then stand for the divided hour.

The value 8,250 corresponds to 08:15,

12,500 corresponds to 12:30 and

17:750 corresponds to 17:45.

For the percentage values of the traffic volume, the value must also be changed. Here, the value 0.000 equals 0% and the value 1.000 stands for 100%. However, for Omsi, 100% is not the maximum upper limit. This value stands for the normal traffic volume. If there is to be a normal volume of traffic during the day, then there is a greatly reduced volume of traffic during the night hours, which increases in the course of the early morning hours until rush hour. In the rush hour, there is a greatly increased traffic volume, which decreases in the course of the morning and returns to normal traffic volume. In the afternoon, the traffic increases again, whereby the second rush hour is not quite as high as in the morning, but lasts longer. After the rush hour, the traffic density slowly decreases and some groups then drop out (trucks, delivery vans, etc.).

Only the times when the changes begin are entered. These are then valid until a further time entry changes the traffic density for this group. If no further time entries follow, the traffic density is valid until midnight. In this example, the traffic density decreases from midnight onwards until it slowly becomes quiet and only a few night owls are on the road. Normal traffic then decreases. More taxis can then be used. During the morning rush hour, the traffic density slowly increases and then slowly decreases again. In the morning, traffic returns to a normal density.

In this way, traffic jams can be formed during rush hour and traffic can be normalised again outside of rush hour. Towards the end of the day, traffic slowly increases and then decreases again. Traffic then continues to decrease until midnight.

The workload increases for each additional group. The more groups you hire and the more you want to slowly increase traffic, the more work you have to do. But it is worth it because the traffic density changes dynamically.

4. Further tips and hints

As already written, you can't do too much with the people in Omsi. You can't use children or only old people on certain bus routes. You can't use a certain group of people more often or in a more targeted way on the streets either (old people's homes, playgrounds, schools). Unfortunately, this is only possible with AI traffic. The amount of work increases the more individually you want to control the traffic or certain groups of vehicles. For example, you could have more ambulances or RTWs driving near a hospital or more fire engines near a fire station. Here you have to decide for yourself whether the effort is worth it or not. In payware projects it would be worthwhile, but hardly anyone makes such a targeted effort. Omsi offers a lot of possibilities, but they are not used in payware projects. It is not about quality, but about money.

Especially when it comes to controlling the temporal traffic density, one saves at the wrong end. Traffic increases with time. Omsi regulates this so that the specifications are implemented quickly. If you set few times, it can happen that you end up in a traffic jam from a less frequented main road to another road (example: Berlin X10, Hamburg Day & Night).