Long Save Research Tool

[kinggath]

Not even near it. I was in sanctuary, but even adding all 3 settlements from the triangle I'm not even close to that number. Especially because is it a new save, I think I only have sanctuary with the requirements for the quest and 2 or 3 plots in the red rocket.

Tomorrow I'll check

Hmm then that doesn't account for the full burst of activity. So definitely some code inefficiencies that can be worked out here.

 

[jims1973]

Is there a SIMP thread because reading the back and forth between @kinggath and @nosfsos I think I've fallen in love! But seriously the two of you are doing incredible work. Thank you!!

 

[Mystical Panda]

In this last run, which was just over 2 hours, there were 291 'active' stack dumps (not 'suspended' this time). Still, there are just two RoTC settlements under auto-construction, with no one at Red Rocket yet, and Garvey's Gang in Sanctuary. As I was playing and as much as I can tell, the 'improvement' notifications were all for Sanctuary. Quite a few came in one right after another- build times are set to 'realistic'. There were a few 'unresponsive' moments as you can see (around a few seconds here and there), but as I was manually saving I didn't notice anything like that as they seemed to be almost instantaneous. I did however notice a very slight 'lag' while occasionally sleeping.

Here, the 'stack dumps' were caused by a utility 'wait' which was called from multiple WetEffects.esp script function calls- which looked to be checking if it was still raining for (and I'm guessing here) multiple npcs as (another guess) that scripts are attached? to each npc, not from SS2. This is the first time I noticed 'active' rather than 'suspended' dumps in these playthrough tests. Each time I had SS2 in the 'stack dump' mix in large quantifies it has always been 'suspended' stacks.

For a stack trace on the one SS2 log entry (if it's LIFO- bottom to top order) is:

Spoiler: single stack trace...

[02/01/2022 - 04:38:42PM] [ (FF003561)].simsettlementsv2:objectreferences:simplot.GetBuildingClass() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 8081
[02/01/2022 - 04:38:42PM] IP: 335 Instruction: 12 Line: 8081
[02/01/2022 - 04:38:42PM] [aFromPlan]: [simsettlementsv2:weapons:buildingplan <SS2_BuildingPlan_Mar_1x1_Checkpoint (13019D4>]
[02/01/2022 - 04:38:42PM] [ (FF003561)].simsettlementsv2:objectreferences:simplot.PlotRequiresPower() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 2467
[02/01/2022 - 04:38:42PM] IP: 455 Instruction: 12 Line: 2467
[02/01/2022 - 04:38:42PM] [SS2_HUDManager (13020B48)].simsettlementsv2:quests:hudmanager.UpdateMeters() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\Quests\HUDManager.psc" Line ?
[02/01/2022 - 04:38:42PM] IP: 2135 Instruction: 39
[02/01/2022 - 04:38:42PM] [::temp207]: [[simsettlementsv2:objectreferences:simplot < (FF004D24)>], [simsettlementsv2:objectreferences:simplot < (FF0036BA)>], [simsettlementsv2:objectreferences:simplot < (FF002A9D)>], [simsettlementsv2:objectreferences:simplot < (FF00343E)>], [simsettlementsv2:objectreferences:simplot < (FF004D8E)>], [simsettlementsv2:objectreferences:simplot < (FF004060)>], [simsettlementsv2:objectreferences:simplot < (FF004AAD)>], [simsettlementsv2:objectreferences:simplot < (FF002C8>], [simsettlementsv2:objectreferences:simplot < (FF002679)>], [simsettlementsv2:objectreferences:simplot < (FF002B30)>], [simsettlementsv2:objectreferences:simplot < (FF003A48)>], [simsettlementsv2:objectreferences:simplot < (FF003765)>], [simsettlementsv2:objectreferences:simplot < (FF003561)>], [simsettlementsv2:objectreferences:simplot < (FF0045D1)>], [simsettlementsv2:objectreferences:simplot < (FF003FF9)>], [simsettlementsv2:objectreferences:simplot < (FF003976)>], ...]
[02/01/2022 - 04:38:42PM] [kPlotRefs]: [[simsettlementsv2:objectreferences:simplot < (FF004D24)>], [simsettlementsv2:objectreferences:simplot < (FF0036BA)>], [simsettlementsv2:objectreferences:simplot < (FF002A9D)>], [simsettlementsv2:objectreferences:simplot < (FF00343E)>], [simsettlementsv2:objectreferences:simplot < (FF004D8E)>], [simsettlementsv2:objectreferences:simplot < (FF004060)>], [simsettlementsv2:objectreferences:simplot < (FF004AAD)>], [simsettlementsv2:objectreferences:simplot < (FF002C8>], [simsettlementsv2:objectreferences:simplot < (FF002679)>], [simsettlementsv2:objectreferences:simplot < (FF002B30)>], [simsettlementsv2:objectreferences:simplot < (FF003A48)>], [simsettlementsv2:objectreferences:simplot < (FF003765)>], [simsettlementsv2:objectreferences:simplot < (FF003561)>], [simsettlementsv2:objectreferences:simplot < (FF0045D1)>], [simsettlementsv2:objectreferences:simplot < (FF003FF9)>], [simsettlementsv2:objectreferences:simplot < (FF003976)>], ...]
[02/01/2022 - 04:38:42PM] : 12
[02/01/2022 - 04:38:42PM] [::temp209]: [simsettlementsv2:objectreferences:simplot < (FF003561)>]
[02/01/2022 - 04:38:42PM] [::temp210]: [simsettlementsv2:objectreferences:simplot < (FF003561)>]
[02/01/2022 - 04:38:42PM] [asPlot]: [simsettlementsv2:objectreferences:simplot < (FF003561)>]
[02/01/2022 - 04:38:42PM] [SS2_HUDManager (13020B48)].simsettlementsv2:quests:hudmanager.ForceUpdateHUD() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\Quests\HUDManager.psc" Line ?
[02/01/2022 - 04:38:42PM] IP: 349 Instruction: 10
[02/01/2022 - 04:38:42PM] [akWorkshopRef]: [workshopscript < (00054BAE)>]
[02/01/2022 - 04:38:42PM] [SS2_HUDManager (13020B48)].simsettlementsv2:quests:hudmanager.OnTimer() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\Quests\HUDManager.psc" Line 373
[02/01/2022 - 04:38:42PM] IP: 4090 Instruction: 90 Line: 373
[02/01/2022 - 04:38:42PM] [kLastInfoBoxTarget]: None
[02/01/2022 - 04:38:42PM] [RecentlyChangedCopy]: []
[02/01/2022 - 04:38:42PM] [::temp19]: [workshopscript < (00054BAE)>]
[02/01/2022 - 04:38:42PM] [::temp22]: [Location <RedRocketTruckStopLocation (00024FA>]
[02/01/2022 - 04:38:42PM] [kWorkshopRef]: [workshopscript < (00054BAE)>]

All in all, the GC seemed to help which is very good indeed and helps immensely during game play, but it's making me wonder if it's a fix that came about due to a 'VM cluster flurb' with recursive calls made because of 'on attaches' that trigger other scripts to 'looking around', or something along those lines. Just a guess there guys, but wanted to keep information/ideas flowing in the loop. Also, I would imagine from Bethesda's angle I can understand why they wouldn't see not calling a GC every 1 minute a 'bug' per se, just not necessary since the VM and references weren't getting hit that hard or 'out of hand' to begin with and they figured that disposing of resources could be done during 'down' times like sleeping, saving etc.,. and that would be enough.

So to summarize, no 'stack dumps' from SS2 and a few un-responsive moments during sleeping. One settlement in active auto-build (level 1). I'll send someone to Red Rocket to get started on that one to add a bit more 'load' then check back with the results here shortly.

 

[kinggath]

All in all, the GC seemed to help which is very good indeed and helps immensely during game play, but it's making me wonder if it's a fix that came about due to a 'VM cluster flurb' with recursive calls made because of 'on attaches' that trigger other scripts to 'looking around', or something along those lines. Just a guess there guys, but wanted to keep information/ideas flowing in the loop. Also, I would imagine from Bethesda's angle I can understand why they wouldn't see not calling a GC every 1 minute a 'bug' per se, just not necessary since the VM and references weren't getting hit that hard or 'out of hand' to begin with and they figured that disposing of resources could be done during 'down' times like sleeping, saving etc.,. and that would be enough.

So to summarize, no 'stack dumps' from SS2 and a few un-responsive moments during sleeping. One settlement in active auto-build (level 1). I'll send someone to Red Rocket to get started on that one to add a bit more 'load' then check back with the results here shortly.

The dll doesn't actually force the GC to run more frequently, it simply optimizes it so that it's capable of cleaning up complex structs in its normal cycle. In Bethesda's version of it, it just never has time to run a full clean until the VM is frozen before a save.

Awesome to see no stack dumps, that's actually why I pipe complex things through the WSFW threading engine, so that we aren't overloading the VM. I never would have guessed in a million years that GC was part of the problem...

Thanks for putting in such a colossal effort to figure out what this problem was. I'm hopeful I'll be able to use the tools you've created, and this new debugging dll, when I get to my planned overhaul of city plan code - as that's likely a very big source of performance gains waiting to be had.

Hotfix 2.0.0m is about to go live - fingers crossed we get to kiss the long save problem good bye after tonight!

 

[Mystical Panda]

Hotfix 2.0.0m is about to go live - fingers crossed we get to kiss the long save problem good bye after tonight!

Your team is very welcome and thanks for maintaining the mod with the diligence you and your team have- I, for one and many others, look forward to the 'long save' being 'long gone'! Having this happen is a good thing as it brought about new software, practices and ideas to better the modding and the community as a whole and that benefits us all.

The tool is a massive data/modding manager which covers all kinda of things using layered frameworks. As soon as I can get it to a public usable state I'll link everyone to it. I've still have the sorting, manifest and a few other frameworks to code- as the roughest part has always been to make the code usable as a generic library of sorts for all kinds of things, but still serve as a dedicated library for mod management.

 

[XxA1xX]

Man I’ll be happy if this fixes it. I’ll fire up the new patch after work tomorrow as I had a spot I’d always get the longer saves it was standing on top of the starlight drive in screen and looking at concord or looking at starlight settlement would always long save up there. It got to the point I stopped playing cause every time id forget to save for a while I’d get killed loose like 1-3 hours play and want to break my tv. heres to hoping this solves it all.

 

[XxA1xX]

Your team is very welcome and thanks for maintaining the mod with the diligence you and your team have- I, for one and many others, look forward to the 'long save' being 'long gone'! Having this happen is a good thing as it brought about new software, practices and ideas to better the modding and the community as a whole and that benefits us all.

The tool is a massive data/modding manager which covers all kinda of things using layered frameworks. As soon as I can get it to a public usable state I'll link everyone to it. I've still have the sorting, manifest and a few other frameworks to code- as the roughest part has always been to make the code usable as a generic library of sorts for all kinds of things, but still serve as a dedicated library for mod management.

Nice work on this you and @nosfsos put in some hard work. I appreciate all you guys did to get a Handel on this lot of people put a lot of hours into this. even if nobody else knows I’m sure everybody here will Remember. Same to @kinggath and the rest of his crew.

 

[Mystical Panda]

Nice work on this you and @nosfsos put in some hard work. I appreciate all you guys did to get a Handel on this lot of people put a lot of hours into this. even if nobody else knows I’m sure everybody here will Remember. Same to @kinggath and the rest of his crew.

Anytime. I'll definitely be in and out of the forums as we go and try to chime in when I can- I've got some upgrades /hardware wise/ to do this upcoming week along with continuing to work on the ModHelper software project (man I'll be glad when that one is done!), and a full time job which takes time away from my software development (lol- don't let them know that!).

Here's to a strong modding community!

 

[XxA1xX]

Yeah works a pita sometimes but in order to buy stuff and eat I got to work.

 

[Martend]

Hmm then that doesn't account for the full burst of activity. So definitely some code inefficiencies that can be worked out here.

This was me standing in Starlight during a long save, right after loading a previous save and walking 10 meters in to the Settlement.
I didn't place an object, I do have a massive burst of activity. Which can be explained for a part lookin at the log.
I filtered the most active ones

First you have lines of "created a struct:"
Second lines of "released an object"
Third lines of "About to destroy a struct"
Last on is particular interesting as many of those lines are followd by:
stack:
<empty stack>
[17:32:45:624 TID 8580] About to destroy a struct:
[17:32:45:624 TID 8580] workshopframework:library:datastructures#worldobject 0x00000179C63A9340
[17:32:45:624 TID 8580] [fPosX = 223.151901, iFormID = -1, ObjectForm = None, fAngleY = 70.190201, fAngleX = -59.176899, fAngleZ = 209.307999, sPluginName = "", fPosY = 65.247101, fScale = 1.000000, fPosZ = 134.967896, bForceStatic = False, fExtraDataFlag = 0.000000]
[17:32:45:624 TID 8580]
info: Object creation site

 

[nosfsos]

Good morning! Sorry for disappearing last night, it was late here :P

Which can be explained for a part lookin at the log

Can you check the logs to see the stack trace? And cross-reference the time in the papyrus log and the times on the GCBugFix to see if during the long save the GC was destroying objects (and which objects). That might help find the problem in the code

Thank you, everyone, for the praises, the internet points feel good But honestly, I'm doing this cause I want to experience Chap2 without this bug xD I haven't touched the thing yet ^^

I'll stick to release L for the time being, to try to debug the HUDManager thingy.

Great job everyone! By the replies in the M Build, the problem seems to be gone

 

[Mystical Panda]

Here's a new test using the latest patches for SS2 and SS2C2. There were some 'stack dumps' during a 3 hour period and 4 RoTC builds having at it, but as you can see from the 'spread' pretty much all were in the utility.wait function. I'll need to refine that summary before this weekend to see which stack frames called it, if it's in the dumps. Initially I'm thinking quite a few frames are walled behind those waits, including other waits.

Generally speaking, the game seem to run a better and to my eye (without using Afterburner) the frame rates also seemed better, as the animations didn't seem to be skipping frames. There were a few seconds after waking from sleep and auto-saving (I turned all that back on for this test) intermittently, but nothing even remotely close to what it was before, and never did I notice it when manually saving (which I did quite frequently). This could be attributed to getting a 'elephant off the engines back' GC wise, but I'll need more sampling to better define it.

Also, I didn't notice 'improvement notifications' spewing out in droves like before, nor did I see icons appearing as the settlements were being auto-built. Very positive there. Though they do come from time to time. This is a new start, with few settlers (sometimes just one), and a level 1 city- if the game save stays good maybe I can get more info on this as things start to really build up.

I haven't started or completed any settlement quests at all, including the SS2 ones, though Jake came into Sanctuary and then seemed to appear at Red Rocket after I slept and from what I can tell, he didn't follow me farther out into other Settlements. Jake... stay put! lest ye be known as the Jake P. Garvey.

 

[Martend]

Good morning! Sorry for disappearing last night, it was late here :P

Good morning as well we all need to hit that sleep button at regular times even in the game Otherwise we don't play and debug well lol.

Can you check the logs to see the stack trace? And cross-reference the time in the papyrus log and the times on the GCBugFix to see if during the long save the GC was destroying objects (and which objects). That might help find the problem in the code

On it, I'll slap some logs on the desktop

Thank you, everyone, for the praises, the internet points feel good But honestly, I'm doing this cause I want to experience Chap2 without this bug xD I haven't touched the thing yet ^^

Same, I was totally hyped and excited to start a new game with the new content, all good untill I hit that save button and found out that door(s) where gone.
So came in here annoyed (still loving SS2 and the team) and ventilated that with good intentions. That went south quick unexpected, but it's all good, i'm still here
helping if I can. Since SS2 and the Story is that good it deserves the extra attention and love we give it

 

[randogaming]

aight so ive been trying the buffout solution and have been getting this result every time i load up and into a save with any form of ss2 installed,
Unhandled exception "EXCEPTION_ACCESS_VIOLATION" at 0x7FF647C285D3 Fallout4.exe+04085D3, also these logs are like a foreign language to me.
log now included inside folder due to obvious issues.

 

[Martend]

aight so ive been trying the buffout solution and have been getting this result every time i load up and into a save with any form of ss2 installed,
Unhandled exception "EXCEPTION_ACCESS_VIOLATION" at 0x7FF647C285D3 Fallout4.exe+04085D3, also these logs are like a foreign language to me.
log now included inside folder due to obvious issues.

You're problem is not per se long save related viewing your log. I would start with disabling the mod functional displays, it's bugged, it's abondend, despite that it is a great mod.
If it's not helping you, start a new thread with the crash log and your full list of mods.
Things can move fast in this thread and probaly most of the conversation won't be about addressing your specific problem.
I'm sure I find the thread if it goes up

 

[Starwaster]

Ok, so the fix addresses garbage collection issues by making sure garbage is disposed of more regularly or often than before.

Will this also help with overall stability issues? I get the occasional CTD but haven't wanted to or felt that I could finger any one particular mod. (most of them were probably just from running FO4 too long without restarting or sitting too long at pause screens)

 

[Martend]

Ok, so the fix addresses garbage collection issues by making sure garbage is disposed of more regularly or often than before.

Will this also help with overall stability issues? I get the occasional CTD but haven't wanted to or felt that I could finger any one particular mod. (most of them were probably just from running FO4 too long without restarting or sitting too long at pause screens)

An occasional CTD can always happen (Todd baked that in) I expect on how hard I tried to get it crash / long save now, performance will become close to original. For me that is 5 to 8 hours without CTD's. Not entire there yet performance wise kinggath said he still needed to do some work. With the team already waiting at their startpositions I bet we can see some great things as soon kinggath can fire that start pistol

 

[nosfsos]

Finally got a little break from work, so let me try to answer/clarify things. Put your seatbelts on, this is another big one xD

For settlement enter events, yes a new one will be triggered. That's why you'll see throughout my code I use simple boolean locks to prevent that sort of code from running again if another instance is already happening. Also, the settlement enter event is actually provided by WorkshopFramework, and is designed to not repeat itself unless the player actually fully leaves the settlement - unlike vanilla location change events which can fire rapidly if the player is waffling on cell boundries.

Yesterday I was already half asleep and didn't read all of your posts correctly. I didn't even see you asking me how many plots I had until this morning. I have 29 plots in the triangle (assuming that storage is a sub plot class).

I saw your code for handling the boundaries and it is simple and efficient :D I also remember seeing your 'locks' in the code which totally freaked me out at first. Eventually, I noticed that they were just flow control bool flags

So, then although the GC was the one screaming in pain, that was just a symptom of the problem, not the root. Yesterday's fix seems to have solved it (GC wise), but we still need to find the root of the problem: why is that function being called so many times? And why does SS2 creates so many structures? This is results with 2.0.0L from yesterday, I'll try to do the test again today with M and I'm expecting fewer structures. But let's analyze the log anyway:

When I first loaded the 'problematic' save, SS2 and workshop framework created 223.000 structures between 16:33:02:489 and 16:33:05:531, so little over 3 seconds. It seems weird to me that SS2 needs so many structures on the game load. Anyway, most of them are released immediately after the game load, so, theoretically, the only impact of this is on the loading time. Now for the stacks. Unfortunately, workshopframework and SS2 won't tell me much about the structs created on the loading process, just that it is a world object and give its id:

[16:33:09:405 TID 16032] About to destroy a struct:
[16:33:09:405 TID 16032] workshopframework:library:datastructures#worldobject 0x0000018837183880
[16:33:09:405 TID 16032] [fAngleY = 0.000000, fExtraDataFlag = 0.000000, ObjectForm = None, fPosZ = 0.000000, fAngleX = 0.000000, fAngleZ = 0.000000, bForceStatic = False, fScale = 1.000000, iFormID = -1, fPosY = 0.000000, fPosX = 0.000000, sPluginName = ""]
[16:33:09:405 TID 16032]
info: Object creation site
...
[16:33:10:856 TID 16032] About to destroy a struct:
[16:33:10:856 TID 16032] simsettlementsv2:datastructures#stageitemstruct 0x0000018839ED0D20
[16:33:10:856 TID 16032] [iStageNum = 1, sLabel = "Locker03Books03", iStageEnd = -1, StageItemDetails = None, iOwnerNumber = 0]
[16:33:10:856 TID 16032]
info: Object creation site

At this point, I'm at line 2.078.590 of the log, when the GC gets its first breathing room. For 13 secs it does nothing until it starts creating more structures again.

[16:33:10:856 TID 16032] Released an object: 0x0000018839ED7560 Handle: 0x0000FFFF0D017261
[16:33:10:856 TID 16032] [Weapon < (0D017261)>]
[16:33:23:605 TID 16032] Created a struct workshopframework:library:datastructures#worldobject 0x000001883B3F1C00
[16:33:23:605 TID 16032] Created a struct workshopframework:library:datastructures#worldobject 0x000001883B3F1B20
[16:33:23:605 TID 16032] Created a struct simsettlementsv2:datastructures#stageitemstruct 0x00000188385E99D0

For the next ~450.000 lines (till line 2.527.969) SS2 and WF created as many objects again. Then it destroys them again, until line 4.105.790. A total of 1min has passed since the log started. I'm still assuming all of this is in the loading process.

I believe the following lines are from when I opened the workshop to build the container:

[16:33:39:575 TID 11648] Created a struct UI#MenuData 0x000001883AE8F320
[16:33:39:702 TID 16148] Created a struct hudframework#widgetmessage 0x000001883AEDEA20
[16:33:39:986 TID 11648] Created a struct fallout:overlays:client#opencloseeventargs 0x0000018831D1DB00

If that's correct, then this is when I closed the workshop:

[16:34:02:986 TID 16032] About to destroy a struct:
[16:34:02:986 TID 16032] fallout:overlays:client#opencloseeventargs 0x0000018831D1DB00
[16:34:02:986 TID 16032] [opening = True]
[16:34:02:986 TID 16032]

Between the call where I opened the workshop and where the save started, there are exactly 6438 lines of SS2 creating subplots structs to update the Hud. At 16:34:04:669 the GC starts cleaning up the structs created for the hud. This time the process was much slower, this was when it was actually saving. It took near 30min to clear GC and finish the saving process. During this time, 10034 structures created by GetPlotSubClasses were destroyed. The stacks show several paths, all coming from OnTimer() events:
290 came from simplot.OnTimer(): 290

stack:
[SS2_PlotManager (0D00EB47)].simsettlementsv2:quests:plotmanager.GetPlotSubClasses() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\Quests\PlotManager.psc" Line 1019
[ (FF0034FD)].simsettlementsv2:objectreferences:simplot.GetBuildingClass() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 8068
[ (FF0034FD)].simsettlementsv2:objectreferences:simplot.PlotRequiresPower() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 2467
[ (FF0034FD)].simsettlementsv2:objectreferences:simplot.IsEligibleForConstruction() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 556
[ (FF0034FD)].simsettlementsv2:objectreferences:simplot.AdvanceStage() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 4873
[ (FF0034FD)].simsettlementsv2:objectreferences:simplot.OnTimer() - "C:\Program Files (x86)\Steam\steamapps\common\CC-F\Data\Scripts\Source\User\SimSettlementsV2\ObjectReferences\SimPlot.psc" Line 618

290 from simplot.AdvanceStage(): 116
5800 came from hudmanager.OnTimer(): 290
58 from hudmanager.OnMenuOpenCloseEvent(): 58
3538 came from plotmanager.OnTimer() 58
174 from unlockmanager.OnStageSet(): 58


If you add them up the numbers of creations and destructions don't match because another 3596 were created during the save. And I might have mistyped something.

Now let's ignore the fact that the structures are being created. That's not my point and that was solved already. At this time, I'm just using them to debug function calls.

Remember how many plots I said I have? It was about 3 hours ago for me, so I had to check the start of the post xD I had 29 plots. Notice the numbers I placed next to the function calls? I Dunno what that ID identifies [SS2_UnlockManager (0D00EAFA)] but it is very curious and it looks like an identifier of the script itself. If I count the number of identical traces in the log, I get the number at the end of the line:

174 from unlockmanager.OnStageSet(): 58. 2 times for each of my plots
3538 came from plotmanager.OnTimer() 58. 2 times for each of my plots
58 from hudmanager.OnMenuOpenCloseEvent(): 58. 2 times for each of my plots
5800 came from hudmanager.OnTimer(): 290. 10 times for each of my plots
290 from simplot.AdvanceStage(): 116. 4 times for each of my plots
290 came from simplot.OnTimer(): 290. 10 times for each of my plots

Considering that the whole log was in a timespan of 32 minutes and that around 30minutes was spent saving the game (which means the clock for the timers were paused), does that mean that the above 'table' is the number of function calls in little more than 2min of gameplay? Do these numbers seem right to you @kinggath? To me it seems a little excessive, but I might be misinterpreting them.

Sorry for the long post, but I think this is valuable information

EDIT: Had to remove the trace quotes cause of the character limit. I'll leave the first one just to serve as an example.

 

[Martend]

Can you check the logs to see the stack trace? And cross-reference the time in the papyrus log and the times on the GCBugFix to see if during the long save the GC was destroying objects (and which objects). That might help find the problem in the code

These objects got massive numbers:
Loot_CorpseBaseRobotMrHandy
Loot_CorpseBaseRobotEyeBot
Loot_CorpseBaseRobotMrGutsy
Loot_CorpseBaseRobotSentryBot
kgSIM_WH_ShackWallOuter01B_Brown

The ShackWall also pops up relabed in garden stuff.
FormId's inside an empty stack labled: About to destroy
are indeed empty, nothing attached to it, or something like a wooden crate.

 

[nosfsos]

Continuing my last post. It makes sense to me that all the numbers are even multipliers of the number of plots I have. The way the function was coded it would allocate 2 memory slots each time GetPlotSubClasses was called. Once inside the function and another one just after the return, when you were casting them. This makes sense, the cast has to allocate new memory, otherwise, you would lose the initial reference.

From reading the creation kit wiki, a function call is the heaviest thing in papyrus, so I think this is a place where optimization can be made to improve script lag.

These objects got massive numbers:
Loot_CorpseBaseRobotMrHandy
Loot_CorpseBaseRobotEyeBot
Loot_CorpseBaseRobotMrGutsy
Loot_CorpseBaseRobotSentryBot
kgSIM_WH_ShackWallOuter01B_Brown

I have never seen any of those in my logs. Maybe they are from another mod?