the Sim Settlements forums!

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Hotfix 2.0.0m - Death to the Long Save!

In my tinkering and trying to fathom what might be conflicting, Wrye Bash is reporting an injection collision between SS2 Chapter 1 and Ch 2:

Check Plugins
• 0F01D6CF injected into SS2.esm, colliding versions:
• SS2RiversideWarehouse [CELL:0F01D6CF] from SS2_XPAC_Chapter2.esm
• SS2JakeSafeRoom [CELL:0F01D6CF] from SS2.esm

Hopefully this is not a bad thing...
 
The Garbage Collector fix started acting up for me, every time I launch the game with it, I get 6 fps maximum. The GPU stops drawing power. When I disable the plugin, game runs smooth at 90~165 fps. No idea what happened. I didn't change any setting neither instaled any new mod.

EDIT: Nevermind, a full system reboot fixed the problem. It might be related to the latest Windows 10 update. Probably some dlls used by Buffout and GC Fix didn't start properly after the update reboot and needed a second reboot to kick in. I'll just leave it here if someone runs into the same issue.
 
Last edited:
Bethesda's servers are a pain in the but for Xbox - basically they will flag it as having an update available when I upload, but you won't actually be able to download it for many hours later.

You can tell when its safe to update/download it as on the description section of the mod on Xbox, it will show a version number that matches what I posted above. For the base of SS2 the version number xbox should show is 44 and for Chapter 2, it should show 17.
I love F4 and I think that all the SS2 mods are absolutely brilliant, unfortunately I play on Xbox which most of the time isn’t that bad but I think I might have to look at getting myself a pc in order to avoid the Bethesda problems :)
 
Bethesda's servers are a pain in the but for Xbox - basically they will flag it as having an update available when I upload, but you won't actually be able to download it for many hours later.

You can tell when its safe to update/download it as on the description section of the mod on Xbox, it will show a version number that matches what I posted above. For the base of SS2 the version number xbox should show is 44 and for Chapter 2, it should show 17.
My versions are showing 50 for SS2 and 22 for SS2 chapter 2 and they’ve downloaded ok
 
I know, I know, chum, CTD is the bread and butter of FO4, I only asking to know if somebody have an excesive CTD presence cause everything was giong fine (even better) after the last upgrade then PAM! , an almost unplayable game :sorry
For the current and past character I didn't have any CTD's at all until just after I updated, mid game, some of my mods- such as SS2, Chapter 2 and workshop- usually it's very few mods. I don't think this is a problem with mods per se, just how the engine handles scripts that are 'baked' into game saves that change from version to version, their reference and how mods are 'layered' on top other mods (the order in which records are processed- the load order) and whether for some reason that changes.

Prior to this I had random CTD's roughly after about 2-3 hours of game play and usually when fast travelling and were non-repeatable. So, as much as I want to update to the newest 2.0.2a, I'll wait for a bit until I'm ready to start a new character or am ready to close gameplay on the current character out and just want to see if I can 'inline' update.

What does your Event Viewer show for Fallout 4 as the cause of the CTD? Buffout can help as can a few other F4SE injected dlls if your able to use them.
 
For the current and past character I didn't have any CTD's at all until just after I updated, mid game, some of my mods- such as SS2, Chapter 2 and workshop- usually it's very few mods. I don't think this is a problem with mods per se, just how the engine handles scripts that are 'baked' into game saves that change from version to version, their reference and how mods are 'layered' on top other mods (the order in which records are processed- the load order) and whether for some reason that changes.

Prior to this I had random CTD's roughly after about 2-3 hours of game play and usually when fast travelling and were non-repeatable. So, as much as I want to update to the newest 2.0.2a, I'll wait for a bit until I'm ready to start a new character or am ready to close gameplay on the current character out and just want to see if I can 'inline' update.

What does your Event Viewer show for Fallout 4 as the cause of the CTD? Buffout can help as can a few other F4SE injected dlls if your able to use them.
Sorry by my ignorance, not sure what do you mean with Event Viewer or Buffout. Definitely I haven't got any super power in modding, only can set armours and guns and lillte craps, you know. The CTD in my case start to make the drive (D) in wich the game is installed disapear, so I need to reset the damn computer for get access again.
 
