Menu
What's new
By:
Filters
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

kinggath

kinggath

Well-Known Member
Staff member
Administrator
Moderator
Verified Builder
Messages
5,182
Been working with shad, who created the Baka F4SE plugins, and he created a tool to help us research this issue.

The attached F4SE plugin will generate text versions of save files whenever you load them or save them. The idea is you load up a save from before a long save occurred, and we can use text comparison tools to compare the long save text file to the one before it. You can find the text files in your saves folder, they will have the same name as the save file but with the .txt extension appended.

The tricky part is that writing these files takes a while so it can actually make it seem like you're getting a long save every time. So you'll probably need to get used to the extra few seconds this tool adds and account for that when making the call of whether your latest save was a long save or not.

I'm also not entirely sure what we're looking for in the text files, but I'm hoping some of you strong troubleshooters and fellow techies can help find some patterns using this tool!

-kinggath
 

Attachments

  • BakaSaveGameFixesv2.zip
    158.8 KB · Views: 54
Last edited:
If any of you comes up with a good workflow for gathering data and comparing files, please post it here. I don't have a great system figured out yet myself.

Like I said, I'm not entirely sure what we're looking for, other than patterns - ie. things you find in the long saves that don't occur in the normal speed saves.
 
ohhh this game... :explode:

now that I want I can't trigger a long save! I'll keep playing normally and try to actively trigger it and I'll report when/if it happens.

Is any1 else having trouble replicating the error with this mod? I've tried everything that worked for me before and nothing
 
Hi,
Using the plugin and a previous save, just into "If I had a hammer" from a clean start (Same build with v1.1.0b has no issues). Save 24 took about 2 seconds, save 25 took around 60 seconds. I can't really see much difference between them (one added industrial plot, which may have triggered the long save) but there is one extra scene listed here in the 25 save that is not in the 24 save.

SCENs:
000E0B60 67/189 80000000 68 - Base(178) Active(0)

Eyebot scene defined in ss2.esm - I don't recall there being an eyebot around in sanctuary but could be wrong.

J
 

Attachments

  • Sim Settlements 2 Testing.7z
    270.5 KB · Views: 15
There are quite some differences between the files, but without timestamps, it is difficult to pinpoint where it hung.

@kinggath trying not to sound ungrateful, but do you think that is possible to ask shad to include timestamps on each line? That way we can see where it took longer than it should to serialize.



PS: the tool I used to compare the files https://text-compare.com/. I'm certain there are others and better, this was just the first google gave me :P
 

Attachments

  • save24 vs save25.zip
    1.3 MB · Views: 9
Last edited:
Unfortunately, we don't have access to timestamps.

This is just parsing out the save file data as it exists - monitoring the data as its being recorded would probably require a pretty complex tool, given that everything F4SE is just hacked memory addresses to inject/catch events they've managed to puzzle out over years of reverse engineering. Remember we don't have the source or even debugging tools for Fallout - the F4SE team had to do this with trial and error of running memory edits... (if you read about how they do it, it's insane and I can't believe we have any of the tools we do).

From what I've gathered, changed records get appended to the end of the section they are a part of, rather than being updated where they were in the previous save.
 
"The idea is you load up a save from before a long save occurred,...."

So I would need to start from a save where not a singel long save has happened?

Or do I just need a short save and a long save in quick sucsession from my current runnig playthrough (where long saves have happened multiple times)?
 
Reaktorbot said:
"The idea is you load up a save from before a long save occurred,...."

So I would need to start from a save where not a singel long save has happened?

Or do I just need a short save and a long save in quick sucsession from my current runnig playthrough (where long saves have happened multiple times)?
Click to expand...
Just a regular save and the long save after it to compare and see the difference is what it sounds like to me.
 
XxA1xX said:
Just a regular save and the long save after it to compare and see the difference is what it sounds like to me.
Click to expand...
Yep - just trying to get an idea of what kind of data is taking so long to write. If it turns out its consistently specific SS2 stuff, we can try and reconfigure things in a way that's more save friendly.
 
Between a long save and a normal save done a few seconds apart, the only differences I've been able to nail down from text comparison, are in the QUST section for SS2's Event Location Grabbers and Settlement NPC Grabbers, a dozen Scene size changes, and Cell Change Flag Data on some ASAM Sensors.

