Skyrim SE Stuttering.

[Guest]

1 hour ago, Church the Cat said:

My SKSE mods, also. 

What are your settings for enginefixes? Most importantly:

 

Quote

; WARNING: These can cause crashes. If you can find a crash caused by MemoryManager, please report it and include a .NET Script Framework crash dump
[Experimental]
MemoryManager = false                   ; Disables Skyrim's memory manager in favor of standard allocation (Use OS Allocators), can help with ILS
UseTBBMalloc = true                     ; Uses TBBMalloc instead of standard allocators, only active if MemoryManager is true

I tried using enginefixes' memory allocator before, and it caused nothing but problems.

[Church the Cat]

4 minutes ago, lynak said:

What are your settings for enginefixes? Most importantly:

 

I tried using enginefixes' memory allocator before, and it caused nothing but problems.

Okay, I'll try playing with it disabled and see how it goes. That being said, I was able to play for an extended time without memory issues just now. I'm still leaning towards it having something to do with "Sexlab" or "Sexlab - Defeat", since everything worked great without any sex going on.

[dankmemesxd]

https://www.nexusmods.com/skyrimspecialedition/mods/10547

 

https://www.nexusmods.com/skyrimspecialedition/mods/17230

 

Try installing this, are you running an enb?

[Church the Cat]

Here's my current "Engine Fixes" settings. 

[Church the Cat]

3 minutes ago, dankmemesxd said:

https://www.nexusmods.com/skyrimspecialedition/mods/10547

 

https://www.nexusmods.com/skyrimspecialedition/mods/17230

 

Try installing this, are you running an enb?

Greetings, I don't use an ENB and I already use "SSE Engine Fixes".

[Guest]

1 hour ago, dankmemesxd said:

https://www.nexusmods.com/skyrimspecialedition/mods/10547

 

https://www.nexusmods.com/skyrimspecialedition/mods/17230

 

Try installing this, are you running an enb?

He just posted that he already has engine-fixes, and sse-fixes is redundant to that - at best running both would do nothing, and at worst this would introduce another conflict.

[Guest]

1 hour ago, Church the Cat said:

Here's my current "Engine Fixes" settings. 

Now identical to mine, except for purely cosmetic stuff (like scrollwheel POV-switching).

[Church the Cat]

1 minute ago, lynak said:

Now identical to mine, except for purely cosmetic stuff (like scrollwheel POV-switching).

Actually, that's how I already had it set. MemoryManager was already false and UseTBBMalloc was already true.

[Guest]

1 hour ago, Church the Cat said:

Actually, that's how I already had it set. MemoryManager was already false and UseTBBMalloc was already true.

....

 

Crap.

 

*Checks the clock* "Well, that's a good excuse to go to sleep, and check back tomorrow."

 

EDIT:

Quote

Okay, I'll try playing with it disabled and see how it goes. That being said, I was able to play for an extended time without memory issues just now. I'm still leaning towards it having something to do with "Sexlab" or "Sexlab - Defeat", since everything worked great without any sex going on.

So, it usually happens outdoors, and when defeat triggers sex-scenes. Gonna look into defeat-settings tomorrow.

[Church the Cat]

25 minutes ago, lynak said:

....

 

Crap.

 

*Checks the clock* "Well, that's a good excuse to go to sleep, and check back tomorrow."

 

EDIT:

So, it usually happens outdoors, and when defeat triggers sex-scenes. Gonna look into defeat-settings tomorrow.

Not sure if the outdoors itself is the issue, I made a mod that adds a larger variety of enemies that can spawn using the ambient animals lists. Quite often, I would get a notification like "troll is moving towards bandit" (to rape her). This would happen while I'm running by, then the scene would be ended early after I leave the area, making them both be cleared from the world. I suspect interrupted scenes from "Sexlab" or "Sexlab Defeat" are the issue, regardless of whether they are indoors or outdoors. Sleep well, thanks for your help.

