Beiträge von wurstbrot

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.

Zitat von PingPong

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.

Glaubt ja nicht dass man mit einem "schnellen" PC OMSI mit auch nur ansatzweise vollen Einstellungen flüssig spielen kann. Es wird immer irgendwo irgendwas ruckeln, nachnladen und stocken, mal mehr und mal weniger. Einen PC der OMSI mit 5 Nachbarkacheln, 2000m Sichtweite und 500 KI-Autos schafft gibt es nicht. Es ist nicht die Schuld der Hardware, sondern des Programms. OMSI hat schon mit Kleinstmengen an Daten Probleme. Trotzdem hilft eine gute CPUm, schneller RAM und eine brauchbare SSD das ganze ein Bißchen erträglicher zu machen. Man kratzt dann weniger an den unteren fps-Grenzen (was aber nicht das stocken verhindert) und viele Kerne bringen mehr Headroom damit sich OMSI alleine auf 4 völlig freien Kernen tummeln kann.

Grafikkarte:

Solang es keine GPU im Prozessor ist geht eigentlich alles. Und wenn schon im Prozessor dann von AMD, Intel ist da um Welten lahmer. Eine aktuelle Mittelklassen-Karte reicht alle mal (diese Aussage galt schon vor 5 Jahren und der damaligen Mittelklasse;-D). OMSI beansprucht die Grafikkarte kaum, höchstens nur wenn man im Treiber mit Supersampling-AA und solchen Dingen spielt, da aber auch nur marginal. Meine 1080 langweilt sich zu Tode, kommt kaum auf 50% und der VRAM-Verbrauch erreicht auch nie die 2GB Grenze. Kein Wunder bei einem 32Bit-Programm...

Netzteil:

Nicht unterschätzen für die Stabilität des Systems! Die Watt-Zahl kommt auf die Komponenten an, je mehr desto mehr Luft, aber jedes Netzteil hat einen Punkt wo es am effizientesten arbeitet. Ein 800W Netzteil tut es zwar auch in einem kleinen System, ist aber total uneffizient. Bleibt es bei einer Grafikkarte der Mittelklasse, rechnet man noch künftig eine weitere Festplatte und noch eine SSD hinzu sollten auch 450W gut sein, vorausgesetzt die Qualität ist gut. Ein schlechtes Netzteil fliegt einem auch nicht gleich um die Ohren, aber wenns passiert dann reisst es möglicherweise auch andere Komponenten in den Tod mit. Normallerweise hat aber halt mehr Systemabstürze, die CPU boostet weniger oder kürzer, es kommt zu Hängern in Spielen und solchen "Kleinigkeiten". In Haushalten mit schlechter Elektrik (z.B. Installationen noch aus den 70er Jahren) besteht noch die Gefahr von Überspannungen, die ganz schlechte Netzteile noch schlechter ausgleichen können, aber man sollte eh eine vernünftige Steckdosenleiste mit entsprechendem Überspannungsschutz vorschalten. Die kosten dann auch gerne so viel wie ein kleines Markennetzteil, sind aber Investitionen die sich langfristig auszahlen, da weniger Komponenten kaputt gehen.

Übrigens empfehle ich gerade für OMSI unbedingt eine Grafikkarten-Monitorkombination die Gsync/Freesync tauglich ist. Bewegt man sich bei den fps in der Range wo diese Technologien greifen, fühlt sich das spielen zigmal natürlicher und geschmeidiger an. Man sollte nur schauen dass die Range mindestens bei 30fps/Hz beginnt, wenns geht noch niedriger. Die meisten Gsync-Monitore gehen ab 30fps in den Modus, bei Freesync meist deutlich höher, zum Teil erst bei 45. Hätte man auf manchen Karten also nix von.

Ich hab früher mit einem Tool konvertiert, aktuell mit Photoshop, weil ich dann eher Fehler erkenne. Interessanterweise ist es ein Plugin von Intel;-D Hab mir beide Dateien angeschaut und direkt gesehen dass die PNG die Transparenz hatte und die dds nicht, dann halt selber einen Konvert gemacht und ausprobiert. Bei der Gelegenheit noch über die anderen Autos gegangen, da ich mir nicht mehr sicher war ob die die X10 Autos von mir bearbeitet waren beziehungsweise überhaupt eine Bearbeitung nötig hatten, da ich vor paar Wochen Ausputz bei OMSI gemacht habe und alles neu installiert habe um es von unnötigem Müll zu bereifen der sich angesammelt hat. Da waren aber alle Transparenzen wohl richtig und ich hab nur _#low-Versionen mit halber Texturgröße erstellt falls ich sie mal brauche.

