Beiträge von wurstbrot

Wenn ein gutes Modell schon da ist kann man es ja nehmen wenn man sich mit dem Ersteller einig ist. Man muss es doch nicht zwingend neu bauen, außer es gäbe Funktionen die man haben möchte und die das eben erfordern. Oder ich kann und will es besser machen...

Zitat von Citea 1998

Wann MAN E

Ein E wäre fast ein Neubau... Das ganze Fahrzeug ist zum Beispiel deutlich höher. Außerdem ist der NLC so leise, da braucht man keinen E...

Muss natürlich jeder selber wissen. Wegen 30€ Unterschied bei der Grafikkarte würde ich nicht die alte Generation wählen, ganz besonders nicht gerade. Grundsätzlich würde ich heute auch keine 8 GB Karte mehr kaufen sondern dann entweder zur 16 GB Version greifen oder zur 4070 mit 12 GB. Wenn der Geldbeutel das nicht zulässt dann aber ginge es zur Not mit 8 GB. Wer in 1080p mixt Ultra-High Texturen spielen will der ist selber schuld, das ist nix für solche Auflösungen sondern für WQHD aufwärts, und selbst da sehe ich schon kaum Unterschiede. Wenn man 4K spielen will dann nimmt man eh eine potentere Karte und da ist dann schon sowieso mehr VRAM drauf.

Bei TramSim glaube ich aber das liegt daran dass das Spiel alles andere als optimiert ist und nicht an der Engine. Deren neues Spielt zuckelt auch mit mässiger Grafik vor sich hin wie ich so auf Videos gesehen habe, das ist kein Maßstab;-)

Die Verfügbarkeit des 5600X3D ist in der Tat ein Problem. Ich behaupte aber mal dass es zur Zeit die Beste CPU für Spiele wie OMSI ist was Preis-/Leistung betrifft, denn man muss bei den anderen Modellen die da heranreichen deutlich tiefer in die Tasche greifen. Leider findet man aber nirgends wirklich handfestes, ich kann auch nur Daten für den 7900X liefern und nur annehmen dass die 3D-Varianten da noch einen drauf setzen. Mit Blick auf die Zukunft ist der 5600X aber nix, da würde ich eher auf einen 7600X spekulieren oder halt je nach Preis die 8 oder 12 Kerner.

Raytracing und DLSS wird ein Thema, da immer mehr Spiele im Sim-Bereich auf die Unreal Engine setzen. Ich denke gerade Fahrsimulatoren werden enorm davon profitieren, allein wenn ich ans Regenwetter und Pfützen denke. Und DLSS relativiert dann den FPS-Verlust durch Raytracing und sieht sogar auf Balanced besser aus als so manches SuperSampling-AA.

Die 3000er Serie von NVidia und ältere würde ich nicht mehr bei Neuanschaffungen empfehlen. Einzige Ausnahme: wenn sie bei ähnlicher Leistung deutlich günstiger ist als die 4000er und wenn man absolut nicht vor hat irgendein modernes Spiel zu spielen. Der Grund ist DLSS 3.0, welches es erst ab den 4000ern gibt. Gerade im Zusammenspiel mit Raytracing ist das eine grandiose Technik, die ein qualitativ hochwertiges Antialiasing bietet bei sehr hoher Leistung. Die fps sind deutlich höher als mit klassischen AA-Technologien, sodass die 4000er Karten hier den Vorgängern davon rennen.

Bei der CPU würde ich aber überlegen wenn schon 6 Kerner dann den Ryzen 5600X3D zu verbauen. Wenn Spiele wie OMSI hauptsächlich gespielt werden dann ist die 3D-Cache Technik vorzuziehen und dürfte einen spürbaren Unterschied machen zu einem vergleichbaren Prozessor ohne.

Beschreib mal was genau Du mit Mikrorucklern meinst. Meinst Du die Nachladeruckler oder hast Du Bildabrisse zum Beispiel beim umdrehen?

Bei Nachladerucklern gibt es eigentlich keine Dinge die man noch tun könnte wenn man eine SSD verwendet. Sie werden interessanterweise aber besser wenn das System insgesamt mehr fps schafft. Ich schätze mal weil die SSDs schnell genug sind, OMSI aber zwischen den Frames nachlädt, ergo mehr fps -> kürzeres Nachladen dazwischen.

