Passenger routes

1. 1 General overview

There are two files for the behaviour and positioning of passengers in the bus:

• passengercabin.cfg
• path.cfg

These file names are not fixed and can also be renamed. Also the storage location is freely selectable. These two files are usually located in the subfolder 'model' and are entered into the bus file with the file path from the bus folder. Together these two files control the entire behaviour of the passengers in the bus, from entering the bus to leaving it. In addition, the positions of the entrances to the bus, the exits from the bus, the positions of the standing and sitting places, the positions of the individual issued tickets, the position of the ticket validator, as well as the seating position of the driver are also defined here. It also specifies the light assignments of the passengers on the seats and standing places, the sounds when walking and the different heights of the floor in the bus. Here it is only about the explanation of the individual commands with the corresponding strings and the exact file structure.

2. 1.1 Link in bus folder

These two files are pure text files and get the file extension 'cfg', so they are configuration files. These files are opened with a simple editor (see Text file in Wiki article File formats). Both files have to be entered in the 'bus' file or 'ovh' file, in the 'sco' file in the case of scenery objects with standing and seating areas. The starting point is the bus folder, where the bus file is also located.

2.1. 1.1.1 Tips on how to work

To make the work easy for yourself, you should first make a sketch. The easiest way to do this, in a 3D program, is to import the bus.

If this is not possible, you can also access other tools without a 3D program. It is recommended to make a sketch and to use a tool to enter the positions of the individual waypoints, seating and standing places into the sketch.

First you note down the path points (shown in red here), starting from zero. These are later entered as [pathpnt]. Then the connections between the points are noted (shown here in orange). These connections will be entered later as [pathlink]. Now note down the standing places (blue letters), which are recorded with [passpos] and the seats (green numbers). Furthermore you write down the position of the driver's seat, which must be entered under [drivpos].

Finally, the exact positions for storing the tickets (if necessary), the position of the customers' money, the position for giving change and the position where the passenger can validate his ticket are written down. Then only the light points in the bus are missing, which can be entered later.

2.2. 1.1.2 Positioning

There are three ways to determine the correct positions:

1. One imports the object files of the bus in a 3D program and reads out the positions exactly.
2. One writes in a position and tests it until it fits.
3. You use a simple cube as a tool (see WebDisk-simple cube).

3. 1.2 Coordinate system in Omsi

The coordinate system in Omsi, is explained in detail in the article Blender Import/Export.

4. 2 Path file

The following entries appear in the path file:

• Sounds for the noises that passengers make when walking on the bus.
• Positions of the path points
• Path point connections
• Limitations of the path points
• Height changes of the path points
• Position of the individual running sounds

5. 2.1 Keywords of the Path.cfg

The following commands [which are always written in square brackets] have different effects and different numbers of strings.

5.1. 2.1.1 stepsoundpack

Under this command all necessary step sounds are entered, which can be found in the subfolder Sounds, for the running noises of the passengers. These vary in volume (louder in front, quieter behind) and depending on the floor covering (wood, rubber, plastic, bituminous building materials, metals) or other conditions (rattling ramps, steps).

Example:

To make sure that different areas, such as entry and exit steps, stairs, walkways, distances to the driver or floor coverings sound different and that these steps also have a varied sound, the individual sounds are entered first. Each sound entered is a new area in the bus and is counted starting from zero. NUM indicates how many sound files there are in total. Below this, all available sounds are entered, which should be located in the subfolder: Omsi\Sounds\Passengers (of course, a subfolder can also be set up there and then noted with subfolder\filename1.wav).

The stepsoundpacks must be defined before the first [pathlink] / [pathlink_oneway] entry.

5.2. 2.1.2 pathpnt

5.3. This command defines a new path point. It is important that all path points are far enough away from each other so that the passengers cannot touch each other. As a rule of thumb a minimum distance of 25 cm to 30 cm can be taken. For fat people, you can also increase this value so that the belly of the fat person is not in the back of the person in front of it.

[hl=3][/hl]

Each of these path points must be located exactly on the floor of the vehicle. You can also specify this point one or two centimeters above, but never below.

Example sketch:

However, the effective range of the light points is higher than entered in the 'model.cfg'.

5.4. 2.1.3 Pathlink

Under this command the individual points are directly connected to each other. Missing connections cause the passengers to disappear at the last waypoint and to pop up at the entrance or at the next possible waypoint. Here you have to work very conscientiously.

Example:

5.5. 2.1.4 pathlink_oneway

