SSE CTD in Kampfsituationen

Judge Red

Reisender
Ich habe seit ein paar Tagen ein seltsames Problem.

Immer dann, wenn ich in eine Kampfsituation gerate, crasht das Spiel. Es passiert in dem Moment, wenn ich selbst den Gegner mit einer Waffe treffe oder aber von ihm getroffen werde, egal welche Waffe er benutzt (Spinnenbiss, Pfeil, Schwert usw.).

Das Problem trat erstmals auf, nachdem ich via Vortex von Dreifels die Mod "Kurzanleitung - Vereinheitlichung deutscher Uebersetzungen mit merged Strings" via Vortex installiert hatte (siehe den Thread ab Mittwoch, den 23.12.2020). Nachdem er mir nachvollziehbar erklärt hatte, dass es technisch gesehen daran nicht liegen kann, habe ich selbst festgestellt, dass das Problem unabhängig davon auftritt, welche deutschsprachigen Strings ich verwende.

Ich habe um den Zeitpunkt, zu dem das Problem erstmals auftrat, als einzig gravierende Veränderung meiner Installation die Aktualisierung des USSEP von der Version 4.2.3 auf die Version 4.2.4 vorgenommen, und zwar zunächst auf 4.2.4a. Da gab es das Problem nicht. Die Aktualisierung auf 4.2.4b habe ich am 22.12.2020 durchgeführt. Danach trat das Problem erstmals auf. Allerdings kann ich anhand des Changelogs der Versionen 4.2.4 bis 4.2.4b nach teilweiser Übersetzung (USSEP Fixes, Actor Fixes, Animation Fixes) und Durchsicht der übrigen Überschriften nicht erkennen, dass es daran liegt. Auch führte eine Rückkehr zur Version 4.2.3 nicht zur Beseitigung des Problems.

Des Weiteren habe ich alle Mods, die ich zeitlich nach dem USSEP zusätzlich installiert habe, deaktiviert und dann das Spiel gestartet. Es kam weiterhin zum CTD im Kampf.

Schließlich habe ich noch unterschiedliche, teilweise mit Fallrim gecleante Speicherstände verwendet, um dem Problem auf die Spur zu kommen. Es ist egal, welche ich verwende: Kommt es zum Kampf, folgt ein CTD. Das gilt selbst dann, wenn ich ein neues Spiel mit der vorhandenen Installation starte.

Hat irgendjemand - außer eine Neuinstallation und Start eines neuen Spiels - eine Idee?

RATLOS, der Judge
 
Was nutzt du ? ...Skyrim LE oder Skyrim SE ?

Wenn du Skyrim LE nutzt, dann versuche mal den CTD-Crash-Fix:
https://www.elderscrollsportal.de/t...-plugin-preloader-by-meh321-and-sheson.52141/

Bei der SSE hilft das FPSFixPlugin welches ebenfalls einen CTD-Crash-Fix inne hat.
Ebenso kann EngineFixes hilfreich sein.

Möglicherweise steht auch dein VRAM am Anschlag, was auch zu CTDs führen kann.
Dies würde ich mal mit dem MSI-Afterburner "InGame" überprüfen.
Welche GraKa nutzt du ?

Skyrim verursacht auch gern CTDs, wenn die RAM-Page nicht groß genug ist.
Lässt sich ebenfalls per MSI-Afterburner "InGame" überprüfen.
 
@Kleiner Prinz , @Judge Red
es liegt an dem Stringpaket. Nur für Übersetzungen benutzen, nicht in /strings installieren, alte Strings von Directors Cut nehmen.
Aus unklarem Grund scheint Skyrim nicht zu mögen, wenn die Originalstrings auch in den loose Strings sind. Hab ich über Weihnachen mit 7 Neuinstallationen bitter rausfinden müssen, ohne zu verstehen, wieso.Also: Directors Cut Originalstrings oder USSEPs Strings (ist dasselbe) in Data/Strings/ - Die Pakete von mir woanders ablegen und nur für Übersetzungen nutzen (Einlesen zum Vergleichen)

"Lässt sich ebenfalls per MSI-Afterburner "InGame" überprüfen." die Funktion hab ich bei Afterburner noch nicht entdeckt.
 
  • Like