On the long save, the QUST data contains "Quest Runtime Data" and on the short/regular save that line in the text isn't present, and the size is lower on the short save. (102/159 to 62/87 in the size column on the long save, down to 14/14 for all of them on the short/regular save)
 
ok so this is a quick question can the notepad bring up be disabled on saves it basically minimizes my game and brings up notepad each save.

ok see if this works save 6 is no ss2 stuff at all going on save 7 is when jake showed up and I placed down housing plot, and it is just about to build.
have not looked at the difference yet sorry its getting a little late for me.
 

Attachments

  • Save6_58E80787_42697463682050756464696E67_Commonwealth_000105_20220106024330_1_2.fos.txt
    1.8 MB · Views: 5
  • Save7_58E80787_42697463682050756464696E67_Commonwealth_000137_20220106031624_3_2.fos.txt
    3.2 MB · Views: 2
Last edited:
NDQ said:
It's not just saves. It's also fast travel that is taking a long time
Click to expand...
can confirm on the og 2.0.0 all the way to H i had no fast travel issues now on I my fast travel takes about 2 mins to finish. walking anywhere is fine everything works like it should.
 
NDQ said:
It's not just saves. It's also fast travel that is taking a long time
Click to expand...
I have that problem too, but i always assumed thats because the game autosaves whe you fast travel. So fast traveling is not taking ages, but the autosave right before
 
I've got a few more things to code up reporting wise that might help automate some of these logs, but here's the angle I'm working towards on this test cycle...

You can see the last gaming session was just a little over 1h:14m ("Load Order History"), and the 'stack dumps' from the papyrus log for that time period just to the left ("Show Papyrus Info"). Then, if you look at the time stamp for the 'stack dumps' in the papyrus log and compare that to the output log to the left of that ("Text File") you can see the 'stack dumps' happened as I was getting a 'long save'. This is noted by the "un-responsive" for 3 seconds entry which was logged after the game became responsive again.

I'll keep following up with this later this afternoon as I need to check into the actual save files- the one that came before and just after the 'stack dumps' and see if there's something else that can help...
 

Attachments

  • screenshot30.png
    screenshot30.png
    2.4 MB · Views: 34
I'm not sure if anyone else has pointed this out but saving in an internal cell never results in a Long Save, for me atleast. The worst culprits are Sunshine Tidings and Sanctuary, although I haven't used much in the way os SS2 plots in Sanctuary. Sunshine Tidings is Industrial and Agricultural heavy. I'll have some save game data soon with this tool
 
I uploaded one with the long saving time in Sanctuary and one without in Vault 111 for comparison, although V11 is an early game save and the other is the most recent

EDIT - The Long Save file is "too large" to upload on here
 

Attachments

  • Save3_A59DA533_4D617276696E20426F6E64_Vault111Cryo_000121_20211212144034_1_2.fos.txt
    2.1 MB · Views: 6
Last edited:
Narmz said:
I uploaded one with the long saving time in Sanctuary and one without in Vault 111 for comparison, although V11 is an early game save and the other is the most recent

EDIT - The Long Save file is "too large" to upload on here
Click to expand...
Just zip or 7z the txt file - reduces file size to about 5%
 
Mystical Panda said:
I've got a few more things to code up reporting wise that might help automate some of these logs, but here's the angle I'm working towards on this test cycle...

You can see the last gaming session was just a little over 1h:14m ("Load Order History"), and the 'stack dumps' from the papyrus log for that time period just to the left ("Show Papyrus Info"). Then, if you look at the time stamp for the 'stack dumps' in the papyrus log and compare that to the output log to the left of that ("Text File") you can see the 'stack dumps' happened as I was getting a 'long save'. This is noted by the "un-responsive" for 3 seconds entry which was logged after the game became responsive again.

I'll keep following up with this later this afternoon as I need to check into the actual save files- the one that came before and just after the 'stack dumps' and see if there's something else that can help...
Click to expand...
If it turns out to be stack dumps, that would be awesome. If so, I'd just need a few papyrus logs that have the dumps that line up with the slow saves, and the saves themselves. Then I'll just need to try and optimize or stagger out the code at the heart of the dumps - assuming this is generally the same stuff occurring in each instance.

Keep us posted and if you find a good workflow for gathering this, would be nice to have it from a few folks.
 
You must log in or register to reply here.
Top