Hof file

1. Hof file for OMSI

A Hof file is the basis for being able to drive a bus on a line, with destination displays of a map. Without a Hof file, the bus cannot display any information (matrix, rolling conveyors), which means that no passengers board the bus. It contains a list of the final stops (hereafter called term), stops and the routes of the individual lines. It is only used for the information of the displays and the audio playback of the stops / terminal stations in and on the bus. Only via the Hof file a given line (in the editor) is identified with the displays.

The routes entered in the Hof file do not specify the route in Omsi, as this is set via the timetable in the editor. The Hof file is used for the information output for the destination displays in the bus, the interior displays in the bus, the displays in the information device (IBIS, IBIS 2, EFAD, Atron, INIT etc.) and the texture names of the roll tape textures, as well as the appropriate announcements.

1.1. Opening

(see also file formats)

Since a Hof file is in pure text format, it can be opened with any text editor, such as Microsoft Windows Notepad. For large and extensive Hof files, where you can quickly lose track of what's going on, Notepad++, a text editor with many functions, which is also helpful in other ways (free of charge), is recommended. Another possibility is to use Microsoft Office Exel (free of charge) or LibreOffice Calc (free of charge).

Furthermore there are special tools explicitly for the Hof file. The HOF Creator by Jan Kiesewalter can only open, edit and save Hof files in OMSI 1 format and is adaptable for different vehicles by templates. The HOF Suite by Lukas reads all formats, saves automatically in the new OMSI 2 format and offers helpful special tools for particularly large Hof files. Both tools are free to download without registration.

1.2. Save

A Hof file must be in the folder of a vehicle (not in any subfolder!) and must have the extension .hof. When saving from a text editor, "All formats" must be selected and the extension .hof must be appended. Alternatively, the file can first be saved as a text file (.txt), then only the extension must be changed. Changes to a Hof file are always only active after a restart of Omsi.

1.3. Structure (OMSI 1 format)

The hof file follows the structure and syntax of a configuration file, comments on whole sections are possible e.g. by tabs. A hof file is always divided into 4 sections:

• Information about the hof file
• List of terms (destinations)
• List of stops
• List of routes

In general, a distinction is made between keywords - this indicates a specific area for certain information - , the assignment lines and strings, the actual "content" read by vehicles.

1.3.1. Information on the Hof file

The first area contains a general definition of the file and information where certain folders are located that the bus will need later. It is recommended to keep the order of the commands.

1.3.2. Global Strings (OMSI 2 only)

The first part of the [global_strings] command specifies the names of the folders that have information about the card (this keyword is omitted in OMSI 1):

• In the Announcements folder under Vehicles\Announcements there are .wav files named equal to the defined stops in the third part of the Hof file (see below). Files that are always played when the stop is at the end of the route (e.g. with the announcement "End stop. Please get off") are given the suffix _#terminal
• The vehicle-specific rolling band folder under Folder under Vehicles\Displays\<Vehicle>\ contains the rolling band files defined per destination in the second part of the Hof file.
• In the side plate folder under Vehicles\Advertisements\side plates\, image files (preferably bitmaps) are located in a 2:1 aspect ratio with the line name. The upper half is the outer side, the lower half is the inner side. (Please also have a look into existing folders to see the concept :))

The digits of the second part can be set arbitrarily if you want to simply add letters to lines. This is matrix- and bus-specific and can be found for the MAN SD buses in the OMSI manual, for all other buses in the documentation.

If, for example, you enter the number "16" for the 500 line, the route input 51200 with a route automatically becomes 51216, which in MAN SD 200/202 displays a "12A" as the line number. If you leave the corresponding figure blank or enter "00", the line number "512" is displayed. So the lines can then be entered as usual, which is necessary if a line exists in the 500, 800 or 900 range. If the codes or one of the codes are not needed, either enter the zero or shorten the number of strings to 3, whereby the line codes are no longer read.

In the Matrix.osc any letter can be assigned to one of the 3 digit positions (see below). The assignment of which letter is shown where exactly in the line display is generally only entered in the Matrix.osc. With the help of the code, the letter can then be set using the assigned code. By the way, a matrix does not necessarily have to be controlled with the file name Matrix.osc. The file name is freely selectable. The file can also be called VMatrix.osc or Matrix_d.osc. A table of the standard suffixes can be found in the appendix.

