Beiträge von wurstbrot

Welchen neuen Abschnitt meinst Du?`Willi-Brand-Platz ist bei Fahrt mit aktuellem Datum Montags bis Freitags bei der Linie 73 drin, den Grabenring kannst Du Montags bis Freitags garnicht befahren, sondern nur in den Nächten von Freitag auf Samstag und auf Sonntag mit der N4, sowie mit dem Grabenring-Express tagsüber nur an Samstagen.

Sollte die 73 bei Dir trotz aktuellem Datum nicht über den Willi-Brand-Platz gehen oder die N4 am Theater wenden, dann stimmt was mit den Chronos nicht, und dann würde ich eine Neuinstallation des Addons erwägen.

Und in wie weit die aktuellen Fahrpläne überhaupt im BBS sind weiss ich nicht. Wenn sie das nicht extra upgedatet haben, dann sind sie nicht auswählbar.

Zitat von Theproloser

Achja... Die Mär vom "man braucht 60FPS um flüssig spielen zu können". Schon fast putzig. Ich verstehe absolut nicht, warum das immer alle denken. Klar, eine hohe FPS Zahl ist im Allgemeinen ein guter erster Indikator für ein flüssiges Bild. Aber eben nicht der einzige. Da spielen nämlich die Frametimes noch eine wichtige Rolle.

FPS = Frames per second

Frametimes = Seconds per frame

Was genau ist das? Frametimes werden in Millisekunden gemessen und sagen aus wie lange das System braucht um einen Frame auszugeben. Bei 60 FPS wären das im optimal Fall alle rund 16,7ms; bei 25 alle 40ms. Aber wie gesagt, nur im optimal Fall. So kann ein Spiel welches mit 40 Frames läuft weniger flüssig erscheinen als ein Spiel welches nur mit 20 läuft. Woran liegt das? FPS werden immer in einem festen Zeitraum (einer sekunde bzw 1000ms) gemessen. Wie geanu die Frames über die Sekunde verteilt sind, lässt sich daraus allerdings nicht ableiten. Extremes Beispiel: wenn bei 60FpS 50 Frames in den ersten 0,5 ausgegeben werden und die restlichen 10, wirkt das Bild rucklig obwohl man doch eine gute Frame zahl hat.

Nicht falsch verstehen, LOTUS ist auch in Sachen Frametimes nicht der Renner. Mit Spikes weit über 100ms bei konstanten 22-25 FPS sieht das Bild halt alles aus, aber nicht flüssig. Wohlgemerkt aber weniger wegen den niedrigen FPS Werten sondern eher weil die Framtimes als Graph gezeichnet, aussehen wie eine Herzrhytmus Linie wenn ich gerade ne Halbestunde Joggen war.

Das wenig Fps auch flüssig sein können, sieht man z.B. bei Xplane 11. Ich komme nie über die 25 Fps Marke aber der Frametime Graph sieht aus wie mit einem Linial gezogen. Weshalb es flüssiger aussieht als z.B. Fernbus Simulator welcher bei mir mt 30-40 Fps (und instabilen Frametimes) läuft.

Selbstverständlich ist auch mir klar, dass man bei stabilen Frametimes einen nicht kleinen Unterschied erkennen kann zwischen 20 und 60 oder mehr Fps. Allerdings ist das bei ruhigeren Szenarien (wie Simulatoren) wo man selten schnelle Aktionen hat eher unerhäblich. Bei Shootern, Rennspielen, etc. also in Games, in denen es auf schnelle Reaktionen ankommt, ist das natürlich ein ganz anders Blattpapier.

Alles anzeigen

Ist im Grunde richtig. Die durchschnittlichen fps sind nur ein guter Anhaltspunkt dafür obs gut läuft oder nicht. Gute Frametimes bei niedrigen fps fühlen sich immer besser an als schlechte Frametimes bei hohen fps. Aber halt auch nur solange die fps über einem erträglichen Minimum sind: bei 16-20 fps ist es selbst bei guten Frametimes alles andere als gut. Zumindest in Simulationen: in Cities Skylines habe ich oft nicht schlecht gestaunt wie flüssig es sich anfühlte obwohl der Zähler bei bestimmten Blickwinkeln unter 20 war. Allerdings kommt in Simulationen noch ein wichtiger Aspekt dazu: mit geringeren fps sinkt die Reaktionszeit beziehungsweise die Latenz erhöht sich. unschön z.B. bei Gefahrenbremsungen oder plötzlichen Ausweichmanövern. Da ist selbst in OMSI der Unterschied zwischen 20, 30 und 40 fps krass fühlbar, vor allem dann wenn man auf Latenzerhöhende Einstellungen wie Vsync verzichtet und somit nicht dauerhaft übertrieben hohe Latenzen hat. In einem Rennspiel wäre das noch krasser wahrnehmbar. Flugsimulatoren sind da wieder ein anderer Fall: trotz der hohen Geschwindigkeit ist man meist weit weg vom Boden, und daher sind da auch um die 30 fps völlig okay. Wenn man allerdings landet wendet sich das Blatt wieder, da sollte man wieder im höheren Bereich sein.

Aber wie auch immer, so als absolutes Minimum was gehalten werden kann sollte in einer Simulation schon 30 fps sein bei guten Frametimes, also ohne die ganzen nervigen Spikes und ohne Nachladeruckler. Auf guten Rechnern mehr, aber dann ist es auch egal ob man an die 60 oder 100 kommt. Für mich persönlich reichen in OMSI 40 fps, Nachladen mal völlig aussen vor gelassen, in Lotus ist das Nachladen zwar etwas besser aber weit weg von dem was ich erwarte, und beim Fahren mit 50 fps fühlt es sich auch ausserhalb des Nachladens noch zu holprig an. Das geht ja schon los wenn ich in D-Lörick die Schleife verlasse, der fps Zähler zwar nie unter 30 fällt und sich meist zwischen 40 und 50 bewegt, das aber gefühlt noch sehr unsauber ist, was an den erwähnten Frametimes liegt.

Wenns um OMSI geht nicht so viel Kopf um die Grafikkarte machen, lieber schauen dass man die beste (min 6 Core bei Ryzen über 2000er Serie, bei 1000er 8 Core) CPU für sein Geldbeutel kriegt kombiniert mit optimal taktendem Speicher. Das stimmt, bei Ryzen sollte man schon schauen mit den Teilern, das variiert auch von Generation zu Generation. Und es kann schon gute 10 oder mehr Prozent ausmachen wenn der Speicher entweder zu langsam ist oder aufgrund des Teilers ungünstig betrieben wird.

Und da gibts noch unterschiede zwischen Sigle Sided und Double Sided Modulen. Letztere waren meist schneller bei gleichem Takt, es gab aber je nach Board Einschränkungen. Das ist nun wohl viel besser geworden, aber ich würde zur Sicherheit immer die RAM-Kompatibilitäts-Liste des Board-Herstellers checken. Dort ist genau aufgeführt mit welchem Takt welche RAM Module betrieben werden können. Das spart unter Umständen viel Ärger, weil es immer mal Boards gibt die dann halt mit Modul X oder Y eben nicht so klarkommen oder nur bei niedrigerem Takt, oder nur bei einer bestimmten Gesamtspeichergröße... Ich hatte damals echt Mühe zwei 16GB Module zu finden die perfekt waren. Und die die ich dann hatte waren nicht perfekt: es sind 3000er, laufen aber leider nur mit 2666 stabil. Bei 2x 8 GB hätte ich mehr Glück gehabt, aber zu dem Zeitpunkt war das alles etwas tricky. Ist heute einfacher, aber es lohnt sich da nicht ein Glücksspiel draus zu machen.

Zitat von Neoplan VEST

Aber eines ist mir aufgefallen im Dunkel, man kann zwar Lichthupe beim eingeschalten Abblendlicht geben, aber hat keine Auswirkung auf den KI-Verkehr. Für die Auswirkung muss man weiterhin auf Standlicht oder komplett aus (Die Beleuchtung) umschalten.

So ist es. Wobei ich glaube bei manchen Bussen wenn man es schaffte kurz genug das Fernlicht einzuschalten, hat es manchmal geklappt. War mir aber zu mühselig. Die Lösung aus dem Solaris PL fand ich dann nahezu perfekt. Ich weiss nicht wie genau OMSI Lichthupe triggert, aber ich glaube es geht um die Kürze der Zeit, und das ist fast im Milisekundenbereich.

Ich dachte beim Alterr-Citaro ginge das, denn immerhin ist der Solsris PL ja auch nur ein Mod vom Alterr-Solaris gewesen, der wiederum scriptmässig sicher mit seinem Citaro auch verwandt ist;-D

Zitat von Lµkas

Zitat von wurstbrot

Lotus ist kein Ersatz für Zugsimulationen. Es kann zwar Zug, aber die Sinnhaftigkeit wird irgendwo im Regionalverkehr aufhören.

Ich meine mal gehört zu haben, dass man sich auch auf den Regionalverkehr beschränken möchte. Im Entwicklungsfortschritt ist jedenfalls die S-Bahn-Linie Spandau-Lichtenberg genannt.

Genau, und ich würd fast sagen eine typische S-Bahn, wovon es in Deutschland eigentlich nur eine in Hamburg und Berlin gibt, ist genau die grenze des sinnvollen. Klar würde man die Zugsicherungssysteme etc so hinkriegen dass auch absolut vorbildgerechter Fernverkehr möglich wäre, aber ich glaube bei der Engine muss man sich entscheiden wo man den Fokus legt. Deswegen verstehe ich auch bis heute nicht warum man sich ausgerechnet an die Luftfahrt noch wagen möchte. Da seh ich viel mehr Sinn drin z.B. etwas Binnenschiffahrt einzubauen z.B. für Fährverkehr, wobei das wieder aufgrund ganz anderer Physik auch grenzwertig wäre. Aber immerhin eine unbesetzte Marktlücke.

Und ob nun externe oder interne Engine spielt meiner Meinung nach keine Rolle, es zählt das was kann man am Besten mit welchem Mittel erlauben. Eine UE Engine bietet grafisch zwar mehr, hat aber seine Tücken. Sie scheint nicht wirklich auf das simulieren ausgelegt zu sein, und hat extrem große Schwächen in Sachen wie Editor bereit stellen etc. Firmen wie DTG haben dies sogar wohl als Vorteil gesehen: je weniger Leute basteln können, desto mehr wird gekauft. So zumindest das Kalkül anfangs, auch wenn sie das so nie sagen würden.

Lotus ist kein Ersatz für Zugsimulationen. Es kann zwar Zug, aber die Sinnhaftigkeit wird irgendwo im Regionalverkehr aufhören. Ich denke die Engine wird auch nicht ausgelegt sein auf sehr hohe Geschwindigkeiten jenseits von 80 km/h. So Dinge wie Karlsruher Modell wird aber Lotus um ein vielfaches besser beherrschen als eine Zugsimulation, vor allem dann wenn es in den Straßenbahnbereich geht.

Man sollte trotzdem schauen dass der hochauflösende Textureinsatz Sinn macht. Gerade in OMSi sieht man wunderbar wie verschwenderisch mit Texturen umgegangen wird. Da wird wegen einem kleinen hochauflösenden Schriftzug gleich mal eine Riesentextur fürs ganze genommen, dann noch im unvorteilhaftem Format und mit völlig inkorrekten Abmessungen. Wenns dann in OMSI knallt ist wieder natürlich die Engine schuld;-D

Es ist schön wenn man Luft hat für hochauflösende Texturen, es sollte aber nie ein Freibrief sein gleich verschwenderisch mit umzugehen.

Und wie Chrizzly sagt, man muss die verwendete Bildschirmauflösung in Verhältnis zur Textur bzw. Objektgröße sehen. Otto-Normaluser fährt wahrscheinlich immer noch in FullHD, Rest verteilt sich wohl auf 1440p und 4K. Jetzt nehmen wir mal an jemand mit 1920x1080 hat auf seinem Bus eine 4K Textur für die Außenwerbung. Wie viel Unterschied würde er also sehen wenn der Bus vor der Nase ist im Vergleich zu einer 2K Textur? Wohlgemerkt vor der Nase, über weiter weg möchte ich garnicht reden;-)

Zitat von lebendig21

Dann müssen wir aber auch erwähnen, dass auf München sämtliches Zeugs ne 2k bis 4k Textur hat. Von daher ist nen Performance-Test oder wie mans nennen mag sowieso sinnlos.

Für heutige Rechner sind 2K oder 4K Texturen ein Witz. Das Laden und Verarbeiten einer solchen geht von einer modernen SSD flott genug dass man da keine Verzögerungen hat. Wenn sich nicht das Programms selbst im Wege ist, was wir zum Beispiel an OMSI gut sehen. Sowas darf aber bei einem aktuellen Programm wie Lotus nicht sein. Was hat denn eine dds-Textur in 2K für eine Größe? 4,5MB. 4K dann das vierfache. Was kann eine moderne SSD schaufeln? 2-3 GB/s.

Zitat von Chrizzly92

Tatsächlich ists aber in OMSI genau andersrum. liegt aber auch daran, dass OMSI sehr CPU-Lastig ist. begrenzt du die Framerate auf 30 FPS, hast du in OMSI spürbar weniger und schwächere Ruckler, weil mehr "overhead" für andere Berechnungen frei bleibt.

Da hatte ich genau das Gegenteil beobachtet;-D Ich sag ja: OMSI-Esotherik...

Zitat von Chrizzly92

Edit: Framerate ist übrigens nicht alles. Klar sind 60 FPS schön, besser wären aber 30, dafür ohne Nachlader und Microruckler, um einen sauberen Spielfluss zu simulieren, vorallem im Hinblick auf VR. selbst wenn auf manchen Karten also Stellenweise 60 FPS erreicht werden, fühlt sich das Spiel noch lange nicht flüssig an und einiges an rechenintensiver Simulation fehlt ja auch noch. wurstbrot , deine Karte im Multiplayer mit einem Spielerfahrzeug mehr wird dir direkt ein anderes Erlebnis bieten.

Ehrlich gesagt weiss ich es nicht mehr so genau, meine aber das wäre so im SP und MP gewesen. geb Dir aber recht, absolut stabile 30 fps sind mehr wert la schwankende 60 oder noch mehr. Bei OMSI war für mich meist 40 fps der Bereich ab wo es mir nach oben egal wurde, nach unten aber die Einbrüche spürbar waren. Und 30 sind bei mir die magische Grenze, denn wegen dem ab da greifendem Gsync fühlen sich schon 29 fps unterirdisch an, während 30 schon okay ist. Deshalb muss Lotus mir diese 30 auch in Innenstädten mit Verkehr liefern können, sonst verliere ich wie bei OMSI für lange Phasen die Lust.

Achja, die Aussage dass stabile 30 besser sind als schwankende 60 sollte niemanden dazu animieren da die Framerate zu locken. Das schafft nämlich auch längere Zeiten zwischen den Frames, wo zum Beispiel das Nachladen und vieles andere passiert, und das bremst man unter Umständen dann aus... Aber da sind wir schon inder OMSI-Esotherik drin;-D

Wenn man in Lotus "viele Dinge vor sich hat", auch welche die man nicht sieht, die aber vor einem liegen, dann geht die Performance runter. Schön zu beobachten in Düsseldorf, wenn man nach der Tonhalle von Oberkassel kommend die Kurve rechts nimmt zum Ratinger Tor. Da ist nicht viel an Objekten etc verbaut, es ist nur eine ungünstige Lage der Blickrichtung, vor allem wenn in Entfernung viele Straßen, Spuren, Kreuzungen, Gleise etc liegen. Ich glaube aber dass man hier einiges rausholen kann um diesen Effekt zu minimieren.

Natürlich wird er das versucht haben, aber viele Dinge merkt man ja erst später, insbesondere wenn die Contentvielfalt zu nimmt. Denn was anfangs einem als performant erscheint (z.B. weil irgendwas die fps von 100 auf 90 senkt) wirkt erst später als Klotz. Und die Dinge beeinflussen sich ja Gegenseitig. Deshalb kommt man nie drumherum das Optimieren eher später zu machen.

Luft gibt es aber sicherlich, und das kann man z.B. in OMSI sehen was da völlig ineffektiv blieb, und ich hab den Eindruck in Lotus ist es (noch) ähnlich: zum Beispiel werden in OMSI Menschen und KI für alle aktiven Kacheln generiert, egal ob man sie sieht oder nicht, oder ob man überhaupt an diesen Stellen vorbeifährt. Das hat den unangenehmen Effekt in dichten Innenstädten dass selbst bei hoch eingestellter KI kaum was los ist weil es sich ungünstig verteilt und trotzdem Resourcen frisst. In Lotus kann man einerseits entgegenwirken die KI auf viel mehr Threads zu verteilen, und erst garnicht dort darstellen wo man sie eh nicht zu Gesicht bekommen würde. Denn: aufgrund desd Fahrplans kennt das Programm ja die Fahrtstrecke und könnte demnach die KI entsprechend sinnvoll spawnen lassen. Nur falls Fahrplan nicht aktiv ist könnte ein weniger optimiertes, allgemeineres verfahren greifen. Gleiches bei Objektdarstellung. Ich kenne zwar nicht da die Konfigurationsmöglichkeiten, aber es lässt sich ja berechnen wie weit ein haus von der Strecke entfernt ist und ob es aufgrund seiner Größe denn überhaupt geladen und berechnet werden sollte.

Zu Optimierungen zähle ich auch so Funktionen wie das Vorladen im Stand: super Sache, wäre in OMSI Gold wert gewesen. Und garantiert lässt sich hier auch noch mehr rausholen, die Frage ist immer nur wie viel;-D

Gottseidank kann man theoretisch den VRAM nun mit Texturen vollmachen und auch sonst den kompletten Speicher nutzen.

Zur Performance:

Ich glaube die nächsten Monate werden erstmal was das betrifft ein Tal der Tränen. Es kommen gerade viele Sachen dazu die eben Perormance kosten, wie Menschen, Autos, aber auch einige neue Effekte. Dass da noch nichts optimiert ist dürfte klar sein. Wenn die Kernmenchanismen alle erstmal laufen wird man sicher optimieren, aber die große Frage ist dann was man da denn rausholt dabei. Ich bin insofern optimistisch dass es besser als bei OMSI wird, die Grundlagen dafür sind ja bereits geschaffen, z.B. ist die Nutzung von mehr Threads um Welten besser. Obs reicht in qualitativ halbwegs brauchbaren Einstellungen eine lebhafte Innenstadt zu simulieren wird man sehen. Das ist für mich die Messlatte ob ich ich dann langfristig Spaß mit dem Programm haben werde oder nicht, denn ich möchte natürlich schon zur HVZ viele Autos da sehen wo man sie erwarten würde, und ich möchte auch dann eine volle Bahn / vollen Bus haben und nicht lab leer Luft durch die Gegend fahren, weil ich die Einstellungen runterregeln musste. Das lässt sich leider noch nicht wirklich erahnen. Aber ich vermute mal dass das ganze noch ziemlich ineffektiv simuliert wird und Luft für Optimierungen noch reichlich vorhanden ist.

Manfred hat wohl einige Kilos abgenommen...

Ja, das wär dann die Frage ob mehrere Texturen von Nachteil wären. Allerdings bei Verwendung von mehreren könnten diese ja kleiner sein bei gleicher Optik, es fällt aber sicherlich eine Art Verwaltungs-Overhead an, wo eine Textur sicher besser ist als zwei halb so große. Könnte man auch nur in der Summe und Masse testen, da einzeln das kaum ins Gewicht fällt. Speichermässig kann man das leicht ausrechnen. Das ist ja auch ein Faktor, da der Adressraum vom 32 bitigem OMSI sehr begrenz ist und auch mit dem 4 GB Patch nicht wahnsinnig groß ist. Der VRAM wird ja immer dabei vergessen, und dann wundert man sich dass OMSI spinnt wenn die Texturauslastung signifikant größer als 1 GB ist. Wenn die OMSI.exe schon gerne 1,5 GB im RAM groß ist, wir dann aber noch 1,7 GB an Texturen im VRAM haben dann sind wir ganz hart an der Grenze, und dann passiert halt das ganze seltsame Zeug. Wer dann noch 4K Texturen in der KI hat, der braucht sich über garnix zu wundern.

Weisse Stadt hab ich nach meinen bisherigen Optimierungen eigentlich nie. Also wenn die Objekte erscheinen, dann sind sie gleich texturiert. Ausser ich wander etwas über die Karte und spring schlagartig wieder zum Bus. Und übrigens auch fast keine schwarzen/durchsichtigen Texturen mehr. Ich kann mehrere Stunden auf einer Map sein ohne dass alles zusammenbricht. Trotzdem bin ich noch nicht zufrieden, insbesondere in den winterlichen Rushhours. Auch muss ich an Bussen etwas noch werkeln, auch da gibts noch Möglichkeiten: der Haltenstellenweiterschaltungsruckler wird ja auch durch Texturen verursacht, wenn der Bus einen Monitor/Ibox hat. Und dann haben wir ja noch die Spiegel, die ich bisher ganz gut im Griff habe, denke aber es geht noch besser.

Unschlüssig bin ich noch bei Bäumen: habe irgendwie etwas mehr Stotterer nachdem nun kürzlich wegen dem Datum von Herbst- auf Winterbepflanzung umgestellt wurde. Ich vermute aber dass hier OMSI wieder einfach zu viel lädt, da ich in der Texturliste sowohl Winter- als auch WinterSnow Texturen gesehen habe, obwohl man doch immer nur eins davon braucht....

Zitat von fOcUs04

Das mit dem Nighttexture verkleinern hab ich bei mir in HC auch gemacht. Das bringt wirklich einiges. Ich hab die Texturen auf maximal 512px (längste Seite) gemacht und mir fällt da nix negatives auf.

mfg

Daniel

Sehr gut, das ist genau das was ich vorhabe.

Dann würde es im Objektbau vielleicht Sinn machen bei Häusern mit Läden unten zwei Texturen zu verwenden: für die Läden eine hochauflösende und für oben drüber eine kleinere. Dann kämen die Night-Texturen der Läden auch mit ihren optischen Vorzügen zum schein, und in der Summe wäre das performanter. Außerdem könnte man getrennt die Zeiten einstellen und oben wären eher die Lichter aus. Mal ehrlich: wenn man mit dem Bus fährt schaut man sich die Schaufenster ja an, die Fenster ab erster Etage nicht so. Und da gibt es sowieso nix zu sehen;-DDD

Gestalten möchte ich da nix, das wäre bei der Masse an Texturen etwas zu viel...

Rein theoretisch bringt das was ich vor hätte, je nach nach Map, einiges. Denn sobald die Night-Texturen zugeschaltet werden hat man quasi für jedes Haus eine zweite Textur. Ist sie nicht optimal hat das zum Teil erheblichen Einfluss auf die Performance. Nicht die Bildraten, sondern das Laden, verarbeiten etc, was dann zu unnötigem Stocken zum Beispiel beim Umdrehen führen. Bei jedem Laden einer zusätzlichen Textur stirbt OMSI ja tausend Tode, und ind er Masse macht sich das eben bemerkbar. Ich denke da vor allem an Innenstadt-Bereiche. Dort hätte man aber auch wiederum mehr von diesen Texturen mit Leuchtreklame, auf die man nicht hochauflösend verzichten sollte der Optik wegen. Es gibt aber trotzdem immer noch genug Häuser drumherum wo einfach nur die Fenster beleuchtet sind, und um die geht es mir.

Man könnte aber auch sagen dass es sich nicht lohnt zu optimieren, denn Nachts gibts ja auch weniger Verkehr und man hat somit eh mehr Spielraum. Das wäre aber ein großer Trugschluss, denn im Winter wirds schon zur Nachtmittags-HVZ dunkel. Und dann knallt alles halt rein und man hat den worst case was Performance betrifft, erst recht wenn es dann auch noch regnet. Ich finde aber hier wäre es möglich etwas abzuhelfen.

Dass eine Optimierungen der Texturen was bringt steht ausser Frage. Alleine die Konvertierung von allen Texturen die man so hat ins dds Format bringt erhebliche Gewinne, sogar bei den OMSI-Standard-Menschen. Jedes mal bei einem anderen Format braucht OMSI länger zur Verarbeitung, und das summiert sich immens. Eine optimierung der Night-Texturen würde da noch weiter in die richtige Richtung gehen, denn hier macht es auch die Masse.

Moin!

Könnte mir jemand erklären wie genau die Night-Texturen bei Häusern funktionieren? Dabei geht es mir nicht darum sie zu erstellen, sondern ich möchte sie zum Teil optimieren im Hinblick auf die Performance. Mir ist nämlich aufgefallen dass auf manchen Karten die Night-Texturen zum Teil genauso hoch aufgelöst werden wie die normalen Texturen. Das finde ich auch sinnvoll wenn es zum Beispiel Leuchtreklame enthält oder beleuchtete Schaufenster mit Schriftzügen, zweifel aber daran ob das nötig ist bei normalen Häusern wo einfach nur einige Fenster beleuchtet werden. Und ich habe die Idee genau diese mit den einfach beleuchteten Fenstern in der Auflösung z.B. auf die Hälfte zu reduzieren, was die Texturlast insgesamt erheblich mindern könnte (dann um Faktor 4 weniger Pixel), denn mal im Ernst: da erkennt man doch eh keine Details und muss dies auch garnicht.

Nun ist mir aber nicht klar wie die Überblendung nachts zwischen der Night-Textur und der normalen Textur passiert. Fakt ist dass OMSI beide voll im Speicher hat, womit ich annehme dass beide auch draufgemappt werden. Wenn ich also eine Night-Textur habe wo einige Fenster ausgeleuchtet sind und der Rest mehr oder weniger dunkel oder schwarz ist, sind die dunklen Teile der Night-Textur auch sichtbar oder wird nur der helle Bereich drübergemappt?`Weil dann würde so eine Optimierung tatsächlich einiges bringen, ohne z.B. die Struktur des Mauerwerks zu verwaschen. Liege ich da richtig in meinen Annahmen?