Naja, ich denke 100 Prozent akkurate Werte für die trafficdens bringen auch nicht viel aufgrund der Eigenheiten von OMSI, aber sie sind doch ein guter Richtwert. Man muss es aber fein tunen. Für Fahrgäste nutze ich dann verschiedene global-cfg für Montag-Donnerstag, Freitag, Samstag und Sonntag, gibt ja leider keine passengerdens-Datei... Und die Eigenheiten das sind halt so Sachen wie das was Du beschreibst, oder das typische Phänomen dass man kaum Verkehr hat in die eigene Richtung. Da versuche ich gerade zumindest über die Seitenstraßen Bißchen was rein zu bekommen, ist aber trial and error. Der Klassiker ist ja auch dass man durch eine leere Innenstadt fährt, und erst wenn die Kacheldichte abnimmt der Verkehr so da ist wie man ihn gerne hätte. Ich glaube das liegt meist an der Obergrenze der Autos, weil dann zum Beispiel die maximalen 120 oder 150 verteilt werden, und eben nicht direkt vor einem auftauchen. Im Falle von X10 müsste man doch dann eigentlich hingehen und ab Roseneck Richtung Fehrbelliner Platz und Richtung Zoo die Dichte entsprechend erhöhen, und den Bereich mit den vielen kleinen Straßen parallel des Kudamms berücksichtigen. Gibt aber auch immer mal Ecken wo auf Teufel komm raus keine oder nur wenig Auto-KI spawnt, auch wenn nicht viel drumherum ist was die Autos "verbrauchen" könnte.

Das erwähnte Straßenstück, welches nicht nass wird ist das Kreuzungsobjekt zwischen Vaals Grenze und Busstation. Und ich glaube es ist das einzige, was nicht nass wird;-)

Folgendes ist mir noch aufgefallen was bei Gelegenheit verbesserungswürdig wäre:

- Wenn 2 Gelenkbusse der Linien 33/73 an der Uniklinik pausieren, blockieren sie die Ausfädelung auf die Spur zum Vorbeifahren an der Pausenhaltestelle. Lösung könnte sein den Pausen-Buswürfel etwas vorzuziehen und die Pfade zum Spurwechseln etwas früher zu legen. Das würde zu Spitzenzeiten den Stau mit den KI Linien wie 3A/3B vermeiden, die nicht vorbei kommen.

- Uniklinik Pfad zum Taxistand: auch wenn auf extrem selten eingestellt versucht die KI manchmal dort abzubiegen, kriegt es aber nicht hin und bleibt auf der Straße mit Blinker links (!) stehen. Irgendwas ist da faul... Workaround wäre das Stück in den Taxistand komplett zu sperren für alle AI-Gruppen, damit aber falls sich doch ein Auto da hin verirrt das Stückchen richtung Haltestelle auf extreme low stellen. Besser verkehrswidrig als da blockierend;-)
(Schuld ist der Fussgängerpfad. Trotz geringerer Priorität der Fußgänger warten die Autos auf ewig bis diese rüber sind, sie werden aber immer dicht gespawnt. Lösung ist die Fußgänger zu deaktivieren, und zwar ab etwa Beginn der Haltestelle, wo der Fußgängerpfad einen Bruch hat. Das falsche blinken der Autos liegt am Fehler in der Kreuzung wo "left" bei Blinker eingetragen ist)