This command limits the running direction of a connection between two waypoints as a one-way street. The running direction is always set from the upper waypoint to the lower waypoint. Here you can make sure that exits can generally only be used for getting out, even if these ways are additionally defined as entrances. But you can also define ways so that the passengers in the bus pass each other, if there is enough space. This makes sense if the passenger has to walk from a waypoint in the aisle to a seat and when leaving the seat in another direction, he has to walk to the next waypoint in the aisle again.

Example:

5.6. 2.1.5 Group commands in the path file

The following commands are entered as group commands. This means that you write them down for a number of additional path points, the following ones and not for each path point individually.

5.7. 2.1.5.1 next_roomheight

With this command, all subsequent [pathlink] and [pathlink_oneway] commands are moved to a higher level until the next occurrence of this command. The value is given in meters. This prevents the passengers from running with their heads through the ceiling. It does not define the height of the floor, because these values are in the path points, but the maximum height of the space between floor and ceiling. This is helpful in double-decker buses, where the room height is lower in the upper part of the vehicle. Or also in other buses where the seats are on platforms or in vehicles that are not continuous low-floor vehicles.

Example:

5.8. 2.1.5.2 next_stepsound

Another group command, which applies to all following [pathlink] and [pathlink_oneway] commands, specifies the next sound from the list of [stepsoundpack] entries. This command then remains valid for all following path points and connections until this command appears again. The assignment of the sounds is read from the entered order above. Under the command, the assignment number of the desired sound must be entered (counting starts at zero for the first sound file).

6. 3 Passenger cabin

The 'passengercabin.cfg' is a simple text file. The following points are entered in it:

• inputs and outputs
• Seating position of the driver,
• all seating positions and standing room for the driving customers (passengers),
• Position of the canceller,
• Position of the ticket office,
• Storage position of the passengers' money,
• Issue position of the change,
• Path point to the transition to another part of the vehicle,
• Light assignments

7. 3.1 Keywords of the passengercabin.cfg

In the passenger cabin, there are again commands that are put in square brackets and have a different number of strings depending on the command. In addition, there are also hint commands and object assignments. These are explained in more detail.

7.1. 3.1.1 Entry/Exit

These commands define a path point as input or output. The number varies depending on the bus model. Only one path point can be assigned to each of these commands. To define a path point as input or output, enter the path point under two different commands. The hint commands which are not set in square brackets but in curved brackets also appear here.

Example:

Starting from the sketch with the paths at the top of the article, the path points 0, 15, 20 and 21 - as entrances or exits - result. Here, the second and third door leaves were defined as entrance and exit in equal measure. The first door leaf was defined as entrance only and the last door leaf as exit only.

7.2. 3.1.2 linkToPrevVeh

This command is only for articulated buses and specifies which path point is the last one in the front of the vehicle and leads to the next part of the vehicle. Only a string follows and specifies the path point.

Example:

Not shown in the enclosed sketch.

7.3. 3.1.3 linkToNextVeh

For the rear part of the bus, this command specifies which path point leads to the front part of the car (i.e. through an accessible joint). The trailer needs its own Path.cfg and its own passengercabin.cfg.

Example:

3.1.3.1 {noticketsale}

Please note that the payment table cannot be reached via this entrance. In order to buy a ticket with money, passengers must use the entrance path point 0.

3.1.3.2 {withbutton}

This indicates that there is an outside door button next to this access. This allows the passenger to make a stop request from the outside. For this purpose the passenger must be close to the imaginary outside door button.

3.1.4 Stamper

This command indicates where a ticket validator is. It does not matter how many ticket validators are installed in a bus. Omsi can only use one ticket validator. Directly under the command the path point is set from where the passenger can reach the ticket validator. According to the sketch above, this is path point 17, and the exact position of the slot where the ticket is inserted, so that the passenger's animated hand will guide his hand near the canceller slot.

Example:

3.1.5 ticket_sale

In order for the passenger to know where to get the ticket he has bought, he must use an entrance that is not equipped with the {noticketsale} instruction. Through this entrance, he can reach the cash desk / sales counter. After the command, the path point follows again, at which he is close to the payment table, followed by the positions.

Example:

3.1.6 ticket_sale_money_point / ticket_sale_money_point_2

For the position of the passenger's money drop, this command is available. It is located on the cash desk and next to the coordinates of the cash desk it indicates how far the field is in total so that the money does not lie in a pile. The larger the field is, the further the money is within the radius of the coordinate point. These two commands differ only in the number of the following strings.

• [ticket_sale_money_point] - with 5 strings
• [ticket_sale_money_point_2] - with 6 following strings

In the first five strings the commands are the same. First follow the three positions of the payment table, where the ticket customer should put the money for the cost of the ticket. The following two values result in the alignments from the original coordinate.