The exact number of strings depends on the written strings. This becomes important for a "Universal Hof File" (see below), which is used for all display systems used in the buses. You can use up to 999 strings, anything more will be acknowledged with an error from Omsi, because normally not so many strings can be used. It depends on the different display systems of the buses, not on the individual bus itself.

1.3.3. List of terms

In this list you write how the displays of the vehicle should display the corresponding end points. It is important that the correct format is observed for each string, otherwise the destinations will not be displayed correctly. The exact letters that can be displayed are determined by the font of the display devices. If this font contains only upper case letters, the display must be set to upper case. The same applies to umlauts, punctuation marks or symbols.

The display has two modes in which the vehicle is in motion. These are generated by keywords:

[addterminus]: The vehicle is on a passenger journey; passengers can enter and leave the vehicle at their exit stops

[addterminus_allexit]: The vehicle is on a service trip; no passengers are boarding. Passengers who are still on the bus activate the stop request and get off when the door is released.

Below the respective keyword, you will find the two assignment lines. First of all, the IBIS code with a maximum of three digits (leading zeros can be removed). By entering this numerical code in the IBIS, Atron, EFAD, etc. at the Destination key, the selected terminal stop is selected. A code may be assigned to several destinations with the same name, but each individual code may only lead to one destination name! However, you should assign a separate IBIS code for each destination entered, so that the different displays can be used, otherwise Omsi will only ever use the first term entry with this IBIS code. This disadvantage is particularly noticeable with destination displays when the line number is entered in the strings or the displays have additions (about destination). With most Integrated Board Information Systems, 3-digit codes are generally accepted. Destination codes, with more than 3 digits, however, are also required (e.g. for additional signs or matrix replacement signs). Here a 4 or more digit code is then written. These codes cannot be entered into IBIS.

This is followed by the name of the terminal stop of this destination. If the destination leads to a bus stop cube in the OMSI editor, the name must be the same as the cube. Another possibility is the naming after the "destination" entry of a timetable trip. One of the two possibilities leads to a correct display where passengers get on and off. On the other hand, however, not all destinations in the HOF file need to be linked to a stop cube, e.g. if a terminal is outside the map area. This is especially interesting for AI vehicles. The name is only displayed in the debug text (CTRL+Z).

Finally, the block with the strings to be displayed comes last. According to the default in the first area of the Hof file under [stringcount_terminus], a maximum of 999 strings can be added for the display systems, but strings exceeding the defined number (under String_count) will be ignored. Also note that the string count is zero-based. This means that if there are seven strings, string 0 to string 6 are read. The strings are defined in the script files for the respective display devices. The use of which string is used for which display is free, but should be entered sensibly so that the Hof file can be used for other buses.

The use, number and usage of the strings can be found in the documentation of the respective vehicle; see below for vehicles compatible with the universal Hof file.

The following example shows a destination for the standard bus MAN SD 200/202:

[addterminus]               <- Schlüsselwort (alternativ [addterminus_allexit] - s.o.)
214                         <- IBIS-Code
Am Kiesteich                <- Name
AM KIESTEICH                <- String 0
    SPANDAU                 <- String 1
  AM KIESTEICH              <- String...
  AM KIESTEICH
Bln_Am Kiesteich.tga
Am Kiesteich

The line notation shown here can be used for Omsi 1 and Omsi 2. To centre short names in Omsi 1, spaces should be used. In Omsi 2 this is sometimes necessary, but most display systems centre automatically. For the new format used in Omsi 2, see below The order of the entered endpoints, will later determine the order of the roll tape textures, when you set them manually in a bus (i.e. not via the Omsi menu) and when you select the order in the Omsi menu.

1.3.4. List of stops

This list is similar to the destination list. However, there is only one command for defining a stop. For the sake of clarity, only stops that can be operated by the player should be defined in the Hof file, since route input and thus stop input is only possible in a player vehicle. AI-vehicles only describe a destination, the stops and routes are given by the timetable.

There is also a defined name for the stops, this should ideally be the same as the name of the bus stop cube in the editor. The name of a stop does not specify the file name of the announcement. The use, number and usage of the strings can be found in the documentation of the respective vehicle; see also the section on the universal Hof file for vehicles compatible with the universal Hof file.

[addbusstop]                <- Schlüsselwort
Haltestelle                 <- Name
BUSPLATZ AM WALD            <- String 0
Busplatz                    <- String 1
Am Wald                     <- String...
Busplatz am Wald

