Beiträge von wurstbrot

Willkommen in der OMSI-WebDisk!
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!

    Zu 32 Bit Zeiten (OMSI 1...) hatte ich OMSi in eine RAM DIsk gepackt und das flutschte wie Eis XD Deutlich besser als von SSD. Mit OMSI 2 wurde das Loading schlechter, RAM DIsk hat da nicht mehr gelohnt...

    Ich würde aber wieder mal probieren und mit den Werten rumspielen für den Texturspeicher. Oft genug hab ich da Probleme mit der 3GB-Grenze der exe, vor allem bei AI Listen mit viel Variation und Repaints. Meinen Trick mit dem zerschneiden von Umläufen wende ich auch nur ungern an.

    Ich schätze mal man müsste die gesamte Bahninfraktuktur inkl Bahnübergängen als eine Kreuzung bauen und dann improvisieren damit realistische Signalbilder rauskommen... Und auch entsprechend mit dem Fahrplan tricksen. Ist wahrscheinlich zu viel Erwartung an Tante OMSI. Ich bin ja schon verzweifelt am Richtungswechsel von KI-Straßenbahnen und bin immer froh wenn Züge aus einer Seite reinfahren auf die Karte, dann halten, und dann weiter fahren;-D

    Ums mal auf den Punkt zu bringen: viel mehr oder viel besser als der Bahnverkehr in TH umgesetzt wurde geht kaum. Und auch damit sind diverse "Phänomene" und Bugs nicht ausgeschlossen.

    Signaltechnisch simuliert OMSI glaub ich auch nicht ansatzweise korrekt den Eisenbahnbetrieb. Ich weiss nicht wie das im konkreten Fall ist, aber ich nehme mal an das ist genau wie bei Ampeln und Kreuzungen, und nicht nach Fahrstraßen mit Freimeldung.

    Ja, ist möglich dass das so läuft. So genau weiss ich das auch nicht;-D Auf jeden Fall knallt OMSI knapp über 3 GB Größe der exe durch, und meiner Beobachtung nach liegt das zu 99% an den Texturen. Nach einer dds-Kur bei wirklich schlecht texturierten Assets bessert sich das ja signifikant, und bekannterweise werden dds Texturen auch komprimiert im Video RAM gehalten. Und dennoch hilft es um die exe am Aufblähen zu hindern. Mir scheint es fast als würde da immer was im System RAM vorgehalten werden an Texturkram. Und OMSI vergisst schlecht: ein einmal erschienener Bus bleibt im Speicher samt Texturen bis sein Umlauf (!) beendet ist.

    0 ist unlimitiert ja. Nur ob das sInnvoll ist stelle ich mal in Frage. OMSI ist ein 32 Bit Programm, wenn man das also nicht limitiert könnte das bei Karten und Bussen die texturfressend sind schneller zum Problem werden als einem lieb ist. Der Gesamtspeicherverbrauch darf bei OMSI auf keinen Fall 2 GB ohne und 4 GB mit dem 4GB überschreiten. In der Praxis heisst es dass es knallen wird knapp über 3 GB Größe der OMSI.exe. Daher würde ich empfehlen da 2048 einzutragen wenn man an der kritischen Grenze ist. Sonst aber gerne 0.

    Kann gut sein;-D Aber auch seltsam dass ich das nicht mehr so beobachte. Ich hatte viel mit verschiedenen Arten der Begrenzung experimentiert um zu schauen wie sich da die Frametimes verhalten und dabei ist mir eben das nicht mehr aufgefallen. In OMSI ist es tatsächlich so dass mal in Stein gemeiselte Gesetze nicht ewig und vor allem nicht überall gelten, und man immer wieder alles hinterfragen muss. So hält sich bis heute die Mär man müsse als Texturspeicher 2/3 des Video-RAMs eintragen... Nun ja, 2012 machte es vielleicht Sinn, heute wäre das Unsinn XD

    Scheint dieses Phänomen von OMSI zu sein. Begrenze mal deine FPS auf 120, dann sollten es wieder 60 sein.

    Das ist aber in der Tat ein Phänomen. Ich hab (mittlerweile vor Jahren?) hier gelesen dass wenn man in OMSi die Framerate sagen wir mal auf 60 begrenzt, dann hat man generell niedrigere Durchnitts-fps als wenn man es auf ;Maximum belässt. Wohlgemerkt selbst wenn man die Grenze nicht erreicht. Konnte da snicht glauben, habs ausprobiert, und konnte das bestätigen. Mittlerweile, aber auch schon auf anderem System, sehe ich dieses Phänom nicht mehr. Also keine Ahnung wovon das abhängt...


    Grundsätzlich rate ich in OMSI die Begrenzung auf dem Maximum zu lassen und dann im Treiber oder RivaTuner auf was brauchbares zu begrenzen, und zwar auf das was man im Schnitt so auf seinem System und bei seinen Einstellungen in den meisten Situationen erreicht. 60 ist hier dann sicher ein guter Wert. RivaTuner glättet dann besser die Frametimes als der Treiber. Das fps Limit von OMSI ist grausam schlecht was das betrifft.


    Henry würd ich raten zunächst eben die fps-Begrenzung in OMSi hoch zu setzen und dann wieder in Grundorf zu schauen.

    Aber apropo Betriebshof:

    Ich finde es gut, dass man da den Halleffekt mit eingearbeitet hat. Mir war bislang kein Objekt bekannt, was diesen nutzte. :thumbup:

    Es gibt Brücken die haben das. Zum Beispiel in Spandau. Ich habe es allerdings irgendwann abgeschaltet da mir der Effekt zu künstlich erschien. An und für sich ist das aber eine gute Idee.

    dies bezüglich gibt es schon 2 Threads, vllt findest du da etwas was weiter hilft

    IVU in den Mercedes Benz Citaro o530G (Citybus o530 Kajosoft)
    IVU Drucker in Kajosoft Facelift einbauen

    Was sollen die erwähnten Threads mir sagen? In dem einen geht es darum dass jemand die Box nicht eingebaut kriegt und Hilfe braucht. Im anderen funktioniert die Matrix garnicht. Bei mir ist die Box eingebaut, funktioniert im O530, O530G, den Ü-Varianten und im O530 FL Solo ebenso. Und beim FL G gibnts die erwähntze Thematik, die mir unlogiosch erscheint.

    Ich hab das nicht geprüft, da ich den 4-Türer (und GL, und GÜ...) noch nicht verwendet habe, hab nur in der Datei des 4-Türers gesehen dass die Werte so sind wie beim 3-Türer. Und Dich hatte ich so verstanden dass das nur den 3-Türer betrifft.

    Dann gibts das erst ab Version 1.5, diese ist scheinbar noch in der Beta. Kannst Du beim Entwickler auf seinem Discord beziehen.


    Auto Sync / Logging ist für LS nicht relevant. Natürlich ist Abschalten des Loggens leicht positiv für die Performance.

    Etwas OT, hat aber auch mit Performance zu tun, und ist vielleicht was für Deinen Performance-Artikel: in AUXI gibt es diese Funktion zum Abschalten des Sleep-Befehls (oder so ähnlich...) das macht OMSI auch deutlich flüssiger. Kann aber hier und da Fehler bei der KI verursachen. habe aber nur auf zwei Karten Spawn-Probleme gesehen. Findet man im Menü unter Einstellungen als "No Sleep Patch".


    Nur zur Klarstellung: bei der Problematik mit LS geht es nur um das HUD, alle anderen AUXI Funktionen sind nicht betroffen. Man braucht nicht auf das Tool verzichten.

    Sind das nicht die LS-Einstellungen, die du hier ein paar Beiträge zuvor gepostet hast?


    Diese hier

    Das kann ich Dir nicht mehr sagen, da von Version zu Version sich bei LS immer mal was verändert hat. Früher habe ich auch den 2-fach Modus genutzt, jetzt den 3-fach. Zwischendurch auch den adaptiven, bin aber davon wieder auf 3-fach zurück, empfand den als stabiler.


    Solche HUDs sind wohl generell problematisch. Hier muss man gucken ob sich bei neuen Versionen nicht was tut. Wie gesagt, Das AUXI HUD alleine verursacht bei mir Mikroruckler. Ist zunächst kaum wahrnehmbar, aber wenn ich dann auf die parkenden Autos an der Seite schaue merk ich es deutlich. Schalte ich das HUD ab, ist alles top. Wird wohl daran liegen dass LS selbst eine Art Overlay ist und es dann eben Konflikte gibt.


    Ein Thema ist auch Tearing. Wenn man insgesamt seine Bildschirmwiederholfreunz überschreitet bekommt man es logischerweise mit Tearing zu tun, für welches es Vsync und Gsync gibt. Das kuriose im LS ist (zumindest bei mir) dass ich Tearing habe wenn Sync Modus auf Standard ist, nicht aber auf Off. Daher stehts bei mir eben auf Off. Da muss man also für sich raustüfteln was am Besten ist Man kann das gut testen wenn man sich zum Beispiel in Grundorf an eine Kreuzung stellt und die von links nach rechts und umgekehrt fahrenden Autos beobachtet. Sie zuckeln furchtbar bei Tearing. Dann spielt man damit rum bis der Effekt weg ist. Bei niedrigen fps weit unter der Grenze des Monitors werden Ihr das nicht haben. Und auch wenn Global ein entsprechender Limiter greift, der scheint nicht immer die generierten Frames auch zu limitieren.

    Ich hab da global ein Limit auf 142 fps, OMSI aber separat auf 60. Müsste mit global auch funktionieren.


    Ich weiss nicht mehr was im LS die default Einstellungen waren...