Hofdatei

geschrieben von Tatra

1. Hofdateien für OMSI

Eine Hofdatei ist die Grundlage, um einen Bus auf einer Linie, mit Zielanzeigen einer Map fahren zu können. Ohne Hofdatei kann der Bus keine Informationen anzeigen (Matrix, Rollbänder), wodurch keine Fahrgäste einsteigen. Sie beinhaltet eine Liste der Endhaltestellen (im Folgenden Terminus genannt), Haltestellen und die Routen der einzelnen Linien. Sie dient lediglich der Information der Anzeigen und der Audiowiedergabe der Haltestellen / Endstellen im und am Bus. Nur über die Hofdatei wird eine vorgegebene Linie (im Editor) mit den Anzeigen identifiziert.

Die in der Hofdatei eingetragenen Routen geben nicht den Linienverlauf in Omsi vor, denn dieser wird über den Fahrplan im Editor gestellt. Die Hofdatei dient der Informationsausgabe für die Zielanzeigen im Bus, die Innenanzeigen im Bus, die Anzeigen im Informationsgerät (IBIS, IBIS 2, EFAD, Atron, INIT usw) und die Texturnamen der Rollbandtexturen, sowie den passenden Ansagen.

1.1. Öffnen

(s. auch Dateiformate)

Da eine Hofdatei im Reintext-Format vorliegt, kann sie mit jedem Texteditor, wie dem Microsoft Windows Notepad geöffnet werden. Für große und umfangreiche Hofdateien, bei denen man schnell den Überblick verlieren kann, empfiehlt sich Notepad++, ein Texteditor mit vielen Funktionen, der auch anderweitig hilfreich ist (kostenfrei). Eine weitere Möglichkeit ist die Nutzung von Microsoft Office Exel (kostepflchtig) oder LibreOffice Calc (kostenfrei).

Darüber hinaus gibt es spezielle Tools explizit für die Hof-Datei. Der HOF Creator von Jan Kiesewalter kann nur Hof-Dateien im OMSI 1-Format öffnen, bearbeiten und speichern und ist durch Templates annpassbar für verschiedene Fahrzeuge. Die HOF Suite von Lukas liest alle Formate ein, speichert automatisch im neuen OMSI 2-Format und bietet hilfreiche Spezialwerkzeuge für besonders große Hof-Dateien. Beide Tools sind kostenlos ohne Anmeldung herunterzuladen.

1.2. Speichern

Eine Hofdatei muß im Ordner eines Fahrzeugs liegen (in keinem Unterordner!) und muß die Endung .hof haben. Beim Speichern aus einem Texteditor muss "Alle Formate" ausgewählt werden und die Endung .hof angehängt werden. Alternativ kann die Datei zunächst als Textdatei (.txt) abgespeichert werden, dann muss nur noch die Endung verändert werden. Änderungen einer Hofdatei werden immer erst nach einem Neustart von Omsi aktiv.

1.3. Aufbau (OMSI 1-Format)

Die Hof-Datei folgt dem Aufbau und Syntax einer Konfigurationsdatei, Auskommentierungen ganzer Abschnitte sind also z.B. durch Tabs möglich. Eine Hofdatei gliedert sich immer in 4 Bereiche:

1. Informationen zur Hofdatei
2. Liste der Termini (Ziele)
3. Liste der Haltestellen
4. Liste der Routen

Generell wird zwischen Schlüsselwort - dies kennzeichnet einen bestimmten Bereich für bestimmte Informationen - , den Zuordnungszeilen und Strings, dem eigentlichen "Inhalt", der von Fahrzeugen ausgelesen wird, unterschieden.

1.3.1. Informationen zur Hofdatei

Der erste Bereich enthält eine allgemeine Definition der Datei und Informationen, wo sich bestimmte Ordner befinden, die der Bus später benötigt. Es empfiehlt sich, die Reihenfolge der Befehle beizubehalten.

1.3.2. Global Strings (nur OMSI 2)

Mit dem ersten Teil des [global_strings]-Befehls wird angegeben, wie die Ordner heißen, die Informationen zu der Karte haben (dieses Schlüsselwort entfällt bei OMSI 1):

• Im Ansagen-Ordner unter Vehicles\Announcements liegen .wav-Dateien, die gleich der definierten Haltestellen im dritten Teil der Hof-Datei (s.u.) heißen. Dateien, die immer dann abgespielt werden, wenn die Haltestelle am Ende der Route ist (z. B. mit der Ansage "Endstelle. Bitte aussteigen"), erhalten den Suffix _#terminus
• Der fahrzeug-spezifische Rollband-Ordner unter Ordner unter Vehicles\Anzeigen\<Fahrzeug>\ enthält die Rollband-Dateien, die pro Ziel im zweiten Teil der Hof-Datei definiert werden.
• Im Seitenschild-Ordner unter Vehicles\Anzeigen\Seitenschilder\ liegen Bilddateien (bevorzugt Bitmaps) im 2:1-Seitenverhältnis mit dem Liniennamen. Die obere Hälfte ist die Außenseite, die untere die Innenseite. (Bitte auch in vorhandene Ordner reinschauen um sich das Konzept anzuschauen )

Die Ziffern des zweiten Teils können beliebig gesetzt werden, wenn man Linien einfach mit Buchstaben ausstatten möchte. Dies ist matrix- und busspezifisch und kann für die MAN SD-Busse im OMSI-Handbuch nachgelesen werden, bei allen anderen Bussen in der Dokumentation.

Trägt man z. B. bei der 500er Linie die Ziffer "16" ein, wird aus der Routeneingabe 51200 mit einer Route automatisch die 51216, was im MAN SD 200/202 eine "12A" als Liniennummer anzeigt. Lässt man die entsprechende Ziffer leer oder trägt "00" ein, wird die Liniennummer "512" angezeigt. Dann können die Linien also wie gewohnt eingetragen werden, was dann notwendig ist, wenn eine Linie im 500-er, 800-er oder 900-er Bereich existiert. Werden die Codes oder einer der Codes nicht gebraucht, trägt man entweder die Null ein, oder man kürzt die Stringanzahl auf 3, wobei die Liniencodes nichtmehr gelesen werden.

