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.
Beiträge von wurstbrot
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet:
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! -
-
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;-)
-
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.
-
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...
-
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....
-
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:
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:
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:
Script 2 zu bearbeiten: lights.osc
Folgenden Code hinter das {end} des Abschnittes {trigger:kw_standlicht_toggle} einfügen:
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:
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!
[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:
Dann suchen wir noch in der cockpit.osc das Makro {macro:cockpit_frame} und fügen vor dessen end-Befehl folgendes zu:
Und zu guter letzt fügen wir noch der cockpit_varlist.txt die zwei neuen Variablen an den Schluss hinzu:
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:
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.
-
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.
-
Es geht nicht um Sprünge, sondern Ausfälle.
-
Bei der Gelegenheit mal eine Frage:
Welche Flughafencodes in Deutschland sind am zuverlässigsten fürs Wetter in OMSI? Ich habe so den Eindruck dass es da Unterschiede gibt und manche öfter mal aufhören zu arbeiten und man merkt es erst wenn man erneut auf das Wetter-Icon klickt. Ich finde das relativ nervig da immer nachzuschauen und den Haken fürs "reale Wetter" zu setzen. Kann aber natürlich sein dass es an OMSI liegt... Aber Tegel, Stuttgart, München flogen mir gefühlt öfter raus, und Hamburg eher seltener... Aber Hamburger Wetter ist ja meist nicht so dolle;-D
-
Aber zumindest hier haben die technisch nicht ganz fachkundigen die Möglichleit Fehlkäufe weitgehend zu vermeiden und eben das optimale Verhältnis aus der eigenen Erwartung und dem eigenen Geldbeutel rauszuholen. Im MediaMarkt kriegen sie eh gesagt dass die Taktfrequenz dazu da ist das Internet zu beschleunigen;-D Leider kein Witz.
-
Ja gut, dann würde sich aber Otto Normalkäufer einen 4 Jahre alten i7 andrehen lassen weil er ja auch so viel GHz hat und hätte das Nachsehen, weil vieles bei ihm schlechter laufen würde als bei heutigen i3/i5ern oder Ryzens. Man muss schon wissen was der Takt bedeutet, sonst kauft man völlig falsch. Jahrelang hat Intel den Leuten eingebläut dass Takt alles ist, und das sitzt noch tief. Sogar Apple hat das verstanden und bewirbt die Rechner mit Taktfrequenz, im gegenteil, man will garnicht dass die Leute wissen wie niedrig die M1 CPU taktet und trotzdem zumindest die heutige AMD/Intel Mittelklasse schlägt.
Hätten wir nur einen Hersteller und eine Architektur, dann wäre der Takt eine brauchbare Vergleichsmöglichkeit. So dient aber einzig und allein als vergleich innerhalb einer Architektur. Gerade in Zeiten wo AMD so deutlich aufgeholt hat sollte man das schon wissen, auch als Laie.
Übrigens hatte ich bis 2017 auch einen i7. Der wäre aber gnadenlos untergegangen gegenüber einem heutigen i3 oder der Ryzen Einsteigerklasse. Es gibt aber genug Leute die der Meinung sind dass der aber schneller sein MUSS;-D Das war er auch, aber halt vor Jahren... Er lief mit 3,3 GHz, mein heutiger R7 taktet mit 3,7 MHz. Taktmässig ein kleiner Sprung, Leistungsmässig sind da Welten dazwischen, auch in OMSI. Damals am RSP froh gewesen über 20fps, heute locker gute 35 bei agressiveren EInstellungen.
-
Der Takt des Prozessors macht sehr wohl einen Unterschied aus, wie gut bzw. schlecht OMSI läuft. Ich selber bin vor kurzem von einem i5 @3,2 auf einem i7 @4,7 (beides Boost) umgestiegen und kann bei gleichbleibenden Einstellungen innerhalb von OMSI deutlich bessere Performance verzeichnen. Es sind keine Wunder zu erwarten, so viel steht fest, aber es macht schon viel aus.
Du kannst aber nicht die Taktfrequenz zwei verschiedener Architekturen (Ryzen vs Intel) vergleichen. Vor paar Jahren war Intel bei gleichem Takt schneller, heute ist es umgekehrt. Auch kannst Du nicht innerhalb der Produktpalette eines Herstellers das wirklich vergleichen, es sei denn es ist die gleiche Generation und Architektur. i7 und i5 haben aber nichts mit Architekturen gemein, ein i5 von heute ist bei exakt gleichem Takt schneller als ein i7 mit dem selben Takt von vor paar Jahren. Ein heutiger i7 wäre aber annähernd gleich schnell wie ein heutiger i5, wenn er auch die gleiche Anzahl an Kernen hat.
Noch ein kleiner Vergleich: die heutigen Ryzens (5000er Serie) sind von Haus aus gute 25% und mehr schneller als ihre Kollegen von vor 2-3 Jahren. Aber: Ein 5000er mit 4,6 GHz ist schneller als ein 5000er mit 4,0 GHz;-)
Und jetzt wieder zu OMSI: ich würde als Messlatte die Single-Core Leistung nehmen, da OMSI einen Kern hauptsächlich auslastet und die anderen geringer. Trotzdem würd ich Hinterkopf behalten dass OMSI bis zu 4 Kerne nutzt und dadurch Vorteile zieht. Aber ich glaube kaum dass irgendwer noch heute einen Dual Core kaufen würde... Trotzdem sollten es 6 oder mehr Kerne sein, damit OMSI "seine" 4 Kerne wirklich für sich hat.
Vor ein paar Jahren konnte man im OMSI noch ziemlich genau ausrechnen, welche Leistungsszeigerung in fps zu erwarten ist, da dies relativ linear war zur Single-Core Leistung eines Prozessors. Wusste man also dass Prozessor A 1,5 mal schneller war als Prozessor B, zum Beispiel durch entsprechend mehr Takt oder die Architektur, dann wusste man auch dass man z.B. bei gleicher Situation statt 20 fps dann 30 fps hätte. Ob das heute noch so genau zutrifft weiss ich nicht. Hier rede ich auch nur von der Bildrate. Sachen wie Nachladen oder der ganze andere Kram der so nervig ist wird dann zwar auch etwas beschleunigt, aber bei weitem nicht um diesen Faktor. Gefühlt bessert sich der Rest dann vielleicht um 10%. Also mag sein dass in 20 Jahren alle mit 200 fps rumfahren, gleichzeitig aber auch alle weiterhin jammern über stockende Performance;-D
Edit:
Man könnte doch einen Community-Benchmark mal machen: es wird eine Situation erstellt die von allen Teilnehmern geladen wird (.z.B. ein MAN SD am Rathaus Spandau zur exakt gleichen Uhrzeit und Datum) und zusätzlich lädt jeder davor die vorgegeben OMSI-Settings für KI und Grafik. Diese müssten so ausgelegt sein, dass grafisch bei jedem das gleiche gerendert wird und es nicht schwächere Rechner überfordert. Dann wird zum beispiel nach genau einer Minute die fps-Zahl abgelesen und notiert. Es müsste halt beachtet werden dass jeder die Standard-AI/parked-list und humans-Datei verwendet, sonst hinkt der Vergleich. Wenn viele mitmachen und ihre Hardwarespecs mit angeben wäre es viel einfacher für jemanden der aufrüsten möchte sich ein Bild davon zu machen was er wirklich so an Nutzen erwarten kann.
-
In der Theorie ginge es, wenn man die Höchstanzahl der Autos auf einen astronomischen Wert setzen würde, mit allen daraus resultierenden Folgen für die Performance, und wenn man mal so komischen Stellen aussen vor lässt wo aus irgendeinem Grund nix gespawnt wird. Das ist ja die Krux an der Sache: da wo man mehr Verkehr bräuchte ist man sowieso von der Performance am Limit, gerade weil dann OMSI leider auch den Verkehr berechnet den man aufgrund seiner Strecke wahrscheinlich nie zu sehen kriegt. Von den sagen wir mal dann maximalen 1000 Autos sieht man vielleicht 150. Dabei weiss OMSI wo man lang fährt, schließlich fährt man meist nach Fahrplan;-D Hier wäre so viel Sparpotential drin...
Für Mapersteller heisst es wohl trial and error bei einer realistischen Einstellung und die Illusion zu erzeugen die man haben möchte ohne Ressourcen zu verschwenden.