- Endstelle Fuchserde: vorausfahrende Kurse werden nicht gespawnt. Normal müsste meistens bei Ankunft der 33 der Kollege vor mir dort noch kurz stehen. Schuld ist glaub ich dass OMSI mit dem Pfadstück da nicht ganz klar kommt. Eventuelle Lösung: den Pfad an der Haltestelle gerade zurück in die Parkplatzreihe vorher noch laufen lassen (und natürlich für jegliche non-scheduled AI deaktivieren. Dann würde der Bus eventuell spawnen. Edit: bei mir hat die Verschiebung des Buswürfels weiter nach vorne ausgereicht, die Busse spawnen wieder. Nur müsste dann auch entweder die Peoplebox verlegt werden, damit die Leute nicht versuchen in den Nachläufer bei der KI einzusteigen, oder den Entry im Nachläufer sperren. Denn die KI kommt dann nicht vom Fleck... Vielleicht ist es auch ein Citaro G-Bug.

- Ponttor Endhaltestelle 3A/3B Kurzläufer: Gelenkbusse ragen da ein wenig zu sehr mit dem Hintern in die Spur links. Eventuell reicht es hier den Buswürfel etwas vorzuziehen.

- Rothe Erde Pausenhaltestelle: die ist etwas knapp für Gelenkbusse, geschweige denn die GLs... Ich nehme mal an dass in der Realität dort keine Pause gemacht wird, sondern eine Haltestelle weiter vor dem Kreisverkehr. Aber da wär auch kaum Platz zum Überholen... Da hab ich keinen Lösungsvorschlag. Als Spieler kann man ja improvisieren, die Bus-KI ist da halt stur.

- KI-Linie 25 fährt weiter bis Heuvel nach dem Fahrplanwechsel, obwohl sie ja dort von der 33 abgelöst wurde;-D
- Kreisverkehr Hörn-Brücke: Autos blinken nicht beim verlassen des Kreisverkehrs. Bei dichtem Verkehr führt das zu Staus, da einfahrende Autos erst einfahren wenn ein Auto der Kreisverkehr verlassen hat (sie wissen dann nicht ob das Auto im Kreisverkehr dort bleibt oder abfährt. Lösung: "blinker right" für die Abzweige aus dem Kreisverkehr im Kreuzungsobjekt setzen)

- Ring Audimax-Ponttor: zum Teil sinnfreie Spurwechsel der KI-Autos. Auffällig bei dichtem Verkehr. Abhilfe wäre bei den Spline-Stücken "overtaking prohibited" auszuwählen, dann wechseln die Autos nicht die Spur. Unfallgefahr könnte auch entschärft werden, wenn man bei allen doppelten Linksabbiege Spuren LKW-verkehr für die jeweils linke Spur verbietet. Normal nutzen LKWs nur die rechten. Man könnte aber auch um ab und zu Ausnahmen zu erlauben die Dichte da auf Low oder Very Low setzen.

- 30er Zonen: Viktoriaallee ist bis zur Bahnunterführung eine 30er Zone. Einfahrten sind auch beschildert, nicht aber die Ausfahrt Richtung Stadtmitte. Meines Wissens nach ist der gesamte Innenstadtbereich innerhalb des Rings heute eine 30er Zone, vermute mal dass dies 2015 aber noch nicht so war. Der Fahrplan legt aber nahe dass er auf 30 km/h in dem Bereich ausgelegt ist, da man gerne Standzeiten von gut 1min pro Haltestelle zwischen Theater und Normaluhr hat. Man könnte also locker daraus eine 30er Zone machen.

Noch was zu den Bussen:

Die Abfahrtzeiten in der IBOX weichen bis zu einer Minute von den im Fahrplan angegeben Zeiten ab. Ich dachte das wären manchmal Rundungsfehler bei Haltestellen mit nicht exakt definierten Abfahrtzeiten, habe aber auch öfter in der roten Statuszeile zum Beispiel eine Abfahrtzeit von exakt 08:28:00 gesehen, während die IBOX mir 08:27 angezeigt hatte. Bei längeren Pausen wie zum Beispiel am Bushof zeigt die IBOX auch öfters eine Verspätung von 3 Minuten an, obwohl die Abfahrtzeit noch nicht erreicht ist. Offenbar nimmt sie manchmal nur die Ankunftszeit, manchmal aber auch eben die Abfahrzeit... Darüber hinaus kommt die Abfahrtmeldung gute 15 Sekunden vor der eigentlichen Zeit. Vielleicht ist das aber gewollt und vorbildgetreu?

Kleine Idee:

Man könnte für den Bereich in den Niederladen sowohl in der AI-Liste eine eigene Gruppe anlegen mit mehr Autos mit niederländischem Kennzeichen, ebenso eine separate parklist. Das würde in dem Bereich das Feeling des Grenzübertritts etwas besser machen. Viel Arbeit wär das nicht, wenn man dafür dann die Vehicle Group so setzen würde, dass diese anfangs deaktiviert ist. Man müsste also nicht ganz Aachen durchgehen;-D

KI-Autos:

Irgendwie mag ich sie. Hab früher meist die Hamburg-Autos auf anderen Karten verbaut, weil die Performance sparend sind. Hier hab ich es kürzlich nur mit den X10-Autos versucht, sie sind auch sehr genügsam, aber sehen bei der Kleinwagen- und Limosinenklasse grottig aus, ausserdem haben sie auch keine NL-Kennzeichen;-D Die Aachen-Autos sind performant aber eins stört mich doch sehr: sie haben weder Abgase noch den Spray-Effekt hinter den Rädern bei Regen. Das fiel mir auf als ich bei Eiseskälte mal fuhr, und einige zusätzliche Lieferwagen und LKWs ordentlich dampften, die Aachen-Autos aber nicht. Das wirkt etwas komisch. Partikeleffekte nicht zu verwenden spart kaum bis garnicht Leistung ein, und wenn doch hat ja der Spieler die Möglichkeit in den OMSI-Optionen das entsprechend zu regulieren. Die Autos liessen sich relativ einfach um diese Effekte erweitern, es fehlen nur die entsprechenden Zeilen in der Modelldatei. Hab mal testweise einfach was aus vergleichbaren anderen Autos rauskopiert und eingefügt, funktioniert prima. Wenn man es ganz genau machen möchte kann man noch die entsprechenden Positionen feiner anpassen oder die Intensität der Abgase variieren, z.B. dass alte Möhren mehr qualmen als neuere. Wichtig beim Test ist aber das man für die Abgase kalte Temperaturen einstellt, sonst sieht man wenig, und für das Spritzwasser natürlich Nässe. Ups, die Autos haben ja gar keinen Auspuff;-D Nicht schlimm, ist halt etwas versteckt unter der Stoßstange-D

Texturen:

Über sie will ich eigentlich nicht meckern, sie sind im Gegensatz zu anderen Karten eigentlich prima: Format passt, Abmessungen zu 90% 2er Potenzen. Es gibt aber einige Ausnahmen wo die Abmessungen krumm sind, und zwar ungünstig krumm. Damit meine ich so viele wo z.B. eine Kante knapp über einer 2er Potenz liegt (drunter wär weniger schlimm). Aber so wird im Speicher mal eben aus 1026 halt 2048, und das macht enorm was aus. Die würde ich um die paar Pixel kleiner machen. Des weiteren würde ich bei den Night-Texturen wo z.B. nur Fenster beleuchtet werden die Auflösung reduzieren, da es da kaum auffällt. Nachts knallen die Night-Texturen nämlich hart rein, weil sie zusätzlich geladen werden, und da könnte man gut was wegsparen. Da wo Schriften, Logos etc sind würd ich sie lassen wie sie sind, ausser die Auflösung ist wie erwähnt krumm;-) Man könnte sich aber bei der Optimierung zunächst auf die Innenstadt begrenzen zwischen Westbahnhof und Schloßstraße, sowie vielleicht bis zur Josefskirche auf dem 73er Abschnitt. In den Außenbereichen kämpft man ja weniger um die Performance.

