Fahrzeuge in Omsi - Ordnerstruktur

Ein Bus in Omsi besteht aus mehreren Dateien. Die unterschiedlichen Dateien sind notwendig, da diese verschiedene Aufgaben haben. In diesem Tutorial soll es darum gehen, was für Dateien notwendig sind und wofür diese Dateien genutzt werden. Bitte beachtet dazu auch den Abschnitt: Dateiformate in OMSI. Das selbe gilt auch für alle KI-Fahrzeuge. Für reine KI-Fahrzeuge, die nicht vom Spieler gesteuert werden sollen, ist der Umfang stark begrenzt und nur auf das Wesentliche bezogen.

1. Allgemeine Grundlagen

Im Grunde bestehen alle Objekte in Omsi aus mehreren Dateien. Zusammen ergeben diese die in Omsi sichtbaren Objekte. Dazu gehören auch Busse, Straßenbahnen, Züge und die Fahrzeuge des Individualverkehrs. In diesem Tutorial beziehe ich mich auf einen Bus. Diese trifft auch für alle anderen Objekte zu, wenn teilweise auch nicht so umfangreich.

Die Dateiarten für Fahrzeuge in Omsi sind:

• 3D-Objektdateien
• Bilddateien (Texturen genannt)
• Audiodateien (nur Fahrzeuggeräuche)
• Textdateien

Diese unterschiedlichen Dateiarten sind in verschiedenen Unterordnern zu finden, was lediglich der Übersciht dient. Ausgehend vom Hauptordner von Omsi, befinden sich alle Fahrzeuge im Unterordner "Vehicles". Die in diesem Ordner enthaltenen Unterordner sind neben dem zentralen Ordner für Ansagen (Announcements für Audiodateien) und dem zentralen Ordner für Schildtexturen (Anzeigen für Texturdateien), die Fahrzeuge für den KI-Verkehr (PKW, LKW, Straßenbahnen, Züge) und die für den Spieler fahrbaren Busse. Der Anzeigename der Busse in Omsi (Fahrzeugauswahl) hat nichts mit den Namen des jeweiligen Fahrzeug-Unterordners zu tun und kann daher abweichen.

Ferner werden für die im oder am Bus benutzten Zeichensätze, wie Kennzeichenschrift, Anzeigeschriften oder ähnliches, noch Fonts, also Schriftarten benötigt. Diese befinden sich aber nicht in einem Busordner, sondern werden zentral im Omsi-Ordner unter Fonts eingestellt.

1.1. 3D-Objektdateien

Jeder Bus besteht aus 3D-Objekten. Diese 3D-Objekte sind die Objekte, die dann im Spiel dargestellt werden. Zusammen mit den Bilddateien ergeben diese dann, die in Omsi sichtbaren Objekte. Diese 3D-Objekte werden mithilfe eines 3D-Programms erstellt.

''3D-Programme''

• Blender
• SketchUp {Make oder Free/Pro}
• zModeler
• autoCAD
• Sweet Home 3D
• Autodesk Maya

und viele andere mehr

Einige dieser 3D-Programme sind kostenfrei, während andere kostenpflichtig sind. Auch ist die Bedienung für Anfänger recht schwer. Für viele dieser Programme gibt es aber im Internet viele Tutorials. Auch der Funktionsumfang ist sehr unterschiedlich.

Ein 3D-Objekt besteht aus einem oder mehreren Polygonen. Ein Polygon ist eine dreieckige Fläche. An jeder Ecke ist ein Vertices. Zwischen den drei Vertices eines Polygone's, verlaufen die Kanten, die den direkten und kpürzesten Weg darstellen und nicht gebogen werden können. Mehrere Ecken von mehreren Polygonen können ein Vertices zusammen haben. Mehrere Polygone ergeben dann ein komplexes 3D-Objekt. Dies wird in Omsi als Objektdatei verwendet. In der Datei stehen dann die Lage und Position des Objektes ansich, Lage und Position der einzelnen Polygone und deren Vertices, die verwendeten Texturnamen der Bilddateien, Größe und die Position des Objektursprungs zum 3D-Objekt.