Reaktionen: Kleiner Prinz
@dreifels
Danke, Dreifels! Ich bin ein Problem los, denn zum Glück hatte ich im August ein Backup gemacht, in dem die unveränderten Originalstrings meiner Neuinstallation aus Juni noch drin waren. Dafür bist Du jetzt als Ordnerbezeichnung auf meiner Festplatte verewigt.

@Kleiner Prinz
Da dank des Hinweises von Dreifels das Spiel wieder funktioniert, habe ich weitere Maßnahmen erst einmal zurückgestellt. Aber ich habe Deine Tipps im Hinterkopf, wenn es mal wieder Probleme gibt. Meine Graka ist eine nVidia GeForce RTX 2070 MaxQ. Ich spiele auf höchster Qualitätsstufe mit bis zu 237 fps, allerdings ohne ENB oder ähnliches. Von daher war ich mir ziemlich sicher, dass keine Probleme mit Grafik- oder sonstigem Speicher vorliegen, sondern eher eine eigene Dummheit beim Modden.
 
Ich spiele auf höchster Qualitätsstufe mit bis zu 237 fps

Bitte unbedingt die fps auf 60 begrenzen, die Physik-Engine von Skyrim als auch Fallout kriegt regelmäßig einen Lagerschaden wenn mehr als 60 fps anliegen und dieses Problem wird in der Tat schlimmer,
je weiter die fps über 60 liegen.
 
@dreifels
Danke, Dreifels! Ich bin ein Problem los, denn zum Glück hatte ich im August ein Backup gemacht, in dem die unveränderten Originalstrings meiner Neuinstallation aus Juni noch drin waren.
Du brauchtest eigentlich kein Backup, nur die Strings aus Directors Cut einfach wieder nach /Data/Strings/ kopieren, also meine dort überschreiben. (Ich versteh aber immer noch nicht, wieso das ist. Muss den Hinweis von @Kleiner Prinz zur Rampage mal verfolgen, ist aber nicht mein Fachgebiet.)

Edit
Bei Google-Suche bin ich über diese Seite von Microsoft gestoßen, die Win10/64 und pagefile memory betrifft. Eine echte Verschlimmbesserung gegenüber Win7
Die Kernsätze sind
  1. Clear the Automatically manage paging file size for all drives check box.
  2. Select Custom size, and then set the "Initial size" and "Maximum size" values for the paging file. We recommend that you set the initial size to 1.5 times the amount of RAM in the system.


    Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
Also bei 32GB Ram sind das 32768 MB x 1,5 = 49.152‬ MB
Toll.
 
Zuletzt bearbeitet von einem Moderator:
Fallout kriegt regelmäßig einen Lagerschaden wenn mehr als 60 fps anliegen und dieses Problem wird in der Tat schlimmer,
Also bei Skyrim kann ich es nicht sagen da ich es nicht spiele aber bei Fallout habe ich folgendes selbst herausgefunden bzw auch bei einem Bekannten nachvollziehen können.
1.
Eine Fps Begrenzung kann man bzw sollte man in Fallout 4 auf 58 setzen Hääh? Ja, stimmt denn Fallout 4 hat eine blöde Angewohnheit: Wenn es 60 Fps nicht halten kann dann versucht es erst einmal durch reduzieren einen flüssigen Spielverlauf zu bieten. Fallout 4 aber reduziert von 60 erst auf 40/45 und wenn das nichts bringt wird das halbiert. Aus dem Grunde haben auch in der Vergangenheit Spieler mit guter Ausstattung in Boston downtown Fps um die 20, einige sogar weniger.
Wenn man aber auf 58 begrenzt kommt es nicht dazu. Wermutstropfen: Wenn viel los ist wird das Spiel ruckelnd und mit mehr oder weniger spürbaren Aussetzern laufen.

2.
Fallout 4 kann bis maximal 75 FPs nahezu ohne spürbare Störungen betrieben werden, Darüber sollte man nicht gehen denn dann spielt die Havok Engine verrückt, Gegner fliegen (komt euch bekannt vor?) die Minigames zu dem Schloßknacken sind nahezu nicht spielbar weil das zu schnell abläuft, Türen öffnen sich nicht, man kann sich nicht mehr aus Konsolen abmelden und die Lippenbewegungen und der Text sind nicht mehr synchron

Da aber der Unterschied zwischen 60 und 75 Fps nicht die Welt ist sollte man sich definitiv hieran halten:
Bitte unbedingt die fps auf 60 begrenzen

