Hofdatei

Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!

Die Hofdatei ist eine einfache Textdatei und dient dem Bus als Informationsort, für die im und am Bus möglichen Anzeigen. Sie enthält die IBIS-Codes für die Endstellen, alle Endhaltestellen und Haltestellen, sowie die möglichen Routen. Ohne eine passende Hofdatei, kann ein Bus keinerlei Informationen ausgeben, was dieser auf einer Map, als Fahrziel oder andere Informationen, anzeigen soll. Die Hofdatei muß sich im Ordner des Busses befinden und dient dem Spielerbus, sowie dem KI-Bus (mit Fahrplan) als Grundlage zum Anzeigen des Fahrzieles.

Hier soll es um den Aufbau einer Hofdatei gehen, wie man eine Hofdatei erstellt und es soll die "universelle Hofdatei" erklärt werden.

Hofdateien für Omsi

Was ist eine Hofdatei

Eine Hofdatei ist die Grundlage, um einen Bus auf einer Linie einer Map fahren zu können. Ohne Hofdatei kann der Bus keine Informationen anzeigen (Matrix, Rollbänder) und dadurch steigen keine Fahrkunden ein. Diese beinhaltet eine Liste der Endhaltestellen einer Karte (alle Endstellen, ob auf der Map vorhanden oder nicht), alle auf der Map vorhandenen Haltestellen und die Routen der einzelnen Linien. Sie dient lediglich der Information der Anzeigen und die 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, dies wird über den Fahrplan im Editor gestellt. Aber 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. Eine Hofdatei muß im Busordner vorliegen (in keinem Unterordner des Busses) und muß als Endung .hof haben. Diese Datei kann mit einem Editor oder Schreibprogramm erstellt werden, muß aber dann als Textdatei.txt abgespeichert werden. Schlußendlich wird dann der Dateiname .txt gelöscht und durch .hof ersetzt.

---

Externe Programme zum Erstellen einer Hofdatei

Um eine Hofdatei zu erstellen, gibt es mehrere Möglichkeiten. Man kann eine Hofdatei erstellen, indem man mit Notepad von Windows, eine Textdatei erstellt- Dieses Programm ist standardmäßig in Windows dabei. Für große und umfangreiche Hofdateien, verliert man aber hier schnell den Überblick. Wahlweise kann man auch mit Notpad++ arbeiten. Dieses Programm kann kostenfrei im Internet runtergeladen und installiert werden. Eine weitere Möglichkeit bietet auch der HofCreator von Jan Kiesewalter. Dieses Programm erstellt Hofdateien für Omsi 1. Außerdem gibt es für dieses Programm noch Templates, um für weitere Busse eine passende Hofdatei zu erstellen.

Für Omsi 2, empfielt sich HOF Suite vom User Rumpelhans. Damit bekommt man eine übersichtliche Arbeitsfläche um einfach und schnell, eine oder mehrere Hofdateien zu erstellen. Dies geht dann komplett ohne Fehler. Auch dieses Programm ist kostenlos auf der Omsi-WebDisk zu bekommen.

---

Aufbau einer Hofdatei

Man kann reinschreiben was man möchte, solange es nicht am Zeilenanfang steht (einmal TAB drücken) da es sonst zu Fehlermeldungen beim einlesen der Hofdatei kommen kann. Alles was nicht am Zeilenanfang steht, wird von Omsi nicht erkannt und daher nicht beachtet. Was am Zeilenanfang steht wird von Omsi beachtet und ausgewertet. Zuerst muß ein Befehl geschrieben werden. Nach dem Befehl kommen eventuell Informationen der sich auf den Befehl bezieht und eine Identifikation oder Zuordnung. Erst dadrauf folgen die einzelnen Strings, für die einzelnen Informationsgeräte.

Allgemeiner Aufbau einer Hofdatei - interne Informationen für Omsi

In der Hofdatei ist dies ein wiederkehrender Prozess. In eckigen Klammern werden Befehle geschrieben und direkt darunter die Strings. Ein String ist ein Eingabewert der einen Verweis auf Punkte einer Map haben kann, oder einen Informationswert für eine Anzeige. Der Aufbau der einzelnen Befehle erklärt sich später bei den einzelnen Bereichen einer Hofdatei.

Eine Hofdatei gliedert sich in 4 Bereiche

1. Teil 1 - Informationen zur Hofdatei
2. Teil 2 - Liste der Endhaltestellen
3. Teil 3 - Liste der Haltestellen
4. Teil 4 - Linienlisten der einzelnen Routen

---

Aufbau des ersten Bereiches einer Hofdatei

Der erste Bereich enthält Informationen, wo sich bestimmte Ordner befinden, die der Bus später benötigt, wie Rollbandtexturen, Steckschildtexturen oder Ansagen, Anzahl der verwendeten Strings in den Bereichen 2 und 3. Der erste Befehl ist der Name der Hofdatei, so wie diese später im Auswahlmenü angezeigt wird. Der Name sollte passend zur Map sein und, falls die Chronologiefunktion benutzt wurde, auch die Zeit. Bedenke dabei, daß auch andere User die eine Strecke erstellen den gleichen Namen nutzen könnten, wenn deren Strecke zum Beispiel real ist, während die eigene fiktiv erstellt wurde.

[name]
Spandau 1990

[servicetrip]
Betriebsfahrt

Zuerst folgt der Name, damit Omsi diese Hofdatei zuordnen kann. Dies ist besonders beim KI-Verkehr wichtig. Wenn der Name mit dem Eintrag in der AI-List nicht übereinstimmt, können die KI-Busse nichts anzeigen. Diese Eintrag muß sich aber nicht auf den Namen der Textdatei beziehen. Vorteilhaft wäre es aber auf jeden Fall. Servicetrip gibt an, was ein Bus schildern soll, wenn er nicht auf einer Linie fährt. Das sind unter anderem Ein- und Aussetzfahrten. Dazu muß Betriebsfahrt später eingetragen werden und als "nicht einsteigen" markiert werden, mit dem Befehl: [addterminus_allexit].

[global_strings]
6
Spandau_old
Spandau
Spandau_90
3
8
16

Mit dem Befehl [Global_Strings] wird angegeben, wie die Ordner heißen, die Informationen zu der Karte haben. Diese Strings sind festgelegt:

6             - zeigt an wieviele Strings unter diesem Befehl folgen
Spandau_old   - Name des Unterordners der die Ansagen der Karte enthält. Dieser Unterordner muß unter
                Vehicles\Announcements
                angelegt werden. Diese einzelnen Ansagen der Haltestellen und Endhaltestellen, sollten im 
                Audioformat .wav enthalten sein. Die Dateinamen der Audiofiles sollten einen Bezug
                zur Haltestelle / Endhaltestelle haben.
Spandau       - Unterordner im Ordner Anzeigen für die Rollbandtexturen
Spandau_90    - Unterordner für die zusätzlichen Seitenschildtexturen.
4             - Ibis-Specialcode die auf dieser Map verwendet werden können. Diese Zahl gibt an,
                welche Liniencodes mit Buchstaben auf speziellen Linien genutzt werden.

• String 4= 900'er-Linien (Anzeige der Linie N.. oder ..N)
• String 5= 800'er-Linien (Anzeige der Linie X)
• String 6= 500'er-Linien (Anzeige der Linie M)

Dieser Bereich ist nur für Omsi 2 wichtig, in Omsi 1 hingegen entfällt dieser Befehl und die Eintragungen, weil sich die entsprechenden Dateien in den Unterordnern des jeweiligen Busses befinden bzw. Funktionen wie Seitenschilder nicht funktionieren. Die Ziffern darunter können beliebig gesetz werden, wenn man Linien einfach mit Buchstaben ausstatten möchte. Erstellt man in der Matrix.osc oder einer vergleichbaren Datei unter dem IBISCode 00016 den Buchstaben "A", so gibt man oben die Zahlen vorn für den Hunderter Bereich ein, die später mit dem entsprechenden Buchstaben versehen wird. Möchte man also auf einer Linie die Linie 83A mit dem Buchstaben "A" versehen und diesen Buchstaben mit der 800-er Linie versehen, trägt man im 2. Zahlenstring die 16 ein. Damit ergibt sich dann die IBIS-Eingabe: Linie/Kurs: 88300 und der Bus schildert dann 83A. Bleiben die jeweiligen Strings leer, kann für die Map die Linien 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. Mit dem oberen Beispiel, würde ein Bus dann die Linie 883 anzeigen. In der Matrix.osc kann jeder beliebige Buchstabe mit einem der 3 Ziffernplätze belegt werden. 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.

Die folgenden Befehle werden nicht in eckigen Klammern geschrieben. Sie enthalten nur die Information, wieviele Strings in den Bereichen 2 und 3 folgen, damit Omsi genau erkennt, wieviele Strings ausgelesen werden sollen. Wichtig ist dies bei Omsi 1 und 2, weil nur die genaue Stringszahl ausgelesen wird, die hier eingetragen werden. Die tatsächliche Anzahl ist dagegen irrelevant.

Stringcount_terminus
7

Stringcount_busstop
5

Terminus gibt den Bereich an, der für die Endstellen vorgesehen ist. Und Busstop bleibt damit nur für die Haltestellenliste. Die genaue Anzahl richtet sich nach den geschriebenen Strings. Wichtig wird dies für eine "Universelle Hofdatei", die für alle verwendeten Anzeigesysteme in den Bussen Verwendung finden. Man kann bis 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 ja nach den unterschiedlichen Anzeigesystemen der Busse, nicht um jeden einzelnen Bus selbst.

---

Aufbau des zweiten Bereiches einer Hofdatei - Endstellenliste

In dieser Liste werden die Anzeigen für die Busse geschrieben, wie diese die entsprechenden Endstellen später anzeigen sollen. Wichtig hierbei ist, daß die Buchstabenanzahl nicht überschritten wird, weil sonst die Ziele nicht vollständig 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.