So besteht ein einfacher Würfel mit 6 Flächen, immer aus mindestens 12 Polygonen. Ein Polygone ist generell nur von einer Seite sichtbar, wenn man nicht mit einer transparenten Textur arbeitet. Soll ein 3D-Objekt etwas rundlicher werden, muß man mehrere Polygone benutzen.

Im Spiel kann ein Fahrzeug, aus einem 3D-Objekt bestehen (parkendes Fahrzeug) oder aus mehreren Objekten zusammen. Ein Fahrzeug kann aus einem 3D-Objekt bestehen, wobei dieses Fahrzeug dann keine rotierenden und verschiebaren Teile haben kann. Jedes 3D-Objekt was sich im Verhältnis zum Haupotobjekt bewegen soll (Animation), muß als seperates Objekt eingebunden werden. So besteht ein KI-Fahrzeug, immer aus mindestens 5 einzelnen 3D-Objekten, wie dem Fahrzeugkörper und den 4 einzelnen Rädern. Sollen an einem Fahrzeug weitere Teile durch eine Animation ihre Form und Aussehen verändern (Bsp. Verdeck eines Cabrios, Dachluke, Türen, Klappen oder Hauben, Dachaufbauten), so müßen diese Objekte auch als eigene 3D-Objekte erstellt werden. Die dazugehörigen Animationen werden in den unterschiedlichen Textdateien eingetragen.

In einem 3D-Programm werden den Objekten die Texturen (Bilddateien) zugewiesen. Diese Zuweisung nennt man mappen.

1.2. Texturen

Texturen sind Bilddateien auf denen sich Bilder befinden, die auf den Oberflächen der Polygone gemappt werden. Auf einer Textur können sich mehrere Flächen für ein Objekt oder auch für mehrere Objekte befinden. Genauso kann man aber auch mehrere Texturen für ein Objekt nutzen.

Texturen sollten immer im Format einer Achterpotenz vorliegen. Das heißt das die Kantenlänge in den Pixelanzahlen 2^n liegen sollten (1, 2, 4, 8, 16, 32, 64, 128, 256, 512 und 1024 Pixel). Die Bildausschnitte sollten gegenüber dem Objekt nicht zu klein sein, da die Textur sonst zu piexelig auf dem Objekt ist. Das gilt nicht, wenn ein Objekt unifarbig sein soll, also einfarbig. Dann ist auch das Format 1x1 Pixel ausreichend. Für Omsi sollten die Bildformate auch nicht zu groß sein. Besonder Texturgrößen über 1024 Pixel belasten das System für Omsi. Da Omsi nur ein 32bit Programm ist, können nicht zu große Texturformate genutzt werden.

Mit Texturen kann man Objekte plastischer aussehen lassen. Besonders bei einer polygonsparenden Bauweise von Objekten, kann man mit guten Texturen auf ebenen Flächen, 3D-Struktur-Effekte optisch simulieren. Dies geht aber nur bis zu einem bestimmten Grad. Flächen mit einer deutlichen Oberflächenstrukur, müßen ausmodelliert werden. Besonders Rundungen sollten ausmodelliert werden.

Da die Lichteffekte in Omsi nur begrenzt umsetzbar sind, können Texturen auch Lichteffekte oder Schatten enthalten, wobei Objekte dann in einem 3D-Objekt lebendiger wirken. Außerdem kann man auch Lichttexturen für Omsi erstellen, die dann mittels Script umgestellt werden können.

1.3. Audiodateien

Audiodateien sind Sounddateien, die dem Fahrzeug seine Geräuschkulisse geben. Da in Fahrzeugen keine Motoren eingebaut werden müßen, wird der Simulierte Motor mit Sounddateien hörbar gemacht. Dazu werden Sounds entweder einzeln aufgenommen und eingearbeitet, wobei Omsi dann wieder über das Script diese Sound abspielt. Oder es wird eine Soundaufnahme in viele kleine Soundschnipsel aufgesplittet. Omsi kann mehrere Sounddateien gleichzeitig abspielen. Somit können beim fahren, neben den Motorengeräusch auch Geräusche der Achsen, Getriebe, Reifenabrollgeräuche und viele weitere Geräusche abgespielt werden.