Stellt sich jetzt die Frage warum habe ich denn extra einen 4K Monitor mit mehr als 144 htz und eine Graka mit 12 GB Vram angeschafft? Frage ich mich auch, ihr wusstet doch das ihr ein Spiel von Bethesda spielt und da sind eben diese Grenzen gesetzt. OKay, ja, sehe ich ein, es gibt außer dem auch andere Spiele die brauchen das und nutzen das dann.
 
FPS: system reduziert automatisch auf den nächst tieferen 10er-Wert, also 58 = 50, auch wenn so nicht angezeigt.
Die GraKa sollte so eingestellt sein dass ihr FPS-Limit dem des Monitors entspricht, weil alles andere verworfen wird. Wenn der Monitor besser ist, als das Spiel erlaubt, in der Spiel-ini den höchstmöglichen Wert einstellen, auch wenn der niedriger ist, als das, was die dem Monitor angepasste GraKa-Einstellung beträgt. Alles andere bringt unnötige Last im processing.
Also: Graka = Monitor, ini = Spiel. Abschalten in Ini nur dann, wenn Monitor/Graka weniger, als maximaler Spielwert. (Bei meinem Flatscreen ist 60 FPS fest, also Graka fest auf 60 setzen, spart Last, und in Skyrim disablen.)
 
Bitte unbedingt die fps auf 60 begrenzen, die Physik-Engine von Skyrim als auch Fallout kriegt regelmäßig einen Lagerschaden wenn mehr als 60 fps anliegen und dieses Problem wird in der Tat schlimmer,
je weiter die fps über 60 liegen.

FPS: system reduziert automatisch auf den nächst tieferen 10er-Wert, also 58 = 50, auch wenn so nicht angezeigt.
Die GraKa sollte so eingestellt sein dass ihr FPS-Limit dem des Monitors entspricht, weil alles andere verworfen wird. Wenn der Monitor besser ist, als das Spiel erlaubt, in der Spiel-ini den höchstmöglichen Wert einstellen, auch wenn der niedriger ist, als das, was die dem Monitor angepasste GraKa-Einstellung beträgt. Alles andere bringt unnötige Last im processing.
Also: Graka = Monitor, ini = Spiel. Abschalten in Ini nur dann, wenn Monitor/Graka weniger, als maximaler Spielwert. (Bei meinem Flatscreen ist 60 FPS fest, also Graka fest auf 60 setzen, spart Last, und in Skyrim disablen.)

Frage eines Technik-DAU's: Welche Variable in welcher INI-Datei müsste ich ändern, falls ich kein Risiko eingehen will?
Zudem habe ich die Mods Monitor Refresh Rate uncap sowie [SKSE64] Havok Fix installiert (Gut, wenn ich mir Mühe gebe, kann ich aus der Beschreibung der zuletzt genannten Mod die Antwort auf die vorherige Frage wohl entnehmen). Ich habe den Eindruck, dass diese beiden zusammen das Spiel trotz der hohen FPS stabil halten.

Du brauchtest eigentlich kein Backup, nur die Strings aus Directors Cut einfach wieder nach /Data/Strings/ kopieren, also meine dort überschreiben.

Ich habe mich unklar ausgedrückt: Das Backup beinhaltete die String-Dateien aus dem Directos Cut.
 
Stellt sich jetzt die Frage warum habe ich denn extra einen 4K Monitor mit mehr als 144 htz und eine Graka mit 12 GB Vram angeschafft?...

Echt ? :)
Wusste ich noch gar nicht. ;)
Welchen Monitor ?
Welche GraKa ?

Bei Google-Suche bin ich über diese Seite...

Es hatte einmal jemand steif und fest behauptet, man könne die RAM-Page komplett abschalten, da fast jeder genug RAM im PC verbaut hat.
Eine RAM-Page würde das System nur verlangsamen.

Der Gedanke klingt erst mal logisch.
Leider ist es aber so, dass manche Spiele zwingend auf eine RAM-Page angewiesen sind.
Dazu gehört SKYRIM, welches geradezu gierig auf die RAM-Page zugreift.

Ich hatte aus Neugier die RAM-Page mal abgeschaltet, und daraufhin an den unmöglichsten Stellen in Himmelsrand, plötzlich einen CTD nach dem anderen.
Nach dem Einschalten der RAM-Page gab es keine CTDs mehr.