[Guest]

Back. A bit of background about the SL-plugins you have installed: There's a few things that are difficult/risky to control in skyrim - such as combat-AI. Defeat hooks into all of them. There's also some notoriously crashprone situations in sexlab (such as the moment of orgasm - everyone and their cat wants to hook into it, which sometimes does not go well), and defeat hooks into all of them.

 

Defeat in essense is nothing but a giant steelfisted override, to bend skyrim and sexlab to its will. That's not really the fault of Defeat, since there is no other way to do it - i'm just saying what Defeat tries to achieve is not something skyrim or sexlab was designed for. And to a lesser extend the same goes for SLSO. I wouldn't be surprised, if those two plugins caused the most crashes among all SL-mods (creatures would be a 3rd candidate, but only because of the complexity and scope (lots of room for user-error)). Again: That's not neccessarily the fault of the mod-authors, but simply has to do with what those mods are  trying to achieve.

 

What they're not known for is memleaks, but as i said yesterday: It's not like we can be sure to have seen every possible combination of things.

 

So with the preamble outta the way, let's narrowing candidates by exclusion:

 

0. Before doing anything: Make a new save, and don't touch your old saves for testing, so you can always go back if something breaks)

 

1. Since you think it's defeat-triggered sexacts being unloaded as you move from cell to cell. That's easy to test for exclusion: Just disable NPC vs NPC in defeat, and see if it still happens. Since the only other NPC-sex trigger in your modlist is jailrape, the only thing you need to make sure for testing is, stay away from jailcells.

 

2. If it goes away, so we know it's either defeat-specific, or problem with NPC-sexacts in general, the next thing i'd try is exclude SLSO, simply because it's a "known offender": Disable SLSO, clean your save, then reactivate Defeat's NPC vs NPC, to see if the issue reappears.

 

3. If it does reappear, install some other mod that triggers NPC-sex, to see if it's Defeat-specific, or just a general issue with NPC-sex.

 

Speaking of which: One thing that is very unusual for your setup, compared to what others are running is, that you don't have SLA (or SLAC for that matter). It's so ubitiqous, that some mod authors might not even consider the possibility, that SLA isn't installed. And when programmers don't consider a case, that's when bad things happen, since computers are stupid. Just an idea.

 

EDIT: Even stranger - you don't have the creature-framework? How then would Defeat let a creature go after someone? Disable defeat for creatures, or install the stuff needed for it to work.

[Church the Cat]

11 hours ago, lynak said:

Spoiler

 

Back. A bit of background about the SL-plugins you have installed: There's a few things that are difficult/risky to control in skyrim - such as combat-AI. Defeat hooks into all of them. There's also some notoriously crashprone situations in sexlab (such as the moment of orgasm - everyone and their cat wants to hook into it, which sometimes does not go well), and defeat hooks into all of them.

 

Defeat in essense is nothing but a giant steelfisted override, to bend skyrim and sexlab to its will. That's not really the fault of Defeat, since there is no other way to do it - i'm just saying what Defeat tries to achieve is not something skyrim or sexlab was designed for. And to a lesser extend the same goes for SLSO. I wouldn't be surprised, if those two plugins caused the most crashes among all SL-mods (creatures would be a 3rd candidate, but only because of the complexity and scope (lots of room for user-error)). Again: That's not neccessarily the fault of the mod-authors, but simply has to do with what those mods are  trying to achieve.

 

What they're not known for is memleaks, but as i said yesterday: It's not like we can be sure to have seen every possible combination of things.

 

So with the preamble outta the way, let's narrowing candidates by exclusion:

 

0. Before doing anything: Make a new save, and don't touch your old saves for testing, so you can always go back if something breaks)

 

1. Since you think it's defeat-triggered sexacts being unloaded as you move from cell to cell. That's easy to test for exclusion: Just disable NPC vs NPC in defeat, and see if it still happens. Since the only other NPC-sex trigger in your modlist is jailrape, the only thing you need to make sure for testing is, stay away from jailcells.

 

