Unofficial Fallout 4 Patch (UFO4P) takes an arrow in the knee.

[Arthmoor]

So it appears we've been hit with an impenetrable roadblock in the workshop system. Bethesda, for reasons unknown, has made some rather... bad changes to how things work.

If you don't want to read through the details, the summary of the situation is this:

Settlers recruited via the radio beacon (basically all of them really) or settlers placed via console commands (shame on you people!) will begin to exhibit gear, appearance, gender, and even race changes after a certain amount of time. My own testing shows this is tied to how long the respawn timer is for the game. Cut it to one hour, you can get the problem almost immediately. Raise it, and you can probably delay it, but it will cost severely in performance elsewhere. In the end, it's an engine issue we cannot solve. Eventually, just standing around in the cell WHILE THE SETTLERS ARE WITH YOU will result in them changing if you turn your back on them, even for just a few seconds.

 

Thread on Bethesda.net: https://community.bethesda.net/thread/53871 Let them know this needs to get fixed!

Anyway, here's the details, as explained by Sclerocephalus:

 

======================================================================
I managed to reproduce this behavior myself and did some testing during the last two days. There are two things happening here:

(1) The settlers lose persistence.

References still are persistent, but everything else is not. Important to know here is that none of the game-created settlers is ever in an alias (putting them in an alias would fix the problem, see below; it won't fix problem (2) though). Instead they make settlers persistent at the settlement location by running the SetPersistLoc function on them. That's all at the end of the AddActorToWorkshop function on WorkshopParentScript. They check each actor whether he's game-created (probably by checking the address range of his reference), then make him persistent with SetPersistLoc(). This function apparently adds persistence of an NPC's inventory and appearance.

I have added traces to this part of the function to see whether there's anything different with mod-added settlers (maybe, the IsCreated() function returns false when the settler is added by a mod, and thus he's never made persistent ?) but there's nothing wrong. The functions still run on all new settlers, irrespective of whether they are vanilla or mod-added. For some obscure reason however, the effects of that function are suddenly invalidated. [NB: I assumed earlier that the decision not to put settlers into aliases was driven by performance considerations. Meanwhile though, I'm thinking that this was done on a different purpose: to negate persistence status to free memory resources whenever the engine considers them as needed. This is much easier to do by removing a 'PersistLoc' flag at engine level than by dealing with aliases.]

NPCs assigned to supply lines are handled in a different way, because they move outside of the settlement borders: they are put into aliases to accomplish this, and this is obviously the reason why they are not affected by appearance changes.

(2) All workshop NPCs (including preplaced ones) are unloaded when they are out of sight.

I added traces to the OnLoad() and OnUnload() events of WorkshopNPCScript, and it turned out that all NPCs unload and reload every couple of seconds. When they reload, all game-created NPCs will have appearance changed because they ceased to be persistent (i.e. the two problems are closely related). After investigating the 'unloading behavior', I've come to the conclusion that the engine is performing some very aggressive sort of visibility culling here: things are fine as long as NPCs are in your field of view and within a sufficiently short distance. They disappear instantly however when they are outside your field of view or when the distance increases (this distance very clearly underrides my game setting for the actors' fading distance). They also disappear when only partially hidden by other objects, e.g. in a tato field: tatos are neither big nor massive enough to hide actors completely, but the engine now behaves as if they did. From a distance, I saw nobody working in my tato field, but when I approached close enough, NPCs in the field were suddenly fading in.

This all taken together, it appears as if the engine changed into a mode where it desperately tries to save every little bit of memory and performance. Sad irony is that the workload on the papyrus engine is now probably much higher than it ever was before, even with the borked vanilla scripts. This is because all actors run a fair bit of code from the OnLoad and OnUnload events of their WorkshopNPCScripts.

It should also be obvious that this is impossible to be caused by a bug, not in the patch nor in any other mod, neither deliberately nor accidentally - simply because telling the engine when it should start to unload any actors (from a loaded cell !) is out of reach to CK edits and papyrus scripting.

The question is why the engine 'thinks' that it has to do what it does. The only answer that came to my mind was this: it has been told to do so when the game has been modded. Now, this answer is not really satisfying, because it implies that the issue is much more widespread than it appears to be. At least, it should have been reported earlier. A search in several forums turned out that it was reported earlier indeed. This post, for example, dates back to 9th march: https://forums.nexusmods.com/index.php?/topic/3886760-settlers-resetting/ (https://forums.nexusmods.com/index.php?/topic/3886760-settlers-resetting/)

There are more reports to be found in the bug trackers of the Better Settlers, New Face Settllers and similar mods on the Nexus, and some of them predate the Unofficial Patch. This is important since it supports my opinion that it is not UFO4P specifically that causes this issue. It rather appears to be a combination of circumstances, maybe a combination of certain mods or certain types of mods. It is particularly noticeable that authors of all previous reports on that issue had a settler mod installed, and many authors of the current reports also do. I'm not saying that those mods are responsible for the issue, but I think that they may aggravate the problem. Actually, anything that increases the memory needed to display a settlement in the game world should aggravate the problem, since this is the only reason for the engine trying to free resources.