Leerfahrten Vaals->Stadt:
Die Trips für die Einrückfahrten aus Vaals sind etwas unsinnig, beziehungsweise vielleicht noch aus einer Version der Map wo es keine Schnellverbindung über die B1 gab. Die ausrückenden Busse fahren die ganze Tour übers Vaalserquartier anstatt direkt Richtung City zu fahren. Lässt sich einfach beheben, man braucht nur ein paar neue StnLinks und muss den Trip halt anpassen. In Gegenrichtung sind die meisten Leerfahrten okay, ich glaube nur eine Ausnahme habe ich gesehen. Für den Abschnitt zwischen Haltestelle Forckenbeckstraße und Miss-von-der-Wasweissichstraße würde ich einen StnLink anlegen der direkt zur Hörnbrücke geht. Das hätte den Vorteil dass die KI-Busse den direkten Weg fahren würden, der Spieler aber wie bisher vorbei am Studentendorf. Ähnlich könnte man in der Stadt verfahren zwischen Ponttor und Kaiserplatz: der Spieler würde sich über die City quälen, die KI den Ring nutzen.

Edit: Ergänzungen im Text in orange

Mir fiel auf dass der X10 MB Sprinter keine transparenten Scheiben hat. Ich hab mir die Dateien mal angeschaut und der Fehler gefunden: die dds-Texturen haben keine Transparenz bei diesem Auto, die noch übriggebliebene png-Variante schon. Offenbar ein kleiner Konvertierungsfehler, den ich mir schnell korrigieren konnte indem ich aus der png eine neue dds erstellt habe im Photoshop.

Bitte nur beim künftigen Update nicht einfach die dds Dateien entfernen, auch wenns optisch den Fehler behebt. Die pngs (wie auch tga) fliegen einem gerne früher oder später um die Ohren, auch mit 4GB Patch. Es ist sehr löblich dass im X10 Addon gerade bei den KI-Autos konsequent auf dds gesetzt wurde.

Btw eine Frage: die trafficdens-Daten scheinen mir ziemlich penibel genau ausgerechnet worden zu sein. Welche Datengrundlage hatte das? Ich kopiere sie mir gerne raus für andere Karten, weil mir so der Verkehr am realistischsten über den Tag verteilt erscheint Da ist mir aber unklar ob die Stau-stadteinwärts/stadtauswärts Werte dazugerechnet werden müssten, falls man diese nicht gesondert verwendet sondern zum Beispiel nur mit der NormalCars Gruppe arbeiten würde. Auch würde mich mal interessieren mit welchen Verkehrseinstlungen in OMSI die Dichte ermittelt wurde: ich nehme mal an 100% Verkehrsdichte und maximale Anzahl von Fahrzeugen auf voll damit es keine Begrenzung gibt? Wäre natürlich performancemässig heftig, aber mich würds mal interessieren was das Optimum wäre.

