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!

Long Save Research Tool

I feel like it did help some but that may very well be random chance but I am still getting long saves although not quite as long or as frequently as before but again, might just be random chance.
Two questions, first, do you have the crazy long saves like I had (more than ten minutes?) Which version of the vats fix did you install? (I took the second one "all options")

Before SS2 I would consider five seconds a long save, so this obviously doesn't solve the problem completely. But I actually slept in an SS2 built town, right after exiting build mode, with autosave enabled!

I 100% expected this not to do anything, I was shocked when my first quick save, immediately after increasing my build limit and upgrading a building, was instantaneous.
 
Last edited:
An interesting read, yet I'm having trouble wrapping my head around how this would affect non-hardcore mode games. :scratchhead(Unless its related to the new disease system) Also, reading the posts, it seems this is addressed by the UFO4P.
How It Works

Basically what I discovered is that if the Player.EquipItem() function is called while in VATS it will cause the game to freeze up. The survival mode manager script uses the EquipItem() function to equip "potions" which apply the effects of diseases and other effects such as hunger and thirst, because consuming potions is the only way to make the effects show up in the Pip-Boy. I took this approach when creating STB to make bleeding effects show in the Pip-Boy but I noticed if I got shot in VATS it would freeze, which led me to the cause. To fix the vanilla VATS freeze bug I altered HC_ManagerScript and added a potion queue so that if VATS is active potions are added to the queue instead of being immediately consumed, so they can be safely consumed after VATS has exited, at which point you should become hungry, thirsty, tired, etc.

Info For Mod Authors

If your mod overrides HC_ManagerScript.pex it should be easy to merge the changes from this fix, you can quickly see all changes by examining the diff of the vanilla source code against the source code provided with this mod. The way I detect whether or not VATS is active in this fix is to use RegisterForMenuOpenCloseEvent("VATSMenu") and then toggle a boolean value when OnMenuOpenCloseEvent detects VATS opening or closing (credit to cdante for the tip).

IMPORTANT: If your mod adds something to the game which could cause a potion to be equipped to the player while they are in VATS then it will cause freezing. The simplest solution is to use IsMovementControlsEnabled() because movement is always disabled when VATS is active, a timer can be used to delay the equipping of a potion until VATS has ended. However a more standardized and reliable solution would be to make use of the TryEquipPotion() function which has been added to HC_ManagerScript.

Here's an example script showing how to make use of this function:
So, have to post and state this little thing completely removed my long save issues, my main settlement is Starlight and I've turned it into a pretty massive fort with loads of plots, saving while in the settlement was always a go make a cup of tea and read a book affair, soon as I installed this it became a none event.
 