Was die Größe der RAM-Page betrifft, kann man dies mit dem MSI-Afterburner (InGame) ermitteln.
Bei einem sehr stark gemoddetem Skyrim SE (wie bei mir) liegt der Wert recht hoch.
Kein anderes Spiel hat je so viel Speicher gefressen, wie mein SKYRIM.

Ich würde auch einen festen Wert einstellen.
Also kein Min und Max Wert, sondern eine feste Größe.
Angeblich soll das Einstellen eines Min und Max Wertes, den Zugriff ausbremsen.

Beispiel:
Ich musste bei mir 77 GB zur Verfügung stellen, da mein Skyrim SE bis zu diesem Wert, Zugriff nimmt.

40189359qo.png


Hier hatte ich nur 44 GB zur Verfügung gestellt, aber Skyrim forderte 56 GB an, was zu Problemen führte.

40189360pu.jpg


Daraufhin sind es nun 77 GB welche zur Verfügung stehen.

Auch habe ich 32 GB an RAM im PC, von denen Skyrim mit 26 GB bis 30 GB ordentlich Gebrauch macht, ...wie man sieht !
Auch steht der VRAM mit 10 GB von 11 GB fast am Anschlag.

Also Vorsicht beim Installieren von Mods und Texturen.
Sehr schnell ist der PC überfordert.

40189361ea.jpg
 
Zuletzt bearbeitet:
@Kleiner Prinz - damit wir über dasselbe reden: wenn Du von "Ram Page" sprichst, meinst Du die Auslagerungsdatei = pagefil.sys, die (auch lt. Deinem Screenshot) in Win als "virtueller Arbeitsspeicher" bezeichnet wird. Das ist nicht "Rampage".
Wie o. Link zu MS zeigt, will Win10 das 1,5 fache des verbauten Ram haben, bei 32 GB also 49.152‬ MB, entsprechend vergrößert sich dann die pagefil.sys (bei mir auf 50.331.648 KB)
Das hat aber nichts damit zu tun, wieviel Skyrim SE tatsächlich nimmt.

Die beste ingame-Anzeige für Ram und VRam Nutzung ist Performace Montor 64. Dort wird nämlich nicht das Gesamt belegte angezeigt, sondern nur, was Skyrim selbst wirklich nimmt, und das ist bedeutend weniger. Der große Speicherfresser ist Win mit seinem Cache, wobei auch hier in Win10 die Anzeige falsch ist, weil der eingestellte "virtuelle" Speicherplatz (s.o.) plus dem verbauten gezeigt wird, also 49 + 32 minus selbst von System genutze 1,9-2,3 GB = 81-79 GB (Im Gegensatz zu Win7, wo das alles noch stimmte, ist bei Win10 nur Murks gemacht worden). So zeigt Win10 als "empfohler" "virtueller Speicher" 4.983 MB, als minimaler 16 MB (obwohl lt. MS 300 MB ein Muss sind) und als zugeteilt dannn die echt zugewiesenen 49.152 (minimal = maximal), als vorhandener im Task-Manager (Commit ausgeführt) 79,7 bei belegten 5,0 (gerade jetzt) und "verfügbar" richtig die 28,6 GB, im Cache 19,7 (jetzt, ohne Skyrim, nur Firefox)

Wieviel Skyrim selbst und für Mods belegt, hängt von uGridsToLoad, uExterior Cell Buffer,
iPreloadSizeLimit ab, wobei ich gerade mit iPreloadSizeLimit bei uGridsToLoad=5 und uExterior Cell Buffer=36 experimentiere, ob eine Erhöhung z.B. von den dabei vorgeschriebenen 26214400 auf z.B. 4194304000 tatsächlich eine höhere Speichernutzung von Skyrim SE bewirkt, oder ob das fest abhängig von uGridsToLoad ist (denn Erhöhung auf 7 will ich nicht, hat andere Tücken)
Das alle ohne ENB !

Edit: ist zwar nicht genau das Thema, zeigt aber, wie Win10 mit seinen Anzeigen trickst: Bei Kopieren von großen Datenmengen wird der Kopiervorgang als abgeschlossen angezeigt, obwohl er noch nicht abgeschlossen ist, sondern bis zu 7 GB noch im Ram sind und rausgeschrieben werden müssen, was je nach Files einige Minuten dauern kann, auch bei einer SSD, wenn sehr viele kleine Files verlegt wurden und entsprechend tausende von MFT-Einträgen gleichzeitig laufen. Win10 ist ein potemkinsches Dorf. Schicke Fassade, dahinter Murks, alles wir durch Oberfläche und Grafik verschleiert.
 