Hier eine Sammlung meiner Script-Mods für diverse Busse, überwiegend noch aus dem MOF, ergänzt durch paar neue Dinge (kursiv). Diese funktionieren in "verwandten" Bussen, da meist die originalen Scriptteile kopiert wurden. Es gibt aber natürlich nie eine Garantie, insbesondere wenn man einen anderen Mod noch verwendet. Man kommt also ums ausprobieren nicht herum, und ich kann leider in vielen Fällen keine Hilfe geben, da ich im Grunde beim Scripten auch nur Basics beherrsche und das meiste durch Ausprobieren und viele Fehlversuche hinbekommen habe.

Scheibenwischer-Hebel durchschalten per Tastatur:

Wie ja allgemein bekannt ist wanderte die Steuerung der Wischer irgendwann in den Kombihebel zusammen mit dem Blinker, sodass man die einzelnen Wischer-Stufen mit diesem durchschaltet, und nicht einzelne Taster auf dem Armaturenbrett drückt. Solch ein Durchschalten ist aber mit der Tastatur standardmäßig nicht möglich, man muss auch in diesen Bussen die einzelnen Wischerstufen wie bei Bussen der ersten VÖV Generation auf einzelne Tasten legen. Damit ist jetzt Schluß. Mit dieser Änderung braucht Ihr nur zwei Tasten belegen, die die Richtung des Kombihebels steuern und nacheinander wie auch bei der Mausnutzung die Wischerstufen durchschalten. Da die Belegung bei den SD202-Doppeldeckern unterschiedlich war, gibt es hiervon zwei Versionen: die D86-Version für D86-88 sowie die neusten SD200er, und die D89-Version für D89-92, NL202/NG272 und viele andere neuere Busse.