Zudem kann Omsi die Sounds auch einmalig abspielen, aber auch in Schleifen. Genauso kann man über das Script den Ursprung der Geräusche zum Spielersichtpunkt steuern, die Lautstärke und das ein - oder ausblenden von Geräuschen.

Sounddateien können in Mono und in Stereo vorliegen.

1.4. Textdateien

Alle anderen Dateien in einem Bus, sind eigentlich nur Textdateien und können mittels Texteditor geöffnet und bearbeitet werden. Diese Textdateien werden in mehrere Unterarten unterschieden. Der Unterschied dient dem Nutzer für die bessere Unterscheidung.

1.4.1. Busdatei

In einer Busdatei finden sich Einträge, wie den Namen des Busses (dieser Name erscheint dann im Auswahlmenü), den Ablageort (Pfad) zu den Sounddateien, Passagierdateien, Pfaddateien, Repaintunterordner, Registrierungsdateien, der Modeldatei sowie den Script- und weiteren Textdateien. Außerdem werden dort auch die Positionen der Fahrkarten festgelegt, Positionen des Spielers als Fahrer oder Passagier, Spiegeleinstellungen und grundlegende physikalische Daten zum Fahrzeug, wie dem Gewicht oder spezielle Daten zu den Achsen. Die Busdatei muß sich immer im Hauptordner des Busses befinden.

1.4.2. Hofdatei

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.

1.4.3. Registrierungsdateien

Registrierungsdateien sind Identifikationsdateien, die jedem Bus eine individuelle Unterscheidung geben. Hier stehen ganzen Kennzeichen oder nur die Wagennummern. Registrierungsdateien haben nichts mit der Registrierung eines Add-Ons für Omsi zu tun.

1.4.4. Modeldateien

Die Modeldatei ist die Schnittstellendatei zwischen Omsi und den einzelnen Objektdateien. Diese Datei wird allgemein nur als "model.cfg" bezeichnet. In der Modeldatei sind die einzelen 3D-Objekte verzeichnet sowie deren Spezifikationen für Omsi, wie den Texturwechsel zu Repainttexturen, Lichttexturen, LOD-Objekten, Sichtbarkeitseinstellungen, Animationen, Zugehörigkeiten zu anderen Objekten, Lichtpunkten, -schein, Glaseffekten, Unebenheiten, Spiegelungen, Schmutz- und Regentexturen und Klickpunkten.

Die Reihenfolge in der die Mesh in dieser Liste eingetragen werden, ist nicht unwichtig. Diese Reihenfolge bestimmt auch die Reihenfolge der Sichtbarkeiten durch andere Objekte. Diese Reihenfolge nennt man Renderreihenfolge, weil diese nach der Reihenfolge in der Modeldatei dargestellt werden. Außerdem ist die Reihenfolge auch wichtig, wenn es um eingetragene Objekte geht, die keine eigenen direkten Animationsbefehle bekommen können (Beispiel Lichtpunkte). Sollen also Lichtpunkte mit einen Objekt mitbewegt werden, müßen diese Lichtpunkte direkt unter dem animierten Objekt eingetragen werden. Stehen Lichtpunkte unter einem animierten Objekt, obwohl diese sich nicht mitbewegen sollen, müßen diese Lichtpunkte umgesetzt werden.

1.4.5. Passengercabin-Datei

In der Passengercabin stehen, die für den Innenraum geltenden Positionen für Sitzplätze, Stehplätze, Position der Kasse (Zahlgeld, Rückgeld, ausgegebene Fahrkarte), die Ein- und Ausgänge, die Entwerterposition, sowie die Position zum Übergang in einen anderen Fahrzeugteil (Beispielsweise dem Nachläufer). Außerdem wird hier auch die Position der Fahrerposition eingetragen. Bei den Sitzplätzen wird zu den einzelnen Positionen auch die Zuweisung zum Innenlicht gesetzt.

