KI-Verkehr - von Ailists, PKW und Menschen

1. Allgemeine Grundlagen

Für den beweglichen Verkehr, die Menschen (Passanten und Passagiere), die parkenden Fahrzeuge, die Fahrer, die KI-gesteuerten Fahrzeuge (wenn dies vorgegeben ist), die zeitliche und ortgebundene Verkehrssteuerung und die Kennzeichen des KI-Verkehr, werden mehrere Konfigurationsdateien benötigt (siehe Dateitypen). Alle Konfigurationsdateien können mit einem Editor geöffnet und verändert werden. Diese Dateien befinden sich in den entsprechenden Mapunterordnern [..\Omsi\maps\Kartenname]. Dadurch kann die Fahrzeug- und Personenauswahl, individuell mit jeder Karte, unterschiedlich gestaltet werden.

1.1. Dateiübersicht

(Alle hiergenannten Textdateien und die Konfigurationsdatei befinden sich im Hauptordner einer Karte unter OMSI\maps\Karte)

• humans.txt
  Eine Auflistung aller Menschen, die auf dieser Karte herumlaufen können. In der Regel kann die Datei von vorhandenen Karten übernommen werden.
• drivers.txt
  Wie humans.txt, bezieht sich aber nur auf die Fahrer von Fahrzeugen, die dies unterstützen (Busse, Straßenbahnen)
• parklist_p.txt
  Liste aller Fahrzeuge, die die sogenannten "Car Parks" (Spezielle Objekte im OMSI-Editor) ersetzen. Je nach gewählter Dichte in den OMSI-Einstellungen werden an diesen Stellen zufällig parkende Autos generiert.
• registrations.txt
  Liste mit möglichen Kennzeichen für Autos u.a., sofern kein Kennzeichen vorgegeben wird.
• ailists.cfg
  Der "Kern" des KI-Verkehrs. In dieser Datei werden die oben genannten Gruppen für eine Karte definiert (mit Ausnahme der Fußgänger). Diese Datei stellt nur den bewegten Fahrzeugteil einer Karte dar.
• unsched_trafficdens.txt
  Legt nach Wochentagen und Tageszeit gestaffelt die Verkehrsdichte von fahrplanungebundenen Fahrzeugen fest. Für jede Gruppe kann dies extra definiert werden.
• unsched_vehgroups.txt
  Legt Gattungen für Gruppen fest. Dies erleichtert im OMSI-Editor die exklusive oder inklusive Zuweisung von Pfaden zu einer bestimmten Gruppe.

Für alle folgenden genannten Dateien gilt:

1.1.1. Fehlerdarstellung

Fehlerhafte Eintragungen äußern sich unterschiedlich:

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

Omsi kann die Karte nicht mehr laden. Es erscheint die Fehlermeldung, dass der letzte Speicherpunkt beschädigt ist, wenn ein Speicherpunkt geladen werden soll.
Wird eine neue Karte ohne Busse erstellt, hört Omsi beim Laden auf und kehrt zum Menü zurück.

• ailist.cfg
  

Für den Individualverkehr gibt Omsi die Fehlermeldung aus, das bestimmte Fahrzeuge nicht mehr geladen werden können oder nicht gefunden wurden. Ist ein Link für eine Busdatei fehlerhaft, dann gibt Omsi keine Fehlermeldung aus, bis der Bus aufgerufen wird. Meist läuft Omsi im Hintergrunf normal weiter, aber das Bild friert ein. Fehlermeldungen werden dann nur in der Logfile.txt eingetragen.

2. Aufbau der einzelnen Textdateien

2.1. Menschen in Omsi

Auch die Passanten und Passagiere zählen im weitesten Sinne zur KI.

Alle animierten Personen, werden in Omsi unter "Humans" aufgelistet. Die Objektdateien, Definitionsdateien und die Texturen befinden sich in OMSI\Humans. Die Datei humans.txt beinhaltet eine Liste mit Verweisen auf die Definitionsdateien (Dateiendung '.hum') der KI-Menschen. Dort werden pro Zeile ein Link zu einem KI-Menschen eingetragen. Ebenso verhält es sich mit der Datei drivers.txt. Die Häufigkeit von bestimmten Fußgängern kann durch Mehrfacheinträge erhöht werden.

Als Referenz können die Dateien von vorhandene Karten (z.B. Berlin-Spandau) genommen werden.

2.2. Busfahrer