Die Bildabrisse, falls es sich um sog. "Tearing" handelt, fühlen sich oft wie Ruckler an, kommen aber davon dass Monitor und Grafikkarte nicht synchron laufen: zum Beispiel hat ein 60 Hz Monitor quasi immer 60 fps, die Grafikkarte liefert aber unterschiedliche Bildraten, wie Du am fps Zähler siehst. Abhilfen hier gibt es einige: VSync einschalten, oder Einstellungen so konfigurieren dass man immer nur 60 fps hat (Limit auf 60 und Settings so dass diese locker geschafft werden). Am Besten hat man es hier mit G-Sync oder Freesync, das schafft das Problem quasi ab, man braucht aber spezielle Monitore und kompatible Grafikkarten. VSync löst es auch, hat aber einige Nachteile wie leicht verzögerte Reaktionszeit und niedrigere fps, da es die Frequenz teilbar mit der des Monitors macht damit die Bilder stimmen: 60/30/20/15/10 fps bei 2-fach Puffer.

Zitat von Hamburg

Auflösung, Größe und Bildfrequenz sind dabei komplett dir überlassen und haben nicht wirklich einen Einfluss auf die Performance von Omsi.

Da musst du einfach schauen was du dir leisten kannst und was für dich persönlich wichtig bei einem Bildschirm ist

Jein. Es ist zwar relativ egal ob man in OMSI 4K oder 1080p darstellt für die Leistung, allerdings sollte man sich überlegen ob nicht G-Sync oder Freesync als Technik eingesetzt werden könnte. Insbesondere bei niedrigeren Frameraten fühlt sich das geschmeidiger an. Jetzt muss man aber genau schauen von wo bis wo die G-Sync/Freesync-Range geht. Ich würde die Finger von lassen wenn es erst ab über 40Hz/40fps aktiv wird, sondern schauen dass es zumindest bei 30 losgeht, wenn nicht gar noch tiefer. Denn drunter wird dann VSync mit seinen Nachteilen aktiv. Würde aber hier auch nicht zu viel Aufpreis in Kauf nehmen, denn G-Sync und Freesync sind für manche Zickereien bekannt, und es ist dann auch blöd wenn man es nicht einsetzt. Wenn es aber läuft ist das definitiv super und man möchte es nie wieder missen.

Und dann zur Prozessordiskussion:
"Es sollte ein i7 sein": 2008 hatte ich einen i7, der würde heute von jedem i3 gegrillt werden. Wenn dann schon genauer sagen welcher empfohlen wird. Ich würde da mir mal die Single-Core-Leistung in Benchmarktabellen angucken und schauen was das Portmonee sagt. Stand Juli 2023 dürften in OMSi die Ryzen 7XXX 3D-VCache Prozessoren so ziemlich alles locker wegfegen was auf dem Markt ist, und da gibt es durchaus halbwegs günstige Modelle.

Ich muss das Thema leider wieder aufgreifen und richte mich vor allem an Windows 11 Nutzer. Nach dem Umzug auf neuen Rechner läuft OMSI eigentlich top. Performance ist erste Sahne, ich sehe aktuell auch keinen Bedarf DXVK (Direct X to Vulkan) einzusetzen. Jedoch bekomme ich das berüchtigte "Direct3D Device Lost" wenn ich manchmal (nicht immer) während OMSI läuft ein weiteres Programm starte. Wenn die Programme bereits laufen kann ich zu ihnen aber problemlos wechseln. Zu 100% kann ich diese Meldung auslösen mit Drücken von STRG ALT ENF zum Start des Task Managers, wunderbar vor allem mit dem OMSI Editor testbar.

Das ganze passiert nicht bei Einsatz von DXVK.

An sich läuft OMSI dann aber stabil, kann ohne Probleme zum Teil mehrere Stunden fahren.

Ich glaube das hängt mit Windows 11 zusammen, da unter Win 10 es da keine Probleme gab. Ich habe auch diverse Kompatibilitätsmodi probiert, da ändert sich das Verhalten aber nicht. Wäre also für mich interessant ob das bei Euch mit Windows 11 (da vor allem bei NVidia Grafikkarten) ebenfalls so auftritt und ob und wie ihr es gelöst hattet. DXVK möchte ich im Moment eher nicht einsetzen, da es keine AA-Modi zulässt und nachts Probleme mit dem Kachelladen hat.

Grob die Hardware: Ryzen R9-7900X, 32 GB RAM, RTX 4070, Windows 11 Pro

Zitat von Maerkertram

Eine Lösung habe ich zwar nicht anzubieten, aber in meiner Erfahrung kann ich sagen, dass ich sowas noch nie bemerkt habe. Ich denke, dass geht dir aber genauso, insofern ist es nur eine Bestätigung. Der T&T der Rückfahrt hat als ersten Würfel die Pausenhaltestelle?