Version "D86" (kompatibel mit D86-D88, neuere SD202er und ähnliche):

Script zu bearbeiten: cockpit.osc

Folgenden Code hinter das {end} des Abschnittes {trigger:cp_wischer_wascher_button_off} einfügen:

{trigger:cp_wischer_runter}
    (L.L.cockpit_wischer_drehschalter_mode)
    1.5 <
    {if}
        0 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
        0 3 / (S.L.cockpit_wischerhebel) 
        0 (S.L.cockpit_wischer_drehschalter)
        0 (S.L.cp_wischer_einaus_sw)
        0 (S.L.cp_wischer_intervall_sw) (S.L.cp_wischer_schnell_sw)
    {else}
        (L.L.cockpit_wischer_drehschalter_mode)
        2.5 <
        {if}
            1 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            1 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            0 (S.L.cp_wischer_einaus_sw)
            1 (S.L.cp_wischer_intervall_sw) 
            0 (S.L.cp_wischer_schnell_sw)
        {else}
            2 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            2 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            1 (S.L.cp_wischer_einaus_sw)
            0 (S.L.cp_wischer_intervall_sw) 
            0 (S.L.cp_wischer_schnell_sw)
        {endif}
    {endif}
    (C.L.wiper_lever) !
    {if}
        l1 (M.L.kippschaltersound)
    {endif}
{end}
{trigger:cp_wischer_hoch}
    (L.L.cockpit_wischer_drehschalter_mode)
    0.5 <
    {if}
        1 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
        1 3 / (S.L.cockpit_wischerhebel) 
        0 (S.L.cockpit_wischer_drehschalter)
        0 (S.L.cp_wischer_einaus_sw)
        1 (S.L.cp_wischer_intervall_sw)
        0 (S.L.cp_wischer_schnell_sw)
    {else}
        (L.L.cockpit_wischer_drehschalter_mode)
        1.5 <
        {if}
            2 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            2 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            1 (S.L.cp_wischer_einaus_sw)
            0 (S.L.cp_wischer_intervall_sw)
            0 (S.L.cp_wischer_schnell_sw)
        {else}
            (L.L.cockpit_wischer_drehschalter_mode)
            2.5 <
            {if}
                3 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
                3 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
                1 (S.L.cp_wischer_einaus_sw)
                0 (S.L.cp_wischer_intervall_sw)
                1 (S.L.cp_wischer_schnell_sw)
            {endif}
        {endif}
    {endif}
    (C.L.wiper_lever) !
    {if}
        l1 (M.L.kippschaltersound)
    {endif}
{end}