Zu den Busfahrern (Driver) zählen nur die KI-Menschen, die Omsi auf den Fahrersitz in den Bussen und Fahrzeugen setzt (oder stellt), die dafür konfiguriert sind. Wie auch bei den Passanten, werden die Objektdateien, Definitionsdateien und Texturen, in dem Ordner "Humans" aufgelistet. Somit können alle Personen in Omsi, egal ob mit Busfahrerkleidung oder Zivilkleidung, als Passanten oder als Fahrer eingesetzt werden. Stellte man mehrere Menschen als Fahrer in die Fahrerliste, werden diese der Reihe nach auf alle Busse mit Fahrerplatz eingesetzt. Man kann nicht bestimmte Fahrer auf bestimmte Busse zuweisen. In den Mapordnern, werden die Fahrer in der Datei Drivers.txt aufgelistet.

2.3. Parkende Fahrzeuge

Hierfür sind die sogenannten Parklists zuständig. Wie bei den Fußgängern sind hier Verweise einzutragen. Dies sind statische Objekte (.sco) ohne Animationen, Lichtpunkte und Kennzeichen, die meist in ressourcenschonender Bauweise erstellt worden sind, um die Performance bei massenhaftem Einsatz (z. B. auf Parkplätzen) zu schonen. Fahrzeuge, die dies unterstützen, wechseln zudem dynamisch die Farbe. Man kann auch fahrbare Fahrzeuge einstellen, was allerdings zu Lasten der Performance geht. parkende Fahrzeuge erzeugen keine Lichtpunkte, auch wenn diese mit eingestellt werden. Kennzeichen können mit eingesetzt werden, allerdings wirkt es sich direkt negativ auf die Performance aus und es besteht die Möglichkeit, dass mehrere Fahrzeuge die gleichen Kennzeichen erhalten.

Es ist möglich, mehrere Parklisten zu verwenden. Hierbei bekommt die Standard-Parklist den Dateinamen parklist_p.txt, weiteren Listen wird ein Index nachgestellt, z.B. parklist_p_1.txt. Der Index wird dann als Beschriftung im OMSI-Editor der jeweiligen Park-Box eingetragen. Somit können bestimmte Fahrzeugtypen in bestimmte Bereiche der Map gesetzt werden (Beispiel Autohäuser, Ostblockfahrzeuge, LKW, Busse, Bahnen, Parkplätze für Zulieferer oder firmeneigene Parkplätze). Um fahrbare Fahrzeuge als statische Fahrzeuge umzusetzen, genügt es, die Definitionsdateien zu kopieren und umzubennen. Hierbei werden alle Einträge für das Kennzeichen, Lichtpunkte und alle Animationen entfernt. Hierbei sollte aber die Anzahl der Polygone beachtet werden.
Auch hier wird die Häufigkeit per Mehrfacheintrag gesteuert, vorhandene Karten (z.B. Berlin-Spandau) können ebenfalls als Referenz herangezogen werden. Hier gibt es eine zusätzliche Park-Liste für den Ost-Teil (Land Brandenburg) mit Trabanten.

2.4. Kennzeichen für KI-Fahrzeuge

In der Datei registrations.txt werden alle nutzbaren Kennzeichen für eine Karte eingetragen. Es ist möglich, Kennzeichen einer Region (Stadt, Landkreis) einzutragen oder auch für mehrere Regionen. Sinnvoll ist eine große Anzahl von ortsbezogenen Kennzeichen, eine mittlere Anzahl von benachbarten Regionen und eine geringe Zahl von entfernten Regionen. Alle Kennzeichen werden der Reihe nach in die Registrationsdatei eingetragen, wobei in jeder Zeile nur ein Kennzeichen stehen darf. Die Reihenfolge ist abhängig vom gewünschten Erscheinen. Omsi weißt jedem Fahrzeug ein Kennzeichen zu, wenn die Fahrzeuge mit einem erstellbares Kennzeichen ausgestattet (Texttexturen) wurden. Die Reihenfolge aus der Registrationsdatei wird dabei jedem Fahrzeug in der Reihenfolge des Erscheinens auf der Karte vergeben, nicht erst in Sichtweite des Spielers. Sinnvoll ist eine sich wiederholende, gemischte Reihenfolge der Eintragungen.

Als Beispiel für Berlin:

• 25 Kennzeichen für die Stadt Berlin
• 15 Kennzeichen für direkt angrenzende Landkreise und Städte (Barnim, Oranienburg, Bernau, Erkner, Königs Wusterhausen, Potzdam, Havelland, Nauen usw)
• 7 Kennzeichen für weiter entfernte Landkreise und Städte (Landkreis Oberspree, Straußberg, Magdeburg uvm)
• 3 Kennzeichen für andere Regionen (aus Bayern, Hamburg, Köln, Aachen, Dresden usw)