Der Aufbau dieses Bereiches kann zwei Formen annehmen. Für Omsi 1 gilt nur eine Form, wobei bei Omsi 2 beide Formen genutzt werden können. Der Übersicht wegen, wird hier die alte Schreibform (untereinander gegliedert) gezeigt. Um eine Hofdatei ganz einfach zu erstellen empfielt sich die Verwendung des Programm's Hof Suite von Rumpelhans, dass eine Hofdatei problemlos und Fehlerfrei vollständig erstellt. Einzelheiten zum Programm entnehmt ihr bitte dem beiliegenden Handbuch. Etwas schwerer, aber auch Möglich, ist die Nutzung eines Schreibprogrammes wie Office Word. Für die neuere Schreibform wie in Omsi 2 ist ein Tabellenprogramm wie Exel sinnvoller, da hier die Anzeigen nacheinander, getrennt von einem Tabulator gesetzt wird. Jeder gesetzte Abstand des Tabulator's, setzt den nächsten String fest. Ein String darf damit nicht als Platzhalter oder zur Zentrierung benutzt werden. Das Programm Hof Suite von Rumpelhans, ist aber die einfachste und leichteste Variante, da dieses Programm eine übersichtliche Oberfläche bietet, viel Schreibkram einspart, auf Fehler hinweißt und auch größere Hofdateien, schnell und einfach, im Omsi-2-Format erstellt. Außerdem kann man eine Hofdatei damit sehr einfach erweitern, ergänzen, umstellen oder berichtigen und anpassen. So können auch Hofdateien aus Omsi 1 problemlos umgestellt werden, um diese auf Maps in Omsi 2 zu nutzen. Änderungen in der Hofdatei werden aber immer erst nach einem Neustart von Omsi umgesetzt. Aus beiden letztgenannten Programmen (Word und Exel), kann man diese Hofdatei als Textdatei abspeichern und die Dateiendung umbenennen.

In dem zweiten Bereich gibt es nur zwei Befehle, die wiederrum das Verhalten der Fahrkunden steuert. [addterminus] bedeutet, daß die Fahrkunden einsteigen können, spätestens beim erreichen dieser Endstelle den Bus verlassen müssen, [addterminus_allexit] bedeutet, egal was die Anzeige zeigt, es darf nicht eingestiegen werden. Direkt darunter kommen zwei Informationen und darauf folgend die Strings:

[addterminus_allexit]
123
Name der Endstelle
String 0
String 1
String 2
String 3
String 4
String 5
String 6

Gemäß der Vorgabe im ersten Bereich der Hofdatei unter [stringcount_...] kann man hier die Strings für die Anzeigesysteme schreiben. Die ersten beiden Punkte unter dem Befehl sind fest vorgegeben und beinhalten nichtangezeigte Informationen. Besonders wichtig ist hier die richtige Stringanzahl. Stehen hier mehr Strings als unter "Stringcount_terminus" eingetragen, werden die folgenden Strings nicht beachtet (gelten also als nicht vorhanden). Außerdem ist zu Beachten, daß die Stingzählung bei NULL beginnt und nicht bei Eins. Das bedeutet, daß sieben Strings ausgelesen werden, von String 0 bis String 6.

123 - die 3-stellige Zahl gibt dieses Ziel einen IBIS-Code. Da man im Ibis keine Buchstaben eingeben kann, werden alle Ziele mittels Code identifiziert. Welchen Code ein Ziel bekommt ist dabei egal, solange der Code für ein einziges Ziel eingetragen wird. Das Ziel kann zwar mit dem Code mehrmals in der Liste erscheinen, aber ein bestimmter Zahlencode darf nicht zwei unterschiedliche Ziele beinhalten.

Gefolgt vom Namen der Endstelle. Hierbei erhält jede Endstelle einer Map seinen eigenen Zahlencode für das IBIS. Der Name der Endhaltestelle, der hier eingetragen wurde, muß dem Endstellenwürfel im Editor entsprechen. Sind diese nicht gleich, wird diese Endstelle nicht mit dem Ziel in Verbindung gebracht und ignoriert. Das bedeutet, daß diese Endstelle (im Editor) keinen IBIS-Code besitzt und daher nicht geschildert werden kann. Im Ibis wird eine Endstelle angezeigt, aber diese existiert für Omsi garnicht. Im gegenzug müßen nicht alle Endstellen einen Haltestellenwürfel haben. Liegt die Endstelle ausserhalb des Kartenbereich's, sollte dennoch eine Endstelle dazu in der Hofdatei erstellt werden. Diese Endstellen sind für KI-Busse interessant. Die Endstellen werden im Fahrplan genannt, da alle Busse nur mit Fahrplan, im Liniendienst fahren könne. Ohne Fahrplan verhalten sich die Busse wie gewöhnliche KI-Fahrzeuge.

Nun folgen die Strings der einzelnen Anzeigen. Diese Strings werden für die jeweiligen Anzeigegeräten 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.

Das folgende Beispel, zeigt die Eintragungen einer ANNAX-Matrix, Rollbandanzeige, IBIS 1 und IBIS 2 Gerät:

[addterminus]
123
Endhaltestelle
BHF KIESELSTEIN
Bahnhof
Kieselstein
Bhf. Kieselstein
Rollbandtextur.tga
Bahnhof Kieselstein

Aufgeschlüsselt bedeuten die Eintragungen (hier am Beispiel eines MAN SD 202) folgende Punkte am Bus:

[addterminus]
123                   - Durch Eingabe dieses Zahlencode in das IBIS, Atron, EFAD, etc. bei der Taste Ziel, wird die 
                        gewählte Endhaltestelle ausgewählt.
Endhaltestelle        - hier muß der korrekte Name der Endstelle wie im Editor/ oder Fahrplan eingetragen werden.
BHF KIESELSTEIN       - Anzeige für das IBIS 1 (max. 16 Zeichen [incl. Leerzeichen] und nur Großbuchstaben, 
                        weil es im Font des IBIS 1 nur Großbuchstaben gibt.
Bahnhof               - Anzeige der oberen ANNAX-Zeile an der Front des Busses. Hier dürfen ebenfalls nur
                        16 Zeichen vorhanden sein, und Buchstaben in Groß- und Kleinschrift.
Kieselstein           - Anzeige der unteren ANNAX-Zeile an der Fahrzeugfront. Hier dürfen ebenfalls nur max. 16 
                        Zeichen erstellt werden.
Bhf. Kieselstein      - Zielanzeige an der einzeiligen Seitenmatrix (ANNAX-Seite) mit max. 16 Zeichen.
Rollbandtextur.tga    - Name der Rollbandtextur im Ordner Anzeigen. Wichtig: die Dateiendung muß richtig
                        eingetragen werden.
Bahnhof Kieselstein   - Anzeige für das IBIS 2-Gerät (Groß- und Kleinschreibung, max. 20 Zeichen).

Die hier gezeigte Schreibweise kann für Omsi 1 und Omsi 2 verwendet werden. Um bei Omsi 1 kurze Namen zu zentrieren, sollte man Leerzeichen verwenden. Für Omsi 2 ist es ratsam, hinter einer Eintragung ein Tabulator zu setzen. Wurden alle Endstellen, die auf der Map vorhanden sind geschrieben, können alle Endstellen geschrieben werden, die nicht auf der Map sind, aber von Linien die auf der Map fahren (KI-Linien) geschrieben werden. Der Präfix "_allexit" hinter dem Befehl addterminus sorgt dafür das keine Fahrkunden einsteigen und eventuell im Bus sitzende Fahrkunden, nach der Eingabe, sofort aussteigen.

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ü).

---

Aufbau des dritten Bereiches einer Hofdatei - Haltestellenliste

In dieser Liste ändert sich lediglich der Befehl und die Anzeige-Orte im Bus. Es gibt nur ein Befehl der eine weitere Haltestelle hinzufügt. Und es werden nur Haltestellen geschrieben, die vom Spieler bedient werden können (unabhägig, ob diese Haltestellen auf der Map existieren oder nicht).

[addbusstop]
Haltestelle
BUSPLATZ AM WALD
Busplatz
Am Wald
Busplatz am Wald

Hier wieder die Aufschlüßelung der Eintragungen:

[addbusstop]
Haltestelle        - Name der Haltestelle wie im Editor und Name der Audiodatei der Ansage (ohne Dateiendung).
BUSPLATZ AM WALD   - Anzeige für das IBIS 1 Gerät
Busplatz           - Innenanzeige erste Sicht vor dem Umschalten.
Am Wald            - Innenanzeige zweite Sicht nach dem Umschalten, die beiden Anzeigen werden im Takt 
                     automatisch umgestellt und zentriert.
Busplatz am Wald   - Name der Haltestelle für das IBIS 2.

Die Reihenfolge der einzelnen Haltestellen ist dabei irrelevant. Die Ausstiegspunkte der Endstellen werden genauso mit eingetragen, wie alle anderen Haltestellen. Damit erscheinen die Endstellen also in beiden Listen, was hauptsächlich den Ansagen, der Innenanzeige und der Anzeige im IBIS dient.

Damit ist dieser kurze Abschnitt schnell geschafft.

---

Aufbau des vierten Bereiches der Hofdatei - Routenlisten

Hier werden nun, für jede einzelne Route die Liste in der Reihenfolge der abzufahrenden Haltestellen eingetragen. Die richtige Reihenfolge ist nicht für die Linie entscheidend, sondern der Fahrplan, so wie er im Editor erstellt wurde. Die richtige Reihenfolge wird aber benötigt, wenn die Ansagen der Haltestellen passen sollen und die Anzeigen in den Businternen Informationsgeräten. Schreibfehler oder die falsche Reihenfolge führt bei Bussen mit automatischer Haltestellenweiterschaltung nicht zu Fehlern im Bus, da nur der Bus diese Daten ausließt.

Zur Definition: Eine Route ist der Weg von einer Endstelle zu einer anderen, also der wahre Anfangs- und Endpunkt einer Linie in einer Richtung. Zwei Routen sind nötig um einen Umlauf zu definieren. Bestehend aus der Hintour und der Rücktour. Es wird also lediglich eine Route je Liste geschrieben, kein kompletter Umlauf.

