Patch 3.0.3 - Community Exterminators

[Karyusan]

better go back to a early save or use fallrim tool is the same ?

 

[EyeDeck]

Hmm... Okay, there is another way to do this. If you were to sabotage the UpdateMaintenanceCosts function (remove it, change the number of arguments, etc), it would cause the thread to error out and stop the next time that function would be called.

You'll have to write a chunk of code to place a temporary turret or generator at whatever happens to be at workshop array 0 to ensure that code runs and subsequently errors, though.

 

[Vejigante]

Hello there!

Unfortunately played quite a few hours after updating to 3.0.3a in survival mode, really don't want to play those bits over!

Never used the tool before, so I was hoping to confirm this is the right way to handle it before doing it. I went ahead and set up Fallrim Tools and opened up my save, and searched for the SetupCurrentMaintenanceCosts script you mentioned in your earlier post. Attached image is where I'm currently at.

So would I proceed to click on Clean up top and select Kill Listed? Would that be all that'd need to be done before saving it? Also, should I have this done before I load up the game with your recently uploaded hotfix?

Appreciate your help!

 

[kinggath]

@Vejigante Good call - I should clarify the steps for folks who haven't done it.

1. Download and install Fallrim Tools
2. Open Resaver.exe, load your latest save file.
3. Expand ActiveScripts, search for any entries of "SimSettlements:SimSettlementParent"
4. Expand each of those and look for "SetupCurrentMaintenanceCosts", if you find it, right click on the folder icon above it and choose terminate.
5. Click File->Save
6. Install 3.0.3b of Sim Settlements if you haven't already and load your save.

 

[kinggath]

Hmm... Okay, there is another way to do this. If you were to sabotage the UpdateMaintenanceCosts function (remove it, change the number of arguments, etc), it would cause the thread to error out and stop the next time that function would be called.

Unfortunately Fallout 4 keeps a local copy of functions that haven't completed inside the save itself so that they can finish running before updating to the new variation of the function.

 

[EyeDeck]

Ha... yeah, because of the way the update script was written, every save/load cycle would start up another infinitely looping thread. To make matters more fun, it isn't even possible to programatically figure out which saves are affected, because the InstalledVersion variable never gets set.

So would I proceed to click on Clean up top and select Kill Listed? Would that be all that'd need to be done before saving it? Also, should I have this done before I load up the game with your recently uploaded hotfix?

I've had poor experiences with deleting active scripts with FallrimTools (unloadable saves), so I recommend right-clicking each of those simsettlements:simparentscript entries and selecting "Terminate" instead. The game engine will clear them out as soon as you load the save.

Unfortunately Fallout 4 keeps a local copy of functions that haven't completed inside the save itself so that they can finish running before updating to the new variation of the function.

That shouldn't be the case with nested function calls like that, otherwise the game engine would have to cache absolutely massive quantities of code into save files: every single possible code branch would have to be stored - as smkviper would probably tell you, that way lies madness. It will save things like function name and variable count, as I mentioned, and Papyrus gets really upset if the cached function calls doesn't match what's in the current scripts, which I do believe will cause the old threads to error and die.

 

[kinggath]

My experience is that it does hold massive amounts of script data. This was a big problem with Skyrim, in that it would almost never actually update the script at all because it would end up cooked into the save file - so updating Skyrim mods often required a clean save to fix issues. With Fallout, it at least updates them after the current iterations have completed.

 

[kinggath]

If you take a look at an ActiveScript in FallrimTools you can see it actually stores the byte code for every function in the stack of that call.

 

[Vejigante]

Much appreciated Kinggath & EyeDeck! Went ahead and did that.

Endorsed over on the Nexus, just wanted to thank you again for such a great mod. Having such a great time with this as a part of the game!

 

[EyeDeck]

If you take a look at an ActiveScript in FallrimTools you can see it actually stores the byte code for every function in the stack of that call.

Only partially true. Look at this:

The UpdateMaintenanceCosts() function call bakes down to this. Notice how it does not include the contents of UpdateMaintenanceCosts, if it did this would not match the bytecode for SetupCurrentMaintenanceCosts() 1:1 . It does include function name, and number of arguments (3). This is why I suggested sabotaging UpdateMaintenanceCosts() in the updated script; if either that function is missing, or the number of arguments don't match, the thread will error and die.

 

[kinggath]

I'll give it a go on my test machine - curious if I can derail this or not...

 

[kinggath]

No dice - tried removing the function and eliminating the arguments, neither caused the loop to stop. So either it's keeping the byte code somewhere else, or it just allows the loop to continue despite the callfunction failing.

Shame, that would have been a nice ace up the sleeve if this were ever to happen again. Though I doubt I'll forget this mistake anytime soon. Will be slowing myself down now that the major issues are worked out so that the cure doesn't become worse than the disease.

 

[EyeDeck]

Are you certain that the workshop at index 0 has a turret or generator? There should definitely be an error in the Papyrus log when it hits that bit of bytecode, I'm just not 100% sure if it kills the thread though... but I know I had a really hard time fixing a bug in one of my mods that was ultimately caused by argument count differing in a vanilla function on some user's installs, because some other mod I never identified was doing something naughty with WorkshopParentScript. It caused the function call to return at the exact point of the argument count mismatch (edit: or did the thread completely stop then? I don't actually rememeber... the function that the CALLMETHOD instruction was in definitely did not progress past that point regardless. Anyway it ended up causing WorkshopParent.DailyUpdateInProgress to get stuck set to true... yeah, that was a nasty one.)

 

[kinggath]

Ahh, I see what you're saying, the sanity checks would prevent that function from even firing to potentially break the thread if there were no generator or turret there. I'll have to do some more detailed testing after work. For now, we've at least got a hot fix in place to reduce the number of people affected.

Also looks like the number of Xbox players who downloaded the patch is relatively small - so I'm hopeful your quick reporting will keep the damage to a minimum number of players.

 

[40ksmything]

Did a clean save. Went to Sanctuary after picking up the city manager module and did a scrap all as per the video. About 30sec into the scrap all process the game crashes. Tried this twice.

I noticed the scrap all function leaves pictures that where hanging on walls behind. Is this an issue to be concerned about?

 

[kinggath]

I noticed the scrap all function leaves pictures that where hanging on walls behind. Is this an issue to be concerned about?

No, it just means we didn't notice them when creating our scrap profile. A handful of our testers went through each settlement and manually scrapped everything they could find so that we could have a safe scrap method, definitely possible a few things were missed.

 

[Doctor Feh]

So does this maintenance bug affect everyone regardless of whether we had maintenance costs enabled in our options? I thought they were disabled by default ever since 3.01. For example, I know for sure that before I updated to 3.03a last night I had the Involvement setting at "Low" which should mean no maintenance--which I also would have thought meant no scripts of that nature running--do I still need to do that ReSaver cleanup?

 

[mytigio]

So does this maintenance bug affect everyone regardless of whether we had maintenance costs enabled in our options? I thought they were disabled by default ever since 3.01. For example, I know for sure that before I updated to 3.03a last night I had the Involvement setting at "Low" which should mean no maintenance--which I also would have thought meant no scripts of that nature running--do I still need to do that ReSaver cleanup?

I believe that kinggath was still calculating maintenance cost for everyone, so it would work if you enabled maintenance costs, he just wasn't actually applying the tax penalty unless you enabled the setting. However the easiest way to tell is to follow those steps and see if you have the offending script active. Might be a useful bit of practice anyway honestly.

 

[Scora]

I've used the Resaver cleanup on my save and things seems to run alot smoother now? but im still crashing whenever i fast travel to a settlement or place near one. Will we have to wait for a patch for this until we can progress? :/

 

[EyeDeck]

Everyone who updated to 3.0.3/3.0.3a and made a save has this issue, the offending function was called by the function that runs on game load and runs update code (and the problem gets worse for every save/load made when that version was installed).

It's okay though, I'm still like 80% sure this can be resolved with some clever scripting that will most likely be in 3.0.3c.