Meine Erfahrung bei X10 war in Omsi 2 ebenfalls, dass Busse an der Endstelle zuverlässiger mit dem alten System spawnen. Sprich, wenn man zur Endstelle fährt (bzw. sich dorthin bewegt), war bei StnLinks seltener der planmäßig wartende Bus gespawnt. Deshalb waren dort auch bei bestimmten Linien noch die T&T in Verwendung, obwohl die meisten Linien mit StnLinks umgestellt wurden.

Ja, die Pausenhaltestelle war in allen Situationen letzte des Hin-Trips und erste des folgenden.

Mittlerweile habe ich die Profile etwas umgestellt und das Verhalten so nicht mehr gesehen. und zwar habe ich bei den zweiten Haltestellen (also nicht die Pausenhaltestelle sondern Einstiegshaltestelle) das "Wait until departure time" bzw "Always & Wait...") rausgemacht und gegen "On Demand" oder "Always" ersetzt und sehe das Phänomen irgendwie nicht mehr. Irgendwas könnte also damit sein. Aber unlogisch, denn warum sollte es ausgerechnet an der zweiten Haltestelle im Plan problematisch sein? Die Entfernung beider Haltestellen ist glaube auch egal, da auch die Linie E522 betroffen war, die an der Galenstraße Pause macht und dann ja erst ein gutes Stück zum Rathaus vorfährt.

Sehr komisch war auch dass dann die Busse zum Teil schon ewig vor der Abfahrtzeit des Folgetrips umgeschildert hatten. Normal passiert das ja bei der Abfahrt.

Ja, mittlerweile kann ich bestätigen dass bei StnLinks Busse haufenweise an den Endstationen nicht gespawnt werden, aber auch unterwegs. Bei T&T ist es mir zumindest nicht mehr aufgefallen wenn ein Bus mal nicht kam.

Moin!

Kurioses aus dem Stadtbus O405:

Wenn es draußen viel wärmer oder kälter ist als innen und man das linke hintere Klappfenster öffnen steigen oder fallen die Innenraumtemperaturen extrem schnell. Das passiert nicht bei allen anderen Klappfenstern, nicht beim Fahrerfenster und auch nicht bei den Türen. Nur beim besagten Klappfenster hinten;-D

Ich hab mir das Heizungsscript angeschaut, das sieht mir aber fast eins zu eins gleich mit den M&R Bussen, sehe auch nicht dass da irgendwo andere Werte wären für eben dieses Fenster... Was hat es also damit auf sich? Ich vermute beim O405G wird es ähnlich sein, hab es aber da noch nicht ausprobiert.

Bei BBS müssen alle Fahrpläne gleich sein, also was Du auf dem Rechner hast muss denen auf dem Server entsprechen. Daher funktionieren Linienerweiterungen etc auch nur wenn die per Hand von PeDePe auf den Server zur Verfügung gestellt werden. Ich nehme mal an dass BBS irgendwie die Dateien vergleicht zwischen Server und Deinen lokalen, und wenn es Abweichungen gibt dann gilt das als modifiziert/ungültig. Ich weiss jetzt nicht ob da mit Checksummen gearbeiotet wird, Dateigrößen oder was auch immer, aber offenbar hast Du dadurch nicht mehr den originalen Fahrplan und es geht deshalb nicht.

Anscheinend ist es auch bei aktuellen CPUs so dass OMSI mit der SingleCore-Leistung mehr oder weniger eins zu eins skaliert, oder sogar noch besser. Ich hatte beim Wechsel von Ryzen 7 1700X auf Ryzen 9 7900X erwartet dass mit viel Glück sich die fps verdoppeln, da in der SingleCore Leistung der neue etwa doppelt so stark ist. Bei den ersten Versuchen in OMSI sieht es aber nun danach aus dass man mehr als doppelt so viel fps bekommt. Gemessen Nachts am Rathaus Spandau steigerten sich die Bildraten von knapp unter 30 auf über 75fps. Unterwegs kam ich dann in Spandau jenseits der 150. Werte die ich wenn überhaupt in Grundorf mal gesehen habe. Es war die gleiche Situation und die gleichen Optionen von "früher", nur noch nicht optimiert.

Wäre mal interessant wie sich die Vcache CPUs hier so machen, ich glaube die wären perfekt für OMSI.

Fakt ist: die Aussagen die man so häufig liest dass für OMSI neue Hardware sinnlos ist stimmen ganz und garnicht. Sie stimmen nur im Hinblick auf die Grafikkarte.

Zitat von Maxi G

Achso okay, ich kann mir auch nicht vorstellen das der Bus in echt Ansagen unterstüzt hat. Danke dir für den Hinweis mit dem Warnton. Was ich mir wünschen würde, wäre eine Readme auf Deutsch.