Diese Reihenfolge (hier 50 Kennzeichen) wird dann mehrfach wiederholt (10 mal ergeben dann 500 Kennzeichen), wobei sich die Kennzeichen ändern. Je größer die Anzahl der Kennzeichen ist, desdo seltener erscheinen diese Kennzeichen. Wurden alle eingetragenen Kennzeichen vergeben, dann bezieht Omsi die neuen Kennzeichen wieder von oben, aus der Liste.

3. Beweglicher Verkehr

In Omsi gibt es eine Ai-Liste in der alle beweglichen Fahrzeuge eingetragen werden. Weitere Textdateien, wie die unsched_trafficdens.txt und die unsched_vehgroups.txt, sind dann für die zeitliche Zuweisungen oder die punktuelle Pfadzuweisung gedacht.

3.1. Allgemeines zur AI-Liste

Der KI-Verkehr wird vom Mapbauer anhand Konfigurationsdateien einer Karte eingestellt. Der Verkehr variiert also von Karte zu Karte (z. B. gibt es andere Busse, Autos der heutigen Zeit, andere Repaints oder eine differenzierte Verkehrsdichte). Entscheidend dafür ist eine logische Kategorisierung der Fahrzeuge in sogenannte Gruppen, die getrennt voneinander behandelt werden. Möglich wäre z.B. Folgendes:

• PKW (in vorhandenen Karten oftmals mit NormalCars bezeichnet)
• Gewerbe-Fahrzeuge (PKW und Sprinter mit Werbe- und Firmen-Aufklebern, in vorhandenen Karten oft mit Commercials bezeichnet)
• LKW (diese dürfen evtl. nicht immer (Sonntagsfahrverbot) oder überall (Anliegerstraße, Beschränkung von Breite, Höhe, Länge, Gewicht, etc.) fahren)
• PKW mit Sonderrechten (z.B. Taxen und Elektroautos, die vielerorts auch auf Busspuren fahren dürfen)
• Andere Fahrzeuge mit behördlichen Sonderrechten (Polizei, Feuerwehr, etc.)
• Linienfahrzeuge, diese können ggf. noch weiter unterteilt werden:
  • Eindecker und Doppeldecker
  • Solo-Fahrzeuge und Fahrzeuge mit Gelenk oder Doppelgelenkbusse
  • Kleine Fahrzeuge und große Fahrzeuge
  • Ein- und Doppeldecker
  • ältere und moderne Fahrzeuge
  • Straßenbahnen
  • Züge

• Wasserfahrzeuge (u.a. Boote, Schiffe)
• Luftfahrzeuge (Hubschrauber, Flugzeuge, etc.)

Diese Anordnung in Gruppen ist grundsätzlich karten-spezifisch und muss nicht immer gleich sein. Ggf. gibt es bei Karten, die außerhalb Deutschlands spielen, weitere Regelungen, die umzusetzen sind. Die Aufteilung der verschiedenen Fahrzeuge in Gruppen, ist notwendig, um Fahrzeugtypen bestimmte Bereiche von Karten, Zeiten, Straßen oder Fahrspuren zugänglich zu machen.

Die Besonderheit dieser Datei ist die Art der Datei und der damit verbundene Aufbau, aber auch die vielfältigen Möglichkeiten. Die Ai-Liste ist keine Textdatei, sondern eine Konfigurationsdatei. Es werden also nicht nur einfach die Dateipfade zu den Fahrzeugen eingetragen, sondern zusätzlich auch weitere Steuerungsmöglichkeiten, wie Häufigkeiten, Einsatzdaten oder Repaints. Zudem kann mit dieser Datei auch der chronologische Einsatz gesteuert werden, wenn man mehrere Gruppen unterteilt.

Zusammen mit den Einstellmöglichkeiten im Editor, ist der Arbeitsaufwand sehr zeitintensiv, wenn man alle vorhandenen Möglichkeiten ausschöpfen möchte. Aber der Aufwand lohnt sich, wenn man eine Map realitätsnah darstellen möchte.

3.2. Aufbau der AI-Liste

In der Ai-Liste werden alle fahrbaren Fahrzeuge einer Karte eingetragen und in Gruppen aufgeteilt. Der Aufbau wiederholt sich stellenweise, je nach Art der Fahrzeuge ob Individualverkehr oder fahrplanbezogener Verkehr. Omsi unterscheidet nur diese beiden Gruppen. Der Individualverkehr wird je nach Häufigkeit zufällig eingesetzt und fährt stur die Pfade ab, die vorgegeben wurden. Hierzu zählen alle Fahrzeuge, die keinem festgelegten Fahrplan folgen sollen oder müssen. Dazu gehören alle PKWs, LKWs, Reisebusse, Luftfahrzeuge, Sonderfahrzeuge oder Wasserfahrzeuge.