This still does not explain however how UFO4P is involved. In the end, I had a weird idea: what if it is just the script ? I mean, not specifically the mdified script, but just the fact that we added a workshop-related script in a mod ? Not necessarily logical thinking, but as I said, the idea was weird. During my second playthrough in january/february, I made backups of specific saves at branch points in the quest line, so I could go back later and finish the game with another faction. Those saves still exist. During that playthrough, I had Better Settlers and a settlement object limit uncapper installed, but (obviously) no UFO4P.

When I loaded one of these saves in the present game (i.e. with the game patched at 1.6), I did not see any issues with my settlements. They are not particularly large, not more than 12-15 settlers on average (except at The Castle), but already have an above average number of static objects, i.e. full walls all around. While checking this, UFO4P was not installed.

I then went into the CK and re-compiled WorkshopParentScript in debug mode. Just the vanilla script. No modifications. Also, I still did not install UFO4P. The re-compiled script appears in the scripts folder, so it should be interpreted by the game as an override (whether it is otherwise modified or not). I then reloaded the game and ... BANG - that was sufficient to trigger the issue !

Conclusion is: we cannot fix the workshops. Remove all workshop-related fixes from the patch and tell everyone who posted a workshop bug on the tracker to ask Bethesda for fixing it themselves (I doubt that they will do it though).

And yes, I'm pissed too.
======================================================================

IMO, this may sound a death bell for the project. Settlement issues are a large portion of what's wrong with the game and it has taken him/us 4 iterations of work to get to the point we're at now, and now it's all for nothing. Considering Bethesda themselves screwed this up for reasons unknown, I don't know if we can trust them not to completely screw something ELSE up later on that gets in the way of fixing a broken quest, bad flags on NPCs, or even stuff as simple as fixing typos. We are already operating under restricted conditions with being unable to do any sort of mesh fixes and being severely limited in the ability to do placed reference corrections. Adding all of this makes it even less useful as a project now.

Only Bethesda can ultimately fix this, so IMO, people should start directing bug reports to them. Make them realize that as long as they're screwing up fundamental systems for resource management reasons, we can't do anything. There was absolutely no reason to have done this either since NPCs placed via script calls don't need to be persistent outside of their settlements and they had no reason to believe that performance would improve by cycling them repeatedly while you're in the settlement. In fact, logic dictates it does exactly the opposite.

[AnvilOfWar]

So Arthmoor, basically settlers will for all intents and purposes "respawn" completely bypassing any gender/face/gear they have and randomly determine themselves again?

So either the player equipping them with any gear will be wiped once "out of sight out of mind" happens likewise for mod added settlers?

[Ethreon]

Settlements are totally a feature that wasn't crammed in.

[pra]

Hm, could this be related to the bug where automatron robots reset to the basic protectron? In a sense, they count as settlers when dismissed, do they not?

[Arthmoor]

So Arthmoor, basically settlers will for all intents and purposes "respawn" completely bypassing any gender/face/gear they have and randomly determine themselves again?

So either the player equipping them with any gear will be wiped once "out of sight out of mind" happens likewise for mod added settlers?

Yes, exactly. Due to them unloading from memory when you turn your back on them, they are literally being cycled out of existence to be replaced on the same form ID when you bring them back into view. It's utterly bizarre.

 

Hm, could this be related to the bug where automatron robots reset to the basic protectron? In a sense, they count as settlers when dismissed, do they not?

Yep, I would guess that's the same issue as well.

[WhiskeyRiver2]

I'm still running 1.03 of UFO4P, so I'll be checking to see if the issue persists with that combo. Did the relevant script(s) change between my version and 1.04b, and if so, how exactly?

[Deleted3507349User]

Good Lord. Y'know, we could save many pages and much bandwidth for poor ol' Dark0ne by limiting posts to the things Bethesda HAS gotten right.

[Arthmoor]

I'm still running 1.03 of UFO4P, so I'll be checking to see if the issue persists with that combo. Did the relevant script(s) change between my version and 1.04b, and if so, how exactly?

It wouldn't help. The issue can be traced back to at least Patch 1.4 in March, which predates all versions of UFO4P. Something they changed there led to scattered reports of mods that mess with settlers suddenly going apeshit and all we did was allow this to finally manifest itself more efficiently by fixing the bugs in their scripts. NOTHING we did could actually cause this since the engine itself is what's triggering settlers to unload from memory. Nobody can counter that because there's no way to tell the engine "don't unload this guy".

[WhiskeyRiver2]

 

I'm still running 1.03 of UFO4P, so I'll be checking to see if the issue persists with that combo. Did the relevant script(s) change between my version and 1.04b, and if so, how exactly?

It wouldn't help. The issue can be traced back to at least Patch 1.4 in March, which predates all versions of UFO4P. Something they changed there led to scattered reports of mods that mess with settlers suddenly going apeshit and all we did was allow this to finally manifest itself more efficiently by fixing the bugs in their scripts. NOTHING we did could actually cause this since the engine itself is what's triggering settlers to unload from memory. Nobody can counter that because there's no way to tell the engine "don't unload this guy".

 

I see.....

 

Well, to repeat my Bethesda.WTF post... GG Bethesda. Gf*#@IN'G.

[pra]

Another note: it affects companions as well. I gave my (synth) Curie road leathers and leather armor upgraded with deep pocketed, and it's gone now, she has her original outfit again. I also gave her Danse's Righteous Authority laser rifle, and strangely, she kept that.

 

Will attemt a downgrade now. Good thing I kept the unofficial patch 1.0.2 around, it seems the only file still on nexus requires 1.6.