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!

Save File Issue - Potential Fix Here

Just finished playing another quick session using the same game save, and here's what I noticed...

I got a massive 'long save' lag when exiting the game (over 2 minutes). Since the exit save was within about a minute of loading the previous save (doing save tests to compare the new save with the previous one) I could check what could be the difference between the two, at least from a script point of view. The one thing that stood out was the 'active' and 'suspended' scripts from the save I loaded (screenshot #11), then everything is cleared out when the game exit saved (just a minute or so later- screenshot #12).

Even though it's possible to have a save game with 'suspended stacks', I'm wondering if the 'suspended stacks' have a bearing on the save time- the more you have, the longer the time to save. As if it's just timing itself out while waiting for them to clear up, and if it doesn't just saves the game data anyways. Which could explain the 'long saves' and game saves having 'suspended stacks' (not being cleared each save).

One possible angle would be that Beth, checking their own scripts, didn't have that many suspended, or had a suspension that was deadlocked so
clearing them out, or having them clear when a game loaded wasn't a problem. But... with scripts heavy mods, this would change with designed (try and clear but timeout if it's deadlocked- so to speak) yet
unwanted results (a very long wait to finish creating a game save).

I'll need to get a bigger game time log, then check the game save data(suspended and active script counts) with the time it took to save them and see if there's a possible correlation.
 

Attachments

  • screenshot11.png
    screenshot11.png
    2.5 MB · Views: 14
  • screenshot12.png
    screenshot12.png
    2.5 MB · Views: 14
I have long saves when I get around 45 mb save files sizes or sometimes it will lock on exiting ( this is without any ss2 stuff) so 56mb is crazy huge but the unattached and undefined being only 1 was pretty clean so guessing it loads up fine. Hopefully all the info everybody has been getting helps out.
 
This post may be a little premature, but I reduced multithreading from 50 down to 10 in Workshop framework and haven' had a Save issue since.

Questline:
I've done VaultTek HQ with Jake, met 'The Ron' Oh yeahhhh!, did all Vault 88 quests including the vanilla's, returned the vitomatic to Jake, built commercial, rec, mil and municipal plots all while saving every step of the way and not a single issue.
I turned multi threading to 25. After a couple hours of play, with autosave on, my longest save was just over a minute, that only happened once. Otherwise, where I would normally get a several minute long save it was maybe twenty seconds.
 
I turned multi threading to 25. After a couple hours of play, with autosave on, my longest save was just over a minute, that only happened once. Otherwise, where I would normally get a several minute long save it was maybe twenty seconds.
I can confirm this as well. After resolving some problems from changing threads multiple times, I'm comfortably sitting at 20 threads with a maximum of 1 minute saves when I was looking at 12 minute saves before. Quicksaves function as normal and autosaves are the only ones seemingly taking longer, although that could be anecdotal due to changing script load. At 10 threads SS2's plots were malfunctioning slightly with upgrading (likely due to the change of thread count while their scripts were actively running) but I could not even replicate the issue with save times. Sticking to 20 for now and waiting for any updates on the problem.
 
I seem to remember changing the Multithreading option in WSFW there "temporarily resolved" an issue in the past too, now that I think about it.
Might just be delicious placebo effect though.
 