Es gibt zwei grundlegende Darstellungen für den Aufbau. Zum Einen gibt es den Aufbau für den Individualverkehr. Dieser enthält folgende Eigenschaften:

• Name der Gruppe zur Identifizierung in anderen KI-Dateien und im Karten-Editor
• Name (nicht Dateiname, sondern Anzeigename!) der .hof-Datei falls vorhanden, ansonsten leer lassen
• Pro Fahrzeug: Pfad zur .bus- oder .ovh-Datei des Fahrzeugs oder .zug-Datei, falls es sich um ein Gespann handelt und optionale Angabe eines Häufigkeitsfaktors, per Tabulator abgetrennt vom Pfad.
• Abgeschlossen wird die Gruppe mit einem [end]-Befehl, worauf andere Gruppen folgen können.

Zum Anderen werden fahrplangesteuerte Fahrzeuge weiter unterteilt, wie Hofzugehörigkeit, Einsatzzeitraum, Kennzeichen und Repaints. Zudem werden diese Fahrzeuggruppen einer Hofdatei zugewiesen. Diese einzelnen Punkte werden im nachfolgenden Abschnitt erklärt.

Gruppen werden in der Datei ailists.cfg mit folgenden Schlüsselwörtern definiert:

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

Die Reihenfolge der Gruppen ist unerheblich. Nach allgemeiner Konvention ist die Gruppe von PKW die erste, es folgen Sonderrechte und LKW und am Schluss die Gruppen mit der Kennzeichnung _depot.

3.2.1. Fahrplanfreier Verkehr

Zuerst folgt der allgemeine Aufbau, für den Individualverkehr.
Jede einzelne Gruppe wird mit einem Eintrag versehen. In der Gruppen können dann mehrere gleichartige Fahrzeuge zusammen gefasst werden. Die Reihenfolge der Gruppen oder die Reihenfolger der Dateipfade ist dabei unerheblich.

Allgemeiner Aufbau:

Hiernach werden alle folgenden Gruppen, nach dem selben Aufbau eingetragen.

Der Häufigkeitsfaktor gibt an, wie oft ein bestimmtes Fahrzeug im Verhältnis zu allen anderen Fahrzeugen einer Gruppe auf der Karte erscheint. Der Faktor (Operand einer Multiplikation) wird im Verhältnis aller Fahrzeuge zu 100% errechnet. Die dem Fahrzeug zugewiesenen Repaints, werden dann zufallsgesteuert verwendet. Somit ist es möglich, bestimmte Fahrzeuge (Beispiel US-Cars, historische Fahrzeuge, Behördenfahrzeuge ohne Sonderrechte oder andere seltene Fahrzeuge mit geringer Stückzahl) seltener auf den Karten erscheinen zu lassen, als moderne und aktuelle Fahrzeugmodelle.

Zu Beachten:

• Der Häufigkeitfaktor muß immer mittels Tabulator vom Link zur Fahrzeugdatei getrennt werden, wenn ein solcher Faktor eingetragen wird. Andernfalls zählt der Link als falsch. Der Faktor kann ganze Zahlen enthalten oder Zahlen mit Kommastelle (0.3), die als Punkt geschrieben wird.
• Es können mehrere Gruppennamen definiert werden, die dann unterschiedliche Fahrzeuge enthalten. Somit kann man auf einer Karte unterschiedliche Fahrzeuggruppen einsetzen, die sich im Zeitrahmen ändern. Mit der Chronologiefunktion, wird dann jedem Zeitrahmen, eine Gruppe zugewiesen.
• Es gibt keine Grenze, wie viele Dateipfade, in die Liste eingetragen werden. Eine hohe Anzahl an unterschiedlichen Fahrzeugen bewirkt mehr Abwechslung des gesehenen Verkehrs, aber wirkt direkt negativ auf die Performance der Karte (Abhängig vom Polycount der Fahrzeuge).
• Es können auch Busse eingesetzt werden, die sich dann ohne Fahrplan auf der Karte bewegen (z.B. Reisebusse). Diese Busse zählen dann zum allgemeinen KI-Verkehr. Der Einsatz von Reisebusse, sollte gut überlegt sein, da diese Busse überall dort fahren, wo auch die anderen PKWs unterwegs sind (kleine enge Seitenstraßen). Zudem muß auch der hohe Polycount der Busse beachtet werden, wenn es sich um fahrbare Busse handelt.
• Es können auch Gruppen eingetragen werden, die nur Busse beinhalten. Dann können diese Gruppen auf bestimmte Pfade gesetzt werden.

Fahrplangebundene Fahrzeuge benötigen keinen Häufigkeitsfaktor, das die Häufigkeit über den Fahrplan gestaltet wird.

