= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Hallöchen!
Wer kennt das nicht, die lästigen weißen oder durchsichtigen Autos und dann geht irgendwann gar nichts mehr und man muss neu starten. 4GB Pacth installiert? Ja. Irgendwann ist man mit dem Latein am Ende. Entweder man lebt also damit oder reduziert radikal seine AI-Liste, versucht die Texturlast einzugrenzen oder führt diverse OMSI-esotherische Maßnahmen durch. Auch dieses Tutorial löst das Problem leider nicht ganz, es hilft aber es einzudämmen und richtet sich vor allem an die Fahrplanersteller, denn da geht was. Aber der Reihe nach.
Einleitung:
Die Ursache für die weißen Autos (und auch andere Objekte) ist Speichermangel. Die Texturen können nicht mehr in den Speicher geladen werden, also fahren neu geladene Autos und Busse ohne Textur durch die Gegend (weiss oder durchsichtig, manchmal auch schwarz), und dann erwischt es auch noch Objekte der Scenery. Wir wissen ja dass OMSI ein 32 Bit Programm ist und somit eine Adressgrenze von etwa 2 GB hat, die man mittels "4GB Patch" auf etwa 4 GB verschieben kann. Man muss bedenken: die maximalen 4GB umfassen sowohl den RAM (Hauptspeicher) als auch den VideoRAm (Grafikspeicher). Das heraufsetzen des Videospeichers auf 4 GB zählt dann zu den OMSI-esotherischen Maßnahmen;-) Auch die alte 2/3-Regel würd ich heutzutage in Frage stellen, stammt sie doch aus einer Zeit wo man es mit deutlich weniger Speicher zu tun hatte als heute. Also ist halt irgendwann Sense, auch dank der schönen Busse in der AI-List, überdimensionalen und schlecht proportionierten Texturen beim Mobilien und Immobilien. Alles hat meist Optimierungspotential, und man sollte es ausschöpfen: KI-Versionen verwenden, nicht übertreiben, Repaint-Anzahl gering halten usw. Hilft aber auch nicht ganz, kann aber manchmal den Unterschied machen.
Mein Ansatz baut an einer anderen Stelle auf. Es ist Euch vielleicht aufgefallen dass die OMSI.exe größer wird je länger das Spiel läuft und sich selten bis gar nicht verkleinert. Bei etwa 3,2 GB Größe knallen dann die Texturen durch. Logisch: 3,2 GB plus Texturen im Video-RAM ergeben 4 GB. Nicht nur dass OMSI nur 32 Bittig ist, nein, es ist nicht gerade schonend mit dem Speicher. Es hält unnötige und zweitweise nicht mehr gebrauchte Dinge im Speicher und stößt dann eben irgendwann an die Grenze. So werden anscheinend Daten von Bussen die auf die Karte gespawnt wurden die ganze Zeit vorgehalten, selbst wenn dieser Bus die Karte und erst recht den sichtbaren Bereich wieder verlassen hat. Kleines Beispiel:
Wir haben einen KI-Kurs morgens um 7:30 mit Schülern zur Schule und um 13:30 Uhr zurück, dazwischen verlässt der Bus die Karte. Wenn die Vormittags- und Nachmittagsfahrt in einem Umlauf sind, dann bleibt der Bus im Speicher wenn man ihm morgens begegnet ist bis Nachmittags wo er die Karte wieder verlässt und der Umlauf endet. Und jetzt mal überlegen was passiert wenn dies 20 KI-Linien sind? Die Antwort liegt auf der Hand... Man muss die KI-Kurse also am Besten dazu kriegen zu verschwinden sobald sie nicht mehr gebraucht werden, und dazu würde auch die Zeit zwischen Vormittag und Mittag in unserem Beispiel zählen. Hier wäre die Abhilfe schonmal den Umlauf in 2 Umläufe aufzuteilen. Eine Linie wird jetzt nicht viel ausmachen, aber 20 schon.
Abhilfe:
Wir splitten also die Umläufe auf und teilen sie in mehrere. Das machen wir per Hand mit Texteditor an den ttl-Dateien der Linien, da es im OMSI-Editor unglaublich kompliziert und unübersichtlich wäre. Hier ein kleines Vorher Nachher Beispiel
Vorher:
nachher:
(Fast) jede fahrt ist also intern zu einem "Umlauf" geworden. Der Bus wird also erscheinen und nach der Fahrt wieder verschwinden. Und: er wird den Speicher freigeben! Das Editieren war simples (aber mühseliges) Copy and Paste. Zwischen jede Fahrt wurde ein [newtour]-Bereich reinkopiert mit der alten Umlaufbezeichnung samt neuem Suffix, aus "Mo-Do 1" wurde "Mo-Do 1-1", "Mo-Do 1-2" usw. Für die Abendkurse hab ich mir das gespart, aber dazu später mehr
Um mal zu zeigen wie viel das bringt:
Vorher war mit meiner AI-Liste nach einer Fahrt im privat gemoddetem Mainz in der HVZ Schluss, da ich da mit der OMSI.exe bereits bei 3,1GB war. Jetzt hatte diese Grenze erst gegen Ende der Rückfahrt erreicht. Am Ende der Hinfahrt war die EXE bei 2,4 GB statt 3,1 GB. Mit gleichen Settings, gleicher AI-Liste. Dabei waren bei weitem nicht alle KI-Linien umgestellt auf dieses System, vielleicht nur etwas mehr als die hälfte. Viel Luft nach oben und mal gucken wie es aussieht wenn alles umgestellt ist;-)
Anwendungsbereiche:
Wo kann man dieses Prinzip anwenden? Es hängt ganz stark von der Art der Linien ab die eine Karte hat. Grundsätzlich bringt es viel bei Karten die viele KI-Linien haben, die auch die Karte verlassen. Ganz wichtig: KI-Linien. Keine vom Spieler fahrbaren Linien! Da würde zum Beispiel eine Karte wie ALU schonmal nicht in Frage kommen für diese Maßnahme (außer bei den Zügen!). Aber Karten wie Spandau, X10/BRT, Hamburg wären perfekt mit viel Potential bei den KI-Linien sowohl bei Bus als auch Zug, Allerdings wo keine Not da auch keine Mühe notwendig. So kann man sich das bei Abendfahrplänen oder fürs Wochenende vielleicht sparen. Kommt eben auf die Karte an. KI-Linien die auf der Karte enden und im sichtbaren Bereich Pause machen würde ich immer beim verlassen der Karte splitten, da also jede zweite Tour. Dennoch würde ich schonmal auf jeder Karte den gesamten Zugverkehr auf diese Weise regeln.
Nachteile:
Als erstes werden die Fahrpläne natürlich furchtbar unübersichtlich fürs spätere Bearbeiten. Also immer dafür eine Kopie bereithalten. Dann ist es natürlich so dass so einen Umlauf immer ein anderer Bus fahren wird und nicht der gleiche wie vorher, denn technisch sind es ja verschiedene Umläufe. ist blöd, ja, aber beim Neuladen des Spielstands würden die Fahrzeuge sowieso wieder neu zugeteilt werden mit gleichem Effekt. Deshalb würde ich aber KI-Linien die zum Beispiel an der gleichen Endstelle wie der Spieler Pause machen von diesem System rausnehmen. Als Beispiel sei hier Spandau mit der KI-Linie 94 genannt die am Reimerweg endet oder die 56 in Ruhleben. Bei Verwendung von StnLinks werden manchmal Busse auch nicht gelöscht, Beim alten T&T System funktioniert das aber recht zuverlässig. Aber vielleicht lassen sich so auch besser "Geisterbusse" mit +1000min Verspätung finden bei StnLinks die dann auch den Speicher unnötig vollstopfen;-)
Ausblick:
Ich hoffe das probiert der ein oder andere aus und noch mehr hoffe ich dass jemand ein Tool schreibt welches diese Prozedur irgendwie automatisiert.