2. If it goes away, so we know it's either defeat-specific, or problem with NPC-sexacts in general, the next thing i'd try is exclude SLSO, simply because it's a "known offender": Disable SLSO, clean your save, then reactivate Defeat's NPC vs NPC, to see if the issue reappears.

 

3. If it does reappear, install some other mod that triggers NPC-sex, to see if it's Defeat-specific, or just a general issue with NPC-sex.

 

Speaking of which: One thing that is very unusual for your setup, compared to what others are running is, that you don't have SLA (or SLAC for that matter). It's so ubitiqous, that some mod authors might not even consider the possibility, that SLA isn't installed. And when programmers don't consider a case, that's when bad things happen, since computers are stupid. Just an idea.

 

EDIT: Even stranger - you don't have the creature-framework? How then would Defeat let a creature go after someone? Disable defeat for creatures, or install the stuff needed for it to work.

 

 

I've since uninstalled a few mods, before starting a new character. Both "SLSO" and "Jail Rape" are gone. Everything seems to be working fine, afterwards.

1. I've since disabled the NPC vs. NPC section entirely, no stuttering has happened since. As already mentioned, "Jail Rape" has been removed from my load order.

2. After disabling "Defeat's" NPC vs. NPC coupled with the removal of "SLSO" and "Jail Rape" everything seems to be back to normal. As far as a "clean save", I think it was the creator of the unofficial patches, Arthmoor that said that there is no such thing as a "clean save". So, I never remove or add mods during a playthrough.

 I believe that the Creature Framework is included with FNIS or Sexlab, now. Either way, the animations work fine.

 

I appreciate your prolonged assistance, but I'm content to just leave it be since I along with help from you guys seem to have got it working again. If anything changes, I'll be sure to report it, here.

 

Thanks, again.

 

(Edit) Nevermind, it's still inhaling memory. Not sure Defeat's the culprit, anymore. Since I've disabled NPC vs. NPC and neither I nor my three followers were downed during combat.

 

My whole playthrough consisted of exiting the home of the blacksmith in Shor's Stone, entering the mine, killing Sylgia after accepting her delivery quest and deciding I didn't feel like being a mailman. Also killed one other miner that carries "Rocksplinter". (Cutting Room Floor - Addon.), mining the iron ore, smelting the ore, crafting many nails for the XP, leaving Shor's Stone on the back of Frost, riding north to the guard tower with three dead guards, looting the dead guards and chest at the top of the tower, leaving the tower heading north towards "Cragslane Cavern", killing the Bouncer and his two caged wolves, looting the bouncer and two wolves. (This is when I noticed the stuttering had begun), afterwards I kept playing for a bit and entered, cleared and looted "Cragslane Cavern" while it constantly stuttered. My current load order.  

[Guest]

Quote

As far as a "clean save", I think it was the creator of the unofficial patches, Arthmoor that said that there is no such thing as a "clean save". So, I never remove or add mods during a playthrough.

That's what i asked you to make a new save for in step 1: So you don't remove mods on your "real saves" - only on your "test saves". Without the willingness to disable mods for testing, your ability to isolate troublemakers will be very limited in the future.

 

Quote

I believe that the Creature Framework is included with FNIS or Sexlab, now. Either way, the animations work fine.

 

It is not. You were running an incomplete setup (still are, if you ever want to use creature-sex), and apparently Defeat failed to check for this when assigning scenes. Although that's impossible to verify now, since you just removed everything, so it's still unclear what caused the leak.

[Church the Cat]

5 hours ago, lynak said:

That's what i asked you to make a new save for in step 1: So you don't remove mods on your "real saves" - only on your "test saves". Without the willingness to disable mods for testing, your ability to isolate troublemakers will be very limited in the future.

 