Beispiele für Gruppen:

Es können beliebig viele Gruppen erstellt werden. Die Gruppennamen sind dabei frei wählbar. Werden eigene Gruppennamen, als die vorgegebenen verwendet, so kann diese Ai-List nicht auf anderen Karten eingesetzt werden, wenn diese Gruppennamen nicht im Editor den Pfaden (Laufwege) zugewiesen wurden.

Je mehr Gruppen für die Fahrzeuge erstellt werden, desdo differenzierter kann man die Fahrzeugklassen an die Pfade anpassen. Es sollte zuerst die AI-List erstellt werden, damit man später im Editor, die Fahrzeuggruppen den einzelnen Pfaden zuordnen kann.

3.2.2. Fahrplangebundener Verkehr

Der fahrplangebundene Verkehr wird, wie der Name schon sagt, mittels Fahrpläne gesteuert. Es ist also nicht erforderlich, einen Häufigkeitsfaktor einzustellen, da im Fahrplan eine Häufigkeit nach Takt vorgegeben wird. Außerdem kann dieser Verkehr auch Punkte (Haltestellen) anfahren. Sinnvoll ist dies, wenn bestimmte Fahrzeuge einen festgelegten Kurs folgen und an bestimmten Punkten anhalten soll. Dies bestrifft nicht allein die Liniengebundenen Busse, sondern auch andere Fahrzeuge, wie Müllabfuhr, Paketdienste oder Zulieferfahrzeuge. Hier werden die Haltestellenwürfel aus dem Editor als Haltepunkte verwendet, wobei bei anderen Fahrzeuge, die keine Personenbeförderungen durchführen, keine Personen eingestellt werden.

Zudem kann man in der AI-Liste alle fahrplangebundenen Fahrzeugen, Kennzeichen, Repaints und Linienanzeigen zuweisen und auch das zeitliche Erscheinen steuern, je nach Datum. In den Fahrplänen wird die Häufigkeit des Erscheinens auf der Karte gesteuert und der feste Weg vorgegeben.

Die Erstellung der AI-Liste, wird hier anhand von Bussen erklärt, gilt aber genauso für alle anderen fahrplangebundene Fahrzeuge gleichermaßen. So kann man an bestimmten Tagen, bestimmte Müllfahrzeuge fahren lassen oder bestimmte LKWs mit Werbung zu festgelegten Punkten fahren lassen. Somit fährt ein Möbelwagen auch zum Möbelhaus, statt zum Discounter.

Wurde im oben genannten Befehl lediglich der Fahrzeugtyp bzw. die Fahrzeugdatei angegeben, gibt es die Möglichkeit, detailliert jedes Fahrzeug einzeln zu definieren. Dies ist der empfohlene Weg für Betriebshöfe mit Bussen, die ein festes Repaint und Kennzeichen tragen. Genauso kann man damit bestimmte Betriebshöfe auch bestimmte Fahrzeugtypen zuweisen oder verschiedene Hofdateien, die nicht alle Kartenziele besitzen.

Auf einen Befehl [aigroup_depot], gefolgt von Name und .hof-Datei (ohne End-Befehl!) folgen ein oder mehrere [aigroup_depot_typgroup_2]-Einträge. Dieser besteht wiederum aus einem Verweis zur .bus- (bevorzugt) oder .ovh-Datei, gefolgt von einer Liste mit folgenden Eigenschaften (getrennt durch Tabulatoren, pro Zeile ein Fahrzeug):

• Wagennummer
• Kennzeichen - falls nicht definiert, wird ein dynamisches Kennzeichen (je nach festgelegter Präferenz aus der Registrierungs-Datei des Fahrzeugs) gewählt.
• Repaint-Anzeigename (nicht Dateiname!) - falls nicht definiert, wird das Standard-Repaint ausgewählt.
• Startdatum (inkl.), ab dem dieses Fahrzeug auf der Karte unterwegs sein kann.
• Enddatum (inkl.), ab dem dieses Fahrzeug außer Dienst gestellt ist und nicht mehr auf einer Karte erscheinen soll.

Auch hier wird die Liste mit [end] abgeschlossen. Alle Eigenschaften sind dabei optional; wichtig ist lediglich die Trennung durch Tabs. Mehrere Tabulatoren hintereinander überspringen Einträge.

Beim Aufbau folgt zuerst der Befehl [aigroup_depot], womit alle folgenden Fahrzeugeintröäge einer Gruppe (Betriebshof oder Linie) zugewiesen werden. Dieser Befehl gilt solange, bis dieser, duch eine Wiederholung geändert wird, womit dann alle folgenden Fahrzeugtypen der neuen Gruppe zugewiesen werden.