So, have to post and state this little thing completely removed my long save issues, my main settlement is Starlight and I've turned it into a pretty massive fort with loads of plots, saving while in the settlement was always a go make a cup of tea and read a book affair, soon as I installed this it became a none event.
Unfortunately, I had this mod installed since the beginning of the playthrough in chap 2 (forgot to remove it, I'm not currently playing in survival).

I'm glad it works for you guys and this might help @kinggath debug the problem, but for me it did nothing :(
 
So this only works in survival game ? I don’t play survival.
 
Two questions, first, do you have the crazy long saves like I had (more than ten minutes?) Which version of the vats fix did you install? (I took the second one "all options")

Before SS2 I would consider five seconds a long save, so this obviously doesn't solve the problem completely. But I actually slept in an SS2 built town, right after exiting build mode, with autosave enabled!

I 100% expected this not to do anything, I was shocked when my first quick save, immediately after increasing my build limit and upgrading a building, was instantaneous.
Don't rightly know if it ever took that long since I tend to step away when it seems to take a while but I had one earlier that took around five. Just grabbed the main file.

Also I have no earthly clue how but so far things seem to run a lot better, I still get the occasional minute long save but most of the time it's seconds. Granted I still only have a few settlements this time as a precaution but I will expand now and see if it holds up. Guess we'll see.
 
Unfortunately, I had this mod installed since the beginning of the playthrough in chap 2 (forgot to remove it, I'm not currently playing in survival).

I'm glad it works for you guys and this might help @kinggath debug the problem, but for me it did nothing :(
It doesn't -- I exclusively play survival and am still stuck with long saves. Not a script guy but the vats freeze fix patches a script that should only be called in survival mode (HC_ManagerScript.pex) and the changes only come into play when vats is active
 
It doesn't -- I exclusively play survival and am still stuck with long saves. Not a script guy but the vats freeze fix patches a script that should only be called in survival mode (HC_ManagerScript.pex) and the changes only come into play when vats is active
The "all options" one is called on any time player controls are disabled, not just VATS. I don't think it helps directly with the long saves, but I think something happens during the save that causes FO4 to hang, resulting in the ridiculously long save times in excess of 10 minutes. So if your "long saves" are a matter of a few minutes, I don't think this would help.

Really just a guess based on personal experience. Before applying this mod entering build mode in any settlement with SS2 structures would consistently cause 10-15 minute saves. Since installing it, with that being the only change, I've not had a save that even approached one minute, but still saves that would otherwise be considered a long save.
 
So this might be the first thing I post here, but I accidentally solved the saving issue on my game.
I'll explain the circumstances so maybe someone can recreate it.

I'm playing on survival difficulty and have had the issue since day one like everyone, but I also had the nasty vats freeze bug in survival. And it came to a point to where I looked for mod solutions on nexus and low and behold there is the 'vats freeze fix' mod. It states on the page exactly what it does and why the vats bug happens. Now this mod also completely fixed the saving on my game and I mean 100% of my saves now only last less then a second.

I hope this can help in further determining the main cause of this bug and since kinggath mentioned it was top priority, I thought I should share this info.
If this doesnt fix it for other people no harm done and I wish you guys a lot of luck.
I dug into the mod, and the thing it changes is never used by SS2 anywhere - so definitely coincidence.
 
One of the things I've been trying to think of a solution to, is how we can narrow down this issue and determine whether the issue is the ESM or the scripts. As whichever is the culprit is going to require a wildly different approach to trying to diagnose and fix this. @Mystical Panda has been doing a lot here to point me at the scripts as being the problem- as stack dumps are no good and show me we've got some optimization work to do - but what if the issue is the ESM...

I think I have a really simple experiment to determine that. Would require some folks to run a sacrificial character for a few hours - as your game will be broken from doing this.

Run with the 2.0.0 release of SS2, none of the hotfixes, next download the 1.1.0 patch from nexus but don't install it, grab the ba2 file out of the archive, then use a ba2 extractor to extract the contents of its \scripts\ folder to your Data folder. That will cause SS2 to run with the release esm and assets but the 1.1.0 scripts.

Then just play it for a while building up settlements with plots to see if the long save issue returns at the level you're used to seeing in the 2.0.0 patch.

This will cause plenty of bugs in SS2, but the majority of the plot gameplay loop is unchanged between those two patches, other than checking for incapacitated owners when testing for the plot to be active. So you should be able to build plots OK.

If the long saves return, it points me at the ESM as the more likely culprit, otherwise, I'll be looking at script optimization as our solution. (I plan on doing a heavy optimization pass anyway, as stack dumps should be extremely infrequent - but I'll prioritize it if we're certain its the cause of the long save issue).
 
Dropping plots is not issue, build 17 of them in one go at Sanctuary all different types, long save didn't trigger once for me. Normally I would have been hit by the long save already. Before and after Paul showed up.
Max now was about 2-3 seconds but that was/is normal Pre Chapter 2 behaviour. Building a lot of plots at once have some impact on save times.
After the building, before the building I had my <1 second saves. Manual / Auto / Quick. Samples Attached.
Test was done on a clean Vortex profile with the usual fixes installed. Unofficial Patch, BuffBaka, HighFps
Hope it helps!
 

Attachments

  • Exitsave0_16EEB37D_4D617274656E64_Commonwealth_000041_20220118072434_4_2.7z
    2.3 MB · Views: 0
  • Quicksave0_16EEB37D_4D617274656E64_Commonwealth_000039_20220118072134_4_2.7z
    2.4 MB · Views: 0
  • Save5_16EEB37D_4D617274656E64_Commonwealth_000005_20220118064547_1_2.7z
    2.6 MB · Views: 0
  • Save15_16EEB37D_4D617274656E64_Commonwealth_000030_20220118071157_3_2.7z
    2.7 MB · Views: 0
Last edited:
One of the things I've been trying to think of a solution to, is how we can narrow down this issue and determine whether the issue is the ESM or the scripts. As whichever is the culprit is going to require a wildly different approach to trying to diagnose and fix this. @Mystical Panda has been doing a lot here to point me at the scripts as being the problem- as stack dumps are no good and show me we've got some optimization work to do - but what if the issue is the ESM...

I think I have a really simple experiment to determine that. Would require some folks to run a sacrificial character for a few hours - as your game will be broken from doing this.

Run with the 2.0.0 release of SS2, none of the hotfixes, next download the 1.1.0 patch from nexus but don't install it, grab the ba2 file out of the archive, then use a ba2 extractor to extract the contents of its \scripts\ folder to your Data folder. That will cause SS2 to run with the release esm and assets but the 1.1.0 scripts.

Then just play it for a while building up settlements with plots to see if the long save issue returns at the level you're used to seeing in the 2.0.0 patch.

This will cause plenty of bugs in SS2, but the majority of the plot gameplay loop is unchanged between those two patches, other than checking for incapacitated owners when testing for the plot to be active. So you should be able to build plots OK.

If the long saves return, it points me at the ESM as the more likely culprit, otherwise, I'll be looking at script optimization as our solution. (I plan on doing a heavy optimization pass anyway, as stack dumps should be extremely infrequent - but I'll prioritize it if we're certain its the cause of the long save issue).
With the 2.0.0 release and 1.1.0 scripts, the Unofficial Patch, BakaScrapHeap and Buffout 4 and no other mods, I do still experience long saves, though it took longer to trigger them than in a fully modded setup. It's hard to say if switching to the 1.1.0 scripts had a noticeable effect on that, given the nature of a heavily modded setup vs a mostly vanilla testing environment. Between Red Rocket, Abernathy Farm and Sanctuary Hills I have about ~60 plots placed, and it took about a solid minute to complete an auto-save when leveling up or fast traveling. Hard saves immediately after the auto-save, predictably, completed in less than a few seconds.

Edit: It's worth noting I was not running the Chapter 2 XPAC ESM, and I spawned in ASAMs rather than procuring them naturally in the world, but I don't think the latter would have any effect on the test. This is pure 2.0.0 SS2 ESM only with the 1.1.0 scripts, no hotfixes as requested.
 
Last edited:
Hmm going to repeat the excersise with a full mod setup :) then switch back to a basic setup and have another round of fun.
 
One of the things I've been trying to think of a solution to, is how we can narrow down this issue and determine whether the issue is the ESM or the scripts. As whichever is the culprit is going to require a wildly different approach to trying to diagnose and fix this. @Mystical Panda has been doing a lot here to point me at the scripts as being the problem- as stack dumps are no good and show me we've got some optimization work to do - but what if the issue is the ESM...

I think I have a really simple experiment to determine that. Would require some folks to run a sacrificial character for a few hours - as your game will be broken from doing this.

Run with the 2.0.0 release of SS2, none of the hotfixes, next download the 1.1.0 patch from nexus but don't install it, grab the ba2 file out of the archive, then use a ba2 extractor to extract the contents of its \scripts\ folder to your Data folder. That will cause SS2 to run with the release esm and assets but the 1.1.0 scripts.

Then just play it for a while building up settlements with plots to see if the long save issue returns at the level you're used to seeing in the 2.0.0 patch.

This will cause plenty of bugs in SS2, but the majority of the plot gameplay loop is unchanged between those two patches, other than checking for incapacitated owners when testing for the plot to be active. So you should be able to build plots OK.

If the long saves return, it points me at the ESM as the more likely culprit, otherwise, I'll be looking at script optimization as our solution. (I plan on doing a heavy optimization pass anyway, as stack dumps should be extremely infrequent - but I'll prioritize it if we're certain its the cause of the long save issue).
Just to be clear, Chap 2 is not supposed to be installed, correct?
 
Did a full load order run, no long saves. The occasional few seconds ones in between while placing 18 plots all over Sanctuary and while Jake is building. Even then not all took seconds. All other saves where again <1 second. FT'd back and forth all done in expected time.
For me a long save (25 seconds or longer to 2 minutes) would already have occured.
 
Just did a quick test session... kinda crazy TBH. I didn't start a new game, placed the 1.1.0b scripts in the scripts folder and reversed SS2 to 2.0.0. Did NOT turn off chap 2 and loaded the same save I've been playing. Quite a big save, 48h+ gameplay, several settlements, some with plans from ROTC, others with plans from the contests and others built by hand (the triangle of death and the drive-in were built by hand).

First impressions are very positive, bunny hopped from settlement to settlement, upgrading/placing plots and quicksave like it was caffeine to a programmer! Not even one slow save.

On the other hand, loading times are crazy long (2x to 3x longer than before), and eventually, it crashed when fast-travelling to another settlement. Probably due to the huge script lag and crazy conflicts that might be happening behind the scenes.

I'll try to do a more extensive test, without as much bunnyhopping and more settlement building.
TLDR: Frankenstein seems to be functioning as good as we can expect from a mod that was cut apart and stitched together with superglue :agree: I think your theory is correct @kinggath. Now to discover which script is the culprit :D
 
Just did a quick test session... kinda crazy TBH. I didn't start a new game, placed the 1.1.0b scripts in the scripts folder and reversed SS2 to 2.0.0. Did NOT turn off chap 2 and loaded the same save I've been playing. Quite a big save, 48h+ gameplay, several settlements, some with plans from ROTC, others with plans from the contests and others built by hand (the triangle of death and the drive-in were built by hand).

First impressions are very positive, bunny hopped from settlement to settlement, upgrading/placing plots and quicksave like it was caffeine to a programmer! Not even one slow save.

On the other hand, loading times are crazy long (2x to 3x longer than before), and eventually, it crashed when fast-travelling to another settlement. Probably due to the huge script lag and crazy conflicts that might be happening behind the scenes.

I'll try to do a more extensive test, without as much bunnyhopping and more settlement building.
TLDR: Frankenstein seems to be functioning as good as we can expect from a mod that was cut apart and stitched together with superglue :agree: I think your theory is correct @kinggath. Now to discover which script is the culprit :D
Spoke too soon :( Here come the long saves. 5min and counting. But let's stay positive.

@Martend remove chap2 and had no long saves, even on a mod heavy setup. I did not remove chap2 and had long saves. Following the current assumption that the problem is with the scripts, maybe it is the scripts in chap 2 and not in SS 2.0?


If this happens to be a crash instead of a long save I'll edit this thread.

EDIT: it was a long save... 11min long. Let me see how far I can push this... turning chap2 off on this save xD
 

Attachments

  • 1642531470356.png
    1642531470356.png
    58.4 KB · Views: 5
Last edited:
Ok... first weird thing. When loading the game, it didn't miss Chap 2.... but it missed the Gun For Hire door patch :todd:

I'm writing this as I play.. let's see how long it takes to make it crash xD Loading times continue long, but I can't imagine what the engine is going through right now, so I'll just assume it is normal.

So, the new plots are in the base SS2, correct? Cause I'm staring at a Hospital in sanctuary :D

Sorry had to share this... The drunk from the theater is AMAZING!

Poor papyrus, is have a really bad time with this xD just after a quick quicksave it made a HUGE stack dump. I mean 20k lines huge.

And there we go... long save again... let's see how long it takes this time. 2.5min. Not that bad, but still qualifies as a long save. I'll keep playing a little bit longer to see if I get a real big one.

This is weird, WSFW was trying to find a file in my g drive (which is my work virtual google drive), while the game is installed in the e drive (M2 SSD). Also, there are loads of references looking for things in the default steam instalation folder, but I changed it.

1642532895694.png

The steamcommons is not here:
1642532946851.png

Papyrus log attachment if you wanna dig around. Interesting fact, there is a save at line 23694 that happens between 2 stack dumps and it was a fast save. On the other hand, the last save of the log also was after a dump but this time it was 3min long.


My conclusions for these quick sessions. Replacing the scripts and removing chap2 seems to improve the situation but it does not solve it. Please don't take this the wrong way, we've all done it before and gonna do it again, but are those paths in the WSFW hardcoded? Why is it looking for a file in the wrong place?


------



Sometimes I cannot do anything else but agree with Todd... somehow, by some miracle, this save file, full of chap2 content on it, it just works without chap 2 installed xD It is amazing the things this engine can handle. I cannot understand how I'm playing for near 1 hour without any crash.
 

Attachments

  • 1642531827793.png
    1642531827793.png
    454.6 KB · Views: 7
  • 1642532124621.png
    1642532124621.png
    1.3 MB · Views: 10
  • 1642532277484.png
    1642532277484.png
    1,018.5 KB · Views: 10
  • 1642532579803.png
    1642532579803.png
    64.9 KB · Views: 10
  • Papyrus.0 .zip
    124.9 KB · Views: 0
Top