It is not. You were running an incomplete setup (still are, if you ever want to use creature-sex), and apparently Defeat failed to check for this when assigning scenes. Although that's impossible to verify now, since you just removed everything, so it's still unclear what caused the leak.

I mistook "Creature Framework" as the "Creature Pack" included with FNIS. But, it looks like creature framework only adds the "equipment" to the animals during sex scenes. Since I just use a mesh replacer "Nude Creatures", I've never bothered installing "Creature Framework".

 

(Edit) Enabled Papyrus logging, to help locate the memory hog. But, after hours of play without issue, I must give up for the night. I'll play more tomorrow after work and hopefully find something in the log.

[Church the Cat]

Got a couple Papyrus logs, 0 includes a stuttering memory leak where's 1 does not. I looked through them, but couldn't see anything different that might point me to the stutter culprit.

Papyrus.0.log Papyrus.1.log

[harrypotter12345]

Are you sure it's not a uGrid issue? I had to lower my settings from BethINI's Ultras to eliminate stuttering. Try to lower your settings in BethINI.

[Church the Cat]

56 minutes ago, harrypotter12345 said:

Are you sure it's not a uGrid issue? I had to lower my settings from BethINI's Ultras to eliminate stuttering. Try to lower your settings in BethINI.

Greetings, thanks for the suggestion. However, I've never altered the "uGrid" setting previously. Should I alter the vanilla "uGrid" setting?

[GenioMaestro]

On 9/22/2019 at 10:16 PM, lynak said:

Next up: https://www.nexusmods.com/skyrimspecialedition/mods/5031/

 

Get this unless you already have it and launch "ReSaver.exe". I don't remember how exactly it works on first launch, but it'll probably ask you for your skyrim saves folder. It's just where we already looked for large files: YourDocumentsFolder/My Games/Skyrim Special Edition/Saves.

 

Then load your most recent save, and compare the numbers to mine:

 

Again, we're looking for completely abnormal numbers. Especially look if there's a large number of suspended stacks. It would be really great if we could find the culprit in there, because..... this program allows filtering data by mod ? But more on that later - for now, just compare to see if anything is completely different on your end.

 

 

Have you follow this instructions?

When your game have heavy stuttering, save your game and look if the file size of the savegame is abnormal big. Try open your gigantic savegame with ReSaver and look the line ActiveScripts, probably you have thousand and thousand.

 

On 9/24/2019 at 5:18 AM, Church the Cat said:

 

 

The only way for consume memory in that constant way and for that gigantic amount (64 GB) is having a mod whit a script that go crazy and start creating thousand and thousand of instances. Each script need memory and each copy of the script consume memory. That constant memory consumition only can be caused by a crazy script.

 

A similar problem in LE(Legendary Edition) is direct CTD when the 3.1 GB of LE is consumed. As SE(Special Edition) is a 64 bits game can consume all the 64 GB of your physical RAM before start requesting Virtual Memory from the hard disk. In that moment you start having severe stuttering.

 

The way for locate the crazy script is save your game regulary or when you have heavy stuttering and open the savegame whit ReSaver to look at ActiveScripts.

 

12 hours ago, Church the Cat said:

Got a couple Papyrus logs, 0 includes a stuttering memory leak where's 1 does not. I looked through them, but couldn't see anything different that might point me to the stutter culprit.

Papyrus.0.log 236.78 kB · 3 downloads Papyrus.1.log 606.85 kB · 1 download

 

If you activate the log you must have gigantic logs of hundreds of megabytes plenty full of Stacks Dumps.

I see one Stack Dump inside one of your logs related to SOS but that is not a security about if the problem is directly caused by SOS.

The only way for know it is save your game regulary or when you have severe stuttering and open your savegame with ReSaver for look the ActiveScripts secction.

[GenioMaestro]

On 9/24/2019 at 6:36 AM, Church the Cat said:

(Edit) Enabled Papyrus logging, to help locate the memory hog. But, after hours of play without issue, I must give up for the night. I'll play more tomorrow after work and hopefully find something in the log.