Die jeweiligen Ein- und Ausgänge werden mit den Nummern der Pfadpunkte angegeben. Mit dem Befehl [entry] wird ein Eingang angegeben. Welcher Pfadpunkt das ist, bestimmt die Poition der Pfadpunktes. Diese werden in der Pfaddatei eingetragen. Genauso verhält es sich auch bei den Ausgängen [exit]. Auch hier werden lediglich die entsprechenden Ausgänge der Pfadpunkte definiert.

1.4.6. Pfaddatei

Diese Datei {paths.cfg} arbeitet mit der Passengercabin-Datei direkt zusammen. In dieser Datei werden nur die Laufsounds der Passagiere eingetragen, die einzelnen Pfadpunkte und die Verbindungen der Pfadpunkte. Wichtig hierbei ist die eingetragene Reihenfolge der einzelnen Pfadpunkte. Die Reihenfolge ist Null-basiert. Hierbei kann man den ersten Punkt (Punkt 0) als Einstiegspunkt nutzen. Über weitere Pfadpunkte wird der Weg zur Kasse gelegt. Weitere Punkte werden Busspezifisch eingetragen. Beispielsweise vom 3. Punkt zum Entwerter, weiter durch den Bus zu den jeweiligen Sitz- und Stehplätzen und zum Ausgang, zu den Ausgängen.

Wichtig ist hierbei, mit den einzelnen Pfadpunkte nicht zu sparsam zu sein. Zu wenige Pfadpunkte im Bus, erzeugen den unschönen und unrealistischen Effekt, das Fahrkunden zum nächstmöglichen Pfadpunkt laufen, der ihrem gewählten Sitzplatz am nächsten ist. Ist der Abstand zwischen Pfadpunkt und Sitz- oder Stehplatz zu groß, dann "beamen" die Passagiere zu den Plätzen. Das heißt, man sieht im Spiegel die Person im Bus verschwinden. Wird die sitzende Passagierposition von anderen Objekten oder Passagieren verdeckt, sieht man diesen Passier nicht wieder auftauchen (siehe Busse aus Hamburg T&N, 3Generationen, Hamburg Hafencity oder Hamburger Buspaket). Werden viele Wegpunkte zu den Sitz- und Stehplätzen gesetzt, dann scheinen sich die Passagier sehr schnell hinzusetzen, bzw hin zustellen. Das selbe passiert dann auch wieder, wenn die Passagiere die Position verlassen um zu den Ausgängen zu laufen. Mit zu wenig Pfadpunkten, erscheinen dann die Fahrkunden plötzlich irgendwo im Bus.

Im letzten Teil dieser Datei, werden die einzelnen Pfadpunkte nacheinander zusammen gelegt. Es werden immer zwei Pfadpunkte zusammengesetzt (Beispiel 0-1, 1-2, 2-3, 4-5, 5-6, 6-7, 3-7, 7-8 usw). Außerdem wird hier festgelegt, ob es sich bei dieser Wegverbindung um eine "Einbahnstraße" handelt. Die Passagiere laufen dann immer den direkten Weg von einem Pfadpunkt zum nächsten. Daher müßen die Pfadpunkte immer um Objekte herum geführt werden.

1.4.7. Sounddatei

Die Sounddatei befindet sich meist im Unterorder Sound. In diesem werden die einzelnen Soundschnipsel und die Parameter der einzelnen Sounds vorgegeben, wie sich der Sound verhalten soll und mit welchen Variablen dieser ausgelöst werden soll. Diese Datei bekommt ebenfalls die Dateiendung cfg.

1.4.8. Script

Im Unterordner Script befinden sich meist nur normale Textdateien. Es gibt vier Arten von Textdateien, die sich in 2 Dateitypen unterscheiden.

• Scriptdateien (Dateiendung cfg)
• Variablenliste (Dateiendung txt)
• Konstanten (Dateiendung txt)
• Stringvariablenliste (Dateiendung txt)

Genau genommen benötigt ein Bus nur diese 4 Dateien.

• Script.cfg
• Variablen.txt
• Konstanten.txt
• Stringvariablen.txt