Dieser Bereich teilt die Liste in 2 Gruppen auf. Hier gibt es auch wieder zwei festgelegte Befehle. Im ersten Teil [infosystem_trip] befinden sich die Information, der Linie und Routennummer, wo eine Linie beginnt und wo diese endet sowie den IBIS-Code welches Zeil geschildert werden soll. Das hat zur Folge, das es vollkommen ausreichend ist, wenn man nur die Linie und die Route im IBIS einträgt, daß Ziel und die Linie werden dann bereits bei einer Matrix geschildert. Rollbänder müßen hingegen, manuell oder über das Menü eingestellt werden. In der ersten Gruppe befinden sich also die Informationen für die Route und in der zweiten Gruppe [infosystem_busstop_list] die Liste der Haltestellen.

[infosystem_trip]
901
Busplatz-Kieselstein
123
 9 

................

[infosystem_busstop_list]
5
Busplatz
Busplatz Am Wald
Einsteindorf
Krankenhaus
Bhf Kieselstein

Dies soll nur eine kurze Liste darstellen die rein fiktiv ist, um zu erklären was wo steht. Hier geht es um die Linie 9 und die erste Route. Nun geht es wieder um die Aufschlüsselung der einzelnen Zeilen:

[infosystem_trip]        - Dieser Befehl sagt aus, daß hier Infos zur folgenden Route stehen.
901                      - Die Linie und die Routennummer. Also Linie 9 und die erste Route. 
                           Diese Zahl "kann" auch 6-stellig sein (also 4-stellig, die Liniennummer und
                           2-stellig für die Route), während die Route 2-stellig sein "muß".
Busplatz-Kieselstein     - Diese Zeile wird nicht ausgelesen, sie dient nur der Orientierung, von welche
                           Route jetzt die Liste folgt.
123                      - IBIS-Code der Zielendstelle (also in diesem Beispiel "Kieselstein").
9                        - Wiederholung der Liniennummer.

................

[infosystem_busstop_list]- Dieser Befehl sagt aus, das hier die Liste der Haltestellen kommt 
                           (inclusive Anfangs- und Endhaltestelle)
5                        - Anzahl der Haltestellen insgesamt. Beginnend bei der Zahl 1 (nicht NULL)
Busplatz                 - erste Haltestelle (also die Einstiegshaltestelle)
Busplatz Am Wald
Einsteindorf
Krankenhaus
Bhf Kieselstein          - Endhaltestelle, wo die Fahrkunden aussteigen sollen.

Dies wird nun für jede, im Editor erstellte Route eingegeben, allerdings nur für die Linien, die auch vom Spieler gefahren werden können. KI-Busse brauchen dies nicht, da KI-Busse keine Ansagen, Innenanzeigen oder sonstige Infos tragen, außer die Außenanzeigen (die aber aus der Endstellenliste ausgelesen werden). Die geschriebene Anzahl der Haltestellen muß mit der tatsächlichen Anzahl der eingetragenen Haltestellen übereinstimmen, sonst werden weitere Haltestellen nicht angezeigt oder angesagt, oder die Fahrkunden steigen alle zu früh aus.

Es müßen 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 einer Matrix oder Röllbänder existierten, wie zum Beispiel die Linie E522 in Spandau, zwischen November 1989 und Dezember 1990.

---

Sonstiges: Wenn ein Ziel, über das Steckschild angezeigt werden soll (nur in Omsi 2)