Bei einer Nachtfahrt auf der N4 (die übrigens einen sehr sportlichen Fahrplan hat, vielleicht sollten Abends/Nachts einige Ampeln wie bei X10 Berlin sich abschalten...) fiel mir im Innenstadtbereich auf, das gewisses Stottern und OMSI-Gedenksekunden jenseits des üblichen Nachladens wohl eher durch die Texturen der Szenerie als durch KI-Verkehr verursacht werden. Gemäß meinen Einstellungen war um diese Zeit kaum Individualverkehr unterwegs und es fuhren insgesamt auf der gesamten Karte nur 4-6 KI-Busse. Trotzdem hatte ich alle paar Meter ein Stottern, insbesondere beim Abbiegen oder Sichtwechsel. Eigentlich hatte ich das immer der KI zugeschoben, denke aber nun dass diese da zwar auch eine Rolle spielen kann, nicht aber den Hauptgrund darstellt. Dieses Stottern empfinde ich schlimmer als irgendwelche fps-Schwankungen oder das Nachladen an den Kachelgrenzen. Meine fps hatte ich bei 36 gelockt und die wurden auch stabil in der Innenstadt geliefert. Nun, warum trotz 36 fps so ein abgehacktes Spielerlebnis? Die Antwort bekommt man, wenn man die Texturen in den Optionen auf Low stellt und bei den Objekten, sofern vorhanden, die #low-Varianten geladen werden. Dies reduziert das Stottern auf ein Minimum. Hier kommt wieder eines der Flaschenhälse von OMSI zum Vorschein: es mag nun mal keine großen Texturen, und vor allem nicht in Masse. Auf der Karte sind standardmässig meist 2048er Texturen verbaut, die Low-Varianten haben meist 512er. Jede Texturgrößenstufe rauf oder runter ergibt eine Größenänderung um Faktor 4. Von High auf Low umzuschalten gibt also im Schnitt die 8-fache Ersparnis.

Nun gibt es aber nicht zu jeder Textur eine Low-Variante, z.B. bei den Grabenring-Texturen. Da wäre also noch Potential bei einem Update was rauszuholen. Auf der anderen Seite können 512er Texturen sehr verwaschen aussehen, insbesondere wenn sie Logos und Schaufenster von Geschäften enthalten. Ich wäre mal gespannt ob es noch stottern würde wenn man z.B. 1024er Texturen grundsätzlich verwenden würde in der Low-Fassung für solche Geschäftsbereiche und ansonsten konsequenter bei Low 512er verwenden würde da wo es nicht so auffällig ist. Außerhalb der Innenstadt könnte man eine Stufe rauf gehen und auch bei Low auf die 512er verzichten und 1024er nehmen.

Bei den night-Texturen bin ich mir nicht sicher ob da eine Unterscheidung auch Sinn machen würde, vielleicht aber schon, denn gerade im Winter sind sie morgens lange aktiv und auch schon am Nachmittag zugeschaltet, und zwar zusätzlich zur sonstigen Texturlast.

Interessant ist was OMSI so alles an Texturen lädt. Wie gesagt, ich fuhr die N4, OMSI hatte aber auch Frankenberg-Texturen im Speicher, und ich meine in der Liste auch Beverau gesehen zu haben. Da stellt sich OMSI quasi selbst ein Bein und man kann sich schon fragen was denn nun eigentlich an den Kachelgrenzen nachgeladen wird;-D Beides Areale die nicht geladen werden sollten bei maximal einer Nachbarkachel.

Edit: und eben ist mir aufgefallen dass ich dabei die Halycon-KI-Menschen drin hatte, die unbearbeitet ebenfalls stark zum Texturdilemma beitragen, Nachts aber immer weniger zu Gange sind;-D Trotzdem sind prinzipiell die Beobachtungen nicht falsch, und alles spielt in der Summe eine Rolle.

Für OMSI 2 ist es ziemlich egal welche SSD, ich habe bis heute keinen Unterschied gesehen ob OMSI auf meiner schnellen M.2 lief, die so um die 2,7 GB/s schafft oder auf einer SATA SSD die nicht über 500MB/s kommt. Der Flaschenhals ist im Programm selbst. Nur auf einer Festplatte würde ich es nicht empfehlen.

Die Kaufentscheidung würde ich also nicht von OMSI abhängig machen, sondern davon was sonst noch drauf laufen soll, und da gibt es dann größere Unterschiede. Allerdings ist es für OMSI von Vorteil wenn eine schnelle SSD vorhanden ist, auf der die Windows-Auslagerungsdatei läuft. Denn die wird ausgiebig genutzt, egal wie viel RAM man frei hat. Auf dieser muss aber nicht das Spiel installiert sein.

Teste das Fahrzeug auf Grunddorf oder eben Aachen und nicht auf einer Freeware-Karte die bei Dir erstens schon selbst zig Fehler ausspuckt und zweitens unzählige andere Busse geladen hat.

Sicher spuckt fast jedes Fahrzeug in OMSI immer mal Fehler aus in der Log, kann aber für die Aachen Citaros zumindest sagen dass es nicht mehr sind als bei den meisten anderen Bussen.

Mir ist was bei den Spiegeln der Busse aufgefallen:

Die Standardsichten sind ja darauf ausgelegt dass Performance gespart wird, deshalb sieht man eigentlich den linken Spiegel in der Hauptsicht nicht. Der Hintergedanke ist klar und nachvollziehbar, funktioniert aber nicht, denn der linke Spiegel wird trotzdem die ganze Zeit gerendert. Man spart also nix, beziehungsweise nur an den anderen Spiegeln. Dann müsste man aber den linken Spiegel nicht "verstecken";-)