Im Anschluss am Besten als cockpit.osc abspeichern. Beim nächsten Start von OMSI gibt es in den Tastatur-Optionen die neuen Events "cp_wischer_hoch" und "cp_wischer_runter" die Ihr mit Tasten belegen könnt. Ich habe hierfür jeweils Shift-Q und Shift-E gewählt, da ich auf Q und E Blinker hab.

Version "D89" (kompatibel mit D89-D92, NL202/NG272 und ähnlichen):

Script zu bearbeiten: cockpit.osc

Folgenden Code hinter das {end} des Abschnittes {trigger:cp_wischer_wascher_button_off} einfügen:

{trigger:cp_wischer_runter}
    (L.L.cockpit_wischer_drehschalter_mode)
    1.5 <
    {if}
        0 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
        0 3 / (S.L.cockpit_wischerhebel) 
        0 (S.L.cockpit_wischer_drehschalter)
        0 (S.L.cp_wischer_einaus_sw)
        1 (S.L.cp_wischer_intervall_sw) 
        0 (S.L.cp_wischer_schnell_sw)
    {else}
        (L.L.cockpit_wischer_drehschalter_mode)
        2.5 <
        {if}
            1 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            1 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            0 (S.L.cp_wischer_einaus_sw)
            0 (S.L.cp_wischer_intervall_sw) 
            0 (S.L.cp_wischer_schnell_sw)
        {else}
            2 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            2 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            1 (S.L.cp_wischer_einaus_sw)
            0 (S.L.cp_wischer_intervall_sw) 
            0 (S.L.cp_wischer_schnell_sw)
        {endif}
    {endif}
    (C.L.wiper_lever) !
    {if}
        l1 (M.L.kippschaltersound)
    {endif}
{end}
{trigger:cp_wischer_hoch}
    (L.L.cockpit_wischer_drehschalter_mode)
    0.5 <
    {if}
        1 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
        1 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
        0 (S.L.cp_wischer_einaus_sw)
        0 (S.L.cp_wischer_intervall_sw)
        0 (S.L.cp_wischer_schnell_sw)
    {else}
        (L.L.cockpit_wischer_drehschalter_mode)
        1.5 <
        {if}
            2 (S.L.cockpit_wischerhebel_mode) (S.L.cockpit_wischer_drehschalter_mode)
            2 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
            1 (S.L.cp_wischer_einaus_sw)
            0 (S.L.cp_wischer_intervall_sw)
            0 (S.L.cp_wischer_schnell_sw)
        {else}
            (L.L.cockpit_wischer_drehschalter_mode)
            2.5 <
            {if}
                3 (S.L.cockpit_wischerhebel_mode)                 (S.L.cockpit_wischer_drehschalter_mode)
                3 3 / (S.L.cockpit_wischerhebel) (S.L.cockpit_wischer_drehschalter)
                1 (S.L.cp_wischer_einaus_sw)
                0 (S.L.cp_wischer_intervall_sw)
                1 (S.L.cp_wischer_schnell_sw)
            {endif}
        {endif}
    {endif}
    (C.L.wiper_lever) !
    {if}
        l1 (M.L.kippschaltersound)
    {endif}
{end}