Sorry by my ignorance, not sure what do you mean with Event Viewer or Buffout. Definitely I haven't got any super power in modding, only can set armours and guns and lillte craps, you know. The CTD in my case start to make the drive (D) in wich the game is installed disapear, so I need to reset the damn computer for get access again.
It's no problem at all. Does any other game cause this? or just Fallout 4? I would suggest running system file checker along with a hard drive scan. These are tools that comes with windows. You can google them for your current operating system for instructions or use windows' explorer on your drive and check the tools tab (if I remember correctly).

System file checker will attempt to verify your operating system files and the check hard drive(hard drive scan) will check the drive for any errors. Be careful to only check the drive for errors and not format it. That would be a good start.

With any game it's a layered kind of things. Where software 'sits on top of' hardware and then you have more layers of software on top of that until you get to the game like Fallout 4. If something is amiss anywhere in the chain, it can cause problems like ctds. If hardware starts to fail, like memory, the hard drive itself, or even the graphics card, It might not be noticeable until that certain part of the hardware that's broken or failing gets used- then the software on top that says... i don't know what just happened so let's report it as a crash. of sorts.

The biggest problem I've seen is either with the usb chips(the programmable side of them) along with the hard drive controller eproms- persistent little repositories. But we need to rule out operating system file corruption(using system file checker) and or hard drive problems (check drive for errors).
 
The Garbage Collector fix started acting up for me, every time I launch the game with it, I get 6 fps maximum. The GPU stops drawing power. When I disable the plugin, game runs smooth at 90~165 fps. No idea what happened. I didn't change any setting neither instaled any new mod.

EDIT: Nevermind, a full system reboot fixed the problem. It might be related to the latest Windows 10 update. Probably some dlls used by Buffout and GC Fix didn't start properly after the update reboot and needed a second reboot to kick in. I'll just leave it here if someone runs into the same issue.
OK this happened again, and the problem isn't Windows Updates. From what I've noticed, the problem is KING OF FIGHTERS XV updates on Steam. Apparently every time KOF XV is patched with updates, I can't use the GC Fix on FO4 properly unless I do a full system reboot. Without rebooting my fps stays at 6 maximum if the GC Fix is enabled.

It's very weird, but it is what it is.
 
Last edited:
F4SE Garbage Collector Fix

Nukem created this patch for Fallout 4: https://drive.google.com/u/0/uc?id=1UAIXTCy9rtQxyFYc0SMjzuHLU4UlMGKV&export=download
It requires F4SE https://f4se.silverlock.org/, and the address library: https://www.nexusmods.com/fallout4/mods/47327

Presumably this will be released officially as a patch you an download on Nexus, or per our conversation, he may send it to the Buffout 4 creator to have it incorporated there, but in the interim you can keep using it.

Even with SS2 presumably having this issue addressed, this fix is something valuable and may have performance gains beyond correcting long saves.

--
For those of you tech-minded, here's what this fix does, and why the long save issue occurred in the first place:


SS2 often bypasses Bethesda's papyrus limitation against multi-dimensional arrays, by storing scripted objects in our data structures and arrays, this way we can simulate as much depth as we need to and effectively emulate a standard programming language as far as keeping complex data is concerned.

The Creation Engine uses a very simple garbage collector, one that is given a very tiny amount of time each frame to do its thing. Unfortunately, when iterating over arrays, if it finds a piece of data it needs to clean up, it restarts the loop. This in itself is generally not a problem, except that it can't dismantle a struct from an array all at once, it has to do so one data point at a time. So when it comes to one of our emulated multi-dimension arrays, it has to restart the loop over and over again, and will rarely ever finish in its allotted time - so this garbage piles up until just before your game saves, when its finally given the time to do a full clean-up.

Still, none of this is new since SS2 released. We've always used these complex patterns without issue. What changed in the 2.0.0 patch that started causing these long saves, is that we introduced several new plot classes, and one of them was entered twice in an array by mistake.