If you not have any issue after playing some hours, probably, you can not see any strange in the log or inside the savegame for that gameplay session.

Maybe, the crazy script not fired in that game session or, maybe, your super powerfull computer procesed all the crazy scripts whitout you notice it.

The only way for locate the problem is having the papyrus log constantly active, save your game, look the size of the log, the size of the savegame and try open it with ReSaver.

If the problem only show under strange circustances the only way for locate it is play and monitoring your game until the problematic script start making crazy things.

[phillout]

6 hours ago, GenioMaestro said:

 

Have you follow this instructions?

When your game have heavy stuttering, save your game and look if the file size of the savegame is abnormal big. Try open your gigantic savegame with ReSaver and look the line ActiveScripts, probably you have thousand and thousand.

 

 

The only way for consume memory in that constant way and for that gigantic amount (64 GB) is having a mod whit a script that go crazy and start creating thousand and thousand of instances. Each script need memory and each copy of the script consume memory. That constant memory consumition only can be caused by a crazy script.

 

A similar problem in LE(Legendary Edition) is direct CTD when the 3.1 GB of LE is consumed. As SE(Special Edition) is a 64 bits game can consume all the 64 GB of your physical RAM before start requesting Virtual Memory from the hard disk. In that moment you start having severe stuttering.

 

The way for locate the crazy script is save your game regulary or when you have heavy stuttering and open the savegame whit ReSaver to look at ActiveScripts.

 

 

If you activate the log you must have gigantic logs of hundreds of megabytes plenty full of Stacks Dumps.

I see one Stack Dump inside one of your logs related to SOS but that is not a security about if the problem is directly caused by SOS.

The only way for know it is save your game regulary or when you have severe stuttering and open your savegame with ReSaver for look the ActiveScripts secction.

 

This is pretty much normal if you overload Papyrus with tons of running scripts.

 

I had the same results with Footprints - just by setting player speed to 100 normal and toggling on "tcl" and making a couple of laps around Skyrim. This was always my stability test, BTW. Footprints caused Papyrus going crazy and dumping tons of thread stacks in the log.

 

I had the same results with "More Hotkeys, Please" and "Better Container Controls" since the latter may add 100s of items into my inventory at once, and the former one triggers a script on every item removed/added to inventory. This gives me tons of threads running and dumping stacks in the log (so I've just removed those event handlers, I don't hotkey potions with MHP anyway).

 

So the behavior of Defeat is pretty much what you expect from a script-heavy mod triggering scripted events on every NPC around. In the LE days I had crashes with the "NPC vs NPC" enabled only because I had "Immersive Patrols" installed. As soon as I reached an area with Stormcloaks fighting Imperials, my game started stuttering like crazy and then crashed in a couple of minutes.

[GenioMaestro]

1 hour ago, phillout said:

 

This is pretty much normal if you overload Papyrus with tons of running scripts.

 

I had the same results with Footprints - just by setting player speed to 100 normal and toggling on "tcl" and making a couple of laps around Skyrim. This was always my stability test, BTW. Footprints caused Papyrus going crazy and dumping tons of thread stacks in the log.

 

I had the same results with "More Hotkeys, Please" and "Better Container Controls" since the latter may add 100s of items into my inventory at once, and the former one triggers a script on every item removed/added to inventory. This gives me tons of threads running and dumping stacks in the log (so I've just removed those event handlers, I don't hotkey potions with MHP anyway).

 

So the behavior of Defeat is pretty much what you expect from a script-heavy mod triggering scripted events on every NPC around. In the LE days I had crashes with the "NPC vs NPC" enabled only because I had "Immersive Patrols" installed. As soon as I reached an area with Stormcloaks fighting Imperials, my game started stuttering like crazy and then crashed in a couple of minutes.

Not, excuse me, none mod need 64 GB of memory under normal circunstances. 