In der Matrix.osc kann jeder beliebige Buchstabe mit einem der 3 Ziffernplätze belegt werden (s.u.). Die Zuordnung, welcher Buchstabe wo genau in der Linienanzeige angezeigt wird, wird generell nur in der Matrix.osc eingetragen. Mit Hilfe des Codes kann dann der Buchstabe über den zugordneten Code gesetzt werden. Übrigens muß eine Matrix nicht zwangsläufig mit dem Dateinamen Matrix.osc gesteuert werden. Der Dateiname ist frei wählbar. So kann auch die Datei VMatrix.osc oder Matrix_d.osc heißen. Eine Tabelle der Standard-Suffixe findet sich im Anhang.

Die genaue Anzahl der Strings richtet sich nach den geschriebenen Strings. Wichtig wird dies für eine "Universelle Hofdatei" (s.u.), die für alle verwendeten Anzeigesysteme in den Bussen Verwendung finden. Man kann bis zu 999 Strings verwenden, alles darüber hinaus, wird mit einem Fehler von Omsi quittiert, da normal nicht so viele Strings benötigt werden können. Es richtet sich nach den unterschiedlichen Anzeigesystemen der Busse, nicht nach dem einzelnen Bus selbst.

1.3.3. Liste der Termini

In dieser Liste wird geschrieben, wie die Anzeigen des Fahrzeugs die entsprechenden Endstellen anzeigen sollen. Wichtig hierbei ist, daß das korrekte Format für jeden String beachtet wird, da die Ziele sonst nicht korrekt angezeigt werden. Welche Buchstaben genau angezeigt werden können, entscheidet der Font der Anzeigegeräte. Beinhaltet dieser Font nur Großbuchstaben, muß die Anzeige in Großbuchstaben gesetzt werden. Das gleiche gilt für Umlaute, Satzzeichen oder Symbole.

Die Anzeige kennt zwei Modi, in denen das Fahrzeug verkehrt. Diese werden durch Schlüsselwörter erzeugt:

• [addterminus]: Das Fahrzeug befindet sich auf einer Fahrgastfahrt; es können Fahrgäste ein- und an ihren Austiegshaltestellen wieder aussteigen
• [addterminus_allexit]: Das Fahrzeug befindet sich auf einer Betriebsfahrt; es steigen keine Fahrgäste ein. Fahrgäste, die sich noch im Bus befinden, betätigen den Haltewunsch und steigen bei Türfreigabe aus.

Unter dem jeweiligen Schlüsselwort, stehen die beiden Zuordnungezeilen. Hier kommt zunächst der maximal dreistellige IBIS-Code (führende Nullen können entfernt werden). Durch Eingabe dieses Zahlencodes in das IBIS, Atron, EFAD, etc. bei der Taste Ziel wird die gewählte Endhaltestelle ausgewählt. Ein Code darf für mehrere gleichnamige Ziele vergeben werden, aber jeder einzelne Code darf nur zu einem Zielnamen führen! Man sollte allerdings für jedes eingetragene Ziel einen eigenen IBIS-Code vergeben, damit die unterschiedlichen Anzeigen auch genutzt werden können, da Omsi sonst immer nur den ersten Termini-Eintrag, mit diesem IBIS-Code verwendet. Der Nachteil macht sich besonders bei Zielanzeigen bemerkbar, wenn die Liniennummer in den Strings eingetragen werden oder die Anzeigen über Zusätze verfügen (über Ziel). Bei den meisten Integriertes Bord Iformations Systemen, werden genrell 3-stellige Codes angenommen. Zielcodes, mit mehr als 3 Stellen, werden aber auch benötigt (beispielsweise für Zusatzschilder oder Matrix-Ersatzschilder). Hier wird dann ein 4 oder mehrstelliger Codes geschrieben. Diese Codes können nicht ins IBIS eingetragen werden.

Es folgt der Name der Endhaltestelle dieses Ziels. Falls das Ziel zu einem Busstop-Würfel im OMSI-Editor führt, muß der Name gleich dem Würfel sein. Eine andere Möglichkeit ist die Benennung nach der "Ziel"-Eingabe eines Fahrplan-Trips. Eine der beiden Möglichkeiten führt zu einer korrekten Anzeige, bei der Fahrgäste ein- und aussteigen. Im Gegenzug müssen aber nicht alle Ziele in der HOF-Datei mit einem Haltestellenwürfel verknüpft sein, z. B. wenn eine Endstelle außerhalb des Kartenbereichs liegt. Dies ist besonders für KI-Fahrzeuge interessant. Der Name wird nur im Debug-Text (STRG+Z) angezeigt.

Zuletzt kommt der Block mit den anzuzeigenden Strings. Gemäß der Vorgabe im ersten Bereich der Hofdatei unter [stringcount_terminus] kann man maximal 999 Strings für die Anzeigesysteme hinzufügen, allerdings werden Strings, die über die festgelegte Anzahl (unter String_count) hinausgehen, ignoriert. Außerdem ist zu Beachten, dass die Stingzählung nullbasiert ist. Das bedeutet, dass bei einer Anzahl von sieben Strings, String 0 bis String 6 ausgelesen werden. Die Strings werden für die jeweiligen Anzeigegeräte in den Script-Dateien festgelegt. Die Verwendung, welcher String für welche Anzeige genutzt wird, ist frei, sollte aber sinnvoll eingetragen werden, damit die Hofdatei für andere Busse genutzt werden kann.

Die Verwendung, Anzahl und Benutzung der Strings kann in der Dokumentation des jeweiligen Fahrzeuges nachgelesen werden; s.u. für Fahrzeuge, die mit der universellen Hofdatei kompatibel sind.

Das folgende Beispel zeigt ein Ziel für den Standardbus MAN SD 200/202:

[addterminus]               <- Befehl (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

Die hier gezeigte Schreibweise in Zeilen kann für Omsi 1 und Omsi 2 verwendet werden. Um bei Omsi 1 kurze Namen zu zentrieren, sollten Leerzeichen verwendet werden. In Omsi 2 ist dies teilweise nötig; aber die meisten Anzeigesysteme zentrieren automatisch. Für das neue in Omsi 2 verwendete Format s.u. Die Reihenfolge der eingetragenen Endstellen, bestimmt später die Reihenfolge der Rollbandtexturen, wenn man diese in einem Bus manuell einstellt (also nicht über das Omsi-Menü) und bei der Auswahl der Reihenfolge im Omsi-Menü.

1.3.4. Liste der Haltestellen

Diese Liste verhält sich ähnlich der Ziel-Liste. Es gibt allerdings nur einen Befehl für die Definition einer Haltestelle. Der Übersichtlichkeit halber sollten in der Hofdatei nur Haltestellen definiert werden, die auch vom Spieler bedient werden können, da die Routen-Eingabe und somit auch die Haltestelleneingabe nur in einem Spielerfahrzeug möglich ist. KI-Fahrzeuge schildern lediglich ein Ziel, die Haltestellen und Routen werden vom Fahrplan vorgegeben.

Auch bei den Haltestellen gibt es einen definierten Namen, dieser sollte im Idealfall gleich dem Namen des Busstop-Würfels im Editor sein. Der Name einer Haltestelle gibt nicht den Dateinamen der Ansage vor. Die Verwendung, Anzahl und Benutzung der Strings kann in der Dokumentation des jeweiligen Fahrzeuges nachgelesen werden; siehe auch den Abschnitt zur universellen Hofdatei für Fahrzeuge, die mit der universellen Hofdatei kompatibel sind.

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

Die Reihenfolge der einzelnen Haltestellen ist dabei irrelevant. Zu beachten ist, dass auch Endhaltestellen, die schon bei den Zielen definiert wurden, als Haltestelle definiert werden müssen, weil diese Haltestelle in der Route die letzte Haltestelle ist. Falls vorhanden, wird bei einer Endhaltestelle die Audiodatei abgespielt, die unter _#terminus.wav zu finden ist. So kann man z. B. die Ansage "Bitte alle aussteigen" einsprechen. Zu den Ansagen siehe auch Global Strings (s.o.).

1.3.5. Liste der Routen

Hier werden nun die Routen definiert. Eine Route ist der Weg von der Anfangshaltestelle über die Haltestellen bis zur Endhaltestelle einer Richtung. Für einen Umlauf sind - außer bei Ring-Routen - zwei Routen nötig (Hin- und Rückfahrt). Zunächst wird eine Route über [infosystem_trip] definiert; es folgt die maximal drei- (bei einzelnen Bussen auch vier-)stellige Liniennummer und direkt danach der zweistellige Routencode (führende Nullen können entfernt werden). Bei der Eingabe von z. B. 13706 wird die Route im IBIS über Linie/Kurs: 137xx und Route: 06 ausgewählt. Es folgt eine ungenutzte Zeile, hier ist Platz für eine Beschreibung, der Code des Ziels, welches bei dieser Route angezeigt werden soll, und eine Wiederholung der Liniennummer, für die Übersicht.

Darauf folgt das Schlüsselwort [infosystem_busstop_list], gefolgt von Anzahl und Auflistung aller Haltestellen, die in dieser Route befahren werden (inklusive erster und letzter Haltestelle).

Die vollständige Definition einer Linie (die Haltestellenliste wurden zu Demonstrationszwecken gekürzt) lautet also:

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

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

Wie auch bei den Haltestellen sollten, um Overhead zu vermeiden, nur Linien eingetragen werden, die vom Spieler befahren werden können, da die Außenanzeigen der KI-Fahrzeuge durch die Ziele geregelt sind. Es müssen nicht alle Linien geschrieben werden. Einige gesonderte Linien kommen auch ohne Linienlisten aus. Dann gibt es aber weder eine Anzeige noch Ansagen, was z.B. bei kurzeitigen Linien gedacht ist oder Zielen, die zu einer bestimmten Zeit nicht in Matrix oder Röllbändern existierten, wie z. B. die Linie E522 in Spandau zwischen November 1989 und Dezember 1990.

1.4. Aufbau (OMSI 2-Format)

OMSI 2 kann mit beiden Formaten umgehen. Neben den Global Strings, die nur in OMSI 2 benutzt werden, gibt es eine Änderung, was die Eingabe von Zielen und Haltestellen betrifft:

An die Stelle von [addterminus], [addterminus_allexit] und [addbusstop] treten nun [addterminus_list] und [addbusstop_list]. Unter diesen Schlüsselwörtern, die jeweils mit einem [end] abgeschlossen werden, befindet sich eine Liste mit allen Zielen bzw. Haltestellen, wobei die einzelnen Strings durch Tabstopps getrennt sind. Pro Zeile ein Ziel bzw. eine Haltestelle.

Die erste Spalte enthält bei normalen Zielen nichts, bei Allexit-Zielen (alle Fahrgäste steigen aus, keiner steigt ein s.o.) wird ein {ALLEX} eingefügt. Im nächsten Tab folgt der IBIS-Code, darauf der Zielname und schließlich die Strings, jeweils ebenfalls durch ein Tab getrennt. Bei der Haltestellenliste verhält es sich ähnlich, im ersten Tab steht der Name, dann folgen die Strings. Ist ein String leer, muss trotzdem ein Tabstopp gemacht werden.

Beispielhaft sind einige Einträge aufgeführt (hier durch Leerzeichen getrennt, in OMSI würde dies so nicht funktionieren, es müssen Tabstopps genutzt werden!

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. Tipps für das Arbeiten mit Tabulator

In Notepad++ kann man Tabstopps mithilfe der Steuerzeichen anzeigen lassen (Ansicht > nicht druckbare Zeichen > Alle anzeigen), sie erscheinen als gelbe Pfeile. Den Abstand der einzelnen Tabs kann man unter Einstellungen > Optionen > Sprache > Tabulatorbreite verändern.

Eine andere Möglichkeit ist das Nutzen von Microsoft Office Excel, Open/Libre Office Calc oder vergleichbare Tabellenkalkulationsprogramme. Pro Tab wird hier in eine Spalte geschrieben. Anschließend kann die Tabelle in die Zwischenablage kopiert (STRG+C) und wieder zurück in Notepad++ eingefügt werden. Umgekehrt funktioniert dies auch: Fügt man einen Text mit Tabulatoren in ein Tabellenkalkulationsprogramm ein, werden die verschiedenen Tabs automatisch in Spalten geschrieben.

Alternativ kann die HOF Suite benutzt werden, die im OMSI 2-Format speichert.

1.5. Steckschild (nur OMSI 2)

Soll es keine Matrix-Anzeigen für ein Ziel geben, sondern durch ein Steckschild hinter der Windschutzscheibe (dies ist eine neue Funktion von Omsi 2), geht dies ebenfalls über die Hof-Datei. Ein Steckschild-Ziel erhält eine 1000er Nummer (dies ist die einzige Ausnahme, in der standardmäßig vierstellige IBIS-Codes zur Anwendung kommen). Als String 0 (IBIS 1) wird ein Rautezeichen (#) eingetragen. Der Texturname (idealerweise ein Bitmap im Seitenverhältnis 1:4) kommt in den String 6, die Datei ist dann unter Vehicles\Anzeigen\SteckSchilder zu finden (Unterordner durch ein \ kenntlich machen, übergeordnete Ordner durch ein ..\, s. Texturen).

Zwei Dinge sind dabei zu beachten. Zum einen muß im Script die Funktion des Steckschildes vorhanden sein. Zum anderen müßen auch die Objektdateien für solch ein Steckschild eingebaut werden. Sind diese nicht vorhanden (nicht alle Busse haben Steckschilder erhalten) werden diese Codes vom Bus nicht beachtet. Die Steuerung von mehreren Steckschildern, wird im Bus über einen Klickpoint [Mouseevent] gesteuert.

1.6. Weitere Hinweise

Jedes Fahrzeug liest nur bestimmte Strings aus. Um dies zu verdeutlichen, einzelne Beispiele:

Die genaue Zeichenanzahl, also die Länge eines Strings ist in der Hofdatei nicht begrenzt, sondern abhängig vom jeweiligen Gerät. Hier wird die zulässige Zeichenlänge über das Script definiert. Hierbei ist zu beachten, dass einige Matrixanzeigen, unterschiedliche Zeichenlängen für die Formatierung der Schrift nutzen (große oder kleine Schrift).

Soll für eine bestimmte Linie ein Buchstabe angezeigt werden, so kann man drei Gruppen festlegen. Mit Hilfe der Codes für die Buchstaben, werden zusätzlich zur Liniennummer auch die Buchstaben entsprechend ihrer Platzierung angezeigt. Soll also als Beispiel die Linie 23A für alle Busse mit den Liniennummern 800 angezeigt werden, schreibt man einfach bei String 5 (unter Global_strings) den Buchstabencode 16 ein. Über das IBIS stellt man die Liniennummer 02317 ein oder die Linie 82300. In der jeweiligen Matrix.osc des Busses im Scriptordner sollte dann natürlich der Buchstabe A für den Buchstabencode 16 eingetragen sein. Fehlt dieser Eintrag, wird an der Stelle ein Leerzeichen angezeigt. Gültig sind hier nur die Zahlen 01 bis 99. Somit lassen sich an allen Stellen der 3-stelligen Liniennummer, alle Großbuchstaben des Alphabets setzen, sowie einige Buchstabenkürzel, wie beispielsweise SEV, BVG, SB5, usw.

Bitte beachtet, daß einige Fahrkartendrucker noch zusätzliche Routeneinträge benötigen, die mit einem mehrstelligen Zahlencode eingetragen werden. Der mehrstellige Zahlencode hat den Vorteil, daß kein IBIS-Gerät diese Routen ausliest und somit einzig und allein nur für den jeweiligen Fahrkartendrucker nützlich sind. Es mag im ersten Moment keine Sinn machen, diese zusätzlichen Routen zu erstellen, ist aber sehr sinnvoll, wenn für andere Fahrkartendrucker, diese Routen erstellt werden, um den vollständig Umfang der jeweiligen Fahrkartendrucker nutzen zu können, was auch den Spielspaß deutlich erhöhen kann.

Zur derzeitigen Vergabe der Strings inklusive der maximalen Zeichenlängen für die Universelle Hofdatei s.u.

2. Die Universelle Hofdatei

Dieser Abschnitt richtet sich an alle Personen die einen Bus bauen, Anzeigegeräte erstellen und komplette Add-Ons produzieren.

Eine Universelle Hofdatei kann - wie der Name schon sagt - vielseitig eingesetzt werden. Konkret bedeutet dies, dass eine einzige Datei für alle Anzeigegeräte und somit auch alle Busse, die die Universelle Hofdatei unterstützen, eingesetzt werden kann. Es wird nie eine einzige Hofdatei für alle Maps geben, aber es ist möglich, eine einzige Hofdatei für alle unterstützten Busse, für eine Map zu kreieren. Somit wird nur eine Hofdatei geschrieben und in alle Bus-Ordner eingefügt. Der Vorteil dabei ist, dass Busse mit unterschiedlichen Anzeigesystemen auch unterschiedliche Zielanzeigen darstellen können, die alle aus einer einzigen Hofdatei für die gewählte Map kommen. Mehrere Hofdateien sind dann nur bei Verwendung der Chronologiefunktion notwendig.

2.1. Die Idee

Marcel und Rüdiger (MR Software), die Entwickler von Omsi, haben eine universelle Hofdatei mit Omsi 1 eingeführt. Es geht also nicht um etwas Neues, sondern vielmehr um die Rückkehr zum Anfang, Back to Roots. Zwei unterschiedliche Anzeigegeräte (Rollband und ANNAX-Matrix) und zwei unterschiedliche Informationssteuergeräte (IBIS 1 und IBIS 2). Wer meint, dass die beiden IBIS-Geräte nicht unterschiedlich wären, sollte sich mal die Anzeigen ansehen. Wärend das IBIS 1 nur Großbuchstaben anzeigen kann und die Anzeige auf maximal 16 Anzeigestellen begrenzt ist, kann das IBIS 2 Groß- und Kleinbuchstaben anzeigen und weist 20 Anzeigestellen vor. Dafür wurden beiden Geräten unterschiedliche Strings zugewiesen. Neue Busse mit neuartigen Anzeigesystemen haben die Strings benutzt, die für die ANNAX-Anzeige vorgesehen waren und mussten dafür umgeschrieben werden. Andere Busse nutzen die Strings, die bereits für die IBIS-Geräte eingestellt wurden. Dazu wurden die bereits festgelegten Strings umgeschrieben. Benutzt man diese Hofdatei in einem MAN SD 202, erhält man teilweise unerwünschte Anzeigeformen und Fehler. Das Umschreiben einer Hofdatei ist dabei aufwendiger als die Hofdatei zu erweitern und das Anpassen der Scripte im Bus für die Anzeigegeräte und die Matrix ist sehr einfach. Es müssen jeweils nur zwei Ziffern je Script geändert werden. Die Scripte müssen dafür nicht komplett umgestellt werden, keine neuen Scripte entwickelt werden und keine Scripte erweitert werden. Es werden nur zwei Ziffern in den entsprechenden Scripten geändert und die Hofdatei um die entsprechend benötigten Strings erweitert.

Sicherlich gibt es Befürchtungen, dass die Hofdatei mit immer mehr Anzeigegeräten aus einem überschaubaren Rahmen fällt, jedoch kann beim Erstellen schon darauf geachtet werden, ob nicht vielleicht ein bereits vorhandener String mit ähnlichen Spezifikationen genutzt werden kann. Unterschiedliche Anzeigen, kann man mittels eingestelltem Code verändern, so wie dies in der Busfanat Vollmatrix schon umgesetzt wurde. Es kann also nicht davon ausgegangen werden, daß künftig über hunderte Strings benötigt werden könnten.

Zitat von Busfanat

Wenn man sich aber anschaut, wie viele Busse, die umgesetzt wurden, mit großteils den gleichen Scripts rumfahren, dann ist meiner Meinung nach der Bedarf nach verschiedenen Strings sowieso bald gedeckt. Ich glaube, mit 25 Strings pro Zielcode kommen wir die nächsten Monate wenn nicht Jahre über die Runden, weil sich einfach die Anzahl der Scripter in Grenzen hält.

Seitdem Omsi 2011 erschienen ist, sind viele weitere Free- und Payware-Busse erschienen. Nicht alle haben eine Rollbandanzeige oder eine ANNAX-Matrix. Zu Omsi 1-Zeiten gab es schon die BUSE-Vollmatrix, die Busfanat-Vollmatrix oder Flipdot-Anzeigen. Auch andere Informationsgeräte im Bus haben ihren Platz in Omsi gefunden. Alle Anzeige- und Informationsgeräte brauchen die Hofdatei als Informationsquelle. Für fast jede Konfiguration von Anzeige-Geräten und Informationssteuergeräten muss die Hofdatei angepasst werden. Möchte man nun einen anderen Bus nehmen, der eines der beiden verwendeten Geräte nicht besitzt, muss eine neue Hofdatei angefertigt oder die vorhandene Hofdatei umgeschrieben werden.

Damit gibt es für eine Map ohne Chronologiefunktion schon mehrere Hofdateien, mit Chronologiefunktion (wie es in Berlin-Spandau der Fall ist) steigt die Anzahl zusätzlich. Stellt man nun noch für die einzelnen Anzeigesysteme umgeschriebene Hofdateien hinzu, schnellt die Zahl an Hof-Dateien in die Höhe und es werden so viele Dateien, dass man in der Busauswahl nicht mehr genau unterscheiden kann, welche Hofdatei nun für den entsprechenden Bus passend ist. Darüber hinaus muss man in der AI-List ebenfalls noch jedem Fahrzeugtyp die passende Hof-Datei zuweisen.

Dies alles würde mit einer universellen Hofdatei wegfallen, weil alle Busse auf diese eine Universelle Hofdatei zugreifen.

Es mag insgesamt nicht schwer sein, eine Hofdatei zu erstellen, aber nicht alle User haben Zeit. Mit einer universellen Hofdatei kann jedes Fahrzeug, unabhängig vom verwendeten Anzeige- und Informationssteuergerät, die selbe Hofdatei für eine Karte verwenden. Bei Einführung eines neuen Anzeigesystems oder eines neuen Informationssteuergerätes braucht der User nur noch eine Hofdatei aus einem anderen Bus kopieren, ohne verher nachfragen oder testen zu müssen, welche Hofdatei eigentlich am besten passt. Das ist nicht nur für Fahrzeug- und Kartenersteller sinnvoll, sondern auch für Paywarehersteller, da somit gewährleistet ist, dass wirklich alle Busse auf jeder Karte einsetzbar sind, ohne zuvor eine extra Hofdatei erstellen - oder von Nutzerseite aus im Internet suchen - zu müssen - dies kommt auch dem Spieler zugute.

2.2. Vor- und Nachteile

Hier soll aufgezeigt werden, dass eine Umstellung unter bestimmten Umständen durchaus sinnvoll ist und sich lohnt.

Vorteile:

• Eine Hofdatei passt für alle unterstützten Busse, unabhängig vom verwendeten Anzeige- und Informationssystem.
• Keine neue Hofdatei bei neuen Anzeigesystemen nötig, sondern lediglich eine Erweiterung
• Neue Busse mit schon bekannten Systemen können vor dem Release schnell für die Universelle Hofdatei angepasst werden.
• Installation neuer Fahrzeuge beschränkt sich auf das Fahrzeug an sich, es sind keine weiteren Hofdateien für vorhandene Maps nötig
• Kein Testen / Suchen nach der passender Hofdatei notwendig
• Ein Ziel kann unterschiedlich auf Anzeigen angezeigt werden.

Nachteile:

• Viele bereits erstellte Hofdateien (und somit auch unzählige Arbeitsstunden) werden überflüssig
• Die Übersichtlichkeit innerhalb einer Hofdatei leidet.
• Bei Nichtabsprache und Alleingängen kann es zu Problemen/ Streitigkeiten kommen.
• Veränderungen in den Scripts nötig

2.3. Umsetzung

Um eine universelle Hofdatei in seinem Fahrzeug umzusetzen, müssen folgende drei Fragen gestellt werden:

1. Welche vorhandenen Strings kann ich nutzen?
2. Welche neuen Strings kann ich verwenden, die noch nicht von anderen Geräten verwendet werden?
3. Wie kann ich neue Geräte auf weitere Strings umsetzen?

2.3.1. Vergabe der Strings

Sinn und Zweck einer Universellen Hofdatei ist natürlich die Anpassung an mehrere verschiedene Informationssysteme an den einzelnen Bussen. Hierbei ist es natürlich unsinnig, wenn nur die von M+R Software vorgegebenen Strings beachtet werden (String 0 bis String 7) und einfach die nachfolgenden bereits vergebenen Strings verwendet werden. Dies ist eine eher weniger sinnvolle Umsetzung der Universellen Hofdatei. Natürlich ist verständlich, dass jeder die benötigten Strings dicht beieinander haben möchte. Wenn aber bereits vergebene Strings einfach wieder umgeschrieben werden, die bereits für andere Informationssysteme vergeben wurden, wäre dies nicht im Sinne der Universellen Hofdatei. Durch die Veröffentlichung hatte jeder die Möglichkeit, sich für eine Beteiligung an der Umsetzung einzubringen, um benötigte Strings im Vorfeld zu reservieren. Besonders Add-On Herstellen wurden von mir direkt angeschrieben. Da aber entweder keine Antwort kam oder die Umsetzung nur überlegt wurde, wurden bereits weitere Strings an andere User vergeben. Hier greift ganz klar das bekannte Sprichwort "Wer zuerst kommt, mahlt zuerst".

Für neue Projekte müßen dementsprechend neue Strings am Ende angepasst werden. Für einige neue Informationssysteme ergeben sich damit leider längere Stringlisten. Für andere Informationssysteme ist es nicht notwendig (aber sinnvoll), die bereits vergebenen, nicht benötigten Strings auszufüllen. Diese können auch frei gelassen werden.

Es ist nicht schlecht, sich vorher Gedanken zu machen, welche bereits vergebenen Strings mitbenutzt werden können und ob neue Strings hinzugefügt werden müssen. Sinnvoll sind neue Strings dann, wenn die Schriftlänge mit anderen Systemen nicht passt oder zum Anzeigesystem gehörige Codes in die Strings geschrieben werden. Ein Anzeigesystem das keine Codes akzeptiert oder bereits verwendete Codes anders auslegen, ergeben auf den verschiedenen Systemen falsche Anzeigen. Eine ANNAX-Matrix würde bei Verwendung eines Codes für die Busfanat-Vollmatrix den Buchstaben des verwendeten Codes mit anzeigen. Andererseits gibt es auch Busse, wo die verwendeten Informationsgeräte bestimmte Eingabeformate erforderlich machen, die kein anderes Informationsgerät sinnvoll nutzen kann. Als Beispiel soll hier nur das Ansagesystem des LU-200 genannt werden. Dieses kann lediglich zwei einzelne Ziffern anzeigen, da dieses Gerät real umgesetzt wurde. Kein anderes bereits erstellte Informationsgerät kann etwas mit dieser Anzeige anfangen. Daher werden zum Beispiel in einem IBIS 2 lediglich die Zahlencodes wiedergegeben, statt einer lesbaren Anzeige.

Besonders Payware-Herstellen sollten, um einen langen Spielspaß zu ermöglichen, die Idee einer Universellen Hofdatei verfolgen, statt blind vorhandene Strings zu überschreiben, was oft dazu führt, dass mit einer Karte mitgelieferte Busse auf anderen Karten nicht in vollem Umfang nutzbar sind und jeweils extra Hofdateien nötig sind. Dies kommt auch dem Endbenutzer in nicht unerheblichem Maße zugute.

2.3.2. Die Universelle Hofdatei in der Praxis

MR Software, die OMSI-Entwickler, haben zur Einführung von OMSI 2 lediglich weitere Strings in der Hofdatei hinzugefügt, alle Standard-Busse basieren also schon auf einer Art Universeller Hofdatei. Busfanat hat auf Empfehlung die von ihm erstellte Vollmatrix auf andere neue Strings umgesetzt. Auch Perotinus hat die von ihm entworfenen MAN ÜL 242/272/292/312 u.a. auf bereits neue und erweiterte Strings umgestellt.

Im Übrigen sei an diese Stelle erwähnt, dass alle Busse, die mit einer Rollbandtextur oder ähnlicher Basis funktionieren, bereits einen einzigen String nutzen, nämlich den String 4. Der Unterschied der Texturgröße, wird über den Zugriff der Anzeige-Unterordner geregelt. Dies betrifft:

• MAN SD 200 Rollband von (M+R Software)
• MAN NL 202 Rollband (FRENZYMAX)
• MB O305 von Rolf (RW1HH) [Payware]
• Setra S215 UL von (L.M.M.W.)
• MB O307 V2 Banhnbus (Perotinus)
• MB O407 von (Perotinus)
• GSÜH 240 von (iTram)
• Gemeinschaftsbusse von (iTram)
• LU 200 und GU 240 von (ViewApp) [Payware]
• u.v.m.

Eine Negativbeispiel sind die Busse aus den Add-Ons Hamburg Tag&Nacht, Drei Generationen, Chicago und dem Add-On Hamburg Hafencity. Hier wurden nicht nur Fehler gemacht (vierstellige IBIS-Codes, die kein Informationsgerät nutzen kann), sondern es wurden auch bereits vergebene Strings einfach umgestellt. Somit benötigen diese Fahrzeuge neue Hofdateien, die erst einmal erstellt werden müßen. Für Kunden dieser Produkte ohne Kenntnisse, wie man eine Hofdatei erstellt, sind andere Busse auf den oben genannten Karten nur bedingt nutzbar und das Einsetzen auf anderen Karten führt zu Mehraufwand.

2.3.3. Hinzufügen von zusätzlichen Strings

Um weitere Strings einzubinden, sollte man sich vorher überlegen:

• Wieviele Strings brauche ich für die im Bus verwendete Frontanzeige?
• Benötige ich separate Strings für eine Seitenanzeige?
• Soll die Heckanzeige unabhängig der anderen Anzeigen Informationen darstellen oder kann einfach die Liniennummer, welche durch die Suffixe ja auch schon Buchstaben enthalten kann, genutzt werden?
• Brauche ich einen zusätzlichen String für ein im Bus verbautes Informationssteuergerät oder können String 1 und 2 der Haltestellen genutzt werden?
• Können einige Anzeigeräte bereits vergebene Strings auslesen?

2.3.3.1. Wie einigt man sich auf neue zusätzliche Strings?

Man kann im offiziellen Omsi-Forum die künftige Verwendung neuer Strings ankündigen. Wer ganz sicher gehen möchte, kann sich hier an @Tatra, im OMSI-Forum oder per E-Mail wenden und die künftige Verwendung weiterer Strings abklären - dies gilt für neue wie bereits erschienene Fahrzeuge. Dabei ist es absolut egal, ob es sich dabei um ein Freeware-Projekt oder um ein Payware-Projekt handelt. Ich erwarte keinerlei Gegenleistungen, keine finazielle Entschädigung, kein kostenfreies Add-On oder sonstigen Arten von Gegenleistungen.

2.4. Zeichenlänge und Format eines Strings

In Omsi gibt es keinerlei Begrenzung einer Stringlänge. Auch die Hofdatei an sich hat keine Längengrenze. Die Länge eines bestimmten Strings misst sich ausschließlich am Anzeigensystem bzw. an der Verwendung des jeweiligen Strings.

Ein einfaches Beispiel ist das IBIS-System, was standardmäßig von den MAN SD 200/202 und NL/NG-Bussen genutzt wird: Während das IBIS 1 ausschließlich Großbuchstaben ohne Sonderzeichen und Umlaute anzeigen kann, kann das IBIS 2 Groß- und Kleinbuchstaben und Umlaute (inklusive "ß") verwenden. Außerdem ist die Länge durch die unterschiedliche Größe anders. So hat das IBIS 1 eine maximale Länge von 16 Zeichen, das IBIS 2 kann vier Zeichen mehr anzeigen. Zeichen darüber hinaus werden nicht auf dem Bildschirm angezeigt.

Bei dem Wort

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

würde im IBIS 1 also der letzte Buchstabe fehlen. Um dies anständig anzeigen zu lassen, sollte man also die Anzeige kürzen, zum Beispiel mit

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

Solch eine Abkürzung macht im IBIS 2 allerdings keinen Sinn, da längere Haltestellennnamen, außerdem auch Kleinbuchstaben angezeigt werden können:

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

Ein Kürzen ist hier in diesem Fall also nicht nötig.

Für die genauen String-Längen und Formate s.u. Bei Anzeigesystemen wie einer Vollmatrix verkompliziert sich die Stringlänge hinsichtlich der Tatsache, dass die Buchstaben nicht alle gleich breit sind. Hier muss einfach getestet werden, ob ein Text drauf passt (Namen mit vielen "i" oder "l" sind kürzer als solche mit vielen "m" oder "o").

2.5. Scripts

(s. auch Scriptsystem)

Hauptsächlich findet sich die Universelle Hofdatei in den Scripten wieder, die die Anzeigesysteme regeln. Dies sind u.a.

• Matrix-Anzeigen
• Rollband-Script
• IBIS (2), Atron, EFAD, INIT, etc.
• Ticketdrucker

Die Script-Namen müssen nicht unbedingt immer gleich lauten, gängige Dateinamen sind z.B.

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

Da diese Dateien allesamt Scripte sind, finden sie sich meist im Script-Ordner eines Fahrzeuges und sind mit der Endung .osc versehen. Die jeweils in den Bussen verbauten Informationssteuergeräte steuern nicht nur die äußeren Matrix-Anzeigen, sondern auch die inneren Haltestellenanzeigen. In diesen dazugehörigen Scripten werden auch die Strings eingetragen, die dann aus der Hofdatei ausgelesen werden sollen.

2.5.1. Auslesen bestimmter Strings

Zum Auslesen der entsprechenden Strings gibt es zwei System-Makros:

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

Diese lesen Terminus- und Haltestellen-Strings aus, die sich im 2. und 3. Bereich der Hofdatei befinden. Dafür muss sich der Index (nullbasiert!) des auszulesenden Strings im obersten Stack befinden (s. Scriptsystem, es empfiehlt sich, einfach vor den Aufruf des Befehls den Index zu setzen). Als Beispiele dienen hier die Stringeinstellungen im IBIS 2 des MAN SD 202 und die ANNAX-Matrix. Außerdem wird das Laden des Steckschilds gezeigt.

2.5.1.1. IBIS 2

Das IBIS2 liest den String 5 aus der Terminus-Liste

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

und den String 3 aus der Haltestellen-Liste aus.

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

Man sieht, dass zuvor der jeweilige Terminus- (bzw. Busstop-)Index geladen wird. Dieser wird vorher aus dem IBIS-Code eines Ziels (bzw. aus dem Namen einer Haltestelle) mithilfe von (M.V.GetTerminusIndex) bzw. (M.V.GetBusstopIndex) generiert.

2.5.1.2. ANNAX-Matrix

Bei der ANNAX-Matrix werden String 1-3 ausgelesen und zu Zeilen zusammengesetzt:

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)

Zunächst wird mitl0 der Index des Ziels geladen (der bei der Eingabe ins IBIS gespeichert wurde), dann der eigentliche String. Anschließend werden Leerzeichen vor und nach dem String entfernt und mit 16 $SetLengthC auf die Länge von 16 Zeichen zentriert. Hier sieht man, dass es nicht mehr nötig ist, Strings mit Leerzeichen zu zentrieren: OMSI macht dies automatisch.

2.5.1.3. Steckschild

Für das Steckschild gilt der gleiche Befehl, dieses kommt aber nur zum Tragen, wenn der Terminus-Code größer als 1000 ist:

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

Das eigentlische Steckschild wird dann wie folgt geladen:

{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}

Der String wird geladen und die so ermittelte Bitmap-Datei in eine Variable gespeichert. Diese Variable ist vereinfacht ausgedrückt mittels eines Freetex-Eintrages in der model.cfg definiert und führt zur Steckschild-Textur.

2.5.2. Auslesen von Ersatz-Strings am Beispiel der Busfanat-Vollmatrix

Der folgende Abschnitt ist von Busfanat erstellt worden und soll zeigen, wie man Ersatzstrings verwendet. Diese Möglichkeit kann in allen Bussen umgesetzt werden, solange diese die Anzeigen einer ANNAX-Matrix sauber anzeigen können (z.B. nicht für eine BUSE-Vollmatrix geeignet). Ein Beispiel für die Nutzung solcher Ersatzstrings bietet die Busfanat-Vollmatrix. Diese beschränkt sich nicht nur auf zwei Strings, sondern nutzt zusätzlich zwei originale Strings als Ersatz. Sie ermöglicht, Teile der Zielinformation besonders darzustellen, ohne Bildtexturen zu verwenden. Mit zusätzlichen Befehlen hinter der Information kann ein Ziel fett oder invertiert dargestellt werden.

2.5.2.1. Grundlegende Funktionen

Soll eine Ziel besonders dargestellt werden, schreibt man in String 11 und 12 das Ziel wie gewünscht rein und mittels Befehlen werden diese Ziele dann verändert:

String 11: Bahnhof*B
String 12: Kieselstein

Hier wird das Wort "Bahnhof" dick geschrieben während die zweite Zeile normal dargestellt wird.

String 11: Pause*I
String 12:

Hier wird das Wort "Pause" invertiert und groß geschrieben, da die zweite Zeile nicht verwendet wird. Dabei erscheinen die Buchstaben dunkler als die Umgebung, wo die Dots erscheinen.

2.5.2.2. Nutzung von Ersatzstrings

Die Matrix liest zuerst Informationen aus den speziell für die Matrix vorgesehenen Strings 11 und 12 aus. Bleiben diese leer, wird auf die Strings 1 und 2 zugegriffen. Soll das gewünschte Ziel so angezeigt werden, wie in einer ANNAX-Matrix, oder sieht die verwendete Hofdatei keine extra Strings für die Busfanat-Vollmatrix vor, bedarf es also keinen besonderen Aufwand.

' 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}

Zuerst ließt das Script die Strings 1 und 2 aus. Falls String 11 und 12 beide nicht leer sind (man beachte die doppelte Verneinung des "oder"), überschreiben diese die vorher gespeicherten Strings 1 und 2. Sie die String 11 und 12 leer oder sind die Strings in der Hofdatei nicht vorhanden, werden die Strings 1 und 2 dargestellt. Omsi erkennt die fehlenden Strings nicht als Fehler.

3. Quellen & weiterführende Links

• Matrix-Anzeigesysteme: Busfanat-Vollmatrix, Krüger++, LAWO-Matrix
• Busse, die die universelle Hofdatei umsetzen: MAN ÜL, MB O307 Bahnbus, MB O407, Gräf&Stift GSÜH 240, Gräf&Stift Gemeinschaftsbusse
• Quellen: Hofdatei Spandau von M+R Software aus OMSI1 und OMSI2, Scripts aus den MAN SD200/202-Bussen

4. Anhang

Ich würde mich freuen, wenn man diese Universelle Hofdatei wieder umsetzen könnte. Es ist keine wirklich neue Idee, da Marcel Kuhnt und Rüdiger Hülsmann diese mit Omsi 1 schon umgesetzt haben. Durch neue Busse, Maps und Addons wurden bereits vergebene Strings überschrieben und die Hofdatei für speziell diese Busse umgeschrieben. Somit gibt es in Omsi heute für eine Map mehrere verschiedene Hofdateien, die jeweils nur für eine Gruppe von Bussen passen.

Für die einfache und schnelle Umsetzung sollte besonders die Kommunikation verbessert werden, besonders zu Herstellern von Addons. Während einige User dem Thema offen gegenüber standen, reagierten Firmen gar nicht oder zeigten sich uninteressiert.

Wenn jemand eine universelle Hofdatei für sein Projekt umsetzen möchte, bin ich gerne bereit, ohne Gegenleistung Hilfe zu geben. Marcel Kuhnt und Janine stehen dieser Idee positiv gegenüber und unterstützten mich, hier das Thema Hofdatei zu veröffentlichen. Busfanat stellte die von ihm entwickelte Vollmatrix sehr schnell um. Auch Perotinus stellte seine neu erstellten Busse MAN ÜL nach Absprache und mit Hilfe von Busfanat und Cooper um.

Die ersten Schritte sind damit getan und ich danke Busfanat, Cooper und Perotinus recht herzlich für ihre großartige Mitarbeit und die Umsetzung. Und ich hoffe, dass dieses Thema in Zukunft mehr Gehör finden wird, denn die Universelle Hofdatei bietet auf Addon-Ersteller-Seite und Userseite viele Vorteile.

Danksagungen gehen an

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

4.1. Aktuelle Strings der universellen Hofdatei

Im Folgenden findet sich eine Liste, welche Strings für die Universelle Hofdatei offiziell vergeben sind. Diese Liste wird nach Möglichkeit stetig aktualisiert und sollte unbedingt beachtet werden, sollte die Universelle Hofdatei genutzt werden. Einige Anzeigesysteme erkennen leere Strings und nutzen dann zwecks Kompatibilität die Originalstrings (Alternativ-String). Sie sind optional und sollten nur ausgefüllt werden, falls man wirklich einen speziellen Nutzen von ihrer Verwendung hat (z.B. Schriftformatierung). Der Hinweis * sagt aus, dass wenn bei einem mehrzeiligen Anzeigesystem eine Zeile leer ist, der String dann auf die volle Anzeige projeziert wird. Die Länge eines Strings darf unter- und überschritten werden, bei letzterem Fall wird dieser aber nur unvollständig angezeigt.

Terminus-Strings (26)

Busstop-Strings (9)

4.2. Standard-Suffixe

Hier findet sich eine Liste mit den IBIS-Suffixen der Standard-Matrix. Diese sind die letzten beiden Zahlen bei der Linie/Kurs-Eingabe und wichtig für die 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