This then caused an innocuous function I had set up, that was meant to ensure other mods and expansions can inject new building classes one day, to never be able to use its own cache of building class information. The way the cache worked was very simplistic, if the number of entries in the cache matched or exceeded the default class list, the cache would be used, otherwise it would be generated fresh. This was done to handle edge cases where addons were registering building plans before the corresponding class has finished registering.

Since the cache would only accept new unique entries, and there was a duplicate in the default list, the cache was always one entry smaller than the default list, so SS2 treated it like the cache still wasn't finished preparing.

The more plots you had in your save, the more time this building class information cache was being regenerated. In realtime, this didn't really matter, and the code could do it thing, but it would start creating thousands of these data structures over time that took too long for the per frame garbage collector to handle. Then come save time, the GC was given as much time as it needed to clean up the unneeded cache copies.

To fix this for SS2, it was as simple as removing the duplicate entry from our default array so that the cache would be considered valid, and would not be constantly regenerated.

Nukem's fix was very straight-forward, and basically optimizes the per-frame garbage collector so that it doesn't have to repeat the entire loop every time it removes an entry from a struct. Effectively making it so it could correctly dismantle SS2's complicated data structures in the allotted time.


So the issue was one part mistake by me, and one part suboptimal engine code that collided into this epic fail.
I'm well into my first playthrough on the PC and started having the long save problem in Far Harbor. I added this F4SE fix and it all went away. Two things were happening right before this (though not assuming they're the cause) Vortex wanted to update and I had just installed PRA's Eden theater settlement. After doing the Vortex update and loading this GC fix, everything is running perfectly again.
 
Finally good news!
I've been waiting for LS & Reset HQ issues to be resolved to release my Leader Pack, and here is, Nobody's Leaders 2 is now out too. :)

F4SE Garbage Collector Fix

Nukem created this patch for Fallout 4: https://drive.google.com/u/0/uc?id=1UAIXTCy9rtQxyFYc0SMjzuHLU4UlMGKV&export=download
It requires F4SE https://f4se.silverlock.org/, and the address library: https://www.nexusmods.com/fallout4/mods/47327

Presumably this will be released officially as a patch you an download on Nexus, or per our conversation, he may send it to the Buffout 4 creator to have it incorporated there, but in the interim you can keep using it.

Even with SS2 presumably having this issue addressed, this fix is something valuable and may have performance gains beyond correcting long saves.

--
For those of you tech-minded, here's what this fix does, and why the long save issue occurred in the first place:


SS2 often bypasses Bethesda's papyrus limitation against multi-dimensional arrays, by storing scripted objects in our data structures and arrays, this way we can simulate as much depth as we need to and effectively emulate a standard programming language as far as keeping complex data is concerned.

The Creation Engine uses a very simple garbage collector, one that is given a very tiny amount of time each frame to do its thing. Unfortunately, when iterating over arrays, if it finds a piece of data it needs to clean up, it restarts the loop. This in itself is generally not a problem, except that it can't dismantle a struct from an array all at once, it has to do so one data point at a time. So when it comes to one of our emulated multi-dimension arrays, it has to restart the loop over and over again, and will rarely ever finish in its allotted time - so this garbage piles up until just before your game saves, when its finally given the time to do a full clean-up.

Still, none of this is new since SS2 released. We've always used these complex patterns without issue. What changed in the 2.0.0 patch that started causing these long saves, is that we introduced several new plot classes, and one of them was entered twice in an array by mistake.

This then caused an innocuous function I had set up, that was meant to ensure other mods and expansions can inject new building classes one day, to never be able to use its own cache of building class information. The way the cache worked was very simplistic, if the number of entries in the cache matched or exceeded the default class list, the cache would be used, otherwise it would be generated fresh. This was done to handle edge cases where addons were registering building plans before the corresponding class has finished registering.

Since the cache would only accept new unique entries, and there was a duplicate in the default list, the cache was always one entry smaller than the default list, so SS2 treated it like the cache still wasn't finished preparing.