Im Anschluss am Besten als cockpit_D89.osc abspeichern und in den .bus-Dateien der betroffenen Busse in der Auflistung der Scripts auch entsprechend statt cockpit.osc eben cockpit_D89.osc eintragen. Beim nächsten Start von OMSI gibt es in den Tastatur-Optionen die neuen Events "cp_wischer_hoch" und "cp_wischer_runter" die Ihr mit Tasten belegen könnt. Ich habe hierfür jeweils Shift-Q und Shift-E gewählt, da ich auf Q und E Blinker hab.

Wer nun auch noch die alte Tastenbelegung bei beiden varianten dafür entfernen möchte, der löscht oder kommandiert alle Zeilen etwas oberhalb im Script zwischen einschließlich {trigger:cp_wischer_schnell_toggle} und einschließlich dem {end} ÜBER {trigger:cp_wischer_wascher_button} aus, denn man braucht die nicht mehr und vielleicht hat man eine sinnvollere Verwendung in diesen Bussen für diese Tasten. Oder man nutzt zwei davon jeweils für cp_wischer_runter bzw. cp_wischer_hoch, dann wäre das Rauf- oder Runterschalten auf den gleichen Tasten wie bei Bussen wo man keinen Heben sondern wie bei den SDs Tasten nutzt. Wie man es macht ist Geschmackssache.