Man setzt aber mehrere dieser Dateien ein, damit man die Übersicht behält, wenn man Umbauten moddet oder Verbesserungen einbaut. Daher git es im Scriptunterordner mehrere Dateien die sich auf mehrere busspezifische Bereiche aufteilen (Bremsen, Motor, Strom, Türen, Cockpit, Kasse, Matrix, Kollisionen, Schmutz, Auspuff und viele andere). Die Dateinamen sind hierbei nicht festgelegt.

1.4.8.1. Scriptdateien

Scriptdateien sind eigentlich nur einfache Textdateien. Aber im Gegensatz zu den anderen Textdateien, werden hier Variablen und Stringvariablen ausgerechnet. Dabei werden die Zustände bestimmter Variablen ausgelesen und in Stackcontainern eingetragen. Je nach verwendetem Operator oder logischen Operationen, werden dann die Ergebnisse berechnet und gespeichert. Diese Ergebnisse werden in Omsi dann ausgelöst. Ist also der Zustand der Variable "lights_stand" gleich Eins, dann wird am Bus das Standlicht aktiviert. Stringvariablen enthalten bestimmte Buchstaben-, Zahlen- oder Zeichenfolgen und werden dann durch die Fonts dargestellt (Beispiel Uhrzeit {digitale Anzeige}, Temperaturen, Matrix, Haltestellenanzeige usw.).

Omsi stellt pro Sekunde eine bestimmte Anzahl an Bildern dar. Wieviele Bilder pro Sekunde dargestellt werden, erkennt man an der angezeigten Fremerate pro Sekunde im Spiel selbst. Also wenn die FPS 30 beträgt, dann werden gerade 30 Bilder pro Sekunden von Omsi dargestellt. Omsi liest die Scripte in jeder Fremerate einmal aus und berechnet diese. Somit werden bei 30 FPS, die Scripte 30 mal ausgelesen und berechnet.

Daher ist es wichtig, Scripte einfach zu halten. Unnütze Abfragen oder die ständig wiederholte Abfrage von Variablen kann die Performance stark belasten. Besonders wenn das Ergebniss immer das selbe ist, weil dieses Ergebniss in jeder Fremerate dann mehrmals überschrieben wird. Auch wenn es viele Möglichkeiten gibt, eine Berechnung zu erstellen, sollte man, soweit möglich, die Berechnungen einfach halten und weitest gehend zusammen fassen.

1.4.8.2. Variablenliste

Alle Variablen, die in den Scripten verwendet werden, müßen von Omsi verifiziert werden, ansonsten werden diese Variablen ungültig. Dieser Fehler wird auch in der Logfile angezeigt. In dieser _varlist.txt werden die einzelnen Variablennamen untereinander eingetragen. Nur Variablen, die in dieser Liste eingetragen sind, werden gültig und können berechnet werden.

1.4.8.3. Konstanten

In einigen Berechnungen, werden nicht nur veränderliche Variablen, sondern auch feste Konstanten abgefragt. Diese Konstanten können sich je nach Bustyp unterscheiden, sind aber dann für einen bestimmten Bus immer gleich. Diese konstanten Werte kann man direkt in die Berechnung einfliessen lassen, oder in der Textdatei _constfile.txt eintragen. Dies ist besonders dann sinnvoll, wenn man bestimmte Gegbenheiten vom User verändern lassen möchte oder wenn es sich um Werte handelt, die nicht ganz genau konstant sind. Das ist zum Beispiel dann der Fall, wenn Anzeigen nicht konstant verlaufen, sondern uneinheitliche Skalen haben. Das ist dann der Fall, wenn ein kleinerer Skalenabschnitt einen größeren Bereich abdeckt, indem die Werte normal sind und die Bereich die abnormal sind, dann verkleinert werden. Ein Beispiel dafür wäre die Temperaturanzeige des Kühlwassers. Für kleinere Diesel- oder Ottomotore, für PKW oder LKWs / Busse, ist eine Tempratur unterhalb der normalen Betriebstemperatur nicht dramatisch. Man sollte nur nicht zuviel Leistung abfordern. Im normalen Betriebstemperaturbereich, kann man dann normal fahren. Ist die Temperatur zu hoch, ist es eigentlich egal, wieviel die Temperatur über dem Normalwert liegt, es muß etwas getan werden. Solche volatilen Anzeigen, bei denen die Anzeige nicht konstante, also gleichgroße Bewegungen ausführen sollen, können dann mit mehreren Konstanten eingetragen werden, wobei dann die jeweils aktuellen Werte in die Rechnung einfließen können.