Example:

With the prefix _2 the number of strings is increased by 1, so that now 6 strings are available.

Example:

With 'animparent' the animation variable of the slide is entered. For this purpose the carrier object gets the additional command [mesh_ident] in the model.cfg under the mesh entry.

Example from the model.cfg: With the prefix _2 the number of strings is extended by 1, so that now 6 strings are available.

Example:

Example for the entry in the passengercabin.cfg

3.1.7 ticket_sale_change_point / ticket_sale_change_point_2

Just like the previous two commands that are there for the position of the passengers' money, these commands are there for the player's change.

3.1.8 drivpos

The driver's seating position is specified here.

Example:

3.1.9 passpos

Just as with the driver position, this command defines the positions of the seating and standing positions.

Example

Rotation around the Z-axis means that the sitting or standing direction is given in degrees.

0 = To the front in the direction of travel,

90 = To the left by 90°,

180 = To the rear, opposite the direction of travel,

-45 = To the right Front,

-90 = To the left,

-135 = To the right rear.

The seat height indicates the height at which the surface of the seat is above the floor of the bus.

3.1.10 Light assignment

This command belongs to the so-called group commands. This means that this command does not have to be entered individually for each object, but is valid until it is changed by a repetition. Important is the order of the light entries in the model.cfg. When using interior light in Omsi, you have to distinguish the types of light. For the assignment of light to objects, the type of light is important. Only this light can illuminate objects. All other light objects have no light effect on bus internal objects.With the command [interiorlight] the light sources are defined in the model.cfg. The sequence then determines the light assignments. However, only a maximum of 4 light sources can be assigned to an object. Again, the count is zero-based. This means that the first light source entry has the number zero.

Example:

In the example sketch there are 12 light sources in total. Thus, all 12 points are entered in model.cfg and the assignment numbers 0 to 11 result. The design of the bus now determines the assignment of the light sources to the passengers in the seating and standing areas. If there is an opaque separating plate behind the driver's seat, the driver's seat, dashboard and steering wheel are not illuminated by the light source behind. Consequently, the driver must not be illuminated by the light behind it. The same applies to the seat directly behind the driver. The passenger sitting there must not be illuminated by the driver's light. But both are illuminated by the door light and the light on the right front.

Sample sketches:

1. Driver's light/cashier light active
2. Door light 1 active
3. Interior light left Front active

Example:

8. 4 General notes

When creating new paths and places for the passengers, not only the light must be considered. Already the construction and the arrangement of the individual points for the positions of the passengers is important. There are no limits to the number of path points. But you should make sure that you do not use too few points. The number of waypoints decides how the passengers move through the bus. Before a passenger leaves a waypoint to follow the path to the next waypoint, the passenger first aligns himself. No passenger walks an arc, but always takes the shortest path between two points. Regardless of whether an object is in the way or not. Too few waypoints also lead to the passengers in the bus plop. There are no animations between standing - sitting and getting up again. This means that a passenger "beams" from the last waypoint to a free standing or sitting position. If the distance between both seats is too big, the passenger disappears in the bus and reappears at another place. This behavior can be observed in many payware buses. But with several waypoints you can control the behaviour.

9. 4.1 Connection between two waypoints

As already mentioned, a passenger on one waypoint aligns with the next waypoint before using the path in between. If there are objects in between, these objects are passed through. If the angle to the next waypoint is too large, the passenger will flinch in the new direction. Arcs or curves must therefore be set up. Angles of more than 45° should be avoided. So it can be that you have to set several waypoints to avoid an object. The smaller the angle desdo more fluid the walking movements and the movements through the bus appear.

10. 4.2 Four-way intersections

Crossings in four directions should also be avoided. Errors can occur here if the point is occupied at the moment (by waiting passengers). These then appear somewhere or at the entrance area. Here one should try to get along with three-way crossings. This is not always easy if the space in the bus is limited (coaches). These problems can be reduced if some routes are converted to "one-way streets".

11. 4.3 Distances between two waypoints

The distances should be kept as small as possible. But also not too close, otherwise the passengers will stand in each other. If there is a traffic jam in some places (for example at the cash desk or the ticket validator) then the people stand at a very large distance from each other. Only at a crossing point to the exit, it can not be prevented. Here the passengers pile up unfortunately and wait for the release of the exit paths. If too few waypoints are entered in the bus, then many passengers stand at the last crossing point before the exit, into each other. As soon as a stop is reached where a large number of passengers want to get off, they immediately leave their standing or sitting area to get as close as possible to the exit. Here you should choose a distance so that the passengers stand close behind each other, but not in each other.