The order of the individual stops is irrelevant. It should be noted that final stops that have already been defined for the destinations must also be defined as stops because this stop is the last stop on the route. If available, the audio file found under _#terminus.wav will be played at an end stop. For example, you can record the announcement "Please all get off". See also Global Strings (see above).

1.3.5. List of routes

The routes are now defined here. A route is the way from the starting stop via the stops to the final stop of a direction. Except for ring routes, two routes are required for one round trip (outward and return journey). First, a route is defined via [infosystem_trip]; this is followed by the line number with a maximum of three (or four for individual buses) digits and directly after that the two-digit route code (leading zeros can be removed). If you enter, for example, 13706, the route is selected in IBIS via Line/Course: 137xx and Route: 06. This is followed by an unused line, there is space for a description, the code of the destination to be displayed for this route and a repetition of the line number, for the overview.

This is followed by the keyword [infosystem_busstop_list], followed by the number and listing of all stops that are travelled on this route (including the first and last stop).

The full definition of a line (the list of stops has been shortened for demonstration purposes) is therefore:

[infosystem_trip]           <- Schlüsselwort 1
9201                        <- Linie und Nummer der Route
FREUDSTR.-STADTGRENZE       <- Name (wird nicht ausgelesen)
81                          <- IBIS-Code des Ziels
92                          <- Liniennummer

[infosystem_busstop_list]   <- Schlüsselwort 2
3                           <- Anzahl Haltestellen
Freudstr                    <- Anfangshaltestelle
Falkenseer Ch Freud         <- weitere Haltestellen...
Stadtgrenze                 <- Endhaltestelle

As with the stops, to avoid overhead, only lines that can be driven by the player should be entered, as the AI vehicles' exterior displays are regulated by the targets. It is not necessary to write all lines. Some separate lines can do without line lists. But then there is neither a display nor announcements, which is meant e.g. for short lines, or targets that did not exist in matrix or rolling bands at a certain time, like e.g. line E522 in Spandau between November 1989 and December 1990.

1.4. Structure (OMSI 2 format)

OMSI 2 can handle both formats. In addition to the global strings, which are only used in OMSI 2, there is a change regarding the input of destinations and stops:

The [addterminus], [addterminus_allexit], and [addbusstop] are replaced by [addterminus_list] and [addbusstop_list]. Under these keywords, each of which ends with [end], there is a list of all destinations or stops, with the individual strings separated by tabs. One destination or stop per line.

The first column contains nothing for normal destinations, and an {ALLEX} is inserted for allexit destinations (all passengers get off, nobody gets on). In the next tab follows the IBIS code, then the destination name and finally the strings, also separated by a tab. The list of stops is similar, the first tab contains the name, followed by the strings. If a string is empty, a tab stop must still be made.