Consume 64 GB (Giga Bytes) of memory is not normal. That only can be caused by an error in a script that is bad developed or a mod bad configured or a script that is incorrectly overwriten by another version of the same script in other mod or ...

 

 

I not know why the people are making test ussing "tcl" because is not the correct way for test the stability of the game. You can use "player.setav speedmult xxxx" for have super speed and "tgm" for enable good mode and you can run as crazy whitout dead and go from WhiteRun to Riften in one minute or two whit the consecuent stuttering and freezess caused by the super speed. But all the game, the mods and the npc's act normal.

But when you enable "TCL" the game works in a very different way and some times can give you specific problems because the npc's, normally, walk over the same spot, the game not control in a correct way what are you making and the npc's can go crazy because some mods try make incorrect things.

Never use "TCL" for test the game.

 

Appart, the game, no matter if we talk about LE or SE, can support hundreds and hundreds of simultáneous scripts whitout any problem. Look any of my test mods if you want verify it. I'm totally sure you never can have a normal game with 200 npc's arround you but Multi_Cloack make it and my game works whitout any problem. How you can have a problem when Defeat launch one script over 10 npc's?

 

Of course, hundreds and hundreds is not thousands and thousands, is very diferent.

One mod can launch hundreds of scripts for make a correct operation while thousands of scripts can only be generated by an error in the scripts of one mod, normally one uncontroled script that go crazy and, of course, can cause a lot of problems.

 

The capacity of the Script Engine is tremendous and all the problems that everybody say are caused by the script, really, are caused by problems in the memory management of LE and the pathetic memory blocks.

Of course, some uncontroled scripts in some bad developed mods has giving us a lot of problems but others mods, like OBIS, Immersive Patrols or Civil War Overhaul never had a problem in the scripts. The only problem was the bad configuration of the memory management in the game of each user, really the lack of SSME or the bad configuration of the skse.ini file or incorrect changes in the INI files of the game.

[phillout]

1 hour ago, GenioMaestro said:

Not, excuse me, none mod need 64 GB of memory under normal circunstances. 

Consume 64 GB (Giga Bytes) of memory is not normal. That only can be caused by an error in a script that is bad developed or a mod bad configured or a script that is incorrectly overwriten by another version of the same script in other mod or ...

 

 

 

Take a look at Defeat sources and all that absurd amount of work the mod does in order to check whenever NPC should be raped by another NPC at the moment. OnHit events etc, and this is done for every NPC out there in combat.

 

Papyrus got a facelift in SSE, but it's still not ready for performing 100s of complex operations per second. And probably will never be, you need a native SKSE plugin for something like that.

[GenioMaestro]

31 minutes ago, phillout said:

Take a look at Defeat sources and all that absurd amount of work the mod does in order to check whenever NPC should be raped by another NPC at the moment. OnHit events etc, and this is done for every NPC out there in combat.

Defeat always had problems. Is the worst desing that is see inside a mod. I have my own version of DD, DCUR, PSQ, Virgin... I try make my own version of Defeat but i'm unable.

 

37 minutes ago, phillout said:

Papyrus got a facelift in SSE, but it's still not ready for performing 100s of complex operations per second. And probably will never be, you need a native SKSE plugin for something like that.

Because Papyrus is not designed for make that. The intention of Papyrus is execute as many script at the same time in the most fast and reliable way preserving the game integrity. For that Papyrus is slow, very slow.

Really, each script is executed only for some nano seconds in each frame because every time a script need external data, from the game or from another script, is suspended. That mean that each script is constanly suspended and started again in the every frame. That allow the game execute hundreds and hundreds of script at the same time but at cost of execution time.

One line of one script that make some verification can need up to 100 ms and some scripts can need 500 ms for be executed. But that, really, is not important because the most important point is that the script is executed correctly, no matter how many time need.

You can not notice if a script is executed in 50 ms or in 100 ms except when the script add a visual effect and in, that moment, a diference of 50 ms is aceptable because we can not know with security if the delay come from the script engine or from the game engine or from the memory manager or if is a graphical problem.

 