12. 4.4 Distances between waypoints to the seats & standing room

When a passenger gets on the bus, he or she first runs to the ticket office or ticket validator to cash in his or her ticket. Then he walks through the bus to a free seat or standing room. The passenger then walks to the nearest waypoint. Once he has reached this waypoint, the passenger is suddenly removed from the waypoint and seated or placed on the seat or standing room. If the distance is too big, the passenger will plop through the bus. This is especially noticeable in double seat rows, when a passenger beams to a window seat between the waypoint in the aisle. Not always enough space can be placed between two waypoints. Therefore it makes sense to set another waypoint which brings the passenger closer to a seat.

13. 5 tips for creating paths

Here are some hints on how to best implement the paths but do not need to implement them.

14. 5.1 Example pictures

The following example pictures should serve as a basis for explanation. They are not guidelines for any standards.

1 - 2 - 3

4 - 5 - 6

14.1. 5.1.1 Example 1

If you set the path from point 1 to point 2 as shown in the picture, people will walk to point 2 and then turn to the cash desk. If one would set the path from point 1 to point 2 directly towards the checkout, then the passengers use the checkout first and turn to point 3 to use this part of the path. Other passengers wait at path points 0 and 1 until point 2 is free. The "one-way street" from point 3 to point 4 prevents a blockade, because people cannot block the further way from entrance 0 to the cash desk and the interior if the second way would also be declared as exit.

14.2. 5.1.2 Example 2

In example 2, path point 7 was not placed directly before the validator, but before it. This means that the passengers do not turn around to the canceller first, but only a little in the direction of the canceller. After validating the ticket, they walk via path point 8 to point 4 to enter the interior.

14.3. 5.1.3 Example 3

In the case of a 4-seater seat as in example picture 3, the passengers are taken to their seats. They no longer pop out of the aisle and then appear in the seats, but walk to their seats. To maintain the flow of running, you can set "one-way streets" between path points 11 to 14, 12 to 18 and 18 to 17. But only if the exit is on the left of 19.

14.4. 5.1.4 Example 4

Example figure 4 shows the possibilities with a double-leaf door. Here, the path points are set as narrow as possible. There are no 4-way intersections. Path connections can overlap. Since passengers never stop between 2 path points, they cannot stand in each other. Therefore there are several 3-way-intersections, where possibly some smaller groups can form.

14.5. 5.1.5 Example 5

In some narrow places in buses, it is seldom possible to create multiple waypoints, because there is simply not enough space. But here you can control the movement of the passengers to their seats a little bit, which makes it seem like a passenger is walking to his seat and lets himself fall on it. Also when getting up, the passenger does not plop into the aisle. In addition, the entrances and exits to the seats should be placed towards the exit doors. If there is no room to continue walking in the bus, the passengers stay at the point in front of the aisle until it is free again.

14.6. 5.1.6 Example 6

For standing places, such as in the pram area, the path points should be placed close to the standing places. There is no need to walk further through the bus, as the passengers only leave the standing places if they want or have to leave the bus. In this example, the passengers walk to point 50 for standing places A and D and to point 51 for standing place H. For the following places, path points 61 and 62 are used.

15. 6 Additional information

Marcel and Rüdiger only implemented what they themselves needed for their vehicles. Therefore many things are not possible. Since M+R Software only had to implement one entertainer in the bus (in Berlin at that time, the rule was always to enter at the front and exit at the back), only one entertainer was implemented. Since Marcel does not respond to user requests, it is not possible to implement a second validator in the vehicles. So all other validators are only dummy validators. The only exception are articulated busses, because one validator can be set per vehicle part. If you want to set several validators per vehicle part, this is only possible if you separate the vehicles and attach them as immovable vehicle parts. However, this effort is contradictory to the benefit.

Further important information on light can be found in the Wiki article Light.

In most vehicles only a few path points were set, because also the creation of the passenger file takes some time. In addition, the number of possible path points is also limited by the space in the bus itself.

In Omsi the entered path points do not serve as standing room. If all registered seats and standing room are occupied, waiting passengers will walk to the door at the bus stops but will not get on. If the bus is fully occupied, then only as many people can get on as want to get off. Therefore, never more passengers can board the bus than the number of registered seats and standing room. This does not always correspond to reality. Transport companies such as BVG calculate with a so-called 300% rule.

100% = one third of all standing and seating places are occupied.

200% = two thirds of all standing and seating places are occupied.

300% = all standing and sitting places are occupied, so the bus is considered to be fully loaded.

301% = The maximum value indicates that the passengers are packed tightly in the vehicle

stand / sit and also use operational free space