Ich habe beim LE ein Setup gemacht, welches die gleiche Performance bietet, aber meiner Meinung nach eine bessere Sicht, mit dem Bonus dass bei der Sicht nach rechts die rechten Spiegel ohne Einschränkungen rendern, was hilfreich beim Rechtsabbiegen ist. Der Trick ist dass der Dreifach-Innenraumspiegel hier versteckt wird und nur aktiviert wird wenn man ihn wirklich braucht, zum Beispiel an den Haltestellen.

Hier eine Kombination aus der Modifikation der Sichten und Spiegel:

    ////////////////////////////////////////////////////////
        Kameras
    ////////////////////////////////////////////////////////


    0: Blick nach ganz links
[add_camera_driver]
-0.783
5.000
1.850
-0.10
62
-110
-5

    1: Blick nach schräg links
[add_camera_driver]
-0.683
4.700
1.850
-0.10
62
-70
-5

    2: Blick in den linken Spiegel
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
-20
0

    3: Blick nach vorne (std)
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
0
-5

    4: Blick in den rechten Spiegel
[add_camera_driver]
-0.665
4.650
1.850
-0.10
55
33
-5

    5: Blick zur Tür
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
70
-5

    6: Blick nach ganz rechts
[add_camera_driver]
-0.683
5.000
1.8
-0.10
62
115
-5

    7: Fahrscheinverkauf-Sicht
[add_camera_driver]
-0.683
4.650
1.8
-0.10
40
52
-36
[view_ticketselling]

    7b: Blick in den Rückspiegel
[add_camera_driver]
-0.713
4.650
1.850
-0.10
45
45
15
[view_schedule]

##########################
Linker Außenspiegel
##########################

[add_camera_reflexion_2]
-1.348
5.56
2.1
0
52
175
-10
0.1

##########################
Rechter Außenspiegel
##########################

[add_camera_reflexion_2]
1.4
6.12
2.2
0
52
195
-12.5
0.3

##########################
Innenraumrückspiegel
##########################

[add_camera_reflexion_2]
0.100
5.348
2.3
0
40
200
-18
0.05

##########################
Innenraumrückspiegel-Zoom
##########################

[add_camera_reflexion_2]
0.100
5.348
2.3
0
12
200
-16
0.05

[add_camera_reflexion_2]
0.100
5.348
2.3
0
10
200
-16
0.05

[add_camera_reflexion_2]
0.100
5.348
2.3
0
18
200
-16
0.05

Für eine Performance-Spar-Variante, wo der linke Spiegel wirklich nur gerendert wird wenn man in die Ansicht links der Standardsicht schaltet könnte man aus obigem Beispiel nur den Spiegel-Teil nehmen, und dann vom linken Aussenspiegel die letzte Zeile etwas nach unten tunen, denn bei 0.1 könnte es noch sein dass dieser in der Standardsicht rendert. Vielleicht reicht hier statt der 0.1 schon 0.08. In der City würde diese Änderung einen Unterschied von 30% in den fps ausmachen, also z.B. statt 20 fps hätte man 26. Das wäre dann gewünschte Effekt dieser Sichten.

Wie gesagt, das Beispiel ist aus dem LE, ich nehme aber mal an dass es auf die anderen Citaros übertragbar ist. Wichtig beim Testen ist dass dabei die Kopfbewegungen an sind und man auch ordentlich Gas gibt und die Eisen gehet, denn dadurch ändert sich die Kopfposition, und innerhalb dieser Toleranz müssen die Werte immer liegen.

Zitat von beedle der barde

So extrem vermutlich schon nicht ganz.

Das (wahrscheinlich) grösste Problem von Omsi ist, dass es (vermutlich wegem Alter) die CPU-Kerne nicht sinvoll nutzen kann. Bei mir sind zwei Kerne dauerhaft auf 100% Auslastung, einer auf 80% und die restlichen 3 im bereich von 0-30%. Eigentlich sollte es ja ausgeglichen sein.

Eine i9 mit mehr Kernen wird also nicht sehr viel helfen, da geb' ich dir recht. Aber die höhere Taktfrequenz dürfte schon ein bisschen 'was ausmachen.

Bis zu 4 Kerne werden genutzt: eins davon hat die Hauptlast, die anderen 3 baumeln um die 50%, was aber nicht zu unterschätzen ist. Daraus ist abzuleiten dass OMSI bis höchstens von 6 Kernen profitiert. Warum 6? Weil dann headroom fürs Betriebssystem und andere Hintergrunddienste bleibt die OMSI weniger in die Quere kommen. Bei AMD Ryzen 1000er/2000er Serie gibts eine Ausnahme: hier ist 8 Kerne das Optimum, da man dann OMSI in einen eigenen CCX mit seinen 4 Threads zwingen kann. Wenn OMSI auf diesen Prozessoren auf beiden CCX verteilt läuft gibt es kleine Einbußen. Ein 6-Kerner hätte da Nachteile. Ab Ryzen 3000 sollte dieses Phänomen aber keine Rolle mehr spielen, hier sollte ein 6-Kerner der Sweetspot sein, wenn der Takt hoch ist. Die höchsten Takte gibts aber mit nur mit mehr Kernen;-)