Ein anderes Beispiel sind Türen. elektrische Türen wechseln von einem Zustand {offen} in den anderen Zustand {geschlossen} mit einer konstanten Geschwindigkeit. Drucklufttüren verändern ihre Geschwindigkeit, je nachdem, wie hoch der Druck im Kolben ist, wobei diese Türen dann beispielsweise langsam beginnen können und im laufe des Weges ihre Geschwindigkeit erhöhen.

1.4.8.4. Stringvariablen

Stringvariablen sind all die Variablen, die aus anderen Zeichen bestehen, als die errechneten Werte. Solche Stringvariablen müßen ausgelesen werden und erst in ein anzeigentaugliches Format umgestellt werden. In Omsi wird die Uhrzeit nach der Anzahl der Sekunden nach Mitternacht berechnet. Da man mit der Uhrzeit: 47340 Uhr wenig anfangen kann, muß diese Anzahl an Sekunden ersteinmal umgerechnet werden. Bei der ersten Umrechnung werden die Sekunden in Minuten umgewandelt und im nächsten Schritt werden 60 Minuten zu eine Stunde zusammen gefasst. Am Ende kann dann die Uhrzeit 12:34 angezeigt werden.

Andere Stringvariablen werden von anderen Dateien ausgelesen. Wenn man im IBIS den Code 123 eingibt, werden die Strings aus der Hofdatei ausgelesen, die zu diesem Ziel gehören und das entsprechende Ziel wird dann als Stringvariable gespeichert um es in der Matrix als Ziel darstellen zu können. Stringvariablen sind also veränderliche Variablen, die nicht direkt angezeigt werden können, sondern für eine sinnvolle Anzeige erst passend umgestellt werden müßen. Alle Stringvariablen müßen in der _stringvarlist.txt eingetragen werden, damit diese im Scriptsystem gültig sind.

2. Performance beim Busbau

Um in Omsi einen Bus zu bauen, ist es wichtig auf den Umfang zu schauen. Ein Bus mit beispielsweise 100.000 Polygone ist ein polygonarmes Model. Ein Model mit 300.000 Polygone fällt aber extrem ins Gewicht. Als Spielerfahrzeug ist ein Bus mit 300.000 Polygonen kein großen Problem, da in Omsi immer nur ein Spieler im Fahrzeug sitzt. Aber wenn ein solches Fahrzeug als KI-Verkehr eingesetzt wird, dann mutiplizieren sich die Polygone mit der Anzahl der Fahrzeuge. An einem großen Knotenpunkt sind 9 weitere Busse im sichtbaren Bereich ein Vorteil, weil die Szenery damit lebendig wird. Allerdings muß Omis nicht 300.000 Polygone darstellen, sondern 3 Millionen - allein für diese 10 Busse. Aber auf einer Karte sind das nicht die einzigsten Polygone. Weitere Polygonzahlen kommen für Kreuzungen, Straßen und umgebenden Szeneryobejkten dazu. Somit kann sich die Anzahl der sichtbaren Polygone sehr schnell vervielfachen. Ein Bus mit 300.000 Polygone, zusammen mit 3 Millionen Polygone für die Umgebung (Häuser, Straßen, Haltestellenschilder, Sträucher, Baume, Gitter, Zäune, Schilder etc.), sind schon eine kleine Belastung. Dann macht es einen Unterschied, ob zehn weitere Busse mit einer Million oder mit 3 oder mehr Millionen Polygonen dazu kommen. Es belebt eine Stadt auch viel mehr, wenn nicht nur 2 oder 3 KI-Fahrzeuge fahren, sondern die Anzahl einer Stadt und der Uhrzeit entsprechend ist. Aber jedes dieser Fahrzeuge hat eine festgelegte Anzahl an Polygone. Diese addieren sich dann zum gesamten Polygonstand dazu.