The more plots you had in your save, the more time this building class information cache was being regenerated. In realtime, this didn't really matter, and the code could do it thing, but it would start creating thousands of these data structures over time that took too long for the per frame garbage collector to handle. Then come save time, the GC was given as much time as it needed to clean up the unneeded cache copies.

To fix this for SS2, it was as simple as removing the duplicate entry from our default array so that the cache would be considered valid, and would not be constantly regenerated.

Nukem's fix was very straight-forward, and basically optimizes the per-frame garbage collector so that it doesn't have to repeat the entire loop every time it removes an entry from a struct. Effectively making it so it could correctly dismantle SS2's complicated data structures in the allotted time.


So the issue was one part mistake by me, and one part suboptimal engine code that collided into this epic fail.
I've been struggling with long loads for weeks, until I found this patch.
It really needs to be built into F4SE or at least a mod on nexus.
Finding it earlier would really have saved me a lot of grief. I was on the verge of giving up this play through.
 
I've been struggling with long loads for weeks, until I found this patch.
It really needs to be built into F4SE or at least a mod on nexus.
Finding it earlier would really have saved me a lot of grief. I was on the verge of giving up this play through.
From my understanding, Buffout 4 will include something similar in a future update.
 
I know this is an old thread but I had to write how thankful I am that i found this. I have been searching for weeks for a fix to the long save times and I was about to give up and ditch my character that I have invested hundreds of hours into.
That plug-in fixed it!!!
I had times when it took more than 30 minutes to save, I think the record was 70 minutes. It happened like every fifth save or so, sometimes completely random.
Thank you, thank you!!
 
For those of you tech-minded, here's what this fix does, and why the long save issue occurred in the first place:


SS2 often bypasses Bethesda's papyrus limitation against multi-dimensional arrays, by storing scripted objects in our data structures and arrays, this way we can simulate as much depth as we need to and effectively emulate a standard programming language as far as keeping complex data is concerned.

The Creation Engine uses a very simple garbage collector, one that is given a very tiny amount of time each frame to do its thing. Unfortunately, when iterating over arrays, if it finds a piece of data it needs to clean up, it restarts the loop. This in itself is generally not a problem, except that it can't dismantle a struct from an array all at once, it has to do so one data point at a time. So when it comes to one of our emulated multi-dimension arrays, it has to restart the loop over and over again, and will rarely ever finish in its allotted time - so this garbage piles up until just before your game saves, when its finally given the time to do a full clean-up.

Still, none of this is new since SS2 released. We've always used these complex patterns without issue. What changed in the 2.0.0 patch that started causing these long saves, is that we introduced several new plot classes, and one of them was entered twice in an array by mistake.

This then caused an innocuous function I had set up, that was meant to ensure other mods and expansions can inject new building classes one day, to never be able to use its own cache of building class information. The way the cache worked was very simplistic, if the number of entries in the cache matched or exceeded the default class list, the cache would be used, otherwise it would be generated fresh. This was done to handle edge cases where addons were registering building plans before the corresponding class has finished registering.

Since the cache would only accept new unique entries, and there was a duplicate in the default list, the cache was always one entry smaller than the default list, so SS2 treated it like the cache still wasn't finished preparing.

The more plots you had in your save, the more time this building class information cache was being regenerated. In realtime, this didn't really matter, and the code could do it thing, but it would start creating thousands of these data structures over time that took too long for the per frame garbage collector to handle. Then come save time, the GC was given as much time as it needed to clean up the unneeded cache copies.

To fix this for SS2, it was as simple as removing the duplicate entry from our default array so that the cache would be considered valid, and would not be constantly regenerated.

Nukem's fix was very straight-forward, and basically optimizes the per-frame garbage collector so that it doesn't have to repeat the entire loop every time it removes an entry from a struct. Effectively making it so it could correctly dismantle SS2's complicated data structures in the allotted time.


So the issue was one part mistake by me, and one part suboptimal engine code that collided into this epic fail.

Not going to update again until Ch.3 is out and hopefully by then things are nice and tidy but I wanted to say, as a developer I always appreciate these kinds of war stories and the extra time it took for you to write it up :)
 
Top