Ansonsten ja, perfekt wird das nie. Nicht mal sehr gut oder gut. Vergessen wir nicht dass es oft nicht die fps sind die einem den Spaß verderben, sondern das Gezuckel und Geruckel, weil OMSI es mal wieder nicht hinkriegt die kleinsten Datenmengen von A nach B zu schaufeln;-)

Definitiv sehr schön dieses Update, auch wenn das Addon schon älter ist. Trotzdem qualitativ immer noch eines der Besten. Ich wundere mich dass ich so wenig darauf gefahren bin;-D

Was mir aber auffiel ist dass es noch einige Kreuzungsobjekte gibt, die bei Regen nicht nass werden, also weder glänzen noch das Nässe-Geräusch machen. Akut könnte ich die Stellen nicht benennen, aber hier und da war es der Fall.

Was man sich auch noch vielleicht ansehen könnte sind die KI-Busse die am Bushof enden oder die Linie wechseln (ich glaube 47 auf 43). Die blockieren gerne den übrigen Verkehr, gerade wenn es Gelenkbusse sind. Vielleicht hier ein wenig mit den Würfeln und Einstellungen spielen. Bei den Linienwechslern fällt mir auch auf dass da das typische OMSI-Problem auftaucht, dass die neue Linie erst bei Abfahrt "einspringt". Ist zwar nur eine Kleinigkeit, aber man kann das mit den Profilen umgehen. Im alten Forum hatte ich mal einen Beitrag gemacht wo das super geklappt hat im Nachtverkehr der Linie 6 am Mainzer Hauptbahnhof. Vielleicht finde ich den und verlinke ihn noch hier.

Edit: Gefunden: https://forum.omnibussimulator…&postID=597085#post597085

Ich finde das DB-Logo bei der Zielanzeige "Bad Hügelsdorf Hauptbahnhof" ziemlich seltsam auf der linken Seite neben der Liniennummer. Das macht die ganze Anzeige inklusive Liniennummer ziemlich unsymetrisch und tut ehrlich gesagt in den Augen weh, gerade wenn die Liniennummer schon so dick ist. Wenn da schon ein Logo hin soll dann würde es sich auf der rechten Seite besser machen.

Es besteht weiterhin (Schilder). Und ich befürchte es bleibt so bis sich der Entwickler dem mal annimmt (wovon ich nicht ausgehe) oder es tatsächlich jemand mit viel Ahnung von der Materie entsprechend moddet.

Bei den Türen habe ich mir halbwegs beholfen mit Umbenennen der entsprechenden Trigger im Script.

Zitat von Maerkertram

Weißt du, ob Omsi bei der Grafikeinstellung zur maximalen Anzahl KI-Umläufe das auf die geladenen Umläufe bezieht? Oder wählt er sich beim Spielstart schon Umläufe aus, von denen dann nur ein Teil zu der bestimmten Uhrzeit sichtbar ist?

Die Grafikeinstellung "Maximale Anzahl an Fahrplan KI" bezieht sich nicht auf Umläufe sondern Fahrzeugmodelle. Wenn nur Solo-Busse auf allen Linien fahren würden, dann wäre es natürlich gleichzusetzen mit Anzahl der Umläufe. Züge und Gelenkbusse bestehen aber aus mehreren Fahrzeugen.

Wie das OMSI nun auswählt ist aber etwas mysteriös. Kann nicht sagen ob das schon am Anfang geschieht oder on the fly. Wahrscheinlich aber letzeres, denn beim Neuladen der Situation werden die Fahrzeuge (leider) neu verteilt.

Zitat von Sherlock Holmes

Dass die Busse auch, wenn sie nicht mehr auf der Karte sichtbar sind, "geladen" bleiben, hat m. E. nach wahrscheinlich den Nutzen, dass gespeichert wird, welches der Fahrzeuge aus der AI-List in dieser Spiel-Session diesem Umlauf zugewiesen wurde. Denn so oft man auf denselben KI-Umlauf trifft, soll schließlich der exakt gleiche Bus zu sehen sein.

Gestaltet man sich nun den Fahrplan so um, dass ein Umlauf nur eine Tour enthält, oder wäre es OMSI-seitig so, dass mit dem Despawn der Bus vollständig "weg" wäre, würde das zwar der Performance guttun. Je nachdem, wie die AI-List gestaltet ist (ob sich alle Busse nur durch die Wagennummer unterscheiden, oder ob zig verschiedene Modelle mit unterschiedlichen Repaints zum Einsatz kommen), wie der Spieler Kenntnis von den Umläufen auf der Linie hat, und wie wichtig es ihm ist, immer dem gleichen Bus zu begegnen, wenn das in der Realität auch so sein müsste, brächte das aber wiederum Einbußen im Realismusgefühl, welches auf der Karte aufkommt.

Wenn man bspw. an einer Endhaltestelle immer auf eine KI-Linie trifft, und über Stunden hinweg jedes Mal ein anderer KI-Bus dort steht, wirkt das nicht so realistisch. Je nach Kartengröße fällt das eben mehr oder weniger auf.