Beim Busbau gibt es zwei Möglichkeiten die Polygonanzahl zu verringern. Entweder baut man polygonarme vereinfachte Objekte, die als KI-Variante gesetzt werden, oder man entfernt diese Objekte aus KI-Fahrzeugen durch die Sichtbarkeiten (Viewpoint-Flags). Der Vorteil von polygonarmen Fahrzeugen ist die stark verringerte Anzahl an Polygonen, die man damit erzielen kann. Der Nachteil dabei st, dass man diese Fahrzeuge zwar übernehmen kann, aber die Qualität dieser Fahrzeuge oder der Funktionsumfang in dem Fahrzeug sehr stark eingeschränkt sein könnte.

Das selbe betrifft auch die Scripte. Scripte sollten, soweit möglich, einfach gehalten werden. Je umfangreicher und komplexer ein Script wird, desdo mehr belastet es Omsi. Die größte und auffälligste Belastung sind unsinnige Abfragen, beispielsweise wenn in mehreren einzelnen Triggern oder Macros verschiedene Berechnungen angestellt werden, aber eine Ergebnissvariable immer wieder neu überschrieben wird.

Scriptberechnungen funktionieren wie folgt. Omsi stellt pro Sekunde mehrere Bilder dar, mehrere Standbilder. Viele Standbilder schnell nacheinander ergeben für das menschliche Gehirn ein bewegtes Bild. Wieviele Bilder Omsi pro Sekunden darstellt, erkennt man an der Fremerate pro Sekunde (FPS). Die FPS zeigt aber nichtnur die Bildanzahl in Omsi, sondern auch die einzelnenn Berechnungen aller Scripte. Pro Fremerate rechnet Omsi alle Scripte, alle einzelnen Trigger und Macros komplett durch. Das bedeutet, wenn Omsi gerade mit 30 Fremerate pro Sekunde läuft, werden alle Scripte dreißig mal pro Sekunde vollständig durchgerechnet. Rechnet man das ganze in einer Minuten hoch, bei konstanten 30 FPS werden also alle eingetragenen Scripte 1800 mal durchgerechnet. Das betrifft nicht nur die Scripte des Spielerbusses, sondern auch die Scripte aller anderen KI-Fahrzeuge und Objektscripte. Aus diesem Grunde sollten unsinnige und vollkommen nutzlose Scripte vermieden werden. Um ein Beispiel zu nennen: In den Bussen aus dem Add-Ons Hamburg Tag&Nacht, 3 Generationen, Hamburg Hafencity, Hamburger Buspaket und Add-On Ruhrgebiet, gibt es eine Abfrage der Hofdatei, bzw des Mapnamen. Der Grund ist, damit diese Busse auf einer bestimmten Karte ein besonderes Verhalten zeigt. Das ist aber eine vollkommen nutzlose Abfrage der Hofdatei, die zudem auch noch unnötige Ressorcen verbraucht.

Omsi ist ein 32-bit Programm (x86). Das bedeutet, dass Omsi maximal 4 GB des RAM-Speichers nutzen kann, wenn der 4GB-Ptach aktiviert wurde. Das Betriebssystem Windows benötigt schon etwa 1GB des Arbeitsspeichers. Steam und sonstige Programme (Treiber-Programme, Browser etc.) benötigen weitere Ressorcen des Arbeitsspeichers. Alle Programme die vor Omsi gestartet werden nutzen Bereiche des Arbeitsspeichers unter 4 GB. Wird nun Omsi gestartet, bleibt für Omsi nicht mehr sehr viel Arbeitsspeicher übrig. Besonders Steam verbraucht viel Arbeitsspeicher und Grafikspeicher, weil die Werbung mit Bildern dargestellt wird, während man Omsi spielt. Wie schon erwähnt macht ein Bus allein nicht viel aus. Aber mehrere Busse auf einer stark bebauten Kachel, drücken die Performance dann sehr stark.

Umfangreiche komplizierte Scripte, große Grafiken, viele Polygone und stark bebaute Kacheln, rechnen sich dann zusammen und drücken somit die Performance. All diese Sachen müßen beim Bus- und Mapbau beachtet werden.