Allgemeiner Aufbau

Erklärungen:

Zunächst wird eine Wagennummer zugewiesen. Sofern ein Bus /Fahrzeug regenerative Wagennummern anzeigen kann, werden diese auch angezeigt. Omsi nutzt diese Nummer zur Indentifikation eines bestimmten Fahrzeugs, damit das selbe Fahrzeuge bei einem Umlauf immer wieder gleich erscheint. Eine Wagennummer muß also immer eingetragen werden.

Das Kennzeichen ist optional. Omsi erstellt ein Kennzeichen anhand der Vorgaben aus der .bus-Datei unter dem Vefehl [registration_automatic] und der hier vermerkten Wagennummer. Soll das Fahrzeug ein von der Wagennummer abweichendes Kennzeichen erhalten, kann dies hier eingetragen werden. Wird hier kein Kennzeichen vorgegeben, nutzt Omsi ein Kennzeichen aus der buseigenen Registrationsdatei.

Der Name des Repaints findet man in dem Texturunterordner "Repaints" oder "Werbung". Es kann in jeder Modeldatei immer nur ein Unterordner zugewiesen werden, indem sich die Repaints befinden können. Dort gibt es mindestens eine Textdatei (.cti) in der die Reapints zugewiesen sind. Diese werden wie folgte eingetragen:

Direkt unter dem Befehl [item] steht der Name für das entsprechende Repaint. Dieser Name wird dann zur Zuweisung, auch in der Ai-List eingetragen. Wird kein Repaints zugewiesen, nutzt Omsi das Standardrepaint. Der Name des Standardrepaints ist in der BUS-Datei eingetragen.

Die Startzeit legt fest, ab welchen Datum ein Fahrzeug/Repaint/Wagennummer auf der Karte verkehren darf. Somit kann auf einer Map festgelegt werden, dass ein bestimmter Bus, erst ab dem Herstellungsdatum / Beschaffungsdatum in den Umlauf kommt. Zusammen mit den Repainteinträgen, kann ein Bus (wenn dies umgesetzt wurde) mit Hilfe des Befehls [setvar] zu DDR-Zeiten mit einer Zahlbox, aber Juni 1990 mit Kasse und D-Mark und ab 2002 mit Eurokasse auszurüstet werden. Wie schon erwähnt, kann ein Bus mit einer bestimmten Wagennummer auch mit einem zeitlichen Repaintwechsel ausgestattet werden.

Die Endzeit legt dann fest, bis wann ein bestimmtes Repaint im Umlauf sein darf.

Die Daten werden in vollständigen Datenzahlen ohne Trennungszeichen eingegeben. Hierbei gilt nur das Format JahrMonatTag. Somit würde ein Eintrag für einen zeitlichen Farbwechsel in der Ai-Liste wie folgt aussehen:

Diese Einträge würden bedeuten, dass der Bus auf einer Map erst nach dem 9.November 86 auf der Map zu sehen ist und bis zum 31.Mai 1990 ohne Werbung und mit DDR-Kennzeichen fährt. Aber dem 1.Juni 1990 verkehrt der Bus mit der Omsi-Werbung und einem veränderten Kennzeichen. Ab dem 1.Januar 2002 hat der Bus dann ein Reapint der WebDisk und ein neues Kennzeichen..

3.3. Verkehrsdichte und zeitliches Verkehrsaufkommen

Wie bereits im Abschnitt "fahrplanfreier Verkehr" beschrieben, kann man in Omsi 2 den Straßenverkehr zeitlich steuern. Mit Hilfe der Gruppennamen ist es möglich, bestimmte Fahrzeugtypen nur auf bestimmten Straßen festzulegen. Zudem gibt es auch die Möglichkeit bestimmte Fahrzeuge auch zeitlich zu steuern. Mit der Chronologiefunktion kann man bestimmte Fahrzeuggruppen, ab einem bestimmten Datum fahren oder verschwinden lassen. Außerdem kann man das Verkehrsaufkommen in Omsi steuern.

