Problem (SSE) CTD sobald ich irgendein neues .esp/.esm/.esl plugin nutzen möchte

So ein wenig erinnert die Geschichte an defekte Ram-Bausteine.
Fehlerhafte Dateien, oder unpassende Treibereinstellungen könnten sich ganz ähnlich verhalten.
 
Noch mal kurz zu meinem ursprünglichen Thema zurück :D
Ich bin wieder auf eine Reihe unerklärlicher, nüchtern betrachtet vollkommen willkürlichen aber zumindest recht zuverlässig herbeiführbaren CTDs gestoßen.

Vom Hauptmenü 'coc whiteriverwatchexterior03' und dort kam dann entweder nach 5-10 Sekunden (ob ich mich bewegt habe oder bloß dort gestanden habe war egal) direkt der CTD oder ich habe ihn durch einen 'kill' befehl in der Konsole verursacht. Von 3-4 Spielstarts ist das Spiel dann auch 2-3 mal abgestürzt.

Nachdem ich ja, wie im ersten Post, noch im Kopf hatte, dass quasi ein einzelnes Plugin das Fass zum überlaufen gebracht hat, hab ich jetzt also einfach mal eine Hand voll Plugins testweise zusammengefasst um die Gesamtzahl an Plugins zu senken und siehe da - bisher keine komischen CTDs mehr.

Bleibt die Frage in welches Limit ich da gelaufen bin:
"Reference handle limit": Liegt, wenn ich mich nicht irre bei 1.000.000 - ich habe (xEdit Script sei Dank) gerundet 272.000 -> wird es wohl nicht sein.
"Pluginlimit": Aktive Plugins (waren) 399 aufgeteilt in 152 .esp & .esm sowie 247 .esl & esl flagged .esp - Rein von den "normalen" Plugins bin ich noch weit von 255 entfernt und die .esl sollten bis 2048? möglich sein, davon bin ich ja dann auch noch sehr weit entfernt -> wird es wohl nicht sein
"maximum number of open file handles": Da ich EngineFixes nutze und diese Option aktiviert habe, wird das Limit dafür auf 2048 erweitert (Standard 512) - ich verstehe die Beschereibung so, dass es sich hierbei um die Anzahl der Plugins inkl. der .bsa-Archive handelt? - ich habe hier 546 Dateien gehabt (die Zahl war/muss aber schon lange über der 512 gewesen sein) -> wird es wohl nicht sein

Was gibt es denn sonst noch?
Meine einzige Vermutung bisher ist, dass der MO2 selbst nicht mit der Anzahl der Plugins umgehen kann und dann irgendwo Sachen einfach verschluckt werden und es dann zu den scheinbar willkürlichen CTDs kommt (ich spreche hier von der Ursache, welche aus den CrashLogs herauszulesen war). Obwohl ich immer nach dem gleichen Schema ins Spiel gegangen bin, habe ich IMMER eine andere Fehlerursache bekommen.

Ich werd wohl die Tage mal auf dem Discord der MO2-Entwickler vorbeischauen und da mal meine Erfahrung teilen, vielleicht ist da ja tatsächlich was im argen.
 
  • Like
Reaktionen: PRieST
Ja ok, aber ob ich da reingelaufen bin (ich war ja "erst" bei 247 und nur die wenigsten kommen an die 2048 Recordeinträge heran)... könnte aber natürlich sein, danke für den Hinweis.

Edit: Weiß jemand ob da nur die neuen Records zählen oder auch die Overrides? Schau ich mir zum Beispiel JK's Dragonsreach an, ist das eine esp mit esl flag, hat aber 2080 Einträge.
Oder ein "Landscape and Water Fixes" hat 7440 Einträge (ist eine esp mit esl & esm flag)
 