Schlüssel-Modifikation:

Ähnlich wie beim Wischer-Kombihebel ist es schon recht seltsam in Bussen die das Licht über die Position des Schlüssels steuern und nicht über Taster trotzdem für Standlicht/Fernlicht separate Tasten drücken zu müssen. Also machen wir mal das ganze ähnlich wie beim Wischerhebel und modifizieren es entsprechend. Diesmal auch mit dem i-Tüpfelchen, dass man den Schlüssel nur in Aus-Stellung ein und ausstecken kann und nur einen eingesteckten Schlüssel auch drehen kann. hier müssen wir allerdings nun zwei Scripte bearbeiten, jeweils die cockpit.osc und die lights.osc.

Script 1 zu bearbeiten: cockpit.osc

Wir ersetzen den Code zwischen dem trigger {trigger:cp_schluessel_mov_drag} und seinem {end} durch diesen:

{trigger:cp_schluessel_mov_drag}
'    Ein- und Ausstecken des Schlüssels nur möglich wenn Schlüssel in Stellung 0 (=Licht aus), 
'    Drehen des Schlüssels nur Mmöglich wenn Schlüssel eingesteckt ist.
'    Fallunterscheidung: Schlüssel in x- oder y-Richtung?
    (L.S.mouse_y) abs (L.S.mouse_x) abs >=
    {if}
        (L.L.cp_schluessel_rot_mode) 0.5 <
        {if}
'            Zunächst Translation (Einstecken)
            (L.S.mouse_y) 10 / (L.L.cp_schluessel_trans) + 0 max 1 min (S.L.cp_schluessel_trans) s0
'            Stufen:
'            0: Schlüssel abgezogen
'            1: Schlüssel eingesteckt
            l0 0.5 <
            {if}
                0 (S.L.cp_schluessel_trans_mode) (S.L.elec_busbar_main_sw)
            {else} 
                1 (S.L.cp_schluessel_trans_mode)
                1 (S.L.bremse_ABS_selftest)
'                Wenn beim Einstecken bereits der Stromkreis geschlossen werden soll, ohne Trennschalter:
                (C.L.automatic_battery_switch)
                {if}
                    1 (S.L.elec_busbar_main_sw)
                {endif}        
            {endif}
        {endif}
    {else}
        (L.L.cp_schluessel_trans_mode) 0.5 >
        {if}