Please, stop tinking that the scripts are the worst part of the game. The base game have 10k script. The modders has written millons of lines in papyrus and that is because papyrus works very good.

[phillout]

3 hours ago, GenioMaestro said:

Please, stop tinking that the scripts are the worst part of the game. The base game have 10k script. The modders has written millons of lines in papyrus and that is because papyrus works very good.

 

I'm not "thinking that the scripts are the worst part of the game", I've told you exactly what I'm thinking, it's just you who can't understand simple statements.

 

There is only so much resources the game engine can dedicate to processing Papyrus scripts, at every frame, and if it can't process all of them - they simply start staying in the execution queue. If the game engine can't execute some script for a given period of time, after timeout the script gets terminated and you've got the stack dump in the Papyrus log. And this is exactly what's going on here. The amount of scripts present on the hard drive is irrelevant, what matters is amount of scripts currently executed. Once you start getting a lot of thread dumps in the log - you're in a lot of trouble, since the game is about to crash, this happens no matter what mod you're running, getting stack dumps happened to me before getting crashes with Footprints too, and with MHP as well.  Papyrus is fine until you push it beyond its limits, then it crashes and burns, and takes the whole game with it. My current understanding of the problem is that terminated scripts do not release all resources and you've got a huge memory leak, leading to 60GB VM used, CTDs etc.

[GenioMaestro]

1 hour ago, phillout said:

If the game engine can't execute some script for a given period of time, after timeout the script gets terminated and you've got the stack dump in the Papyrus log.

You are another of that users that think that, in each Stack Dump, the game automatically terminate all the scripts exposed in the Stack Dump making the game totally unstable and that derive in a broken save game. Please, read my blog and my post, download my tools and learn how works the game.

 

1 hour ago, phillout said:

Once you start getting a lot of thread dumps in the log - you're in a lot of trouble, since the game is about to crash, this happens no matter what mod you're running,

That not have any relation. Any of my test mods can force the game to write one Stack Dump per minute in the papyrus log and my game, Skyrim Legenday Edition, no have any problem and no make CTD.

 

1 hour ago, phillout said:

Papyrus is fine until you push it beyond its limits, then it crashes and burns, and takes the whole game with it.

Papyrus can support any tremendous amount of scripts before the game have any problem.

The game can generate gigantic Stack Dumps and the game can continue working.

My blog, my post and my test mods demostrate it whitout any doubth.

If you have any problem in the game caused by the scripts is because your game is bad configured.

We have that suposed problem for years and every body think "the problem are in the scripts and the cloacks", "overcharge the scripts engine mean secure CTD", "a lot of mods with cloacks give problems", "a single stack dump mean problems in the game with total security"... and the only thing that all that users has say for years is "remove mods with script" or "remove mods with cloacks" or "remove this mod because show in the Stack Dump"

 

All that is totally false. The game not have any problem with the script or the cloacks or the Stack Dumps.

Make some test with ScriptTest and look how the game support 3200 simultáneous constant cell scan.

Make some test with Multi_Cloack and look how the game support 3200 simultáneous cloacks.

All the problem in the game is memory management because each script and each cloack need memory.

If your game is not correctly configured, of course, every time a mod request a bit of memory you have CTD.

 

Another diferent thing is a crazy script from a bad mod that can consume all the available memory in the game causing save game bloat and gigantic logs plenty full of Stacks Dumps. That is the real problem. Bad developed mod whit bad scripts that give a lot of problems. An the only solution is locate the problematic mod, alert the developer of the problem and remove the mod.

But if the developer say "my mod can not cause that problem, look in your game configuration" probably the cause of the problem is in our side caused by a bad installation or a bad configured game.

 

Letting appart specific problems in specific mods, the game support 200 mods from this web site all working at the same time whitout any problem, until you find a crazy script inside one of that mods.