Zuletzt bearbeitet:
Die nächste ENB-Absonderlichkeit:
Nach nochmaligem "harten" Installieren sämtlicher Visual-Runtimes und selbst der DirectX-Dateien kommt jetzt der Crash zuverlässig unmittelbar vor dem Laden des Logos. Die Musik läuft bereits und die berüchtigte Fehlermeldung 6025 taucht auf.
Nun ist mir aufgefallen, daß die enblocal.ini plötzlich 27k groß ist, statt der normalen rund 700 Byte. Ich habe das noch nicht im einzelnen verglichen, aber die zusätzlichen Einträge sehen aus wie die, die normalerweise in der enbseries.ini enthalten sind. Da frag ich mich, wer oder was die INI dermaßen verunstaltet.:confused::(o_O

Bye, Bbm.
 
Private Profile Redirector ist aber nicht zufällig installiert, oder? Das wäre jetzt das einzige, was irgendwie in die .ini eingreifen könnte. Und so weit ich mich erinnern kann gab es da auf jeden Fall mal Probleme mit ENBs. Weiß aber nicht mehr genau, ob es auf bestimmte Presets oder ganz allgemein galt. Ich meine dies wurde auch schon mal irgendwann gefixt. Ich selbst nutze es und habe keine Probleme feststellen können.
 
Danke, das ist wieder eine neue Richtung. Hab da auch in den Kommentaren schon neue Ansätze entdeckt, von denen einer sehr vielversprechend aussieht. Die Fehlerbeschreibung paßt und die Lösung ist plausibel.
Mal sehen, könnte eine Weile dauern, das zu überprüfen, da ich nicht ständig Zugriff habe.

Bye, Bbm.
 
Die Ladezeit ist nicht das Problem. Der Crash kommt unmittelbar vor dem Ladebildschirm des Hauptmenüs.
Ich habe jetzt eine falsche Einstellung in den SSE Diplay Tweaks in Verdacht, bei der dieser Ladebildschirm nicht auf 60FPS festgelegt ist. In der Beschreibung wird zwar ausdrücklich darauf verwiesen, auf 60 zu begrenzen und VSync einzuschalten, original ist das aber in der INI nicht so eingestellt. Und eine manuelle Einstellung ist mit ziemlicher Sicherheit nicht vorgenommen worden, jedenfalls nicht von mir.
Muß mir das auf jeden Fall mal angucken.

Bye, Bbm.
 
Also ich habe SE Build auf 120 FPS laufen, dafür gibt . Shadercache und VSync habe ich Software und SKSE Plugin seitig in Skyrim abgeschaltet. Shadercache und VSync mache ich nur noch über den Nvidia Treiber, weil ich gelesen habe, dass der die moderne Software Architektur hat.
 
Ingame mögen hohe FPS durchaus sinnvoll sein, aber bei einem quasi Standbild (Ladebildschirme, Menüs) bringt es nichts. Im Gegenteil, ich könnte mir schon vorstellen, daß da die Engine garnicht drauf ausgelegt ist und anfängt zu spinnen. In Menüs und Ladebildschirmen sind nicht viele Objekte darzustellen und Bewegungen gibt es erst recht nicht. Es ist also nicht viel zu tun und der Bildaufbau ist ganz fix erledigt. Werden jetzt nicht die FPS begrenzt, erfolgen sehr viel mehr Funktionsaufrufe, als ingame. Das bringt dann das Betriebssystem an seine Grenzen, weil zu viele Aufrufe zu schnell hintereinander erfolgen. Die Fehlermeldung "6025" weist, allerdings recht unspezifisch, auf dieses Recourcenproblem hin.

Bye, Bbm.
 
Ich selbst bin mittlerweile trotz DisplayTweaks von max 144FPS wieder auf 60 zurück, weil bei mir bei der höheren Zahl (in Innenzellen hab ich die locker erreicht) manche (Standard) Animationen nicht mehr sauber abgespielt wurden. Bewegen mit gezogener Waffe wurde so z.B. zu über den Boden gleiten ohne die Beine zu bewegen.
Im Ladebildschirm hab ich immer die empfohlenen 60 FPS gelassen. Dank SSD geht das Laden eh flott genug oder wofür auch immer dort höhere FPS sorgen sollen.
Aber wer weiß, vielleicht hakt es da bei der ENB dann ja tatsächlich aus, man müsste mal die Gegenprobe machen.

Edit: Gerade mal bei mir mittels DisplayTweaks für Hauptmenü und Loadingscreen deutlich höhere Werte als 60 eingetragen und habe keinen Absturz bekommen. Muss nichts heißen ich kann es aber auch nicht bestätigen...leider.
 
Zuletzt bearbeitet:
Also gut, fangen wir mit der "Katastrophen-Meldung" an:
ES LÄUFT!!!

Meine Vermutung mit dem Display Tweak hat sich bestätigt, aber genau andersrum als angenommen. Bisher war der Tweak garnicht installiert -> also drauf damit. Dann noch ein paar der zugehörigen Einstellungen korrigiert und ENB läuft.
Es hatte also scheinbar doch mit den zu hohen FPS im Hauptmenü zu tun, genau diese Einstellung muß korrigiert werden.

Bye, Bbm.
 
  • Like
Reaktionen: PRieST
Ja sehr schön, dass du es hinbekommen hast. Ist aber gleichzeitig wohl auch stark Systemabhängig denn wie schon gesagt, bei mir hat es keinerlei Probleme verursacht dort andere/deutlich "zu hohe" Werte benutzt zu haben.
 
Hab ich bisher tatsächlich nicht gesehen, werde ich dann das nächste mal ausprobieren, wenn das bei mir vorkommt. Danke.