Das hing vom Betrieb ab. Speziell an SL200 mit Ansagen kann ich mich nicht erinnern, allerdings an O305(G) die mit IBIS-Gerät und automatischen Ansagen Mitte/Anfang der 90er nachgerüstet wurden. Würde mich also nicht wundern dass man es auch im SL200 hier und da getan hat. Übrigens "IBIS 1", von dem es hier immer heisst der kann keine Ansagen;-D

Zitat von PingPong

?

In meiner Mod muss die Haltestellenbremse eingelegt werden um die Türen zu bedienen. So wie beim SD eben…

Achso, wunderbar, dachte Deine Mod hätte das nicht geändert, insbesondere auch bei der Vordertür.

Ich schrieb ja schon von den Problemen als KI, dass die kein Kennzeichen haben. Das hab ich auf Grundorf ausprobiert. In Spandau ist mir der Wagen lustigerweise nie als KI Begegnet, obwohl er in den AI-Listen eingetragen ist und fast den gleichen Linien zugewiesen ist wie der O305 und O405. Seltsam. Eintrag ist korrekt, merk ich im Busauswahlfenster beo aktivem Häkchen für "Nur dem Hof zugehörige Busse anzeigen" - dann hab ich genau die Nummern wie in der AI List zur Auswahl - stimmt also eigentlich alles.

Die Türen sind wohl auch leider völlig unabhängig von der Haltestellenbremse. Vielleicht wäre das auch etwas für den AutoDoor-Mod? PingPong

Genau, die Gültigkeit in der global.cfg scheint ebenfalls eine wichtige Rolle zu spielen. Trotzdem wird man immer mal Linien haben wo man einfach nicht dahinter kommt warum es nicht klappt. Und dort ist es dann irgendeine Banalität.

Ja genau, bei den Liniennummern ist das wie bei Kurbel-Zielrollband. Hat mich auch nie gejuckt da ich vor zig Jahren beide Events auf die gleiche Taste gelegt hatte. Erst mit Lenkrad und LS-Seitenkonsole hab ich gemerkt dass es verschiedene Trigger sind.

Bei dem habe ich noch gar nicht geschaut. Dann vermute ich mal dass da eigene Trigger verwendet werden und nicht die standardistierten. Allerdings gibts bei den standardisierten auch zwei Varianten. die einen heißen Rollband vor/zurück und die anderen Rollband kurbeln vor/zurück, oder so ähnlich. Erste kommen zum Beispiel bei SD77 etc zum einsatz, die anderen dann wo man wirklich kurbelt und nicht nur je eins weiterschaltet.

Perfekt richtig ist in dem Zusammenhang nicht immer perfekt;-D Das ist sowas von kleinlich, es wird Dir kein fehler verziehen, und das kann schon ein TAB irgendwo zu viel sein.

Grundsätzlich sehe ich keinen Unterschied bei der Verwendung ob Du Trips&Tracks nutzt oder StnLinks. Bei der Bennenung vermeide ich Leerzeichen im Dateinamen, auch wenn ich keinen Beleg dafür habe ob es was bringt. Die wichtigsten Zuweisungen, also wo es mir besonders drauf ankommt, schiebe ich alphabetisch nach oben (A_xxxxxx.ocu vor B_xxxxxx.ocu), oder wenn ich sehe dass OMSI bei irgendeiner Linie das nicht schluckt.

Wenn ich 2 Dateien für eine Linie habe im gleichen Zeitraum kommt die spezifische nach der allgemeineren. Zum Beispiel: Wochenendkurse mit type_tour zuerst und dann die Datei für die ganze Linie. Dann scheint OMSI an Wochenenden die überlagernde zu nehmen. Weiss aber nicht ob es andersrum auch klappen würde, so hab ich gesehen geht es aber.

Ganz wichtig: penibel auf das Gültigkeitsdatum achten und versuchen keine Busse aufzuführen die es zum gegebenen Zeitpunkt in der AI Liste nicht mehr gibt oder noch nicht gibt. In der Theorie sollte das egal sein, aber ich hab so das Gefühl dass dies zu Problemen führt. Wenns geht also vermeiden.

Trotzdem wird das ganze nicht immer hinhauen, weil es einerseits die erwähnten Fehler irgendwo in der AI List geben kann, und es gibt da noch viele unbekannte oder Bugs.

Das Rollband funktioniert über das Borse-Steuergerät, ähnlich wie beim SD83-RLB. Es reagiert also nicht auf die Trigger für das Kurbeln. Das macht auch Sinn so.