Wenn es keine Anzeigen im Bus geben soll, sondern die Ziele nur über ein Steckschild angezeigt werden sollen, muß der IBIS-Code über eine 4-stellige Nummer verfügen. 4-stellige IBIS-Codes können nicht im IBIS eingetragen werden. Daher bleibt die Anzeige leer, aber die Linie bleibt erhalten und das Steckschild fungiert als Anzeigen-Ersatz, womit auch die Fahrkunden einsteigen. Im String für das IBIS 1 (String 0) sollte dann ein Rautezeichen eingetragen werden (#). Da alle Ziele in Omsi über den IBIS-Code identifiziert werden (Endstellen-ident), können nur hier ein Ziel über einen zweiten Zielcode identifiziert werden. Der Zielcode für das Steckschild wird it dem 4-stellugen IBIS-Code 1000 eingetragen. Damit dies ausgelesen wird, mußt der Code im jeweiligen Script der Zielanzeige mit 1000 addiert werden. Dies kann für andere Anzeigegeräte ebenfalls verwendet werden, wenn in den Scripten der IBIS-Code mit höheren Codes addiert wird.

---

Form der Hofdatei in Omsi 1

Die Form der Hofdatei ist bei Omsi 1 einfacher und übersichtlicher, als in Omsi 2. Der Ablauf wie oben beschrieben ist einfach gestaffelt. Mit einem Befehl werden die einzelnen Zeilen zum Auslegen festgestellt, die dann durch die Scripte des einzelnen Busses ausgelesen werden: Ein Befehl wird immer in einer Klammer festgelegt

[name]
Spandau

Damit beginnt die Hofdatei und legt fest, wie die Hof-Datei OMSI-intern heißt. Beim Erstellen einer Map kann ein Standard-Hof definiert werden (es muss der Name eingtragen werden, der in der Hof-Datei festgelegt wurde), der dafür sorgt, dass bei der Busauswahl gleich die richtige Hof-Datei vorausgewählt wird. Was unter dem Namensblock eingetragen wird, steht später auch im Busauswahldialog in OMSI. Außerdem wird dieser Name auch für die KI-Busse verwendet, die in der AI-List eingetragen sind. Stimmt der Name in der AI-List nicht mit dem Namen der Hofdatei überein, wird diese Hofdatei von den KI-Bussen nicht erkannt/geladen. Anmerkung: der Dateiname der Hofdatei ist an dieser Stelle für das Auslesen irrelevant. Die Hofdatei wird lediglich über den Befehl [name] identifiziert und damit genutzt.

[servicetrip]
Dienstfahrt

Dieser Befehl legt fest, welche Anzeige am Bus angezeigt wird, wenn der Bus als KI ohne Route fährt. Es wird hier offensichtlich nicht festgelegt, welche Anzeige eingestellt wird nach dem Laden/Platzieren eines Spieler-Busses. OMSI nimmt dafür immer das erste Ziel aus der Endstellenliste.

Die nächsten zwei Befehle (die ohne eckige Klammer geschrieben werden) legen fest, wieviele Strings insgesamt ausgelesen werden können. In der Endstellenliste und der Haltestellenlsite kann man soviele Strings schreiben wie man möchte, aber nur die festgelegte Anzahl wird auch tatsächlich ausgelesen. Beide Befehle bestehen aus zwei Teilen:

Stringcount_terminus
18

Stringcount_busstop
9

Stringcount sagt aus, das hier die Anzahl der auszulesenden Strings hier festgelegt werden. Der zweite Teil bezieht sich auf die folgenden Bereiche wofür die Stringanzahl festgesetzt wird. _terminus bezieht sich auf die Liste der Endstellen, _busstop legt fest, wieviele Strings dort ausgelesen werden müßen.

---

Endstellen

Mit dem Befehl [addterminus] kann man die Entstellen festlegen. Direkt darunter werden erst die Zugehörigkeiten festgelegt und dann folgen die eigentlichen Strings. Ein String ist der auszulesende Teil der für die Anzeigeinformation ausgelesen werden soll. Der erste String beginnt aber erst in der dritten Zeile nach dem Befehl. Die zwischenliegenden Zeilen werden von Omsi für die Zugehörigkeit der Endstellen benötigt. Danach kann Omsi genau die gewünschten Anzeigen für die Endstelle definieren. Ein Bus liest aber nicht alle Strings aus, sondern jeder Bus liest nur die Strings aus, die in den jeweiligen Strings des busses festgelegt sind, egal ob das dortige Format der Anzeige entspricht oder nicht. Stimmt das Format wird die Anzeige korrekt dargestellt, ist das Format für die jeweilige Anzeige ungeeignet wird entweder nichts angezeigt oder nur der Teil der verwendet werden kann. Das gewünschte Verhalten, wie die Fahrkunden auf die jeweilige Anzeige reagieren soll, wird mit dem Präfix _allexit festgelegt. Die Personen in Omsi können nicht lesen, sie reagieren nur stur auf die gewählte Anzeige. Jetzt folgen zwei Beispiele für Anzeigen. Zur besseren Übersicht werde ich die Zeilen Nummerieren und bezeichnen. Als Trennung verwende ich Wellenlinien. Ich beziehe mich hier ganz bewußt auf eine universelle Hofdatei.

1 ~~~Befehl ~~~~[addterminus]
2 ~~~IBIS-Code~~123
3 ~~~Name der Endstelle~Potzdamer Straße
4 ~~~String0~~~~POTZDAMER STR
5 ~~~String1~~~~Potzdamer
6 ~~~String2~~~~Strasse
7 ~~~String3~~~~Potzdamer Str.
8 ~~~String4~~~~Potzdamer.bmp
9 ~~~String5~~~~Potzdamer Strasse
10~~~String6~~~~Potzdamer.bmp
11~~~String7~~~~Potzd_Stra.bmp
12~~~String8~~~~M48 Potzdamer
13~~~String9~~~~M48
14~~~String10~~~246
15~~~String11~~~Potzdamer*I
16~~~String12~~~Straße*I
17~~~String13~~~Potzdamer Str/
18~~~String14~~~Lützow Str.
19~~~String15~~~Potzdamer
20~~~String16~~~Straße
21~~~String17~~~Potzdamer Straße
22~~~String18~~~Potzdamer Straße/*B
23~~~String19~~~Lützow Straße
24~~~String20~~~Potzdamer Straße
25~~~String21~~~Warschauer Straße
26~~~String22~~~Leer

Wie bereits geschrieben, liest jeder Bus nur ganz bestimmte Strings aus. Um dieses zu verdeutlichen mal 4 Busse als Beipiel:

• MB O 305 - braucht String0 für das IBIS1 und String 4 für das Rollband,
• MAN NG 272 - Braucht String 1 und 2 für die Krügeranzeige und String 5 für das IBIS 2,
• SD 202 - braucht String 1 und 2 für die ANNAX vorn, String 3 für die ANNAX an der Seite und String 5 für das IBIS 2,
• MAN ÜL - braucht String 8 für die Matrix vorn und Seite sowie den String 9 für die Heckmatrix.
• MB O407 - benötigt die String's 4, 5, 6, 8, 9, 13 ,14, 15, 16 für die unterschiedlichen Anzeigesysteme.

Die genaue Zeichenanzahl, also die Länge eines Strings ist hier nicht begrenzt, sondern ist abhängig vom jeweiligen gescripteten Gerät, mit Ausnahme des Rollbandes, des Steckschildes und der Krüger++ da diese Texturen verwenden. Die Texturnamen sollten aber für Omsi kurz sein. Kürzere Texturnamen lädt Omsi schneller als lange, was sich bei vielen Texturnamen irgendwann bemerkbar macht.

2. Beispiel für eine Anzeigevariante

1 ~~~Befehl ~~~~[addterminus_allexit]
2 ~~~IBIS-Code~~101
3 ~~~Name ~~~~~~Aussetzfahrt
4 ~~~String0~~~~AUSSETZFAHRT
5 ~~~String1~~~~Aussetzfahrt
6 ~~~String2~~~~BT Meullerstr.
7 ~~~String3~~~~Betriebsfahrt
8 ~~~String4~~~~Endfahrt.bmp
9 ~~~String5~~~~Heimfahrt
10~~~String6~~~~Aussetzen.tga
11~~~String7~~~~Diensfahrt.bmp
12~~~String8~~~~END
13~~~String9~~~~Dienstfahrt
14~~~String10~~~201
15~~~String11~~~Nicht einsteigen*B
16~~~String12~~~
17~~~String13~~~Feierabend
18~~~String14~~~
19~~~String15~~~Nicht
20~~~String16~~~einsteigen!

Was in den einzelnen Strings drin steht ist fast egal. Die Texturen müßen mit den entsprechenden Texturnamen übereinstimmen. Was in den einzelnen Anzeigen steht ist vollkommen egal, da die Fahrkunden auf die Bedeutung der Worte nicht reagieren. Entscheidend für die Passagiere in Omsi ist der IBIS-Code des in Verbindung mit dem Namen der Endstelle, so wie diese in der Map eingetragen sind oder im Fahrplan. Oder das Präfix _allexit, womit die Figuren in Omsi das Fahrzeug vollkommen ignorieren.

---

Haltestellen

Das ganze wiederholt sich nun auch für die Haltestellen. Was dort im einzelnen angezeigt wird, ist auch hier vollkommen egal. Wichtig ist nur der Name der Haltestelle wie im Editor und auch die entsprechende Ansage. Der Dateiname der Audiodatei muß genauso geschrieben sein, damit Omsi die Audiodatei der Haltestelle zuordnen kann. Die Reihenfolge, wie die Audiodateien abgespielt werden, ist im letzten Abschnitt "Routenlisten" festgelegt. Die genaue Reihenfolge der Haltestellen die in der Route abgefahren werden sollen, wird im Fahrplan mit dem Editor festgelegt. Wird eine neue Haltestelle angefahren, wird aus der Hofdatei der Name der Haltestelle ausgeleden, im IBIS angezeigt und die entsprechende Audiodatei abgespielt.

Zum besseren Verständnis: Wie die Haltestelle im Editor heißt ist für die Hofdatei irrelevant. Steht im Fahrplan für die nächste Haltestelle Breite Straße und in der Hofdatei steht Baumalle, muß die nächste Haltestelle Breite Straße angefahren werden, da sonst alle Fahrkunden aussteigen. Der Bus liest für die nächste Haltestelle aber die Baumallee aus und spielt auch die dazugehörige Audiodatei ab. Ihr solltet immer daran denken, was in der Hofdatei drinsteht ist nicht für die Perosnen in Omsi, sondern ausschließlich für euch. Steigt eine Person in einem Bus ein, orientiert diese sich nur nach zweit Punkten. Welchen IBIS-Code fahrt ihr an und welche Endstelle ist mit diesen IBIS-Code verbunden. Omsi legt dann fest das diese Figur eine bestimmte Anzahl an Haltestellen mitfährt und steigt dann aus. Welche Ziele am Bus stehen, was dort geschrieben oder angezeigt wird, wie die nächste Haltestelle heißt und welche Audiodatei abgespielt wird, ist der Figur in Omsi egal, sollange ihr auf dem Pfad der Tugend (also dem festgelegten Pfad zur Haltestelle, wie im Fahrplan angegeben) bleibt. Ihr braucht also lediglich nur im IBIS den Ziel-Code eintragen und die Leute steigen ein. Dies kann man am besten im MB O 305 sehen. Gibt man in diesen Bus die Linie und Route ein, wird aus der Hofdatei der Zielcode ermittelt und übernommen. Außen am Bus stehen keinerlei Informationen, aber die Leute steigen ein.

1 ~~~Befehl ~~~~[addbusstop]
2 ~~~Name der Haltestelle~Baumallee
3 ~~~String0~~~~BAUMALLEE
4 ~~~String1~~~~Baumallee/
5 ~~~String2~~~~Hammerweg
6 ~~~String3~~~~Baumallee/Hammerweg
7 ~~~String4~~~~4

Direkt nach dem Befehl in Zeile 1 folgt die Identifizierung mit dem Haltestellenwürfel im Editor von Omsi. Die nachfolgenden Informationen werden nun im Bus für diese Haltestelle angezeigt. Was genau angezeigt wird, ist euch überlassen.

---

Form der Hofdatei in Omsi 2

Zuersteinmal sei an dieser Stelle erwähnt, daß Omsi 2 beide Formationen der Hofdatei auslesen kann. Im Grunde ist die Hofdatei gleich, es werden nur andere Trennungen verwendet. Dadurch ergeben sich einige kleine Änderungen. Somit braucht ein Befehl nicht mehr, mehrfach geschrieben werden, sondern leicht verändert in einmaliger Form.

Im ersten Abschnitt einer Hofdatei kommt ein weiterer Befehl hinzu. Dieser regelt die dazugehörigen Unterordner in Omsi, da nun einige Dateien (Audiodateien und Texturdateien für Rollband, Steckschilder und Krüger++ Matrix), nichtmehr in jeden Bus-Ordner eingestellt werden, sondern zentral in einem Unterordner zusammengefast sind. Der Vorteil liegt dabei klar auf der Hand: Man spart Speicherplatz auf der Festplatte und muß nicht bei neuen Bussen alles einzeln einkopieren. Damit Omsi genau weiß, welche Daten für die jeweilige Hofdatei genau zu finden sind, wird mit einem neuen Befehl die Namen der Unterordner angegeben.

1 ~~~Befehl ~~~~[global_strings]
2 ~~~Stringanzahl~~~~6
3 ~~~String0~~~~Name des Ansagen-Unterordners 
4 ~~~String1~~~~Name des Rollband-Unterordners 
5 ~~~String2~~~~Name der Seitenschild-Unterordners
6 ~~~String3~~~~IBIS-Spezialcode für 900-er Liniennummern
7 ~~~String4~~~~IBIS-Spezialcode für 800-er Liniennummern
8 ~~~String5~~~~IBIS-Spezialcode für 500-er Liniennummern

Hier folgen die genaue Anzahl der Strings die ausgelesen werden sollen. Nach der festlegung der Anzahl folgen die 3 Unterordner für die Ansagen (Audiodateien) sowie die Namen der Unterordner für die Texturen des Rollbandes und der Seitenschilder im Ordner Anzeigen.

Die IBIS-Spezialcodes sind bereits in der jeweiligen Matrix-osc eines Busses festgelegt. Die darunter liegenden Zahlen die dort eingetragen werden, müßen den Buchstabencodes der Busse entsprechen. Da man in den IBIS-Geräten keine Buchstabentasten hat, werden Buchstaben nur über Codes eingetragen. Hier kann man also festlegen, welche Buchstaben an welcher Liniennummerposition angezeigt werden sollen. Eventuell muß ein Buchstabe in der jeweiligen Matrix.osc neu festgelegt werden.

Hier folgt nun eine kleine Tabelle mit einigen ausgewählten Buchstaben:

1 ~~~ "E" an erster Stelle
4 ~~~ "N" an erster Stelle
5 ~~~ "S" an erster Stelle
6 ~~~ "A" an erster Stelle
9 ~~~ "E" an zweiter Stelle
10~~~ "E" an dritter Stelle
15~~~ "N" an zweiter Stelle
16~~~ "A" an dritter Stelle
28~~~ "M" an erster Stelle
32~~~ "M" an dritter Stelle
36~~~ "X" an erster Stelle

Soll also 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 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.

---

Endstellen

Im Omsi 1-Format werden die jeweiligen Strings einfach untereinander geschrieben. Im einfachen Windowsseitigen Editor (Wordpad) schreibt man einfach unter dem Befehl die gewünschte Anzeige für den entsprechenden String ein. Dazu ist es aber erforderlich den jeweiligen Befehl immer wieder zu schreiben und neu die genaue stringposition zu zählen. Im Omsi 2-Format kann man nun alle Strings nacheinander schreiben, wobei man am Anfang lediglich den Grundfehel schreibt, dann folgt die Liste der Anzeigen und beendet die Liste mit einem "end". Mit dem windowseigenen Editor Wordpad gibt es hier einen riesigen Nachteil. Da die Zeichenlänge der Anzeigen variieren kann, erscheinen nicht die jeweiligen Strings sauber untereinander. Die Trennung der jeweiligen Strings wird mit der TAB-Taste gesetzt. Auch diese Abstand variiert. Bei einer geringen Anzahl von Strings und auch von Endstelle kann man das ganze noch überschauen. Aber wenn eine Karte doch etwas umfangreich ist, Wird das ganze zunehmend unübersichtlich und ungenau. Dann können Tababstände ein Feld mit der Leertaste entsprechen.

Daher wird dringend die Verwendung eines externen Programmes empfohlen, wie das Hof Suite von Rumpelhans .

Übersichtlich wird es aber auch mit einem Tabellenprogrammen wie Windows Office Exel oder ähnlichen Tabellenprogrammen, die es auch kostenlos gibt, wie Open Office. Dabei erstellt man die Anzeigen Zeilenweise und erstellt die Strings sauber nebeneinander in Spalten.

Als erstes eröffnet man eine Liste mit den entsprechenden Befehl [addterminus_list] Nun folgen die Einträge für jede Endstelle in einer Zeile, wobei die einzelnen Strings mittels TAB getrennt werden. Damit ergeben sich zwar nacheinander mehrere Spalten, aber die Übersicht bleibt bei der verwendung externer Programme erhalten. Nachfolgend nun eine Liste, was in die entsprechenden Spalten eingetragen werden soll.

Spalte 1 Soll bei dieser Anzeige niemand einsteigen, wird diese Spalte mit dem Präfix {allexit} geschrieben,
 andernfalls bleibt dieses Feld leer
Spalte 2 IBIS-Code
Spalte 3 Identifikation der Endstelle
Spalte 4 String 0
Spalte 6 String 1
Spalte 7 String 2
Spalte 8 String 3
Spalte 9 String 4
Spalte 10 String 5
Spalte 11 String 6
Spalte 12 String 7
Spalte 13 String 8
Spalte 14 String 9
Spalte 15 String 10
Spalte 16 String 11
Spalte 17 String 12
Spalte 18 String 13
Spalte 19 String 14
Spalte 20 String 15
Spalte 21 String 16

Wurden alle Endstellen eingetragen, wird die Liste mit dem Befehl [end] abgeschlossen. Anschließend folgt die nächste Liste, also die Haltestellenliste, was dem 3. bereich einer Hofdatei entspricht.:

---

Haltestellen

Das selbe Prinzip wie zuvor, wird auch in dieser Liste angewendet:

[addbusstop_list]
Spalte 1 Name der Haltestelle
Spalte 2 String 0
Spalte 3 String 1
Spalte 4 String 2
Spalte 5 String 3
Spalte 6 String 4
Spalte 7 String 5

Und auch diese Liste wird am Ende mit dem Befehl [end] geschlossen.

Der vierte und letzte Teil der Hofdatei bleibt wie im Omsi 1-Format erhalten.

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. 

---

---

Die Universelle Hofdatei.

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

---

Was bedeutet "Universelle Hofdatei" ?

Wie der Name schon vermuten läßt, bedeutet Universell = Vielseitig! Also eine einzige Datei die vielseitig eingesetzt werden kann. Diese vielseitigkeit bezieht sich hierbei (in Bezug auf Omsi) für alle Gruppen von Anzeigegeräten, die in den Bussen verbaut wurden. Es wird nie eine einzige Hofdatei für alle Map's geben, aber es ist Möglich, eine einzige Hofdatei (für jede einzelne chronologische Zeitspanne), für jede einzelne Map anzulegen, wenn diese nicht in einem Busordner eingestellt wird, sondern in einem seperaten Ordner, wie die Ansagen (Announcement) oder die Rollbandtexturen (Anzeigen).

---

Wenn eine "universelle Hofdatei" sinnvoll wäre, hätten M+R Software diese umgesetzt.

M+R Software 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 Basic. Zwei unterschiedliche Anzeigegeräte (Rollband und ANNAX-Matrix) und zwei unterschiedliche Informationssteuergeräte (IBIS 1 und IBIS 2). Wer meint das die beiden IBIS-Geräte nicht unterschiedlich wäre, sollte sich nur 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 20 Anzeigestellen vorweisen. Dafür wurde beiden Geräten, unterschiedliche String zugewiesen. Neue Busse mit neuartigen Anzeigesystemen haben die Strings benutzt, die für die ANNAX-Anzeige vorgesehen waren und mußten 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. Stellt man diese Hofdatei in einem MAN SD 202, erhält man teilweise unerwünschte Anzeigeformen. 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üßen 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.

Befürchtungen, daß die Hofdatei dadurch aus einem überschaubaren Rahmen fällt, dem sei gesagt, daß dies auch in der Zukunft und auf längere Sicht hin, nicht passieren wird. Sicher werden noch einige neue Anzeigegeräte hinzu kommen. Aber man sollte beim Erstellen schon darauf achten, ob man nicht vielleicht den ein oder anderen String, der für andere Anzeigegräte erstellt wurde, weiterhin nutzen 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.

Dazu möchte ich gern ein passendes Zitat von Busfanat aus dem offiziellen Forum einfügen:

"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."

---

Sinn und Zweck einer "universellen Hofdatei".

Seitdem Omsi 2011 erschienen ist, sind viele weitere Busse erschienen. Nicht alle haben eine Rollbandanzeige oder eine ANNAX-Matrix. Neue Anzeigen sind auch nicht erst mit Omsi 2 erschienen, wie die Krüger-Matrix. Es gab schon die BUSE-Vollmatrix, die Busfanat-Vollmatrix oder Flipdot-Anzeige. 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 & Informationssteuergeräten, muß die Hofdatei angepasst werden. Möchte man nun einen anderen Bus nehmen, der eines der beiden verwendeten Geräte nicht besitzt, muß eine neue Hofdatei angefertig oder die vorhandene Hofdatei umgeschrieben werden.

Damit gibt es für eine Map ohne Chronologiefunktion schon mehrere Hofdateien, was völlig unnötig ist. Für eine Karte mit Chronologiefunktion gibt es allein schon mehrere Hofdateien, um die einzelnen Zeitspannen abzudecken. Stellt man nun noch für die einzelnen Anzeigesystemen noch die umgeschriebenen Hofdateien hinzu, werden es soviele Dateien, das man in der Busauswahl nichtmehr genau unterscheiden kann, welche Hofdatei nun für den entsprechenden Bus passend ist und man muß die einzelnen Busse in der AI-List genau zuweisen, damit diese richtig anzeigen. Dies würde mit einer universellen Hofdatei wegfallen, weil alle Busse auf diese eine universell angepasste Hofdatei zugreifen.

Das mag insgesamt nicht schwer sein, aber nicht alle User haben dazu Zeit oder die Fähigkeit eine entsprechende Hofdatei zu erstellen. Mit einer universellen Hofdatei kann jeder Bus, unabhängig vom verwendeten Anzeige- und Informationssteuergerät, eine einzige 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 zu müßen, oder testen zu müßen, welche Hofdatei eigentlich am besten passt. Das ist nichtnur für Buserbauer und Mapersteller sinnvoll, sondern ganz besonders für Paywarehersteller, da somit gewährleistet ist, daß wirklich alle Busse auf jeder Karte einsetzbar sind, ohne zuvor eine Hofdatei erstellen oder im Internet suchen zu müßen.

---

Vor- & Nachteile einer universellen Hofdatei.

Es gibt für eine universelle Hofdatei, natürlich einige Vorteile, aber leider auch einige Nachteile. Hier soll aufgezeigt werden, daß eine Umstellung durchaus sinnvoll ist und die Umstellung auch lohnt. Bei der Umsetzung einer universellen Hofdatei reicht es nicht aus, einfach die Hofdfatei ansich, zu erweitern. Es müßen auch einige Kleinigkeiten in den jeweiligen Bussen geändert werden.

Vorteile einer universellen Hofdatei:

• Eine Hofdatei passt für alle Busse, unabhängig vom verwendeten Anzeige- & Informationssystem.
• Es werden auch alle verwendeten Informationsgeräte und Anzeigen im Bus unterstützt.
• Bei neuen Bussen mit bisher veröffentlichten Systemen, passt die universelle Hofdatei.
• Eine universelle Hofdatei ist unabhängig vom verwendeten Hofsystem (also für Omsi 1 oder Omsi 2).
• Diese Hofdatei kann bei Bussen mit neuen Systemen leicht angepasst/ erweitert werden.
• Bei neuen Bussen muß der User lediglich die Hofdatei in den Busordner einsetzen.
• Alle Busse werden dadurch leichter für alle Karten kompatibel.
• Ein Ziel kann unterschiedliche Anzeigen erhalten, die auf den unterschiedlichen Systemen angezeigt werden.
• Eine universelle Hofdatei kann durch kopieren/ einfügen schnell ergänzt und erweitert werden.
• Es muß nichtmehr getestet werden, welche Hofdatei für einen Bus passender ist.
• Bei Maps, kann ein User alle Busse problemlos einsetzen.
• Kann sehr einfach mit der Hof Suite von Rumpelahns erstellt werden.

Nachteile einer universellen Hofdatei:

• Einige bereits erstellte Hofdateien werden überflüssig (und auch die haben Arbeit und Zeit gekostet).
• Die Übersichtlichkeit innerhalb einer Hofdatei leidet (hauptsächlich beim Hofformat in Omsi 2).
• Bei nichtabsprache, welche Strings verwendeten werden können, kann es zu Problemen/ Streitigkeiten kommen.

Insgesamt bleibt aber die Anzahl der verwendeten Strings, innerhalb eines kleinen und leicht überschaubaren Rahmen.

---

Wie man eine "universelle Hofdatei" umsetzen kann.

Um eine universelle Hofdatei umzusetzen, muß man lediglich drei Dinge beachten:

• Welche vorhandenen Strings kann ich nutzen, ohne die Strings in der Hofdatei umstellen zu müssen?
• Welche neuen Strings kann ich verwenden, die noch nicht von anderen Geräten ausgelesen werden?
• Wie kann ich neue Geräte auf weitere Strings umsetzen?

Im folgenden geht es um bereits verwendete Strings, neu verwendete Strings und Strings die dadurch bereits vergeben sind und wie man das Auslesen der Strings beeinflußt.

---

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 die von M+R Software vorgegebenen Strings beachtet werden (String 0 bis String 7) und einfach die nachfolgenden bereits vergebenen Strings verwendet werden. Hier ist es eine schwachsinnige Umsetzung der "universellen Hofdatei". Es ist natürlich verständlich das jeder die benötigten Strings dicht bei einander haben möchte. Wenn aber bereits vergebene Strings einfach wieder umgeschrieben werden, die bereits für andere Informationssysteme vergeben wurden, wurde der Sinn der "universellen Hofdatei" nicht verstanden. Durch die Veröffentlichung hatte jeder die Möglichkeit, sich für eine beteiligung an der Umsetzung einer "universellen Hofdatei" 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 und zweckmäßig) die bereits vergebenen, nicht benötigten Strings auszufüllen. Diese können auch frei gelassen werden.

Sinnvoll ist es sich vorher Gedanken zu machen, welche bereits vergebene Strings mitbenutzt werden können und ob neue Strings erweitert werden müßen. 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, eine "universelle Hofdatei" annehmen, statt blind einfach vorhandene Strings zu überschreiben. Man kann natürlich auch so unüberlegt handeln und seine Busse scriptseitig auf einer bestimmten Map festlegen. Das verkürtzt den Spielspaß aber erheblich, wenn man nicht ohne weiteres andere Busse, besonders dann wenn die mitgelieferten Busse schnell langweilig werden oder Freeware-Busse qualitytiv gleich- oder höherwertiger sind, einsetzen kann. Besonders Freeware-Busse die keine festgelegten Karten haben, können hier mit einbezogen werden.

So wie Menschen sich anpassen können, sind auch die einzelnen String's individuell anpassbar. Besonders in Hinblick auf die verwendbaren Zeichen und Symbole, wie auch in der Zeichenlänge der damit versorgten Anzeigesysteme oder die Verwendung von Codes zur Anzeigeform.

Für Hilfe zur Anpassung oder zur Einigung von neuen Strings, ist es sinnvoll die Kommunikation zwischen Paywareherstellern und Usern deutlich zu verbessern. Wenn man weiterhin, blind vorhandene bereits vegebene Strings benutzt, braucht man sich folglich nicht wundern, wenn es negative Kritiken (die dann auch berechtigt sind) für das jeweilige Produkt gibt. Man weiß nun nicht, ob es Faulheit oder Dummehit ist, wenn man bereits vorhandene Strings für eigene Systeme benutzt, daß soll hier auch nicht diskutiert werden, aber wenn es Omsi-seitig schon die Möglichkeit gibt, sollte man diese natürlich auch benutzen.

---

Veränderungen in der Hofdatei.

Welche Strings bereits umgesetzt wurden und ausgelesen werden

M+R Software haben bereits angefangen, neue Strings zu verwenden, als Omsi 2 eingeführt wurde. Hier wurden lediglich weitere Strings in der Hofdatei umgesetzt und neue Informationsteile auf die neuen Strings eingestellt. Busfanat hat auf bitten einer umsetzung, die von ihm erstellte [1], sofort auf andere neue Strings umgesetzt. Auch Perontinus hat die von ihm entworfenen MAN ÜL 242, 272, 292 und 312, auf bereits neue und erweiterte Strings umgestellt.

Im übrigen sei an diese Stelle erwähnt das alle Busse mit einer Rollbandtextur, oder Busse, die auf dieser Basis funktionieren, bereits einen einzigen String nutzen. Alle Busse auf dieser Basis nutzen nur den String 4. Der Unterschied der Texturgröße, wird über den Zugriff der Anzeige-Ordner geregelt. Dies betrifft mehrere Busse:

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

und einige mehr

Im Folgenden soll es um die Stringsvergabe gehen und um die Anpassungen im Bus.

---

Bereits verwendete Strings

Bisher wurden folgende Terminus-Strings in der Hofdatei bis zum String 24 erweitert und festgelegt:

Unter dem Befehl stringcount_terminus muss die Anzahl der Strings auf 25 gesetzt werden.

[addterminus]
123
Endhaltestelle
String  0 -  Anzeige IBIS 1 (nur Großbuchstaben, maximal 16 Zeichen)
String  1 -  Anzeige ANNAX-Matrix obere Zeile  (maximal 16-Zeichen)
String  2 -  Anzeige ANNAX-Matrix untere Zeile (maximal 16-Zeichen)
String  3 -  Anzeige Seiten-ANNAX-Matrix, wenn diese einzeilig ist (maximal 16-Zeichen)
String  4 -  Rollbandtextur (.tga-Datei)
String  5 -  Anzeige IBIS 2 (Groß- & Kleinbuchstaben, maximal 20-Zeichen)
String  6 -  Texturname für Steckschild (wenn Ziel in Matrix nicht darstellbar ist, 
             oder nicht angezeigt werden soll)
String  7 -  Texturname für Bildanzeige in Krüger-Matrix (Krüger+)
String  8 -  Frontanzeige für ANNAX-Matrix (Groß- & Kleinbuchstaben, maximal 15-Zeichen)
String  9 -  Heckanzeige für ANNAX-Matrix (maximal 4-Zeichen)
String 10 -  IBIS-Code für Gegenroute für künftige Ikarus-Beschilderung (Ikarus 280.02)
String 11 -  Anziege für Busfanats-Vollmatrix obere Zeile (oder Komplettanzeige, Wenn diese Zeile leer ist, 
              wird String 1 ausgelesen)
String 12 -  Anzeige für Busfanats-Vollmatrix untere Zeile (falls erforderlich, Wenn diese Zeile leer ist, 
              wird String 2 ausgelesen)
String 13 -  Anzeige für Coopers Lawo-Matrix Front oben (bleibt dieser String leer, wird String 1 ausgelesen)
String 14 -  Anzeige für Coopers Lawo-Matrix Front unten (bleibt dieser String leer, wird String 13 ausgelesen)
String 15 -  Anzeige für Coopers Lawo-Matrix Seite oben (bleibt dieser String leer, wird String 16 ausgelesen)
String 16 -  Anzeige für Coopers Lawo-Matrix Seite unten (bleibt dieser String leer, wird String 15 ausgelesen)
String 17 -  IBIS-Anzeige für Niederflur-Busse aus den Wien-Add-Ons 1 und 2
String 18 -  MAN ÜL Vollmatrix oben
String 19 -  MAN ÜL Vollmatrix unten
String 20 -  MAN NL 2x3 Innenanzeige
String 21 -  MAN NL 2x3 Innenanzeige II (zeigt eine zusätzliche Information an [über])
String 22 -  Zusätzliche Heckanzeige für Coopers LAWO-Matrix, wenn Ziele keine Liniennummer haben (Betriebsfahrt)
String 23 -  einfache Krüger-Matrix oben
String 24 -  einfache Krüger-Matrix unten
String 25 -  Anzeigecode für das Ansagegerät im LU 200 / GU 240 aus Wien (Zwei Ziffern getrennt durch Leerzeichen)

Bisher wurden folgende Busstop-Strings in der Hofdatei bis zum String 8 erweitert und festgelegt:

Unter dem Befehl stringcount_busstop muss die Anzahl der Strings auf 9 gesetzt werden.

[addbusstop]
Haltestelle
String  0 -  Anzeige IBIS 1 (nur Großbuchstaben, maximal 16 Zeichen)
String  1 -  Innenanzeige 
String  2 -  Innenanzeige nach Umschaltung
String  3 -  IBIS 2 (Groß- & Kleinbuchstaben, 20 Zeichen)
String  4 -  Haltestellencode für die Ansagengeräte der Hochflurbusse aus den Wien-Add-Ons 1 und 2
String  5 -  Wabencode von iTram (aktuell im GSÜH 240 umgesetzt)
String  6 -  IBIS-Anzeige für Niederflur-Busse aus den Wien-Add-Ons 1 und 2
String  7 -  Ansagenlänge in Sekunden für IBIS-Geräte der Busse aus den Wien-Add-Ons 1 und 2
String  8 -  Innenanzeige für Niederflur-Busse aus den Wien-Add-Ons 1 und 2 
             (fixe Länge von 2x24 Zeichen (24 Zeichen (= Zeile 1), dann "@" und nochmals 24 Zeichen (= Zeile 2)))
String  9 -                                  weitere Strings wurden noch nicht festgelegt

Diese bereits zugewiesenen Strings sollten unbedingt beachtet werden, da es unsinnig ist, bereits veröffentlichte Scripte neu anzupassen - im Gegenteil ist es einfacher, neue Objekte und Systeme auf neue Strings anzupassen!

Hinweis zur LAWO-Matrix von Cooper: Diese Vollmatrix verwendet in erster Linie die Strings 13 bis 16. Es müßen aber
nicht alle Felder ausgefüllt werden. Cooper hat hier gleich mehrere Möglichkeiten eingebaut um auf andere Strings
ausweichen zu können.

String 13 - bleibt dieser String leer, wird String 1 ausgelesen,
String 14 - bleibt dieser String leer, wird String 13 ausgelesen,
String 15 - bleibt dieser String leer, wird String 16 ausgelesen,
String 16 - bleibt dieser String leer, wird String 15 ausgelesen,
          - Bleiben String 15 und 16 leer, werden die Strings 13 und 14 benutzt.

Solange der String 13 benutzt wird, werden keine anderen Ersatzstrings verwendet. Bleiben aber alle für die
Lawo-Matrix verwendeten Strings (also String 13 bis 16) leer, werden von der Lawo-Matrix, ersatzweise die
String 1 bis 4 verwendet. Hier gibt es wieder mehrere Möglichkeiten Ersatzstrings zu benutzen:
String 1 - bleibt dieser leer, wird String 2 ausgelesen,
String 2 - bleibt dieser leer, wird String 1 ausgelesen,
String 3 - bleibt dieser leer, wird String 4 ausgelesen,
String 4 - bleibt dieser String leer oder wird ein Textureintrag mit der Dateiendung TGA eingetragen,
wird String 3 ausgelesen.

Mit dieser Variante hat man sogar die Möglichkeit ein Ziel in verscheidenen Varianten anzeigen zu lassen.

---

Zeichenlänge eines String

Wie bereit's geschrieben, gibt es von Omsi keinerlei Begrenzung wie lang der Inhalt eines String sein darf. Auch die Hofdatei ansich (also Textdokument) setzt keine Längengrenze. Einige Anzeigen geben aber eine bestimmte Maximallänge, also eine maximale Anzahl von Zeichen vor. Benutzt man also zwei Anzeigen die eine unterschiedliche Zeichenanzahl zulassen und setzt diese auf einen String, wird eine Anzeige falsche Ergebnisse liefern. Als einfaches Beispiel kann man hier die beiden IBIS-Geräte nehmen, wie sie von M+R Software umgesetzt wurden. Während das IBIS 1 nur und ausschließlich Großbuchstaben verwendet und nur diese anzeigen kann, kann das IBIS 2 Groß- und Kleinbuchstaben verwenden. Dadurch ist auch die Anzahl an verwendbaren Zeichen begrenzt. Umlaute wie "Ä,Ö und Ü" fallen vollständig beim IBIS 1 raus (sowie auch das "ß"). Die genaue Länge eines Strings ist einerseits in dem jeweiligen Script genau festgelegt und auch in der verwendeten Font. Das Script des IBIS 1 mit der verwendeten Font, läst insgesamt nur maximal 16 Zeichen zu. Dazu zählen alle in dem String verwendeten Zeichen, also Buchstaben, Zahlen, und Leerzeichen. Alles was nach den 16 Zeichen geschrieben wird, kann einfach im Display des IBIs 1 nicht angezeigt werden. Hat man als Beipiel einen Haltestellennamen der Länger als 16 Zeichen ist, werden nur maximal 16 Zeichen angezeigt:

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

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

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

Solch eine Abkürzung macht im IBIS 2 keinen Sinn, da dort Umlaute genauso angezeigt werden können, wie längere Haltestellennnamen:

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. Entwickelt oder setzt jemand eine neue Anzeige um, die beispielsweise nur Großbuchstaben aber 18 Zeichen anzeigen kann, emfpielt sich die verwendung eines weiteren String. Oder man weicht vom Original ab.

Um nun genau zu wissen, welche Strings man nun verwenden kann oder ob man neue verwenden muß, ist es sinnvoll es an den originalen Fahrzeugen von M+R Software zu testen. Auch die folgenden Strings die von Freewarefahrzeugen verwendet werden sollte man beachten.

Wer sich nur an den von M+R Software vorgegebenen Standard hält und alle folgenden belegten Strigs mißachtet, 
kann auch ganz auf eine universelle Hofdatei verzichten, da der Sinn einer universellen Hofdatei definitiv 
nicht verstanden wurde.
Wer also unbedingt nur die Standardfahrzeuge und ihre Strings beachtet und andere bereits vergebenen Strings 
ungeachtet läßt und diese sinnlos überschreibt, sollte sich unbedingt nochmal den Sinn und Zweck der 
universellen Hofdatei durchlesen. 
Ich habe jedem die Möglichkeit gegeben sich rechtzeitig bei mir zu melden, um weitere Strings zu vegeben. 
Einige haben diese Möglichkeit genutzt, wie Busfanat, Perotinus, iTram, Chrizzly92 und Cooper. Bekannte Payware-Hersteller habe 
ich vor Veröffentlichung dieses Artikels auch angeschrieben!
Hier greift ganz klar das Sprichwort: " Wer zuerst kommt, malt zuerst. " und " Den letzten beißen die Hunde ". 

Nachfolgend nocheinmal einige Zeichenlängen für einige Anzeigen in Bussen:

IBIS 1 = 16 Zeichen, nur Großbuchstaben (String 0)
IBIS 2 = 20 Zeichen, Groß- & Kleinbuchstaben, Umlaute (String 5)
ANNAX  = 16 Zeichen in 2 Zeilen (String 1 und 2)
Seiten-ANNAX = 16 Zeichen einzeilig (String 3)
Ansagegerät im LU-200 = 2 Ziffern (String 4 in der Haltestellenliste)
Innenanzeige SD 202 oder MAN NL/NG = 2x 20 Zeichen mit automatischer Umschaltung (String 1 und 2 
                                     in der Haltestellenliste)
Vollmatrix, Die Zeichenlänge ist von der Form der Schrift (Font) und die Mitnutzung von Liniennummern abhängig.
ANNAX-Matrix vom MB O307, O407 und MAN ÜL, Maximal 15 Zeichen incl. Liniennummer (String 8)
ANNAX-Matrix am Heck des MB O307, O407, MAN ÜL maximal 4 Zeichen (String 9)
LAWO-MATRIX am Heck von Modifizierten Bussen von Cooper, maximal 6 Zeichen (String 22)

Die Zeichenanzahl in den unterschiedlichen Matrizen ist vom jeweilig verwendeten Font abhängig. Hier kann man keine festgelegte Zeichenanzahl angeben. Das selbe betrifft auch die Innenanzeige, wenn diese auf einer LED-Animation umgestellt wird. Auch dann entscheidet wieder die einzelne Zeichenlänge der Font die zu verwendete maximale Länge in den Innenanzeigegeräten. Auch die Krüger-Matrix vom MAN NL und NG von M+R Software sind nicht genau festgelegt, es sieht nur passender aus, wenn man hier die Anzahl der Dots beachtet.

---

Hinzufügen und erweitern 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 seperate Strings für eine anders anzeigende Seitenanzeige?
• Soll die Heckanzeige seperat und unabhängig der anderen Anzeigen, Informationen darstellen?
• Brauche ich einen zusätzlichen Strings für ein im Bus verbautes Informationssteuergerät?
• Können einige Anzeigeräte bereits vergebene Strings auslesen ohne das diese Strings angepasst oder geändert werden müßen?
• Wie einigt man sich auf neue zusätzliche Strings.

Man kann im offiziellen Omsi-Forum die künftige Verwendung neuer Strings ankündigen und diese in den Scripten des Fahrzeug's einstellen. Wer ganz sicher gehen möchte, kann sich im offiziellen Omsi-Forum an den User <<Tatra>> , via PN wenden und die Verwendung weiterer Strings abklären. Oder via E-Mail an: e_marko@web.de - das gilt für neue und auch bereits erschienende Fahrzeuge.

---

Veränderungen in den BusScripten

Welche Scripte betroffen sind

Hauptsächlich finden sich die Änderungen, nur in zwei Scripten wieder. Zum einen muß das Auslesen des Zieles in den Scripten der Matrixanzeige stattfinden. Diese Scripte haben im Dateinamen meist den Präfix: Matrix, Rollband`` oder ähnliches und die Dateiendung lautet immer auf osc.

Zum anderen finden sich Änderungen in dem jeweils verbauten Informationssteuergerät wieder. Die Dateinamen der verwendeten Steuergeräte sind noch unterschiedlicher als bei der Matrix. Teilweise sind die Scripte zum Steuern der Informationsanlage mit den Fahrkartendruckern zusammengelegt, da es in einigen Bussen kombinierte IBIS-Fahrkartendrucker gibt, wie dem EFAD, INIT, Atron etc, muß man hier eventuell nach mehreren Präfixen suchen:

• IBIS
• IBIS_2
• EFAD
• Atron
• Ticketprinter
• Printer

Aber auch hier lautet die Dateiändungen generell: osc.

Die jeweils in den Bussen verbauten Informationssteuergeräten, steuern alle Informationsgeräte die es im Bus gibt, also nicht nur die äußeren Matrix-Anzeigegeräte, sondern auch die inneren Haltestellenanzeigen. In diesen dazugehörigen Scripten werden auch die jeweils benannten Strings angegeben, welche ausgelesen werden sollen.

Die Befehle zum Auslesen bestimmter Strings.

Zum Auslesen der entsprechenden Strings gibt es zwei Befehle:

• (M.V.GetTerminusString)

 Zum Auslesen eines bestimmten Strings aus der Endstellenliste (2.Bereich einer Hofdatei)[addterminus]

• (M.V.GetBusstopString)

 Zum Auslesen eines bestimmten Strings aus der Haltestellenliste (3.Bereich einer Hofdatei) [addbusstop]

Nur diese beiden Befehle sind für das Auslesen eines bestimmten Strings zuständig. In diesem Bezug finden sich leider nicht immer die entsprechenden nummerierten String, was das umstellen sehr erschwert.

Einstellungen zum Auslesen der Strings.

Als Beispiele sollen hier die Stringeinstellungen im IBIS 1 des MAN SD 200 und des IBIS 2 des SD 202 dienen, sowie die Stringeinstellungen der ANNAX-Matrix.

IBIS 1

Das IBIS 1 ließt den String 0 aus der Endstellenliste [addterminus]:

{macro:IBIS_RefreshTerminusText}
	(L.L.IBIS_TerminusIndex) 0 (M.V.GetTerminusString) (S.$.IBIS_terminus_name)
{end}

und den String 0 aus der Haltestellenliste aus:

'Sonst zeige die Bushaltestelle
	(S.L.IBIS_busstop_index) 0 (M.V.GetBusstopString)
	(S.$.IBIS_busstop_name)

Die hier eingestellten Ziffern NULL, stehen für den String 0 in beiden Listen.

IBIS 2

Für das IBIS 2 Gerät sind es zwei verschiedene Strings die ausgelesen werden. In der Endstellenliste ist es String 5:

{macro:IBIS_RefreshTerminusText}
	(L.L.IBIS_TerminusIndex) 5 (M.V.GetTerminusString) (S.$.IBIS_terminus_name)
{end}

und String 3 in der Haltestellenliste:

'Sonst zeige die Bushaltestelle
	(L.L.IBIS_busstop_index) 3 (M.V.GetBusstopString)
	(S.$.IBIS_busstop_name)

Die hier gezeigten Ziffern 5 und 3 weisen auf die Strings hin, die die Information für das IBIS 2 Gerät enthält.

Innenanzeige

Auch die Innenanzeige des MAN SD 202 (D92) ließt bestimmte Strings aus. Diese findet sich ausschließlich in der Haltestellenliste (3.Bereich) der Hofdatei. Da die Innenanzeige zwei unterschiedliche Informationen anzeigen kann, die im zeitlichen Interval umschaltet, finden sich dort natürlich 2 Strings:

{macro:IBIS_LCD-refresh}

'Formatierung der D92-Innenanzeige

	(L.L.IBIS_LCD-zeile) 1 = 
	(L.L.IBIS_busstop_index) 2 (M.V.GetBusstopString) $length 0 > &&
	{if}
		(L.L.IBIS_RouteIndex) 0 >=
		{if}
			(L.L.IBIS_LCD-zeile) 
			(L.L.IBIS_busstop_index) 2 (M.V.GetBusstopString)
			(S.$.IBIS_cabindisplay)
		{endif}
	{else}
		(L.L.IBIS_RouteIndex) 0 >=
		{if}
			(L.L.IBIS_LCD-zeile) 
			(L.L.IBIS_busstop_index) 1 (M.V.GetBusstopString) 
			(S.$.IBIS_cabindisplay)
		{endif}
	{endif}
{end}

Hier erkennt man, daß aus der Haltestellenliste zwei unterschiedliche Strings ausgelesen werden sollen. Für die Innenanzeige sind in der Hofdatei die String 1 und 2 vorgesehen.

Rollbandanzeige

Für das Rollband gibt es nur einen String der ausgelesen werden soll:

'Aktualisierung der Strings für das Austauschen der Texturen:
			(L.L.rlbnd_ziel) trunc s0
			"..\..\Anzeigen\Rollband_SD79\" 1 (M.V.GetDepotStringGlobal) $+ "\" $+ (S.$.Rollband_Tex_H)
			l0 4 (M.V.GetTerminusString) $+ (S.$.Rollband_Tex_V)
			(L.$.Rollband_Tex_H) l0 1 + 4 (M.V.GetTerminusString) $+ (S.$.Rollband_Tex_H)

'Internen Index aktualisieren:
			(M.L.rollband_refreshIntIndex)
		{endif}
	{endif}

Hier steht der String der ausgelesen werden soll, direkt vor dem Befehl (M.V.GetTerminusString) und zeigt auf den String 4. Für Rollbandbusse, sollte dieser String beibehalten werden (unabhängig von der Form der Rollbandtextur), da jeder Bus im Unterordner Anzeige seine eigene Rollbandtextur benutzt kann, wenn sich die Form der Textur von den Formen anderer Rollbandbusse unterscheidet. Bei bereits vorhandenen Maps, sollte man die Dateinamen der Rollbandtexturen, aus einer vorhandenen Hofdatei abschreiben. So ist gewährleistet, daß man keinen seperaten String benötigt, um die richtigen Texturen anzeigen zu lassen. Wichtig ist auch die Beachtung der verwendeten Dateiendungen.

ANNAX-Matrix

Damit auch die Außenanzeige (Matrix) die richtigen Strings ausließt, muß in der Scriptdatei matrix.osc oder einer ähnlich lautenden Datei, die Matrix auf die richtigen Strings gesetzt werden.

{if}
	"xxx" 30 random 1 (M.V.GetTerminusString) 10 $SetLengthL $+ "xxx" $+ "@" $+
	"xxx" 30 random 2 (M.V.GetTerminusString) 10 $SetLengthL $+ "xxx" $+ "@" $+ $+
	"xxx" 30 random 3 (M.V.GetTerminusString) 10 $SetLengthL $+ "xxx" $+ $+    
              (S.$.Matrix_NewTerminus)						
	{else}
	"yxyxyxyxyxyxyxyx@xyxyxyxyx       @zzzzzzzzzzzzzzzz" (S.$.Matrix_NewTerminus)
	{endif}

Bei den Bussen MAN SD 200 sowie SD 202, stehen diese Einträge zweimal drin. Und es gibt natürlich auch 3 Strings die Ausgelesen werden müßen. Die auszulesenden String stehen auch hier wieder direkt vor dem Befehl (M.V.GetTerminusString) und beziehen sich bei den MAN SD-Bussen auf die Drei verbauten Matrix-Zeilen.

1. String enthält die Information der oberen Zeile der Front-Anzeige (maximal 16 Zeichen),
2. String enthält die Information der unteren Zeile der Front-Anzeige (maximal 16 Zeichen), was eine erweiterung für die obere Zeile darstellt und
3. String befindet sich seitlich am Bus. Hier gibt es nur eine Zeile (maximal 16 Zeichen).

Wenn sich die Seitenmatrix am Bus von der vorderen unterscheidet, sollte ein seperater String verwendet werden, da man auf der Front-Matrix mehr Informationen unterbringen kann als an der Seite.

Die Verwendung des 3. Strings entfällt, wenn sich die Front-Anzeige und die Seiten-Anzeige gleichen. Dann werden für die Seiten-Anzeige ebendfalls die Strings 1 & 2 ausgelesen, damit das angezeigte Ziel identisch ist.

Steckschild

Für das Steckschild gilt der gleiche Befehl, aber abhängig vom verwendeten IBIS-Code. Soll statt einer Anzeige in der Matrix oder einer vewendeten Rollbandtextur, ein Steckschild in der Frontscheibe verwendet werden, Sollte der IBIS-Code in der Hofdatei 4-stellig sein. Also ein IBIScode größer als die Zahl 1.000, setzt den auszulesenden String um auf den String 6, wo sich die Texturname des Steckschildes befinden sollte, daß Verwendtet werden soll.

' Trigger für Steckschild

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

Im oberen Bereich dieses Abschnittes, steht die Zahl 1000, was darauf hindeutet, daß das Steckschild verwendet werden soll. Im unteren Abschnitt folgenden dann der Verweis auf den String 6 für die richtige Textur des Steckschildes und darunter der Pfad, wo sich die Steckschilder befinden.

---

Auslesen von zusätzlichen String, mit der Möglichkeit von "Ersatz-Strings". Die 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 (für die BUSE-Vollmatrix ungeeignet). Während eine ANNAX-Matrix nur wenige Möglichkeiten bietet ein Ziel anzuzeigen, gibt es andere Anzeigen, die die Möglichkeit bieten, ein und das selbe Ziel unterschiedlich darzustellen. Eine Variante bietet die Krüger+ Anzeige. Hier kann statt eines Ziels das nur über Buchstaben verfügt, mittels Textur auch Zeichen dargestellt werden. Diese Anzeige verwendet dann den String 7 und beinhaltet ebenfalls einen Texturdateinamen.

Eine andere, raffinierte Möglichkeit bietet die Busfanats-Vollmatrix. Diese beschränkt sich nicht nur auf 2 Strings, sondern bietet zusätzlich die Möglichkeit 2 originale Strings als Ersatz zu verwenden. Die Busfanats-Vollmatrix ermöglicht Teile der Zielinformation besonders darzustellen, ohne Bildtexturen zu verwenden. Mit zusätzlichen Befehlen, hinter der Information kann ein Ziel Großgeschrieben oder Invertiert dargestellt werden. Diese Vollmatrix kann aber auch Ziele so darstellen, wie es die ANNAX-Anzeige ermöglicht. Dazu brauchen die String 1 und 2 nicht kopiert werden, da die Busfanats-Vollmatrix diese String mitausließt.

Grundlegende Funktion der Busfanat-Vollmatrix :

Soll eine Ziel besonders dargestellt werden, schreibt man in String 11 und 12 das Ziel wie gewünscht ein 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 der "Kieselstein" normal dargestellt wird.

  String 11: Pause*I
  String 12:

Hier wird das Wort "Pause" invertiert. Dabei erscheinen die Buchstaben dunkler als die umgebung, wo die Dot's erscheinen.

Die erweiterte Funktion der Busfanats-Vollmatrix.

Wenn das gewünschte Ziel so angezeigt werden soll, wie in einer ANNAX-Matrix, bedarf es bei dieser Möglichkeit keinen besonderen Aufwand, da die Busfanats-Vollmatrix, die String 1 und 2 ebenfalls ausließt. Stehen in den Strings 11 und 12 Informationen drin, werden die Informationen aus den Strings 11 und 12 ausgelesen und dargestellt. Bleiben diese beiden String leer, werden die Informationen aus den Strings 1 & 2 ausgelesen und diese in der Matrix gezeigt.

'  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 der Busfanat-Vollmatrix die Strings 1 und 2 aus. Bevor die Matrix die Anzeige umstellt, ließt das Script die Strings 11 und 12 aus der Hofdatei aus. Bleiben diese Zeilen leer, wird das zuerst eingelesene Ziel auf der Matrix dargestellt. Wenn aber in der Zeile 11 und 12 Informationen enthalten sind, werden die Informationen die zuerst aus den Strings 1 und 2 ausgelesen wurden, überschrieben und durch die neuen Informationen ersetzt.

Weitere Informationen zur Busfanats-Vollmatrix, findet ihr im Omsi-Forum.

---

---

Quellen

• Busfanat-Vollmatrix,
• Perotinus MAN ÜL's, MB O 307 Bahnbus, MB O307 Bahnbus V2 und MB O407
• Hofdatei Spandau von M+R Software aus Omsi 1 & Omsi 2,
• Offizielles Omsi-Forum,
• Gräf & Stift GSÜH 240 M12 von iTram.
• Grät & Stift Gemeinschaftsbusse von iTram.
• Lawo-Matrix und Mod's von Cooper

Einen herzlichen Dank

geht an

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

Anhang

Ich würde mich freuen, wenn man diese "universelle Hofdatei" wieder umsetzen könnte. Es ist wirklich keine neue Idee, da Marcel Kuhnt und Rüdiger Hülsmann, diese mit Omsi 1 schon richtig umgesetzt haben. Durch neue Busse, Maps und kompletten Add-On's wurden bereits vergebenen 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 das einfache und schnelle Umsetzen einer universellen Hofdatei sollte besonders die Kommunikation verbessert werden, nicht nur zwischen den Usern, sondern besonders zwischen den Firmen die Add-On's herstellen. Leider war es mir in der Vergangenheit nicht möglich, den Kontakt zu einer Softwareschmiede herzustellen. Bei einer anderen Firma konnte ich Kontakt herstellen, aber eine Umsetzung wurde nicht angestrebt oder um Hilfe gebeten. Während einige User dem ganzen Thema der "universellen Hofdatei" offen gegenüber standen, reagierten Firmen garnicht oder zeigten sich uninteressiert. Wenn jemand eine universelle Hofdatei für sein Projekt umsetzen möchte, bin ich gern bereit, ohne irgendeiner 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 das es in Zukunft mehr Gehör findet um eine "universelle Hofdatei" umsetzen zu können. Denn diese dient allen und die Vorteile sollten, eigentlich überwiegen.

geschrieben von Tatra