Zuletzt bearbeitet von einem Moderator:
@Kleiner Prinz
meinst Du die Auslagerungsdatei = pagefil.sys...
wobei ich gerade mit iPreloadSizeLimit bei uGridsToLoad=5 und uExterior Cell Buffer=36 experimentiere...

JA !
Aber mal ehrlich, ...setzt du dich mit dem Taschenrechner hin, um den genauen Wert zu ermitteln ?
Jeder dürfte auf seiner SSD genug Platz haben, um großzügig zu sein.

Wenn du mit der SSE spielst, ist es mittlerweile völlig Wurst, wie groß du dein uGrid einstellst.
Ob 5 oder 15 spielt bei der SSE kaum noch eine Rolle.
Bei meinem System kommt es zu keinen Performance-Einbrüchen.

Und hier noch ein heißer Tipp für alle Oldrim-Gamer:
https://www.pcgameshardware.de/The-...Memory-Patch-behebt-Speicherprobleme-1105785/
 
Wenn du mit der SSE spielst, ist es mittlerweile völlig Wurst, wie groß du dein uGrid einstellst
Ob 5 oder 15 spielt bei der SSE kaum noch eine Rolle.
nein, ein weit verbreiteter Irrtum. Es geht nicht um Performanceverlust, sondern darum, dass bei höheren uGirdsToLod (also 7, mehr ist eh sehr kritisch, aus anderen Gründen) Skyrim benachbarte Zellen im Voraus lädt und evtl. Aktionen dort, die erst bei Betreten durch den Char ausgelöst werden sollen, früher ausgelöst werden. z. B. Kämpfe.

Ich hatte bei LE auch lange Zeit 7 eingestellt, wegen der größeren Sichtweite (bevor ich DynDoLod nahm), aber immer wieder gab es Ereignisse, die zu früh gestartet waren, bevor ich da war. Das ist bei der SE ebenso. Deswegen bin ich zu 5 zurückgekehrt. Nicht wg. Performance, die ist bei mir eh gut.

(Und Taschenrechner nehm ich nicht, dafür gibt es UmrechenWebseiten)

Was noch den Ram Bedarf beeinflußt, ist in der Ini
[Archive]
bLoadArchiveInMemory=1
sArchiveToLoadInMemoryList=Skyrim - Animations.bsa
sResourceArchiveList=Skyrim - Animations.bsa, Skyrim - Interface.bsa, Skyrim - Meshes0.bsa, Skyrim - Meshes1.bsa, Skyrim - Misc.bsa, Skyrim - Patch.bsa, Skyrim - Shaders.bsa, Skyrim - Sounds.bsa
sResourceArchiveList2=Skyrim - Textures0.bsa, Skyrim - Textures1.bsa, Skyrim - Textures2.bsa, Skyrim - Textures3.bsa, Skyrim - Textures4.bsa, Skyrim - Textures5.bsa, Skyrim - Textures6.bsa, Skyrim - Textures7.bsa, Skyrim - Textures8.bsa, Skyrim - Voices_de0.bsa, Skyrim - Voices_en0.bsa, Unofficial Skyrim Special Edition Patch - Textures.bsa, Unofficial Skyrim Special Edition Patch.bsa

Das sind die Basispakete. Hier könnten (noch ungetestet) evtl. auch die BSAs der Mods angehängt werden, die immer aktiv sind, also nicht von anderen Welten, die nur geladen werden, wenn man sie betritt. So was wie z.B. Cutting Room Floor - Textures.bsa
 
Da ich einen FPS 60 Monitor habe, haben mich andere Überlegungen nie interessiert.
Bei mir genauso. Ich konnte auch nur etwas zu Fallout sagen da ich Skyrim nicht spiele.
Echt ? :)
Wusste ich noch gar nicht. ;)
Welchen Monitor ?
Welche GraKa ?
Sche**** Ich hatte die Smilies vergessen ;)
Ich würde auch einen festen Wert einstellen.
Also kein Min und Max Wert, sondern eine feste Größe.
Grundsätzlich, ich hatte mit dem anderen auch nur Probleme. Und-----nicht manche Spiele, bei mir bisher alle