Mir zum Beispiel ist es eher wichtiger, den Eindruck zu haben, dass der Gesamtbetriebsablauf auf der Karte realistisch ist, als ein paar FPS mehr zu erreichen. Anderen kommt es viel mehr aufs reine Busfahren an, während der KI-Busverkehr bestenfalls Nebensache ist.

Das ist richtig. Man muss natürlich abwägen auf welchen Linien es Sinn macht. Ich würde es beispielsweise auf X10 nur bei Zügen anwenden, und bei der Bus-KI dann nur bei denen reinen KI-Linien die nicht da Pause machen wo Spielerlinien enden. Ausnahme vielleicht am Zoo, in dem Bereich wird man von den Eindrücken eh erschlagen und würde als Spieler nicht so genau hingucken. Und da wo man bestimmte Busse/Wagenummern erzwingen möchte eventuell mit car_use Touren explizit Wagennummern zuweisen.

Man muss auch eins berücksichtigen: wenn Dir OMSI anfängt rumzukrebsen oder gar abstürzt und Du den Spielstand neu lädst, wird den Umläufen eh ein neuer Wagen zugeteilt und der von Dir beschriebene Effekt ist hin. Man kann halt nicht alles haben... Und bei Zügen ist es mir als Spieler echt wurscht ob am RE XY nun die 143-123-4 zieht oder die 143-432-1... Da ist es mir lieber der Zug macht Platz für andere Busse und ein paar fps wett.

Zitat von kendrick

Ich werf hier einfach mal Hardware Accelerated GPU Scheduling in den Raum, welches mit der Build 2004 ergänzt wurde. Es wäre mal interessant zu wissen, ob Omsi davon in irgendeiner Art und Weise

Hatte ich auch vor ein paar Tagen dran gedacht, weil es erst mit dem letzten Nvidia Treiber aktivierbar wurde. Hab aber wenig Hoffnung dass es irgendetwas in OMSI bringt, denn jegliche Treibereinstellungen brachten bis jetzt nichts, außer denen die einfach das Bild verbessern (AA, SSAA, SGRSTAA etc etc etc). Da kann man ja reinhauen fast was man will, OMSI ist dermaßen CPU lastig dass sich die GPU sowieso zu Tode langweilt, wenn sie nicht gerade von vor-vorgestern ist.

Zitat von Maerkertram

Grundsätzlich kann ich den Verlauf der Performance bestätigen und auch dass die einmal "gesehenen" Busse scriptmäßig irgendwie weitergeführt werden, selbst wenn sie nicht mehr sichtbar sind. Die Idee, dass die Fahrzeuge zum Ende ihres Umlaufs entladen werden, hatte ich noch nicht. Ich habe nämlich beobachtet, dass Busse oft einfach an der Kachelgrenze stehen bleiben.

Also Beispiel: Ich fahre um 8:00 im X10 vom Zoo nach Teltow. Um 8:05 fahre ich über die Kachel X und weil ich zügig fahre, gerät ein Bus hinter mir aus dem Sichtbereich. Um 9:30 komme ich aus der Gegenrichtung wieder auf Kachel X an. Mir kommt jetzt ein Bus entgegen, der schon von außen als die Fahrt von 8:05 Uhr mit +85 Minuten identifiziert werden kann (z. B. weil das KI-Ziel nur 1x am Tag geschildert wird). Hilft das vielleicht für eine Experimente?

Hatte ich so noch nicht beobachtet. Allerdings hätten sich dann doch gerade Abends wenn sich Aussetzfahrten häufen auch solche Situationen gehäuft. Oder im depot in den Hallen.

Bisher habe ich nur beobachtet dass wenn die Tour beendet ist, der Fahrplan also de facto fertig abgearbeitet ist, die Busse/Bahnen auch aus der Liste der Busse im Debugfenster verschwinden. Und natürlich dass je mehr Busse sich dort sammeln die Gesamtperformance auch mal gerne locker um 30% oder mehr gemindert wird. Ich glaube auf X10 auf höchster Fahrplanpriorität vor allem mit Zügen könnte man das ganz gut testen. Weil gerade Züge füllen die Fahrzeuganzahl extrem auf nach einer Weile. Wenn man also die Fahrpläne so beschneidet dass die Züge nach dem Despawn quasi fertig mit dem Fahrplan sind, müsste das einiges bringen. Das ist der Hintergedanke dabei, und ein erster Test auf der Szczecin Karte brachte auch positive Ergebnisse: die Fahrzeuge verschwanden aus der Liste. Der nächste Gedankengang wäre das auf reine KI-Buslinien auszudehnen. Gerade wenn diese durch Gelenkbusse bedient werden dürfte der Effekt spürbar sein. Wobei bei X10 wäre das glauib ich nur eine Handvoll von Linien. Allerdings könnte es beim Zugverkehr viel bringen.