In den Optionen von Omsi 2 kann man die Verkehrsdichte global für alle Fahrzeuge festlegen. Die eingestellte Verkehrsdichte gilt für alle, in der AI-Liste eingetragenen Fahrzeuge und Gruppen gleichermaßen, je nach eingestelltem Häufigkeitsfaktor. Es wird also global die 100% des Verkehrsaufkommens festgelegt. Es ist aber auch möglich, das Verkehrsaufkommen für bestimmte Fahrzeuggruppen zeitlich festzulegen. Hierbei bietet Omsi einen einfachen Weg, die Verkehrsdichte der Fahrzeuggruppen zu bestimmten Tageszeiten oder an bestimmten Wochentagen zu verstärken, zu verringern oder ganz auszuschließen. Im Editor wird lediglich festgelegt, auf welchen Pfaden, bestimmte Fahrzeuggruppen wandeln dürfen. Mit den beiden zusätzlichen Dateien [unsched_trafficdens.txt] und [unsched_vehgroups.txt], ist es möglich, an bestimmten Wochentagen, einen Berufs-, Nacht-, Wochenend-, sowie Feiertagsverkehr zu realisieren aber auch ein zeitliches Fahrverbot (Wochenendfahrverbot, Nachtfahrverbot) umzusetzen.

3.3.1. unsched_vehgroups.txt

Dies ist die einfachste Datei. Hier wird festgelegt, dass die eingetragenen Fahrzueggruppe seperat behandelt werden sollen und ob diese von Anfang an fahren sollen oder ob die entsprechenden Pfade der Splines erst freigeschaltet werden müssen.

Der Befehl [group] hat nur zwei Strings, die Ausgelesen werden können. Weitere Einträge darunter, werden von Omsi nicht beachtet. Daher muß dieser Befehl nicht mit einen [end] geschlossen werden. Es gibt auch nur die beiden Möglichkeiten der Eintragungen von Ziffern:

• 0 = Darf nicht fahren, Pfade müssen für diese Gruppe freigeschaltet werden.
• 1 = Darf frei fahren, Gruppe hat normale Verkehrsdichte
  

Hier werden alle Gruppe nacheinander einzeln eingetragen, wobei natürlich nur die fahrplanfreien Gruppe eingetragen werden. Nicht vorhandene Gruppen oder fahrplangebundene Gruppen, werden als Fehler erkannt.

3.3.2. unsched_trafficdens.txt

Nachdem die Gruppen, als einzelne Gruppierungen festgelegt wurden, folgt nun die Einstellung der Verkehrsdicht, für jede Gruppe, entsprechend den Uhrzeiten und Wochentagen.

Hierfür gibt es mehrere Befehle, mit genau festgelegter Stringanzahl wird nicht mit [end] geschlossen. Diese Befehle lauten:

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

So läßt sich die Verkehrsdichte für jede Gruppe, Minutengenau festlegen. Möchte man in bestimmten Mapbereichen, eine Fahrzeuggruppe öfter erscheinen lassen, als in anderen Bereichen, muß man die selben Fahrzeuge einer Gruppe, noch einmal unter einen neuen Gruppennamen eintragen. Somit kann man beispielsweise Sonereinsatzfahrzeuge bei Events (Feste, Weihnachtsmärkte, Demos) öfter erscheinen lassen, als auf dem Rest der Karte, oder man kann LKWs in Industriegebiete häufiger fahren lassen.

Der Grundaufbau wiederholt sich dabei immer wieder. Man benennt eine Gruppe, weißt dieser die Wochentage zu und legt das Verkehrsaufkommen, für diese Gruppe, nach den Tageszeiten fest.

Der Aufbau sieht wie folgt aus:

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

Die Befehle sind schnell erklärt:

Der Befehl [group], sollte klar sein. Der folgende Befehl [set_day_of_week] bezieht sich, wie der Name schon sagt, auf die einzelnen Wochentage. Hier ist Omsi relativ flexibel. Bei den Wochentagen erkennt Omsi keine Feiertage, die innerhalb seiner Woche liegen. Zudem unterscheidet Omsi die Wochentage von Montag bis Freitag, nicht voneinander. Die Wochentage werden mit Zahlen angegeben, wobei die Addition der einzelnen Werte, die Tage erfaßt:

Es gibt insgesamt folgende Möglichkeiten:

• 0 = Alle Tage
• 1 = Montag-Freitag
• 2 = Samstag
• 3 = Montag-Samstag (1+2)
• 4 = Sonntag
• 5 = Montag-Freitag+Sonntag (1+4)
• 6 = Samstag+Sonntag (2+4)

Als letztes, erscheint der Befehl [trafficdensity], der nun festlegt, ab wann die eingetragene Verkehrsdichte geändert werden soll. In der Textdatei sieht es nun wie folgt aus:

Die Eintragungen für den Befehl [trafficdensity] erscheinen auf den ersten Blick seltsam zu sein. Omsi kann mit Uhrzeiten oder bestimmten Wertangaben nichts anfangen. Omsi berechnet die Tagesuhrzeit für jeden Tag einzeln, wobei es um Mitternacht (0:00 Uhr) anfängt, die einzelnen Sekunden zu zählen. Bis 23:59:59 Uhr zählt Omsi dann bis 86400 Sekunden und beginnt dann von vorn. Hier wird die Uhrzeit anders dargestellt. Jede Stunde hat den Wert 1. Somit unterteilt sich eine Stunde in 1000 Einheiten. Der maximale Wert liegt dann bei 24.000. Die Werte dazwischen stehen dann für die geteilte Stunde.

