Beiträge von ma7t3

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!

  • E-Citaro Hamburg, jede Veränderung an bestehendem Repaint für zum silbernen Bus

    Moin, die einfachste Lösung wäre, die Deckkraft des Busses weit runter zu stellen (auf z.B. 10-15%).


    Wenn du sauber arbeiten willst, musst du mal im Repaintordner schauen, dort dürfte es irgendwo einen Templates-Ordner geben (ich habe den E-Citaro nicht, von daher hier am E-Citaro G des Linie20-Teils:



    Die mit "AL" bezeichnete Datei ist die Alphamaske, sie legt fest, wo auf dem Bus wieviel Alphakanal (normalerweise für die Transparenz) vorliegt.

    Die sauberste Lösung wäre also, genau diese Datei als Alphamaske über dein Repaint zu legen. Ich kann dir aber leider gerade nicht genau sagen, wie das in Paint.net am besten geht, da ich das Programm normalerweise nicht verwende. :)

  • omsi startet net

    Zitat von DarkStar2604

    Für mich liest sich das so, als ob das Spiel selbst startet, allerdings deine ausgewählte Map nicht.

    Naja, zumindest, wenn das oben gepostete Logfile vollständig ist, ist da eigentlich relativ offensichtlich, dass es beim Punkt "Download Internet Textures..." plötzlich abrupt endet.

  • omsi startet net

    Deine Antwort ist jetzt für mich gerade etwas widersprüchlich bzw. unverständlich:

    Zitat von Theworstomsidriver

    ach und ich hab keine passagiere die auf der map spawnen auch keine autos aber mit der ai liste stimmt alles

    Wie konntest du das feststellen, wenn dein OMSI garnicht startet? Oder wie soll ich das verstehen.



    Zitat von Theworstomsidriver

    ich kann leider die itx dateien nicht löschen.

    Wieso kannst du sie nicht löschen? Du kannst auch die Dateiendung sonst einfach von "itx" auf etwas anders ändern, sodass OMSI die Datei ebenfalls nicht mehr erkennt (z.B. "_itx").

    Sofern dein oben gepostetes Logfile vollständig ist, bricht es nämlich bei dem Punkt "Downloading Internet Textures" ab. Das ist ein relativ typischer Fehler, der zum abstürzen, von OMSI bereits beim Start führt, wenn dort ein Problem vorliegt. Und da itx-Dateien die Dateien sind, in denen die Internettexturen definiert sind, hilft es normalerweise, genau diese außer Kraft zu setzen.

  • omsi startet net

    Moin,


    ich tippe auf ein Problem mit Internettexturen bei dir.

    Geh mal in deinem OMSI-HVZ in den Texture-Unterordner (also OMSI 2\Texture) und schau, ob du da irgendwelche *.itx-Dateien findest.

    Falls ja, lösche sie testweise, bzw. schiebe sie irgendwo anders auf deine Festplatte als Backup, wo OMSI sie nicht mehr findet und versuche es dann nochmal. :)

  • Bus wird nicht gespawnt

    Moin,

    dir fehlt ein Haufen an Variablen. Bist du sicher, dass du die in der Readme angegebenen Voraussetzungen korrekt installiert hast:

    Zitat von Readme.txt

    - MB Citaro Facelift von Helvete (mindestens) v1.4

    - Morphis Soundpack für den Facelift (mindestens) v1.1

  • Screenshots - OMSI

    Spätschicht im Nachtverkehr

    Hab zugegeben auf den Fahrten stadtauswärts die Verfrühung auch nicht mehr abgewartet, weil eh absolut niemand um 2:30 groß mit wollte und konnte am Ende rund 5 Minuten früher nach Eichenhöhe einrücken. ^^

    Auf einer Fahrt in der Gegenrichtung davor bin ich Nochem mit +11 richtung Hbf gefahren, weil ich meinen Bus noch reparieren musste, habe es aber trotzdem mit etwas zügig fahren locker geschafft, bis zum Hauptbahnhof die Verspätung auf ca. +3 runterzufahren. xD



    Ahlheim V4 | Nachtlinie NE8 | Setra S415NF

  • Alle Repaints von einem Bus weiß

    Du hast hier eine Reihe von Scriptfehlern, die darauf hindeuten, dass du mindestens eine Script-Datei nicht richtig eingebunden hast, da einige Macros nicht gefunden werden können.

  • [texchanges] - bisher recht unbekannte Möglichkeit für einfachen Texturtausch bei Objekten und Fahrzeugen

    Moin liebe OMSI-Gemeinde,


    Dass im Zusammenhang mit Fahrzeugen oder Szenerieobjekten manchmal auf einem bestimmten Mesh eine statische Textur nicht ausreicht, sondern es stattdessen notwendig wird, während des Spiels zwischen verschiedenen Texturen zu wechseln, ist erstmal nichts besonderes und findet häufig Verwendung (man denke z.B. an Repaints bei Bussen, Fahrscheindrucker mit verschiedenen Menüs oder Haltestellenwerbungen bzw. seperate Werbetafeln, gerade bei letzterem soll oft auch eine zufällige Textur gewählt werden).


    Gerade weil das ein relativ triviales Problem ist, biete OMSI gleich mehrere Möglichkeiten an, einen solchen Texturtausch umzusetzen, zwei davon sind (würde ich mal sagen) relativ weit verbreitet und bekannt, allerdings gibt es noch eine dritte Möglichkeit, die scheinbar in der OMSI-Community bisher noch kaum Verwendung findet, die ich deshalb hier nun einmal kurz vorstellen möchte. - Vielleicht gibt es hier den ein oder anderen der das Prinzip schon kennt, in meinem ganzen OMSI-Verzeichnis habe ich jedoch keinerlei Objekte und Fahrzeuge finden können, die es verwenden - mit Ausnahme des Spandauer Doppeldeckers von Marcel eben - dort wird es verwendet, um die Rollbandtexturen durchzuwechseln.


    Bevor ich jetzt damit anfange, vielleicht nochmal eine ganz kurze Übersicht über die anderen Möglichkeiten:

    1. [matl_freetex]

    Die mMn. simpelste und am einfachsten zu verstehende Möglichkeit ist die Verwendung des [matl_freetex]-Befehls, damit können wir einfach eine auf einem Mesh bestehende Textur als Variabel definieren und mit einer Stringvariable verbinden, die Stringvariable kann dann während des Spiels beliebig von einem Script verändert werden und somit sehr einfach die Textur durchgetauscht werden. [matl_freetex] findet vor allem bei Fahrscheindruckern Anwendung, um die Bildschrimtexturen (=Menüs) durchzuschalten - je nach dem, was gerade angezeigt werden soll. Der Vorteil hier ist, dass man sehr flexibel ist, da man im Script in die jeweilige Variable quasi alles eintragen kann, weshalb es vor allem praktisch ist, wenn man aus einem Pool von sehr vielen (teilweise in Unterordnern sortierten) Texturen auswählen muss. Allerdings ist die Gefahr auch groß, versehentlich eine Textur zuzuweisen, die garnicht existiert, was im Spiel dann natürlich unschön aussieht. Außerdem ist es mit Freetex ziemlich aufwendig, eine Textur zufällig auszuwählen (man würde dafür ein recht komplexes Script mit vielen if-Blöcken benötigen - je nach dem, wie viele mögliche Texturen es gibt.

    Daher gibt es noch eine andere, sehr bekannte, Möglichkeit:

    2. Klassische "Repaints" ([CTCTexture])

    Überlicherweise bei Fahrzeugen für das Repaint verwendet - aber auch bei Objekten (z.B. Werbetafeln) oft gesehen bzw. selbst früher immer dafür verwendet. Das "CTC"-System. Das Prinzip ist hier etwas anders: Man definiert separat in einer CTI-Datei ein Texturschema und legt die Datei in einem Ordner ab. Per Script kann dann über eine Index-Variable einfach entschieden werden, welches Farbschema aktiviert werden soll (für zufällige Texturen weist man dann eben eine zufällige Zahl in richtiger Range zu). Auch hier gibt es noch zwei weitere große Vorteile gegenüber dem Freetex-System (abgesehen von der einfacheren Umsetzbarkeit von Zufallstexturen):

    Zum einen ist das ganz sehr einfach mit neuen Texturen erweiterbar: Ich kann einfach neue Texturen im Ordner ablegen, eine cti-Datei erzeugen, mein Repaint entsprechend eintragen und zack - fertig ist es. Keine Notwendigkeit, irgendwo im Script, der model.cfg oder dergl. etwas herum pfuschen zu müssen (gut bei Zufallstexturen müsste man ggf. noch die Range bei der Generierung der Zufallszahl anpassen, aber trotzdem: mit freetex wäre es um einiges einfacher).

    Außerdem ist dies die einzige, elegante Möglichkeit, Texturwechsel als "Paket" zu definieren. Wir kennen das alle von Bus-Repaints. Wir haben eine Textur für den Wagenkasten, aber dann noch eine weitere für den Innenraum, Sitze nochmal separat usw. Dennoch sollen alle diese Texturen als ein Paket zu verstehen sein und gemeinsam ausgetauscht werden. Auch das geht hier natürlich sehr leicht.

    Doch es gibt auch hier natürlich aus meiner Sicht auch einen Nachteil: Aufgrund der hohen Flexibilität ist die erstmalige "Einrichtung" einer CTC relativ aufwendig - gerade bei Objekten ist das konfigurieren in der sco, sowie das anlegen der Werbungen in cti-Dateien relativ viel Schreibarbeit für ein paar Tauschtexturen. Geht das nicht einfacher? Lange dachte ich "nein", aber doch es geht! Und wie? Das zeige ich jetzt:

    3. [texchanges]

    Hier haben wir nun die neue "Entdeckung". Das Prinzip der texchanges ist ähnlich, wie bei CTC. Es wird eine separate Konfigurationsdatei angelegt, in der alle eintauschbaren Texturen eingetragen und mit einer Zahlvariable verbunden werden können. Über diese Variable kann dann einfach indexbasiert gesteuert werden, welche Textur verwendet werden soll. Im Gegensatz zu CTC können wir hier keine Texturpakete definieren, sondern immer nur einzelne Texturen tauschen, das ist aber in den meisten Fällen (z.B. bei Haltestellenwerbungen ja auch völlig ausreichend). Dafür ist das ganze doch um einiges kompakter und dennoch relativ Robust, da wir die Texturnamen dennoch separat in einer Datei festlegen und nicht (wie bei freetex) direkt in das Script schreiben müssen.


    Als Beispiel und zu Demonstrationszwecken soll nun mal eine Werbeteafel mit vier verschiedenen Testwerbungen erstellt werden. (Bitte nicht über das Model beschweren, das ist hier ein spontaner "One Minute Craft" - es geht ja nur um das Prinzip.

    Wichtig ist - wie eigentlich - immer, dass ich in Blender auf der Texturfläche, die später getauscht werden soll, eine entsprechende Textur zuweise, überlicherweise verwendet man für so etwas eine Dummy- oder "Leer"-Textur, in meinem Fall habe ich nun einfach die erste Werbung "Werbung_01.dds" zugewiesen. An sich ist das völlig egal. Ihr müsst nur genau wissen, welche Textur ihr in Blender zugewiesen habt. :D


    Ansonsten habe ich einfach nur ein ganz normales Szenerieobjekt mit sco-Datei, model-Ordner mit o3d-Datei und texture-Ordner mit meinen Werbungen erstellt. In meinem Fall liegen alle Werbetexturen direkt im Texture-Ordner und heißen "Werbung_01.dds" bis "Werbung_04.dds". Natürlich kann man auch noch einen Unterordner verwenden, das geht genau so. Man muss dann eben nur die Texturpfade entsprechend anpassen.


    Aber jetzt kommt die Magie:

    Zusätzlich zur sco-Dateie erstelle ich noch eine cfg-Datei, die ich nun "Werbetafel_chtex.cfg" nenne. Auch hier gilt. Der Name ist aber völlig egal, ich muss ihn nur gleich richtig in der sco einbinden.

    Diese cfg-Datei bekommt nun folgenden Inhalt:


    Code: Werbetafel_chtex.cfg
    [newtexchangemaster]
Werbung_01.dds
WerbungIndex

[entries]
4
texture\Werbung_01.dds
texture\Werbung_02.dds
texture\Werbung_03.dds
texture\Werbung_04.dds

    Was bedeutet das jetzt? Oben unter [newtexchangemaster] wird als erstes eine Textur angegeben. Hier muss die jeweilige Textur eingetragen werden, die ihr in Blender auf das Objekt gemappt habt. D.h., wenn ihr eine Dummy-Textur verwendet habt, tragt ihr hier den Dummy ein, damit Blender weiß, welche Textur überhaupt auszutauschen ist (im Zweifelsfall kann man auch direkt die o3d in einem Texteditor öffnen, relativ weit unten, sind die Texturen im Klartext zu finden, die dort angegebene Textur muss exakt mit der eingetragenen übereinstimmen.

    Darunter folgt eine Variable - in meinem Fall WerbungIndex - die dient als Steuervariable, mit der wir festlegen, welche der Unten angegebenen Texturen verwendet werden soll. (Natürlich tragen wir die nachher noch richtig in eine Varlist ein. ^^)

    Tja, und dann folgt unter [entries] einfach nur eine Auflistung meiner "registrierten" Tauschtexturen. Zuerst die Anzahl der folgenden Einträge, dann die Einträge selbst. Wichtig ist hier, dass diese Pfade immer ausgehende von der cfg angegeben sein müssen. Ich könnte die Datei theoretisch auch genau so gut mit in den texture-Unterordner legen, dann müsste bei allen Einträgen das texture\-Präfix jedoch wegfallen.


    Dann tragen wir diese cfg-Datei noch in der sco unter unserem Mesh-Eintrag, wiefolgt ein:

    Code: Werbetafel.sco
    [mesh]
Werbetafel.o3d

[texchanges]
Werbetafel_chtex.cfg

    Auch hier nochmal als reminder: Wenn ich die cfg-Datei mit in den texture-Ordner gelegt hätte, müsste ich hier dann natürlich texture\Werbetafel_chtex.cfg schreiben. :)


    Zuletzt müssen wir jetzt nur noch die Variable und ein Script definieren, das die Variable steuert. Dazu erzeuge ich eine Varlist und ein Script im script-Unterordner und trage beide Dateien auf dem bekannten Wege in der sco mit ein:

    Code: Werbetafel.sco
    [varnamelist]
1
script\Werbetafel_varlist.txt

[script]
1
script\Werbetafel.osc

    In der Varlist wird einfach nur die vorhin verwendete Variable WerbungIndex eintragen:

    Code: script\Werbung_varlist.txt
    WerbungIndex

    Im Script kann ich nun eine beliebige Logik programmieren, mit der die Variable einen Wert bekommt, der dann einfach als Index entscheidet, welche der Texturen in der cfg verwendet werden soll.

    Da es sich in meinem Fall um eine Werbetafel handelt, die bei der Initialisierung einmal eine zufällige Textur bekommen soll, sieht mein Script wiefolgt aus:

    Code
    {init}
    4 random (S.L.WerbungIndex)
{end}

    Die 4 steht dort, weil wir insgesamt vier Werbungen haben und somit eine zufällige Zahl zwischen 0 und 3 ausgewählt wird (nullbasierter Index). Diese Zahl müsste ich also ändern, wenn ich weitere Werbungen hinzufüge. Allerdings könnte man ihn auch z.B. in eine constfile auslagern.


    Das ist tatsächlich schon alles. Die Werbetafel funktioniert und erhält jedes mal eine zufällige Textur:


    Man sieht also, das ganze ist deutlich einfacher und "schlanker" als ein CTC, aber dennoch auch robuster und somit ebenfalls in gewisser Weise einfacher als mit freetex zu arbeiten.

    Übrigens. Es ist ohne Probleme möglich, in einer chtex.cfg-Datei auch mehrere [newtexchangemaster]-Einträge mit jeweils eigenen Entries einzutragen, wenn man verschiedene Variablen verwendet, kann man dann auch mehrere Tauschtexturen separat voneinander umsetzen.

    Ich empfehle dazu nochmal einen Blick in die folgende Datei aus der OMSI-Basisinstallation: OMSI 2\Vehicles\Anzeigen\Rollband_SD79\chtex_rollband.cfg


    Ich hoffe, das hilft einigen weiter. Es ist - aus meiner Sicht - gerade für Werbetafeln oder Haltestellenhäuser wirklich eine viel einfachere Möglichkeit, Tauschtexturen umzusetzen und es funktioniert bei Objekten genau wie bei Fahrzeugen.

    Als Referenz findet ihr auch nochmal meine komplette Werbetafel im Anhang als Download zum angucken und nachvollziehen. :)

    Dateien

    • Werbetafel.7z

      (140,6 kB, 35 Mal heruntergeladen, zuletzt: )

  • [SUPPORTTHREAD] IVU.ticket.box CE70 mobil

    Ah stimmt, man sollte mal paar Posts darüber lesen. :facepalm:


    Was mir spontan als einziges noch einfallen würde wäre, dass das irgendwie komisch in der Situationsdatei steht. TrainFW hast du mal eine komplett neue Situation (Karte ohne Busse laden) probiert und nicht die letzte Situation wieder neu geladen?

  • [SUPPORTTHREAD] IVU.ticket.box CE70 mobil

    Anhand der Logfile-Meldung 241 17:10:20 - - Error: 'IVU_freier_Port_11' ist kein gültiger Gleitkommawert: AMUAV.CNAVO.MV.E würde ich eher vermuten, dass der (durchaus korrekte Variablenname "IVU_freier_Port_11" in einer anderen Datei, z.B. der Model.cfg an einer Stelle eingetragen wurde, an der keine Variable erwartet wird und verarbeitet werden kann, sonden tatsächlich ein konstanter Zahlwert erwartet wird.


    Würde die Variable nicht definiert, aber im Script verwendet werden, wäre die Fehlermeldung eher so etwas, wie Fehler im Befehl (L.$.IVU_freier_Port_11) - der Variablenname ist ungültig (habe gerade den genauen Wortlaut nicht so im Kopf ,:)

  • Massive Performanceprobleme und FPS-Einbrüche

    Danke für die vielen, bereits hilfreichen Hinweise, ich gehe alles mal durch:

    Zitat von KomBus90

    Das könnte gelöst werden in dem man DirectX neu Installiert.

    Werde ich mal probieren.


    Zitat von KomBus90

    In deinem Bild sieht man eine deutliche Auslastung des Ram´s Da ist die Frage: Wurde das Bild aufgenommen während OMSI 2 im Hintergrund läuft?

    Ja, während es lief. Wie auch im Startpost geschrieben, vor allem deshalb so hoch, weil Firefox nochmal 2 GB schluckte. Das ist normalerweise nicht offen.


    Zitat von KomBus90

    Windows 11 ist so eingestellt das die Verwaltung der Threads (Kerne) automatisch regelt. Man kann Windows 11 so einstellen das alle Kerne genutzt werden.

    Siehe hier wie das geht: https://praxistipps.chip.de/wi…en-starten-so-gehts_30574

    Danke, schau ich mir mal an.


    Zitat von KomBus90

    Ist bei dir die Zielwiederholrate (FPS begrenzer) richtig eingestellt? Mit dieser Einstellung siehe BILD. Kannst du OMSI 2 zwingen mehr FPS zu nutzen. Da du eine NVIDIA GeForce GTX 1070 Ti hast, denke mal mit 4GB Ram. Kannst du sie so einstellen wie im Bild.

    Hatte beides probiert, mit Begrenzung auf 60 FPS und auch auf "200", also unbegrenzt. Hatte keinen spürbaren Unterschied gemacht.


    Zitat von KomBus90

    Nächste Frage ist: Sind all deine Treiber wie Grafikkarte etc. Aktuell? Ich nutze bei Nvidia immer Nvidia Geforce Experience. Dieses Tool optimiert deine Games und hält deine Treiber auf den neusten stand.

    Öhm, müsste ich mal schauen ^^


    Zitat von KomBus90

    Hast du auf deinem PC ein Viren-Programm Installiert? Falls ja Deinstalliere es. Windows 11 nutzt bereits ein sehr gutes Viren Programm. Selbst Installierte Viren-Programme können deinen PC extrem einschränken und in der Leistung Drosseln, da diese ständig im Hintergrund laufen. Die meisten Viren-Programme schützen nicht.

    Nein, mittlerweile nutze ich keine externen Virenscanner mehr (und hatte auf dem derzeitigen Rechner auf nie einen installiert), da, wie du selber ja schon sagtest, der Windows Defender mittlerweile völlig ausreichend ist.


    Zitat von KomBus90

    Hast du OMSI 2 schonmal über Steam Überprüfen lassen?

    Wollte ich bisher nicht machen, weil ich auch einige Änderungen an Hauptspiel- und Addon-Dateien vorgenommen habe, das müsste ich dann alles erstmal sichern.

    Aber, wenn nichts anders hilft, wäre das natürlich die letzte Option.



    Zitat von Willem1974
    Zitat von ma7t3

    328 18:43:19 - - Error: [OMSIPresence] TRoadVehicle.hersteller and/or TRoadVehicle.friendlyname were null

    Da fehlen Daten von ein Fahrzeug. Hast du in letzter Zeit noch neue Fahrzeuge installiert? Check von denen die Dateien ob alles gefüllt ist.

    Eigentlich nicht, aber das lag warscheinlich daran, dass ich aus versehen ein KI-Fahrzeug als User übernommen hatte. :D

    Aber das ist trotzdem ein guter Hinweis, vielleicht liegt das an diesem OMSIPresence Plugin. ^^

  • Massive Performanceprobleme und FPS-Einbrüche

    1. Mit welchem Programm hast Du ein Problem? (Hauptprogramm, Editor, SDK Tools, etc.)

    OMSI-Hauptspiel


    2. Bitte beschreibe das Problem so ausführlich wie möglich. Was ist passiert oder was hat vielleicht zu dem Fehler geführt?

    Seit ein paar Tagen ungefähr habe ich in OMSI recht starke Performanceprobleme, das Spiel läuft mit unveränderten Einstellungen erheblich schlechter als sonst. Zwar sind auch Ruckler usw. häufiger, vor allem fällt aber auf, dass die FPS sehr gering sind und Texturen ungewöhnlich lange zum Laden brauchen (ich fahre immer häufiger tatsächlich direkt an weißen Häusern oder parkenden Autos ohne Textur vorbei, nicht, weil die Textur fehlt, sondern, weil sie in der ganzen Zeit, in der die Kachel geladen wurde, bis zu dem Zeitpunkt, wo ich das Objekt während einer normalen Fahrt tatsächlich erreiche, noch nicht geladen werden konnte.


    Ich konnte dieses Problem insbesondere auf den Maps Ahlheim V4 und Hamburg beobachten, tritt aber prinzipiell auf allen Maps gleichermaßen auf.

    Auf Hamburg ging es teilweise so weit, dass ich schon direkt nach dem Starten mit dem Bus im Bereich Hauptbahnhof so wenige FPS hatte, dass der Bus anfing, zu hüpfen (dauerhaft weniger als 10 FPS). Aber auch auf Ahlheim musste ich längere Strecken (natürlich gerade in den zentralen Bereichen, wie Eichenhöhe Bhf. oder Hauptbahnhof) mit 15 oder weniger FPS zurücklegen.

    Mir ist schon klar, dass gewisse Performanceprobleme für OMSI in teilen völlig normal sind, allerdings ist es plötzlich eben doch auffällig schlecht. Meine Einstellungen sind unverändert, aber selbst, als ich die Bereiche "Grafik" und "Umgebungsverkehr" nochmal deutlich heruntergeschraubt habe, war kaum eine Verbesserung bemerkbar, sodass ich mit meinem Latein langsam echt am Ende bin.

    Das Logfile ist mMn. völlig unauffällig, jedenfalls gibt es keine auffälligen "Spam-Fehler", die OMSI ausbremsen könnten. Dennoch ist die Logfile unten hinzugefügt.

    Zudem tritt bei mir sehr "empfindlich" der Fatal Error "Direct3D Device Lost" auf, dass man den kriegt, wenn man Strg+Alt+Entf gedrückt hat oder Windows gesperrt hat, ist ja relativ normal, jedoch tritt das bei mir in letzter Zeit teilweise schon auf, wenn ich nur das Fenster wechsle, d.h. kurz aus OMSI heraus klicke, um z.B. auf einen PDF-Netzplan zu schauen.

    Task Manager habe ich auch mal nebenan offen gehabt, auch dort kann ich bei keinem meiner Hardware-Komponenten eine ansatzweise hohe Auslastung feststellen, weder RAM, Grafikkarte bei OMSI ja sowieso nicht aber auch die CPU bleibt eigentlich stabil bei. Auf dem Screenshot unten ist RAM noch relativ hoch, das liegt aber daran, dass Firefox, während ich das hier gerade schreibe mal entspannt 2 GB frisst, aber das habe ich normalerweise eh beim OMSI-Spielen nicht offen.

    Da das Problem so plötzlich auftritt, ohne dass ich bewusst irgendwas verändert habe, habe ich noch überlegt, ob das theoretisch an einem Windows-Update irgendwie liegen kann. Daher wäre mal ganz interessant zu wissen, ob andere User vielleicht ähnliche Probleme haben.


    3. Bitte füge Deinem Beitrag eine Log-Datei hinzu, entweder im Spoiler, Code-Block oder als Dateianhang.

    Wie oben beschrieben ist das Logfile für mein Verständnis völlig unauffällig, der Vollständigkeit halber trotzdem hier:


    4. Falls es einen hilfreichen Screenshot des Problems gibt, kannst du ihn als Beitragsanhang mit hochladen und einfügen.

    Hier sieht man es nochmal, ingame, OMSI frisch gestartet auf Hamburg, noch nichtmal einen Bus platziert und wir schaffen mit Ach und Krach die 15 FPS (vor allem schwankt es sehr stark, daher nicht wundern, dass bei den gemittelten FPS noch 37 stehen):


    Einfach mal Screenshots von allem, was sonst noch so hilfreich sein könnte:


    5. Gib Deine Systeminformationen an, falls es sich um ein Performance-Problem handelt. (Betriebssystem, Prozessor, Grafikkarte, Festplattentyp, Arbeitsspeicher, etc.)

    Windows 11 Pro 23H2

    CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz 3.70 GHz

    RAM: 16,0 GB DDR4

    GPU: NVIDIA GeForce GTX 1070 Ti