Also ich denke darüber besteht schon länger hier Einigkeit
 
Da habe ich mich jetzt ja ganz umsonst für dich gefreut ! :mad:;););)
Nein, ich habe immer noch meine alte Ausstattung und für das was ich mache reicht die.
aber immer wieder gab es Ereignisse, die zu früh gestartet waren, bevor ich da war. Das ist bei der SE ebenso.
Hier muss ich @dreifels Recht geben. Auch wieder, da nicht Skyrim Spieler, nur für Fallout.
Sehr gut war das zu beobachten in Boston Downtown. Dort standen Werkbänke die man nach Rücksprache mit einem freundlich gesinnten NPC nutzen konnte. Bei Grid 5 kein Problem, es ging einwandfrei, bei Grid 7 kam die Meldung "Das kannst du im Kampf nicht nutzen" Warum? In einem Gebäude nebenan waren feindliche NPC . Bei Grid 5 war man noch außerhalb ihres Aggroradius----bei Grid 7 voll drin und 7 hat einiges falsch getriggert weil viele Ereignisse zu dicht beieinander sind dafür.
 
nein, ein weit verbreiteter Irrtum. Es geht nicht um Performanceverlust, sondern darum, dass bei höheren uGirdsToLod (also 7, mehr ist eh sehr kritisch, aus anderen Gründen) Skyrim benachbarte Zellen im Voraus lädt und evtl. Aktionen dort, die erst bei Betreten durch den Char ausgelöst werden sollen, früher ausgelöst werden. z. B. Kämpfe.

Ich hatte bei LE auch lange Zeit 7 eingestellt, wegen der größeren Sichtweite (bevor ich DynDoLod nahm), aber immer wieder gab es Ereignisse, die zu früh gestartet waren, bevor ich da war. Das ist bei der SE ebenso. Deswegen bin ich zu 5 zurückgekehrt. Nicht wg. Performance, die ist bei mir eh gut.

Der Meinung bin ich aber auch, dass die uGridsToLoad daher nicht angefasst werden sollte. Unter anderem (früher hab ich damit auch herumexperementiert) hat es mir regelmäßig die Squenz in Flusswald am Anfang zerschossen, weil das Questgespräch stattgefunden hat, ohne dass ich in der Nähe war. Des weiteren sind manchmal Quest-NPCs in Kämpfen mit Kreaturen gestorben, weil ich einfach nicht rechtzeitig zur Unterstützung da sein konnte, weil ich noch Meilenweit entfernt war, der Rest wegen dem zu frühen Laden aber schon getriggert wurde.
Hat also überhaupt gar nichts mit irgendwelchem Performance plus/minus zu tun, sondern mit "allem" anderen, was dadurch kaputt gehen kann.

Meiner Meinung nach braucht es aber auch seit DynDOLOD (wenn es denn richtig funktioniert, was es wie gesagt bei mir immer getan hat) auch keine Änderung an dieser Einstellung in der ini. Wenn man sich jetzt noch die Alpha von Version 3 von DynDOLOD anschaut im zusammenspiel mit den Grasscache von "No grass in objects", ja aller spätestens dann ist die Änderung von uGridsToLoad vollkommen überflüssig.
 
Also ich habe eine hohe uGrid-Einstellung gewählt, und noch nie Probleme damit.
Auch lief und läuft mein Skyrim SE völlig problemlos.
Auch funktioniert DynDOLOD einwandfrei, nachdem ich die Art der Installation geändert habe.
Seitdem funktioniert auch das Speichern wieder.

Ich vermute eher andere Gründe für das DynDOLOD-Problem.
Es wurde ja auch bereits von @EvilMind bei #3 angesprochen.
https://www.elderscrollsportal.de/themen/ctds-seit-dyndolod-installation.55412/#post-1097166

Aber das ist hier in diesem Thread nicht das Thema.
 
@Kleiner Prinz - Als Nachtrag zum Begriffswirrwar "Memory Page" oder "Ram Page"
Gibt es in der .ini für Papyrus:
iMinMemoryPageSize
iMaxMemoryPageSize
iMaxAllocatedMemoryBytes
Gibts hier einen älteren Thread zu, in dem alles steht. Also: Nicht verwechseln.