Some entries are listed as examples (here separated by spaces, this would not work in OMSI, tab stops must be used!

Allexit    Nr.     Name            String 0        String 1   String...
[addterminus_list]
{ALLEX}    0       Empty                                                                      Blanko.tga
           149     Sonderfahrt     SONDERFAHRT                SONDERFAHRT     SONDERFAHRT     Sonderfahrt.tga     Sonderfahrt
           196     Kaiserdamm      U KAISERDAMM    U-BAHNHOF  KAISERDAMM      U KAISERDAMM    Bln_Kaiserdamm.tga  U Kaiserdamm
{ALLEX}    39      Fahrschule      FAHRSCHULE                 FAHRSCHULE      FAHRSCHULE      Fahrschule.tga      Fahrschule
           163     Am Omnibushof   AM OMNIBUSHOF   SPANDAU    AM OMNIBUSHOF   AM OMNIBUSHOF   Betriebshof.tga     Am Omnibushof
[end]

Name                String 0            String 1              String...
[addbusstop_list]
Goltzstr/Reussstr   GOLTZSTR/REUSSS.    Goltzstr./            Reußstr.          Goltzstr./Reußstr.
Am Bogen            AM BOGEN            Am Bogen                                Am Bogen
Beerwinkel          BEERWINKEL          Beerwinkel                              Beerwinkel
[end]

1.4.1. Tips for working with tabs

In Notepad++ you can display tab stops using the control characters (View > Unprintable Characters > Show All), they appear as yellow arrows. You can change the spacing between tabs in Settings > Options > Language > Tab Width.

Another option is to use Microsoft Office Excel, Open/Libre Office Calc or similar spreadsheet programs. Each tab is written in one column. Afterwards you can copy the table to the clipboard (CTRL+C) and paste it back into Notepad++. This also works the other way round: If you insert a text with tabs into a spreadsheet program, the different tabs are automatically written in columns.

Alternatively you can use the HOF Suite, which saves in OMSI 2 format.

1.5. Plug-in label (OMSI 2 only)

If you do not want to have matrix displays for a target, but rather through a plug-in sign behind the windscreen (this is a new feature of Omsi 2), this can also be done through the Hof file. A slotted target is given a 1000 number (this is the only exception where 4-digit IBIS codes are used as standard). A hash character (#) is entered as string 0 (IBIS 1). The texture name (ideally a bitmap with an aspect ratio of 1:4) is entered in string 6, the file can then be found under Vehicles\Displays\Plug-in Labels (subfolders are identified by a \, parent folders by a ..\, see Textures).

There are two things to consider. Firstly, the function of the insertable sign must be present in the script. On the other hand the object files for such an insertion tag must also be included. If these are not available (not all buses have received insertion labels), these codes are ignored by the bus. The control of several plug-in labels is controlled in the bus via a click point [Mouse event].

1.6. Further notes

Each vehicle only reads certain strings. To illustrate this, individual examples:

The exact number of characters, i.e. the length of a string is not limited in the Hof file, but depends on the respective device. Here the permissible character length is defined via the script. Please note that some matrix displays use different character lengths for the formatting of the font (large or small font).

If a letter is to be displayed for a certain line, three groups can be defined. With the help of the codes for the letters, in addition to the line number, the letters are also displayed according to their placement. For example, if you want to display line 23A for all buses with the line numbers 800, simply enter the letter code 16 at string 5 (under Global_strings). Via IBIS you can set the line number 02317 or the line 82300. In the respective Matrix.osc of the bus in the script folder the letter A for the letter code 16 should be entered. If this entry is missing, a space is displayed at this position. Only the numbers 01 to 99 are valid here, which means that all capital letters of the alphabet can be set in all positions of the 3-digit line number, as well as some letter abbreviations, such as SEV, BVG, SB5, etc.

Please note that some ticket printers require additional route entries, which are entered with a multi-digit numerical code. The multi-digit numerical code has the advantage that no IBIS device reads these routes and is therefore only useful for the respective ticket printer. It may not make sense at first to create these additional routes, but it is very useful if these routes are created for other ticket printers in order to be able to use the full scope of the respective ticket printer, which can also increase the fun of the game considerably.

For the current assignment of strings including the maximum character lengths for the Universal Hof File see below.

2. The universal Hof file

This section is aimed at all those who build a bus, create display units and produce complete add-ons.

A Universal Hof file can - as the name suggests - be used in many ways. In concrete terms, this means that a single file can be used for all displays and thus also for all buses that support the Universal Hof File. There will never be a single Hof file for all maps, but it is possible to create a single Hof file for all supported buses, for one map. So only one Hof file will be written and inserted in all bus folders. The advantage of this is that buses with different display systems can also display different destination displays, all coming from a single Hof file for the selected map. Several Hof files are then only necessary when using the chronology function.

2.1. The idea

Marcel and Rüdiger (MR Software), the developers of Omsi, have introduced a universal Hof file with Omsi 1. So it is not about something new, but rather about returning to the beginning, Back to Roots. Two different display devices (Rollband and ANNAX matrix) and two different information control devices (IBIS 1 and IBIS 2). If you think that the two IBIS devices are not different, you should take a look at the displays. While the IBIS 1 can only display upper case letters and the display is limited to a maximum of 16 display digits, the IBIS 2 can display upper and lower case letters and has 20 display digits. For this purpose, both devices have been assigned different strings. New buses with new display systems used the strings that were intended for ANNAX display and had to be rewritten for this. Other buses use the strings that were already set for the IBIS devices. For this purpose the strings already set were rewritten. If you use this Hof file in a MAN SD 202, you may get unwanted display forms and errors. The rewriting of a Hof file is more complex than extending the Hof file and the adaptation of the scripts in the bus for the display devices and the matrix is very simple. Only two digits per script have to be changed. The scripts do not have to be changed completely, no new scripts have to be developed and no scripts have to be extended. Only two digits in the corresponding scripts have to be changed and the Hof file has to be extended by the correspondingly required strings.

Certainly there are fears that the Hof file will fall out of a manageable size with more and more display devices, but when creating it, one can already take care that an already existing string with similar specifications cannot be used. Different displays can be changed by means of a set code, as has already been implemented in the Busfanat full matrix. It cannot be assumed that hundreds of strings will be needed in the future.

Zitat von Busfanat

But if you look at how many buses that have been converted are driving around with mostly the same scripts, I think the need for different strings is soon covered anyway. I think that with 25 strings per target code we can make ends meet for the next months if not years, because the number of scripters is limited.

Since Omsi 2011 was released, many more free and payware buses have been released. Not all of them have a rolling band display or an ANNAX matrix. At Omsi 1 times there was already the BUSE full matrix, the Busfanat full matrix or Flipdot displays. Other information devices in the bus have also found their place in Omsi. All display and information devices need the Hof file as a source of information. For almost every configuration of display devices and information control units the Hof file has to be adapted. If you want to take another bus that does not have one of the two used devices, a new Hof file must be created or the existing Hof file must be rewritten.

Thus, for a map without chronology function there are already several Hof files, with chronology function (as it is the case in Berlin-Spandau) the number increases additionally. If you now add rewritten Hof files for the individual display systems, the number of Hof files increases and there are so many files that it is no longer possible to distinguish exactly which Hof file is suitable for the corresponding bus in the bus selection. In addition, you also have to assign the appropriate Hof file to each vehicle type in the AI list.

All this would not be necessary with a universal Hof file, because all buses access this one universal Hof file.

It may not be difficult to create a Hof file, but not all users have time. With a universal Hof file, every vehicle can use the same Hof file for a map, regardless of the display and information control unit used. When introducing a new display system or a new information control unit, the user only needs to copy a Hof file from another bus without having to ask or test which Hof file actually fits best. This makes sense not only for vehicle and map manufacturers, but also for payware manufacturers, as it ensures that all buses can be used on any map without having to create an extra Hof file beforehand - or search the Internet from the user's site - which also benefits the player.

2.2. Advantages and disadvantages

The aim here is to show that, under certain circumstances, a changeover is certainly sensible and worthwhile.

Advantages:

• One Hof file fits all supported buses, regardless of the display and information system used.
• No need for a Hof file for new display systems, just an extension
• New buses with already known systems can be quickly adapted for the Universal Hof File before the release.
• Installation of new vehicles is limited to the vehicle itself, no additional Hof files are required for existing maps
• No need to test / search for the appropriate Hof file
• A destination can be displayed differently on indicators.

Disadvantages:

• Many already created Hof files (and therefore countless working hours) become superfluous
• The clarity within a Hof file suffers.
• In the case of nonagreement and going it alone, problems/ disputes can arise.
• Changes in the scripts necessary

2.3. Implementation

To implement a universal Hof file in his vehicle, the following three questions must be asked:

1. Which existing strings can I use?
2. Which new strings can I use that are not yet used by other devices?
3. How can I convert new devices to additional strings?

2.3.1. Allocation of the strings

The purpose of a Universal Hof File is of course to adapt to several different information systems on the individual buses. It is of course absurd here if only the strings specified by M+R Software are observed (string 0 to string 7) and simply the following strings already assigned are used. This is a rather less sensible implementation of the Universal Hof File. Of course it is understandable that everyone wants to have the required strings close together. But if already assigned strings are simply rewritten, which were already assigned for other information systems, this would not be in the sense of the Universal Hof File. By publishing them, everyone had the opportunity to get involved in the implementation in order to reserve required strings in advance. Especially add-on producers were contacted directly by me. But since either no answer came or the implementation was only considered, further strings were already assigned to other users. Here the well-known saying "first come, first served" clearly applies.

For new projects new strings have to be adapted at the end accordingly. For some new information systems this unfortunately results in longer string lists. For other information systems it is not necessary (but useful) to fill in the strings that have already been assigned but are not needed. These can also be left blank.

It is not bad to think about which strings already assigned can be used and whether new strings need to be added. New strings are useful if the font length does not fit with other systems or if codes belonging to the display system are written into the strings. A display system that does not accept codes or interprets codes already used differently will result in incorrect displays on the various systems. An ANNAX matrix would also display the letter of the code used if a code for the Busfanat full matrix was used. On the other hand, there are also buses where the information devices used require certain input formats that no other information device can use meaningfully. As an example, we will only mention the LU-200 announcement system here. This can only display two individual digits, as this device has been implemented in reality. No other existing information device can do anything with this display. For this reason, for example, only the numerical codes are reproduced in an IBIS 2 instead of a readable display.

Especially payware manufacturers should, in order to ensure a long game fun, pursue the idea of a universal Hof file instead of blindly overwriting existing strings, which often leads to the fact that buses supplied with one card cannot be used to their full extent on other cards and that extra Hof files are necessary in each case. This also benefits the end user to a not inconsiderable extent.

2.3.2. The universal Hof file in practice

MR Software, the OMSI developers, have simply added more strings to the Hof file for the introduction of OMSI 2, so all standard buses are already based on a kind of universal Hof file. On recommendation Busfanat has converted the full matrix he created to other new strings. Perotinus has also converted the MAN ÜL 242/272/292/312 designed by him to, among others, already new and extended strings.

By the way, it should be mentioned here that all buses that work with a rollband texture or similar base already use a single string, namely string 4. The difference in texture size is controlled by the access of the display subfolders. This concerns:

• MAN SD 200 Rollband from (M+R Software)
• MAN NL 202 Roller conveyor (FRENZYMAX)
• MB O305 by Rolf (RW1HH) [Payware].
• Setra S215 UL from (L.M.M.W.)
• MB O307 V2 Banhnbus (Perotinus)
• MB O407 from (Perotinus)
• GSÜH 240 from (iTram)
• Community buses from (iTram)
• LU 200 and GU 240 from (ViewApp) [Payware]
• and much more.

A negative example are the buses from the add-ons Hamburg Tag&Nacht, Drei Generationen, Chicago and the add-on Hamburg Hafencity. Here, not only were mistakes made (four-digit IBIS codes that no information device can use), but strings already assigned were simply converted. Therefore these vehicles need new Hof files, which have to be created first. For customers of these products without any knowledge of how to create a Hof file, other buses on the above-mentioned maps are only of limited use and using them on other maps leads to additional work.

2.3.3. Adding additional strings

In order to include further strings, you should consider beforehand:

• How many strings do I need for the front display used in the bus?
• Do I need separate strings for a side display?
• Should the rear display show information independently of the other displays or can simply the line number, which can already contain letters due to the suffixes, be used?
• Do I need an additional string for an information control unit installed in the bus or can strings 1 and 2 of the bus stops be used?
• Can some display devices read strings that have already been assigned?

2.3.3.1. How do you agree on new additional strings?

You can announce the future use of new strings in the official Omsi forum. If you want to be sure, you can contact Tatra here, in the OMSI forum or by e-mail and clarify the future use of additional strings - this applies to new as well as already released vehicles. It makes absolutely no difference whether it is a freeware project or a payware project. I don't expect any quid pro quo, no financial compensation, no free add-on or any other kind of consideration.

2.4. Character length and format of a string

In Omsi there is no limit to string length. Also the Hof file itself has no length limit. The length of a particular string is measured exclusively by the display system or the use of the respective string.

A simple example is the IBIS system, which is used as standard by the MAN SD 200/202 and NL/NG buses: While the IBIS 1 can only display uppercase letters without special characters and umlauts, the IBIS 2 can use upper and lowercase letters and umlauts (including "ß"). In addition, the length is different due to the different size. The IBIS 1 has a maximum length of 16 characters, the IBIS 2 can display four more characters. Characters beyond this are not displayed on the screen.

So the last letter of the word

I N V A L I D E N S I E D L U N G

would be missing in IBIS 1. In order to display this properly, you should shorten the display, for example with

I N V A L I D E N S I E D .

Such an abbreviation does not make sense in IBIS 2, however, as longer stop names can be displayed as well as lower case letters:

I n v a l i d e n s i e d l u n g

A shortening is therefore not necessary in this case.

For the exact string lengths and formats see below. With display systems such as a full matrix, the string length is complicated by the fact that the letters are not all the same width. Here you simply have to test whether a text fits on it (names with many "i" or "l" are shorter than those with many "m" or "o").

2.5. Scripts

The Universal Hof File is mainly found in the scripts that control the display systems. These are among others

• Matrix displays
• Rollband script
• IBIS (2), Atron, EFAD, INIT, etc.
• Ticket printer

The script names do not necessarily always have to be the same, common file names are e.g.

• Matrix.osc, Matrix_D.osc, VMatrix.osc
• rollband.osc
• IBIS.osc, IBIS-2.osc, Ticketprinter.osc

As these files are all scripts, they are usually found in the script folder of a vehicle and have the ending .osc. The information control units installed in each bus control not only the outer matrix displays but also the inner stop displays. In these associated scripts the strings are also entered, which are then to be read from the Hof file.

2.5.1. Reading specific strings

There are two system macros for reading the corresponding strings:

(M.V.GetTerminusString)
(M.V.GetBusstopString)

These read out term and stop strings which are located in the 2nd and 3rd area of the Hof file. For this purpose the index (zero-based!) of the string to be read out must be located in the topmost stack (see script system, it is recommended to simply set the index before calling the command). The string settings in IBIS 2 of the MAN SD 202 and the ANNAX matrix are used as examples. Furthermore the loading of the insertion label is shown.

IBIS 2

The IBIS2 reads string 5 from the term list

(L.L.IBIS_TerminusIndex)
5 (M.V.GetTerminusString)
(S.$.IBIS_terminus_name)

and string 3 from the stop list.

(L.L.IBIS_busstop_index)
3 (M.V.GetBusstopString)
(S.$.IBIS_busstop_name)

You can see that the respective term (or bus stop) index is loaded first. This index is first generated from the IBIS code of a destination (or from the name of a stop) using (M.V.GetTerminusIndex) or (M.V.GetBusstopIndex).

2.5.2. ANNAX Matrix

In the ANNAX matrix, strings 1-3 are read out and assembled into lines:

l0 1 (M.V.GetTerminusString) $RemoveSpaces 16 $SetLengthC "@" $+
l0 2 (M.V.GetTerminusString) $RemoveSpaces 16 $SetLengthC "@" $+ $+
l0 3 (M.V.GetTerminusString) $RemoveSpaces 16 $SetLengthC $+
(S.$.Matrix_NewTerminus)

First the index of the target is loaded with l0 (which was saved when entering it into IBIS), then the actual string. Then spaces before and after the string are removed and centred to a length of 16 characters with 16 $SetLengthC. Here you can see that it is no longer necessary to centre strings with spaces: OMSI does this automatically.

2.5.3. Nameplate

The same command applies to the insertion label, but this only applies if the term code is greater than 1000:

1000 >
{if}
     l1 1000 - (S.L.matrix_steckschild_index)
     l0 (S.L.matrix_steckschild_Termindex)

The actual insertion label is then loaded as follows:

{trigger:bus_matrix_change_steckschild}
     (L.L.matrix_steckschild_index) 1 + (S.L.matrix_steckschild_index)
     1000 + (M.V.GetTerminusIndex) (S.L.matrix_steckschild_Termindex)

     (M.L.matrix_setsteckschild)
     (M.L.matrix_refreshIntIndex)
{end}

{macro:matrix_setsteckschild}
     (L.L.matrix_steckschild_Termindex) s0
     0 >= 
     {if}
          l0 6 (M.V.GetTerminusString) (S.$.Matrix_SchildFrnt)
          1 $SetLengthL $StrToFloat 1 max (S.L.matrix_steckschild_vis)
          "..\..\Anzeigen\SteckSchilder\" (L.$.Matrix_SchildFrnt) $+ (S.$.Matrix_SchildFrnt)
     {else}
          0 (S.L.matrix_steckschild_index) (S.L.matrix_steckschild_vis)
          ""  (S.$.Matrix_SchildFrnt)
     {endif}
{end}

The string is loaded and the bitmap file thus determined is saved in a variable. This variable is defined by a Freetex entry in the model.cfg and leads to the label texture.

2.5.4. Reading replacement strings using the example of the Busfanat full matrix

The following section has been created by Busfanat and is intended to show how to use replacement strings. This possibility can be implemented in all busses as long as they can display the displays of an ANNAX matrix cleanly (e.g. not suitable for a BUSE full matrix). An example for the use of such replacement strings is the Busfanat full matrix. This is not limited to two strings, but also uses two original strings as replacements. It allows parts of the target information to be displayed in a special way without using image textures. With additional commands behind the information, a target can be displayed bold or inverted.

2.5.4.1. Basic functions

If a target is to be displayed in a special way, you write the target in string 11 and 12 as desired and these targets are then changed by commands:

String 11: Bahnhof*B
String 12: Kieselstein

Here the word "station" is written in bold letters while the second line is displayed normally.

String 11: Pause*I
String 12:

Here, the word "pause" is inverted and written in capital letters because the second line is not used. The letters appear darker than the area where the dots appear.

2.5.4.2. Use of replacement strings

The matrix first reads information from the strings 11 and 12, which are specially designed for the matrix. If these remain empty, strings 1 and 2 are accessed. If the desired target is to be displayed as in an ANNAX matrix or if the Hof file used does not provide extra strings for the Busfanat full matrix, no special effort is required.

' wenn die Zielanzeige wechseln soll
(L.L.Matrix_TerminusIndex) 1 (M.V.GetTerminusString) (S.$.Matrix_Hofdatei_oben)
(L.L.Matrix_TerminusIndex) 2 (M.V.GetTerminusString) (S.$.Matrix_Hofdatei_unten)

(L.L.Matrix_TerminusIndex) 11 (M.V.GetTerminusString) "" $= !
(L.L.Matrix_TerminusIndex) 12 (M.V.GetTerminusString) "" $= ! ||
{if}
     (L.L.Matrix_TerminusIndex) 11 (M.V.GetTerminusString) (S.$.Matrix_Hofdatei_oben)
     (L.L.Matrix_TerminusIndex) 12 (M.V.GetTerminusString) (S.$.Matrix_Hofdatei_unten)
{endif}

At first the script omits the strings 1 and 2. If strings 11 and 12 are both not empty (note the double negation of the "or"), they overwrite the previously saved strings 1 and 2. If strings 11 and 12 are empty or the strings are not present in the Hof file, strings 1 and 2 are displayed. Omsi does not recognise the missing strings as errors.

3. Sources & further links

• Matrix display systems: Busfanat-Vollmatrix, Krüger++, LAWO-Matrix
• Buses that implement the universal Hof file: MAN ÜL, MB O307 Bahnbus, MB O407, Gräf&Stift GSÜH 240, Gräf&Stift Gemeinschaftsbusse
• Sources: Hof file Spandau by M+R Software from OMSI1 and OMSI2, scripts from the MAN SD200/202 buses

4. Attachment

I would be delighted if this universal Hof file could be implemented again. It is not really a new idea, because Marcel Kuhnt and Rüdiger Hülsmann have already implemented it with Omsi 1. By new busses, maps and addons already assigned strings were overwritten and the Hof file was rewritten for especially these busses. So there are several different Hof files for a map in Omsi today, each of which only fits for one group of buses.

For the simple and fast implementation, the communication should be improved, especially to manufacturers of add-ons. While some users were open to the topic, companies did not react at all or showed no interest.

If somebody wants to implement a universal Hof file for his project, I am willing to give help without return. Marcel Kuhnt and Janine have a positive attitude towards this idea and supported me in publishing the Hof file here. Busfanat very quickly converted the full matrix he had developed. Perotinus also converted his newly created buses MAN ÜL after consultation and with the help of Busfanat and Cooper.

The first steps have now been taken and I thank Busfanat, Cooper and Perotinus very much for their great cooperation and the implementation. And I hope that this topic will be heard more in the future, because the Universal Hof File offers many advantages on the addon creator side and user side.

Acknowledgements go to

• Busfanat
• Chrizzly92
• Cooper
• Danny
• Davidps
• iTram
• Janine
• Marcel Kuhnt
• Nuorahino
• Perotinus
• Rumpelhans
• Teneberus
• ViewApp

4.1. Current strings of the universal Hof file

Below is a list of the strings officially assigned to the Universal Hof File. This list will be constantly updated as far as possible and should be strictly observed if the Universal Hof File is used. Some display systems recognise empty strings and use the original strings (alternative string) for compatibility. They are optional and should only be filled in if you really have a special benefit from their use (e.g. font formatting). The asterisk * indicates that if a line is empty in a multi-line display system, the string is then projected onto the full display. The length of a string may be exceeded or undershot, but in the latter case the string will be displayed incompletely.

Terminus-Strings (26)

4.2. Standard suffixes

Here is a list of IBIS suffixes of the standard matrix. These are the last two numbers in the line/price input and are important for the global strings.

00   ###            10   ##E        25   _U#        35   N##
01   E##            11   _D#        26   U##        36   X##
02   Dreieck        12   _C#        27   _M#        97   Version
03   Schulbus       13   _B#        28   M##        98   Schachbrett
04   ##N            14   _A#        29   BVG        99   Alle (Wechsel)
05   S##            15   _N#        30   ##S
06   A##            23   _S#        31   ##U
09   _#E            24   S##        32   ##M