Der Wert 8.250 entspricht 08:15 Uhr,

12.500 enstpricht 12:30 Uhr und

17:750 entspricht 17:45 Uhr.

Auch für die prozentualen Werte des Verkehrsaufkommen, muß der Wert umgestellt werden. Hierbei ist der Wert 0.000 gleich 0% und der Wert 1.000, steht dann für 100%. Allerdings ist für Omsi, die 100% nicht die maximale Obergenze. Dieser Wert steht für das normale Verkehrsaufkommen. Wenn am Tage ein normales Verkehrsaufkommen herrschen soll, dann hat man in den Nachtstunden ein stark verringertes Verkehrsaufkommen, dass im Laufe der frühen Morgenstunden, bis zum Berufsverkehr zunimmt. Im Berufsverkehr hat man ein stark erhöhtes Verkehrsaufkommen, was im Laufe des Vormittag abnimmt und sich wieder zum normalen Verkehrsaufkommen verringert. Am Nachmittag nimmt der Verkehr wieder zu wobei der zweite Berufsverkehr nicht ganz so hoch wird wie am Vormittag, aber dafür länger dauert. Nach dem Berufsverkehr, nimmt die Verkehrsdichte langsam ab und einige Gruppen fallen dann raus (LKWs, Lieferwagen, etc.)

Es werden immer nur die Zeiten eingetragen, wann die Änderungen beginnen. Diese gelten dann solange, bis durch eine weitere Zeitangabe, die Verkehrsdichte für diese Gruppe geändert wird. Folgen keine weiteren zeitlichen Einträge, gilt die Verkehrsdichte bis Mitternacht. In dem vorliegenden Beispiel, nimmt ab Mitternacht die Verkehrsdichte ab, bis dann langsam Ruhe einkehrt und nur wenige Nachtschwärmer unterwegs sind. Der Normale Verkehr nimmt dann ab. Hier kann man dann mehr Taxis fahren lassen. Beim morgentlichen Berufsverkehr nimmt die Verkehrsdichte langsam zu, und auch wieder langsam ab. Vormittag folgt dann wieder der Verkehr in einer normalen Verkehrsdichte.

So kann man im Berufsverkehr Staus bilden und Außerhalb den Verkehr wieder normalisieren. Zum Feierabendverkehr nimmt der Verkehr langsam wieder zu und anschließend wieder ab. Bis Mitternacht nimmt der Verkehr dann weiterhin ab.

Der Arbeitsaufwand erhöht sich für jede weitere Gruppe. Je mehr Gruppen man einstellt und umso mehr man den Verkehr langsam zunehmen möchte, desdo höher wird der Arbeitsaufwand. Dieser lohnt sich aber, weil die Verkehrsdichte sich damit dynamisch verändert.

4. Weitere Tips und Hinweise

Wie schon geschrieben, kann man bei den Personen in Omsi, nicht all zuviel machen. Auf bestimmten Buslinien kann man keine Kinder oder nur alte Leute einsetzen. Auch auf den Straßen, kann man eine bestimmte Personengruppe nicht öfter oder Ortsbezogen gezielter einsetzen (Altenheime, Spielplätze, Schulen). Das geht leider nur beim KI-Verkehr. Der Arbeitsaufwand steigert sich, je individueller man den Verkehr oder bestimmte Fahrzeuggruppen steuern möchte. So könnte man mehr Krankenwagen oder RTWs in Krankenhausnähe fahren lassen oder mehr Feuerwehrfahrzeuge in der Nähe einer Feuerwache. Hier muß man für sich festlegen, ob sich der Aufwand lohnt oder nicht. In Payware-Projekten würde es sich lohnen, allerdings betreibt kaum jemand solch gezielten Aufwand. Omsi bietet zwar sehr viele Möglichkeiten, die aber in Payware-Projekten nicht ausgenutzt werden. Es geht nicht um Qualität, sondern ums Geld.

Besonders beim Steuern der zeitlichen Verkehrsdichte, spart man am falschen Ende. Der Verkehr nimmt mit der Zeit zu. Omsi regelt das so, dass die Vorgaben schnell umgesetzt werden. Wenn man wenige Zeiten setzt, kann es vorkommen, dass man von einer wenig befahrenen Hauptstraße auf eine andere Straße in den Stau kommt (Beispiel: Berlin X10, Hamburg Tag & Nacht).