I have long saves when I get around 45 mb save files sizes or sometimes it will lock on exiting ( this is without any ss2 stuff) so 56mb is crazy huge but the unattached and undefined being only 1 was pretty clean so guessing it loads up fine. Hopefully all the info everybody has been getting helps out.
I know the size is massive and has a ton of scripts in it from all the mods- it usually gets up there pretty quick now. Actually the normal save times are about a second when saving, though occasionally it would go up a bit more than that but never 'long'- until recently. Interestingly enough, I didn't clean the game saves with Resaver, I was just using it to view the game file data (though I've used it before in the past for cleaning) and you can see the game cleaned itself up- so both 'unattached' were gone either just before while I was in the game for a minute, or during the save game process (screenshot #12).

Yeah, the game saves loads up ok- even the one that had 71 'suspended' stacks. The previous crash logs I posted had most entries from ConditionBoy- the BodyPartsUI.dll I'm guessing the menu 'layer' he was using was disposed of when the game switched back to a loading screen of the main menu and that caused a game CTD. It was more than likely with a bad reference or pointer. Though some of the newest crashes I haven't had time to investigate yet. I've got a bit of coding to do, then I'll try a few more tests.
 
Up until today, my long saves were fairly reasonable. Maybe a minute, maximum two. I have changed nothing (because I'm freakin' lazy), and the saves from today have been stretching well over five minutes. From Kinggath's last post, he might be onto something. I'm hoping!
 
I can safely say, size has no direct correlation to the long saves or freezing on exit. I have a 90mb save file that behaves the same as fresh ones, sometimes long, sometimes about a second.
 
I turned multi threading to 25. After a couple hours of play, with autosave on, my longest save was just over a minute, that only happened once. Otherwise, where I would normally get a several minute long save it was maybe twenty seconds.
How does one do this, and can it be undone if it doesn't work or causes unforeseen consequences?
 
How does one do this, and can it be undone if it doesn't work or causes unforeseen consequences?
In WSFW, I use the mod configuration menu, otherwise I think it's on the holotape. It's easily undone, I don't see how doing so could cause issues.
 
In WSFW, I use the mod configuration menu, otherwise I think it's on the holotape. It's easily undone, I don't see how doing so could cause issues.
I always ask before I do something to my game that I don't understand. Better you have your ass covered than sticking up in the air waiting for a digital foot to be placed in it.
 
I always ask before I do something to my game that I don't understand. Better you have your ass covered than sticking up in the air waiting for a digital foot to be placed in it.
I'd wait for someone with more knowledge then me for advice. Several posts saying turning it all the way down causes issues, and I really haven't been playing on 25 all that long.
 
I can safely say, size has no direct correlation to the long saves or freezing on exit. I have a 90mb save file that behaves the same as fresh ones, sometimes long, sometimes about a second.
I don’t think my issues where size specific I think it was related to scripting but when the saves got about 45mb was when I’d have issues with them probably scripts that don’t finish running after use and just continue in the background.
 
I'm kind of 'ball-parking' it here without a bit more research, but by looking at the Resaver tree-view of a game file there are "Scripts", "Active Scripts" and "Suspended Stacks"...

The game either saves all compiled scripts it has found in the active plugins and loose when the game is run (which would make the save fairly large with script heavy mods right off the bat) whether the scripts are currently 'active' or not, or it just saves a link to a script name table along with a current script index(which points to the current executable position in the script- which would make the save much smaller). If the actual .pex is 'baked in' changing the script mid-playthrough can have an effect on script variables that itself uses, or that are passed to other scripts.

Removing mods mid-game play will thereby remove the mods scripts (if they're present) which should remove them from the 'baked in' list "Scripts" (the 'clean save'... remove mods, load save, acknowledge missing mods, save again- this is your clean save- without knowing the scripts and engine it could kill your game save somewhere down the road), and I'd venture a guess that if said script is currently 'active', when the VM tries to get the next executable position if won't be there and the 'active' script is just ignored and removed. One problem, I'd guess, would come in if the removed script was modifying shared variables that other scripts still in the game might be using- things might revert back, or possibly not function at all if the removed script changes default variables into custom ones that only it can manage.. without that the other scripts won't know what to do with the data it's now trying to process.

The "Active" part more than likely refers to those scripts that are currently executing in the script VM, and the "Suspended Stacks" possibly refers to those scripts that are 'hung' up waiting on another script (on an 'active' script? if so, would one of the actives point to the problem), got tossed out of the 'active' pool pre-maturely (heap overrun? in which case the 'active' script is just dumped), or something else. If it a script get's 'killed' or tossed out of the VM that would account for various odd behaviors during gameplay- such as actors and other things not updating properly when removing some mods mid-gameplay.

Sorry to get OT from the original problem. Still coding some things in, and testing the same game save.
 
Last edited:
I'm kind of 'ball-parking' it here without a bit more research, but by looking at the Resaver tree-view of a game file there are "Scripts", "Active Scripts" and "Suspended Stacks"...

The game either saves all compiled scripts it has found in the active plugins and loose when the game is run (which would make the save fairly large with script heavy mods right off the bat) whether the scripts are currently 'active' or not, or it just saves a link to a script name table along with a current script index(which points to the current executable position in the script- which would make the save much smaller). If the actual .pex is 'baked in' changing the script mid-playthrough can have an effect on script variables that itself uses, or that are passed to other scripts.

Removing mods mid-game play will thereby remove the mods scripts (if they're present) which should remove them from the 'baked in' list "Scripts" (the 'clean save'... remove mods, load save, acknowledge missing mods, save again- this is your clean save- without knowing the scripts and engine it could kill your game save somewhere down the road), and I'd venture a guess that if said script is currently 'active', when the VM tries to get the next executable position if won't be there and the 'active' script is just ignored and removed. One problem, I'd guess, would come in if the removed script was modifying shared variables that other scripts still in the game might be using- things might revert back, or possibly not function at all if the removed script changes default variables into custom ones that only it can manage.. without that the other scripts won't know what to do with the data it's now trying to process.

The "Active" part more than likely refers to those scripts that are currently executing in the script VM, and the "Suspended Stacks" possibly refers to those scripts that are 'hung' up waiting on another script (on an 'active' script? if so, would one of the actives point to the problem), got tossed out of the 'active' pool pre-maturely (heap overrun? in which case the 'active' script is just dumped), or something else. If it a script get's 'killed' or tossed out of the VM that would account for various odd behaviors during gameplay- such as actors and other things not updating properly when removing some mods mid-gameplay.

Sorry to get OT from the original problem. Still coding some things in, and testing the same game save.
This is surprisingly good info as far as I’m concerned cause it’s a lot easier to understand then active inactive or unattached when looking at them. And I’d guess the same for active and suspended as well as unattached and stuff. A lot of the tool makers don’t give adequate descriptions for their software.
 
I was just taking a moment to look over the papyrus log profiler output and I noticed these...

66161646^QUEUE_PUSH^6089949^3^SS2_NewBugle_RegisteredNews (13021B18)^FormList.??.GetAt
66161657^QUEUE_PUSH^6089551^4^WSFW_LCharWorkshopGuard_Holder (120091E8)^LeveledActor.??.AddForm
66161669^QUEUE_PUSH^6089637^6^WorkshopMenu01Power02ArcadeCabinets (0024A0E3)^FormList.??.GetAt
66161677^QUEUE_PUSH^6089845^4^SS2_InjectionDefaults_Visitor (13016881)^FormList.??.GetAt

66210607^QUEUE_PUSH^6089891^4^ (FF004B84)^simsettlementsv2:objectreferences:simplot.??.IsDeleted
66210620^QUEUE_PUSH^6089922^5^DLC06VaultWorkshop (05000F31)^Cell.??.IsInterior

66210637^QUEUE_PUSH^6089148^2^ (00000014)^Actor.??.GetItemCount

... and have no idea if being 'queued' could hang up something else, or is simply 'queued', and is this normal or a sign of 'suspending' stacks, etc.,. Most of the 'queued' items I came across were from these sources and came in groups like these.

Gimme a bit to cobble together a quick reporting function to summarize the profiler entries to something that makes more sense.
 
The game either saves all compiled scripts it has found in the active plugins and loose when the game is run
I know all instantiated script objects are in the save file. A good deal of the data presented in resaver is black magic.
(the 'clean save'... remove mods, load save, acknowledge missing mods, save again- this is your clean save
The clean save is a myth. This leads us to Unattached Instances which are generally orphans (removed mod's instantiated objects who's scripts are no longer present) created when a mod is removed during a playthrough. There is also a chance for an unattached instance to infinitely try to finish a function call which is a waste of already limited VM resources.
The "Active" part more than likely refers to those scripts that are currently executing in the script VM, and the "Suspended Stacks" possibly refers to those scripts that are 'hung' up waiting on another script (on an 'active' script?
Active scripts are those that have a code block executing in the Papyrus VM at the time the save was created. When you save the game, it also saves a snapshot of the current Papyrus VM. If you enable debug logging, you will find VM Freezing, VM Frozen and Saving Game... in the log file every time you save. VM Freezing is the engine telling the VM to quit doing work. VM Frozen is the VM telling the engine 'good to go' then the save is made.

Suspended Stacks are a different animal. A better analogy would be Windows Virtual Memory. When the amount of stuff exceeds a threshold, it is cached to deal with when more resources are available. So when the Papyrus VM has more calls than it can process, it starts suspending stacks. i.e. caching them to run later. (unrelated: this can cause issues if an active stack requires output from a suspended stack)

Edit: I found this bit of info as well:
 
Last edited:
The location given by Preston for "The First Step" (which is usually Tenpines) and where they want you to go (which is usually Corvega) is actually Radiant, but the way it's "weighted" means that's 99.99999% what you're going to get.
(hint: notice they never actually verbally NAME locations, just say "nearby" or whatever; that's a clue it's Radiant or at least dynamically generated rather than hardcoded)
I was surprised, recently, for first time ever, Preston sent me to the reservoir from TenPines. once in like 20 playthrus...
 
are serialized sequentially by the order you add mods (I assume the load order in the case of a new save).
This could work to our advantage... where it's hanging should the be mod that's potentially causing the problem- let me look into the save file format and one of my saves here in a bit. This should give me some time to 'digest' some the possibilities and see if I can come up with something useful.
 
Top