'            Sonst Rotation (Lichtschalter)
            (L.S.mouse_x) 20 / (L.L.cp_schluessel_rot) + 0 max 1 min (S.L.cp_schluessel_rot) s1
'            Stufen:
'            0: Licht aus
'            1: Standlicht
'            2: Abblendlicht
            l1 0.2 <
            {if}
                0 (S.L.cp_schluessel_rot_mode) 
            {else} 
                l1 0.8 <
                {if}
                    1 (S.L.cp_schluessel_rot_mode) 
                {else}
                    2 (S.L.cp_schluessel_rot_mode)
                {endif}
            {endif}
        {endif}
    {endif}
{end}

Script 2 zu bearbeiten: lights.osc

Folgenden Code hinter das {end} des Abschnittes {trigger:kw_standlicht_toggle} einfügen:

{trigger:kw_schluessel_rechts}
    (L.L.cp_schluessel_trans_mode) 0.5 >
    {if}
        (L.L.cp_schluessel_rot)
'        Wenn Schlüsselposition Aus dann Standlicht
        0.2 <
        {if}
            0.5 (S.L.cp_schluessel_rot)
            1 (S.L.cp_schluessel_rot_mode)
            (T.L.ev_schluessel_dreh)
'        Wenn Schlüsselposition Standlicht dann Abblendlicht
        {else}
            (L.L.cp_schluessel_rot)
            0.8 <
            {if}
                1 (S.L.cp_schluessel_rot)
                2 (S.L.cp_schluessel_rot_mode)
                (T.L.ev_schluessel_dreh)
            {endif}
        {endif}
    {endif}
{end}
{trigger:kw_schluessel_links}
    (L.L.cp_schluessel_trans_mode) 0.5 >
    {if}
        (L.L.cp_schluessel_rot)
        0.4 >
        {if}
'        Wenn Schlüsselposition Standlicht dann Aus
            (L.L.cp_schluessel_rot)
            0.8 <
            {if}
                0 (S.L.cp_schluessel_rot)
                0 (S.L.cp_schluessel_rot_mode)
                (T.L.ev_schluessel_dreh)
'        Wenn Schlüsselposition Abblendlicht dann Standdlicht
            {else}
                0.5 (S.L.cp_schluessel_rot)
                1 (S.L.cp_schluessel_rot_mode)
                (T.L.ev_schluessel_dreh)
            {endif}
        {endif}
    {endif}
{end}

Beim nächsten Start von OMSI gibt es in den Tastatur-Optionen die neuen Events "kw_schluessel_links" und "kw_schluessel_rechts" die Ihr mit Tasten belegen könnt. Ich habe hierfür jeweils Pfeiltaste links und rechts gewählt, mit Pfeil runter stecke ich den Schlüssel ein und aus.

Unnütz sind nun die Trigger {trigger:kw_scheinwerfer_toggle} und {trigger:kw_standlicht_toggle} geworden und können gelöscht oder auskommandiert werden bis zu ihrem {end}

Licht-Drehschalter:

Für Busse die das Licht unabhängig vom Schlüssel mit einem Drehschalter steuern (z.B. diverse Citaros) hätten wir folgenden Code zum "drehen":

Script zu bearbeiten: lights.osc:

{trigger:kw_scheinwerfer_toggle}
    (L.L.cp_schluessel_rot)

'Wenn Schlüsselposition Standlicht dann Abbl-Licht
    0.5 =
    {if}
        1 (S.L.cp_schluessel_rot)
        (T.L.ev_schluessel_dreh)
    {endif}
    (L.L.cp_schluessel_rot)
'Wenn Schlüsselposition Aus dann Standlicht
    0 =
    {if}
        0.5 (S.L.cp_schluessel_rot)
        (T.L.ev_schluessel_dreh)
    {endif}
{end}

{trigger:kw_standlicht_toggle}

    (L.L.cp_schluessel_rot)
'Wenn Schlüsselposition Standlicht dann Aus
    0.5 =
    {if}
        0 (S.L.cp_schluessel_rot)
        (T.L.ev_schluessel_dreh)
    {endif}

    (L.L.cp_schluessel_rot)
'Wenn Schlüsselposition Abbl-Licht dann Standlicht
    1 =
    {if}
        0.5 (S.L.cp_schluessel_rot)
        (T.L.ev_schluessel_dreh)
    {endif}
{end}

Abblend-Licht nur aktiv bei eingeschaltetem Motor:

Wenn ich mich nicht irre wurde das hier für die verschiedensten Busse schon oft gewünscht. Dabei ist die nötige Modifikation und der Aufwand sehr minimal. Da ich es aber nur OMSI 2 ausprobiert habe, weiss ich nicht ob es auch in OMSI 1 so funktioniert.

Script zu bearbeiten: lights.osc

Wir suchen uns im Script den Kommentar "Lichterzustand in Abhängigkeit vom Schlüsselschalter und Batterierelais setzen:", und fügen dem Code eine Zeile hinzu , nämlich Zeile 11. Das war's schon!

'Lichterzustand in Abhängigkeit vom Schlüsselschalter und Batterierelais setzen:
        (L.L.cp_taster_nebelschluss_target) (L.L.elec_busbar_main) sqr * (S.L.lights_nebelschluss)
        (L.L.cp_licht_nebelschw_sw) (L.L.elec_busbar_main) sqr * (S.L.lights_nebelschw)
        (L.L.cp_schluessel_rot) 0.2 > 
        {if}
            (L.L.elec_busbar_main) sqr
            (S.L.lights_stand)
            (S.L.lights_rueck)
            1 (S.L.lights_terminus)
            (L.L.cp_schluessel_rot) 0.8 >
            (L.L.engine_n) 200 > && 
            {if}
                (L.L.elec_busbar_main) sqr
                (S.L.lights_abbl)
            {else}
                0
                (S.L.lights_abbl)
            {endif}
        {else}
            0
            (S.L.lights_stand)
            (S.L.lights_terminus)
            (S.L.lights_rueck)
            (S.L.lights_abbl)
        {endif}
'        Fernlicht
        (L.L.lights_sw_fern)
        {if}
            (L.L.elec_busbar_main) sqr
            (S.L.lights_fern)
            (S.L.lights_abbl)
        {else}
            0 (S.L.lights_fern)
        {endif}

[Platzhalter]

"Polnische" Lichthupe / Fernlicht-Steuerung:

Im Urbino PL-Komplettpaket ist mir die Modifikation der Lichthupen/Fernlichtsteuerung aufgefallen und habe sie für genial befunden. Es hat mich immer genervt dass in Dunkelheit ich zum Geben der Lichthupe immer erst das Abblendlicht abschalten musste, da sonst nur das Fernlicht einspringt, und die KI dieses ja auch nicht als Lichthupe interpretiert, selbst wenn man es nur kurz einschaltet. Es gibt in OMSI so viele Situationen wo man einfach die Lichthupe braucht, da man oft die Vorfahrt der KI überlassen muss, zum Beispiel um "ums Eck" unfallfrei zu kommen, weil diese viel zu weit vorne steht. Mit dieser Modifikation geht das. Wenn das Abblendlicht eingeschaltet ist, funktioniert die Lichthupe so wie wenn man es Tags übergewohnt ist. Möchte man aber aber Fernlicht haben, drückt man die entsprechende Taste einfach mindestens 2 Sekunden, und man aktviert damit das Fernlicht.

Script zu modifizieren: lights.osc, cockpit.osc, cockpit_varlist.txt

lights.osc:

{trigger:kw_fernlicht_toggle}
    (L.L.lights_sw_fern) ! (S.L.lights_sw_fern)
        
    1 (S.L.dlugie_odliczanie)
    
    (T.L.ev_wischerhebel)
{end}

{trigger:kw_fernlicht_toggle_off}
    (L.L.cp_schluessel_rot)    0.8 <
    {if}
        0 (S.L.lights_sw_fern)
        (T.L.ev_wischerhebel)
    {else}
        (L.L.dlugie_czas) 2 <
        {if}
            0 (S.L.lights_sw_fern)
            (T.L.ev_wischerhebel)
        {endif}
    {endif}    
    
    0 (S.L.dlugie_odliczanie)
{end}

Dann suchen wir noch in der cockpit.osc das Makro {macro:cockpit_frame} und fügen vor dessen end-Befehl folgendes zu:

    (L.L.dlugie_odliczanie)
    {if}
    (L.L.dlugie_czas) (L.S.Timegap) + (S.L.dlugie_czas)
    {else}
    0 (S.L.dlugie_czas)
    {endif}

Und zu guter letzt fügen wir noch der cockpit_varlist.txt die zwei neuen Variablen an den Schluss hinzu:

dlugie_odliczanie
dlugie_czas

Wer mag kann sich dies auch aus dem Uribino PL Gesamtpaket entsprechend rauskopieren.

"richtige" Hebelsteuerung für Blinker:

Ich fand es immer komisch, dass man den Blinker nach rechts mit nochmaligem drücken der Taste für Blinker rechts deaktivieren konnte. Es erschien mir völlig unlogisch, weil man doch den Blinkerhebel auch nicht weiter nach rechts umlegen kann wenn man schon rechts blinkt. Um also einen rechts blinkenden Blinker auszuschalten muss man den Hebel zurücksetzen (also die Taste für Blinker links drücken). Entsprechend umgekehrt beim linken Blinker. Das ist also der Sinn dieser Modifikation, für all die jenigen denen das auch komisch oder unreal erscheint wie es standardmässig in OMSI seit Jahren gehandhabt wird.

Script zu modifizieren: lights.osc:

{trigger:blinker_left_move}
    (L.L.lights_sw_blinker)
    0 =
    {if}
        1 (S.L.lights_sw_blinker)
        (T.L.ev_lights_blinker_swon)
        (M.L.lights_calc_geberfaktor)
        (M.L.lights_startblinkgeber)
    {endif}
    (L.L.lights_sw_blinker)
    2 =
    {if}
        (T.L.ev_lights_blinker_swoff)
        0 (S.L.lights_sw_blinker) 
    {endif}
{end}


{trigger:blinker_right_move}
    (L.L.lights_sw_blinker)
    0 =
    {if}
        2 (S.L.lights_sw_blinker)
        (T.L.ev_lights_blinker_swon)
        (M.L.lights_calc_geberfaktor)
        (M.L.lights_startblinkgeber)
    {endif}
    (L.L.lights_sw_blinker)
    1 =
    {if}
        (T.L.ev_lights_blinker_swoff)
        0 (S.L.lights_sw_blinker)  
    {endif}
{end}

Wir ersetzen die Trigger blinker_left_move und blinker_right_move durch den obigen Code. Die darauf folgenden Trigger blinker_left_set und blinker_right_set können wir auskommandieren oder löschen, denn wenn wir die Events mit den gleichen Tasten belegt haben wie für unsere Trigger, dann wird das ganze nicht funktionieren oder ein Chaos geben. Wenn wir die richtigen Events für die Tastenzuweisung finden wollen suchen wir nach "Blinker über rechts" und "Blinker über links". Sie sind relativ oben angeordnet und haben die deutsche Übersetzung angezeigt.

Zitat von SGTVP

Nach einem Neustart deaktiviert OMSI das reale Wetter, also die aktuellen Daten werden gespeichert, aber du musst nach einem Neustart den Haken wieder neu setzten. Das der einfach so rausfliegt, habe ich noch nicht erlebt.

Also ich drehe in letzter Zeit immer einige Runden auf der gleichen karte und gehe zwischendurch auch aus OMSI raus. Beim Neustart habe ich in vielleicht 70% der Fälle das vorher aktuelle Wetter aktiv. Das merk ich auch in dem ich ganz klar sehe wie sofort nach dem Laden das Wetter "einspringt", denn meistens hat es sich ja verändert. Der Haken ist nur dann weg, wenn bei der vorherigen Runde das Wetter rausgeflogen ist, oder zum Zeitpunkt des erneuten Ladens nicht verfügbar war.

Dass es bei Dir immer neu gesetzt werden muss liegt vermute ich mal daran dass Dein Wetter auch unbemerkt rausgeflogen ist. Wie gesagt, ich habe da die Server der Wetterdienste im Verdacht, aber in gewisser Weise auch OMSI.

Übrigens: das "rausfliegen" des Wetter merkst Du eigentlich nur an zwei Dingen: erstens Du schaust nach ob der Haken noch drin ist, oder zweitens Du siehst dass sich seit längerem nichts verändert hat am Wetter. Dann bleibt die letzte empfangene Wettereinstellung für ewig aktiv.