Jump to content

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


Arthmoor

Recommended Posts

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.

 

A few additional comments from Sclerocephalus:

 

Since I have to test all modifications to the workshop script in vanilla conditions, I'm running Fallout4 with no settler mods, no settlement object limit uncapper and no mods to add new items to be constructed. I also have the Workshop DLCs (Wasteland Workshops and Contractions) disabled. In addition, I'm running all settlements with low settler numbers [Limiting the settler number is pretty simple: just don't assign them to any job. The vanilla scripts check he number of unassigned settlers and won't create any new ones if there are 5 or more unassigned. This won't work when you have mods installed to create new settlers, since they bypass this check (on WorkshopScript) and call the CreateActor function(s) on WorkshopParentScript directly.] This is simply because the logs produced by the workshop scripts get overly long when large numbers of actors are involved. I have the Unofficial Patch installed though.

With this setup, I have not seen the issue occurring. After reading through the reports here, I remembered to have seen actors occasionally fading out/disappearing though. However, they never changed appearance when they appeared again (i.e. they still were fully persistent), so I did not think about relating this to a specific issue but booked it as one of the game's various glitches. Now, thinking about this again, it makes me wonder whether this issue is not actually more widespread and simply has been overlooked, just because the two effects (effect 1: actors losing persistence, effect 2: actors unloading/reloading) may not always be hitting your game at the same time. If this was observed earlier, please let me know

To reproduce the issue, I had to go back to saves that are a couple of months old, from times where I was playing with settler mods and settlement sizes being above average (considering the number of constructed objects). Re-activating those saves with the respective mods and installing UFO4P in addition made the issue become apparent very quickly.

As already mentioned, the engine behaves as if it is trying to free resources - making the NPCs' appearance and inventory temporary (so it is not kept in memory all of the time) and unloading actors when out of view are good indicators, and there is no doubt that this operation mode was implemented on purpose [NB: We have seen similar things in the papyrus engine, where issues are identified and handled before they actually become a problem, e.g. scripts will be stopped when they are suspicious of infinite recursion and stacks will be dumped pro-actively when their number goes over a certain limit. Compared to Skyrim, where those issues were game-breaking in most cases, this is a big advance.] There is a technical aspect of settler recreation that is worth mentioning: basically, settlers are not different from any actors created at spawn points: they get chosen from leveled lists and placed in the game world at run time. However, when a new actor is recreated at a spawn point, it will be entirely new, i.e. it also gets another reference. It is not normally possible to retain the reference and only change appearance, but this is nonetheless exactly what is observed with the settlers: the engine specifically recreates appearance and inventory from leveled lists and 'links' them to existing actors. That's an entirely new feature and supports my assumption of all this happening on purpose. Again, it's basically a good thing to see that they have optimized their engine to react to performance and memory bottlenecks to prevent them from becoming game-breaking, but I am pretty unhappy with the way it was implemented.

It is impossible to predict at which point this issue may hit your game, but from a few experiments I did during the last two days [NB: they were neither exhaustive nor comprehensive, and I did use only a few of the mods out there that deal with settlements, so forgive me if the following information is a bit vague] it appears that they are a combined result of various ways that increase the memory needed by the game to handle a full settlement in the game world. Simply installing many settlement mods alone does not trigger the issue. It's also important how you use them. When you install a mod that adds hundreds of objects to be build, but only ever use a handful of them, the effect will likely be negligible [Thus, your personally style of playing the game may also play a role on whether you run into the issue or not]. Settler mods with heaps of custom clothing and a quatrizillion (i.e. an unreal number) of new hairstyles are likely to aggravate the problem more than other mods: the more clothing and hairstyle options, the more different options will be used on a given number of settlers and the more memory will be needed. The workshop DLCs also add to the problem, as they add many new objects (some of them heavily scripted). I'd wager to predict therefore that the issue will hit all settlements sooner or later, when they grow beyond a certain size.

Of all the various methods to increase the workload on settlements, scripts appear to be what the engine is the least forgiving about. I have not further looked into this issue, so cannot say which modifications are 'allowed', but they may depend on the actual size of your settlements too. With large settlements and mods installed, just recompiling the WorkshopParentScript was sufficient to trigger the issue, but with no mods and small settlements (and small settler numbers too), I could play (almost) issue-free for some time. Maybe it's specifically the workshop scripts, maybe it's the number of modifications made to them (although I have no idea how the engine could be able to detect whether a script is heavily modified or not). I did not check this (and at the time being, I'm not really eager for doing it either).

What really pisses me is that the engine does obviously not even check whether the scripts are really imposing a higher workload. The modifications made in UFO4P 1.0.3 reduce the workload on the papyrus engine considerably, but with the engine entering its "special" operation mode, the workload gets higher than ever before: Preston Garbage alone will call a quest script (which in turn leads to several function calls on WorkshopParentScript) every time he loads, and every NPC will run a significant bit of code from its OnUnLoad and OnLoad events. Not to tell about settlement attacks, where you get a full reset running at the same time (since you're not normall already at the workshop when this happens) and additional calls from WorkshopNPCScripts when actors get hit by enemies ...

 

Link to comment
Share on other sites

Arthmoor & team, please don't give up on the UFO4P just yet! Beth has fixed some of the engine bugs or at least confirmed and promised a fix in one of the next official patches (Weapons Dropped / Mesh overrides).

 

I don't see how they could just ignore this latest issue, especially now that they are expanding the mod audience to the consoles (i.e. depending on a vibrant modding community). Given the  UFO4Ps popularity, it should be in their very own interest to ensure that this gets addressed quickly. Here's hoping that they'll listen...

Link to comment
Share on other sites

Weapon bloat was already fixed, it's about the only bright spot in all of this. That's basically the only good thing Patch 1.6 brought to the table.

Link to comment
Share on other sites

Hi!

Actually I am not sure if this is a part of the current issue, but you really should revert back the change you made to the createActorPUBLIC args in the worhshopParentScript

Some mods are calling this function in its vanilla form, and the mess with the arg order can have some very bad unforseen issues.

I really don't think you should change this kind of stuff. They are called "PUBLIC" for a reason.

Link to comment
Share on other sites

Yeah, don't worry, that's been fixed for whatever it's worth given that the entire setup collapsed and made that minor issue a moot point. Especially since as it currently exists, the vanilla scripts that called it were all altered to use the new format.

 

The ONLY reason I'm bothering to change it to move the new argument last at all is because it'll allow us to remove 2 edits to vanilla scripts and also won't require us to worry about whether or not Nuka-World messes with it (Far Harbor doesn't).

Link to comment
Share on other sites

Hi!

Actually I am not sure if this is a part of the current issue, but you really should revert back the change you made to the createActorPUBLIC args in the worhshopParentScript

Some mods are calling this function in its vanilla form, and the mess with the arg order can have some very bad unforseen issues.

I really don't think you should change this kind of stuff. They are called "PUBLIC" for a reason.

 

"They are called PUBLIC for a reason."

 

Sic!

 

The comments in the vanilla scripts state very clearly that the PUBLIC function should be called by any external scripts, If you look at the difference between the public and the non-public versions (or in general, the difference between the public and non-public versions of any function on WorkshopParentScript) you'll  notice ithat the publlc versions go through an edit lock while the non-public versions don't (the public versions simply call the non-public ones themselves, but do it while their threads are locked). Simple reason: All sensitive threads started on WorkshopParentScript are locked anyway, so making them run through the same lock again will deadlock the whole script.

 

External function calls however should check the lock before proceeding. Otherwise, threading issues are inevitable.

 

Nonetheless, WorkshopScript and others were calling the non-public version (despite the notes clearly stating that they should not). Simply speaking, they could slip in locked threads at any time, with the result of resource data values getting messed up. In the end, all functions accessing WorkshopParentScript will call the SetResourceData and/or ModifyResourceData functions, and those functions - although they simply set a passed in WorkshopRating to a new value - are not threading safe, because the WorkshopRatings structs are defined on an external script (therefore, accessing them will naturally release any lock on the thread). Calls from WorkshopScript that did not go through any lock are confirmed culprits of the settlement stats issue. But those values are not just used for displaying stats: the scripts evaluate happiness parameters, attack chances and other stuuf  based on those wrong values, so the issue can potentially become game-breaking, but even if not, it is still extremely annoying.

 

For this reason, WorkshopScript and WorkshopRadioBeaconRecruitScript have been modified to use the public version instead of the non-public one. There was a small obstacle however in that the non-public version did not perfectly conform to the public one (in all other cases where two versions of the same function exist on WorkshopParentScript, paremeters are perfectly the same) : the non-public version allowed for an extra bool to be passed-in, while the public version did not, and called the non-public version with this extra bool set to a default value of false [NB: this extra bool specifies whether the new actor to be created is a brahmin, and WorkshopScript was the only user of that bool because the creation of brahmins is exclusively handled in the DailyUpdate function of that script].

 

It was a deliberate decision to chose the order of arguments so as to conform with the vanilla users (i.e. those functions that were previously calling the non-public version). Of course, this appears to preclude any compatibility with mods using that function. The sad truth however is that there is no such compatibility. If a function is modified on an FO4 script, all external scripts will have to be recompiled to make them work as expected. Just read on.

 

Let's have a look the point you made about the arguments' order (I already explained that elsewhere, so will keep it very short here):

 

Let's assume that there's a function in some script that looks as follows:

 

function DoSomeStuff (bool A = false, bool B = false)

 

Let's also assume that there is an external script that calls this function like so:

 

DoSomeStuff (true, true)

 

Now, we modiffy the DoSomeStuff function as follows:

 

function DoSomeStuff (bool A = false, bool B = false, bool C = false)

 

In this case, the external script that calls this function would not have to be modified, since the new argument has been added at the end and has been given a default value (as opposed to adding the new argument in the middle, where an argument mix-up has to be expected and the function would almost certainly behave unpredictably). That's what you are criticizing, aren't you ? Correct me if II'm wrong.

 

Well, that's not true here. It worked that way in Skyrim Papyrus (it also works in most other scripting languages), but in FO4 Papyrus, it won't: You will get errrors on the papyrus log telling you that the number of arguments doesn't match and that the function call has been aborted. You need to recompile the script ALTHOUGH YOU WON'T EVEN HAVE TO MODIFY IT AT ALL. There are a couple of scripts in UFO4P that have not been modified either (i.e. the source code is perfectly the same as the vanilla code) but had to be recompiled and included to make them work as expected just because of that reason.

 

Long story short, the order of arguments really doesn't matter here, since you will have to recompile all scripts using the modified function anyway. Feel free to try it out yourself.

 

Of course, we could have left everything as it was, but then it would still be bugged.

 

But even that won't probably matter now, since it appears that we're going to abandon it anyway.

Link to comment
Share on other sites

Not abandoning it, just moving the new argument to the last position. The two scripts being dropped from the package for 1.0.4c both call the public function already and we only updated them to use the out of order arguments. Now that won't be an issue.

 

I've been running tests on the updated argument order, no errors thrown, and brahmins showing up when expected. Nothing is out of place.

 

It might have bugged the way you're saying in Skyrim, but it appears Fallout 4 is smart enough to know it doesn't need to change anything.

 

If Bethesda later changes the function themselves to switch the arguments around, we'll follow suit, and everyone else will have little choice but to do the same to remain compatible with the base game.

Link to comment
Share on other sites

It might have bugged the way you're saying in Skyrim, but it appears Fallout 4 is smart enough to know it doesn't need to change anything.

 

 It's the other way around. Better inspect the logs very carefully.

 

EDIT: That way its is now, mod authors will simply assume that they won't have to change anything (unless they are aware of the issue) and wonder in the end why it still doesn't work.

 

EDIT2: There will be no errors thrown on our logs of course, unless one of the respective mods is installed.

Link to comment
Share on other sites

Someone on the Nexus forum says he's solved the settler regespawning issue by removing packages "WorkshopSandboxRelaxation20x4" and "UFO4PWorkshopSandboxAtRelaxLocationAndGuardArea":

https://forums.nexusmods.com/index.php?/topic/3502925-the-unofficial-fallout-4-patch/?p=40327015

 

That doesn't make much sense, considering that the settlers will run the package only within a narrow period of game time (4 hours out of 24). Maybe it made things appear fixed temporarily. Even quitting the game and reloading will make the settlers stop respawning for a while. After some time in game, things will more or less rapidly go back to "unnormal" though.

Link to comment
Share on other sites

This is somewhat unrelated, but should not be forgotten:

 

Someone needs to tell our users that it is a bad idea to spawn settlers via console. It's their own decision to do this, of course, but they should be well informed on waht they're doing. It's a relatively minor problem that those settlers will never be properly added to the workshop. A bigger problem is that all spawned settlers will run a WorkshopNPCScript, which is only partly functional. Partly because the workshopID is never set. The scripts react to all events all other settlers do as well, and their WorkshopNPCScripts will call WorkshopParentScript to let them handle. From this point on, everything goes wrong though, because WorkshopParentScript cannot handle them when the workshopID is invalid (i.e. never set). Those calls will clog the scripts (because they lock out other threads from getting in) and do nothing else than just fail and spam errors on the log.

Link to comment
Share on other sites

 It's the other way around. Better inspect the logs very carefully.

 

EDIT: That way its is now, mod authors will simply assume that they won't have to change anything (unless they are aware of the issue) and wonder in the end why it still doesn't work.

 

EDIT2: There will be no errors thrown on our logs of course, unless one of the respective mods is installed.

I did, line by line, not a single error relating to anything to do with calling CreateActorPUBLIC while I was pulling hairs out over this. Radio recruitment worked flawlessly when the game reverted back to its unedited copy of the WorkshopRadioBeaconRecruitScript.

 

That doesn't make much sense, considering that the settlers will run the package only within a narrow period of game time (4 hours out of 24). Maybe it made things appear fixed temporarily. Even quitting the game and reloading will make the settlers stop respawning for a while. After some time in game, things will more or less rapidly go back to "unnormal" though.

Well, it doesn't have to make sense apparently. I've confirmed that removing the AI pack changes did in fact minimize the effects of whatever engine bug is in play here. Settlers still regularly change their clothing, but they've stopped changing their physical appearance, gender, and race entirely. They're not losing their inventories anymore either.

 

I've uploaded 1.0.5c with these things taken care of. Better to have minimal issues than catastrophic ones IMO.

 

I can cause the problems to return easily by activating the ESP I moved the AI pack changes into. Takes less than 1 game day for the full swaps to start happening again. Deactivate that plugin, and only their clothing swaps from time to time. So I don't get it either, but clearly SOMETHING in the package + template is triggering their engine bug in a huge way.

 

Yes, I know the engine bug has existed since Patch 1.4, but here we are. Maybe it'll help the devs figure it out? I have yet to try it with a strictly vanilla game though so that's something that still needs to be done.

Link to comment
Share on other sites

 

Well, that's not true here. It worked that way in Skyrim Papyrus (it also works in most other scripting languages), but in FO4 Papyrus, it won't: You will get errrors on the papyrus log telling you that the number of arguments doesn't match and that the function call has been aborted. You need to recompile the script ALTHOUGH YOU WON'T EVEN HAVE TO MODIFY IT AT ALL. There are a couple of scripts in UFO4P that have not been modified either (i.e. the source code is perfectly the same as the vanilla code) but had to be recompiled and included to make them work as expected just because of that reason.

 

 

 you might be right there, then

 

 

Link to comment
Share on other sites

I am not tech savvy but the problem I'm having with the game seems linked to the problems described on here. I can safely say that ufo4p not connected or adds to the problem as I started a new game and have been adding mods a different intervals and have ran into problems with settlers. I haven't downloaded ufo4p yet hence I safely say it has nothing to do with the problems. I only have the basic game so it isn't dlc, must be Bethesda. In the end what ever they have done it has caused a multitude of problems.please read my feed to see the problem I am having " can't assign selltlers "

Link to comment
Share on other sites

It's not a landmine, it's a piss bomb (short for: Pre-vIS/Pre-cOMB; yes, it's a bad joke)

 

It's actually pretty simple: First, the work benches are static objects that can't be moved. Thus, somebody thought that it would be OK to include them in piss bombs [NB: I don't know whether they were configured that way from the beginning, but they definitely are now.] Second, work benches are sxripted objects. When you attach a script to an object, the script extends the object and you create something new. In other words: when you modify the script, you modify the object. And when that object is included in a piss bomb, the bomb explodes.

 

You can safely consider this as verrified (details below).

 

This issue is ridiculuous for two reasons:

(1) Even if there's logically no difference between an object and the script that extends it (i.e. it's not aven a bug), I would have expected that the engine can discern mesh and/or position edits from script edits, but it obviously doesn't.

(2) Including the work benches in piss bombs has been an inredibly stubborn idea. If they had been left out, there would be just one more object per workshop in addition to hundreds of player-built objects that don't have any piss bomb data either, and the loss of performance would likely not even have been noticeable. This way, the whole workshop system is basically off limits to modders.

 

To verify this, I modified the UFO4P version of WorkshopParentScript just enough so that it works with the vanilla WorkshopScript [NB: It was that latter script, not WorkshopParentScript which I recompiled to trigger the issue on my old save; I did re-read the text twice to make corrections, but that one escaped me.] and removed the latter from UFO4P 1.0.4b entiirely (I repacked the archive with the tool that came with the CK). The teleporting issue disappeared instantly as did the pop-in/pop-out issues [plus several other issues of which you don't know already; they will be explained below].

 

Unique settlers and preplaced ones went back to 'normality' very quickly, and any new settlers that were created after removing the script were persistent immediately (i.e. no changes whatsoever in appearance or inventory over time, even mod-added ones). Preplaced settlers that are not unique (e.g. the couple at Tenpines Bluff and the ladies at Oberland Station) kept on changing their outfits but it turned out that they had several outfits in their inventories and removing them fixed that problem too (new outfits did not spawn again ever since). Mod-added settlers that were already at the workshops before I removed the script take a much longer time to 'recover' though. Some alredy did, but it's difficult to say whether all of them will do eventually. I also started another new game without WorkshopScript, but Better Settlers installed (at easy level, in order to built a fairly-sized settlement within a few hours) and did not see any problems with the settlers who showed up.

 

It is important that you give all workshops the opportunity to unload twice, so make sure to stay far away for a sufficiently long time. The first unload is important to force a full reload, to re-enable the piss bombs and reconfigure mesh data accordingly. The second unload is important because some data (navmeshes, possibly others) are only updated on unloading [NB: You can see that in your game when you build new obstacles and let the settlers run into them. This does not stop until you leave the area for a long enough time and return (well, they may still run into walls even then, but it usually gets better once the workshop has unloaded). As you may know, some navmesh data are in the piss bombs too]. Besides, workshop resets running after a full reload also help to refresh the workshop data.

 

I have now played with this setup long enough (around 20 hours real time) to make sure that the effects are lasting. Most importantly however, the script lag is permanently gone and engine activity is back at a normal level. Also, most the error messages that let my papyrus logs explode after upgrading to 1.6 with UFO4P installed (many of them extremely weird) are gone as well.

 

Now, that's some of the things you don't already know: with UFO4P 1.0.4b (unmodified) and patch 1.6 installed, the engine was basically choking (and yes, that patch definitely made things worse). That's also the entirely unspectacular reason why settler recruitment apparently stopped working: it didn't stop working; it simply took incredibly long for the code to execute. You can check that from within the game rather easily: activate an armor or weapon workbench (or a chem station or a cooking spit, but not the red workbench) while you're at a workshop, and see how long it takes until the menu opens. Those calls are not going through any edit locks (as function calls on the workshop scripts do, so the time this takes is just the time it takes the engine to handle the activation. In normal gameplay, the menus open instantly, but at the 'borked' workshops, it can easily take more than 10 seconds !!!!!

 

Now, when you take into account that most activities on the workshop scripts have to wait until previous calls have finished running, you easily understand why they appear to stop working. They still do work, but they take an incredibly long time. That's solely a result of engine overload. The engine does not only behave as if it had to save every little bit of performance (I had no ultimate proof of that when I posted, this two days ago), it really does. A close inspection of the papyrus logs and workshop logs (the latter tell how long the workshop related tasks take to complete) verified this eventually.

 

What the engine is doing here is also known from the Skyrim engine: in situations of very high workload, priority is given to the graphics engine. The game tries at all cost to keep up the frame rate and draws performance from everything else. As a result, the game may appear to run fluently and you may be easily deceived into thinking that everything's fine when it's actually whistling the last hole.

 

It's not surprising me that removal of individual edits from the UFO4P appears to cure the issue. You free memory and/or gain performance for one part of the engine, and all other parts will instantly benefit from this. For example, the AI is running low too (the teleporting issue is a result of this), so removal of AI-related edits or additions (e.g. a package) will show immediate results. The question is however whether this will be lasting. The settlement size is an important factor in this game, so be prepared for the negative effects to return in the long run. In the first stages of my investigations on this issue, I have experimented with removal of certain edits myself, and they led undoubtedly to positive effects. In the end however, none of them did reliably cure the script lag (i.e. bring the engine activity back to an acceptable level) - which removal of WorkshopScript did !

 

The reason of all this is that we detonated a piss bomb because we didn't know it better (or, because we inferred that Beth means what they say and really want to encourage modding which would imply a certain level of fairsightedness and would have precluded such things from happening).

 

Another detail worth mentioning: In the 1.6 patch, Beth did modify the WorkshopScript themselves. This means that they should actually know what the recent complaints are about. Either they already knew they would run into this issue (and also knew already how to fix it) or they didn't. In that case, I hope they had a really bad time figuring out what was going on. I actually think however that this hope is futile; they probably just did recalculate the piss bomb data. There's also a third possibility of course: they were not aware of this issue and didn't run into it either. In that case, they might not have taken care of it appropriately. Which takes us back to the problems of patch 1.6

  • Like 2
Link to comment
Share on other sites

Regarding world edits, the only two they seem to have made between 1.5 and 1.6 were to the trigger boxes in Starlight Drive-In and Jamaica Plain, both of which are settlements people say can no longer be built on properly in a game where they'd never been visited before.

 

Forms 0001D0E1 and 001BF6B3.

 

Can't really see why they did it either. There was never anything wrong with these settlements.

Link to comment
Share on other sites

So basically to us less tech savvy guys, Bethesda has made the game useless for now ( well partly useless anyway)?

Link to comment
Share on other sites

So basically to us less tech savvy guys, Bethesda has made the game useless for now ( well partly useless anyway)?

 

Not really.

Link to comment
Share on other sites

Okay, I had to create an account to chime in here, so if I'm gathering this information correctly, that means that UFO4P could be causing bugs elsewhere as well, say with quests, or companions, correct? The reason I ask is because with the patch I was able to avoid a bug in Benign Intervention, only to run into a previously unheard of bug in the very same quest. 

To me, at least, it would make sense for Cait, her quest, or the vault to be tied to one of those Piss Bombs, meaning that the fix could've broken something else.
Am I just crazy, or am I somewhere in the realm of sanity here?

Link to comment
Share on other sites

No, not at all. It means what Sclerocephalus said it means. That the workshop system is a mess and that editing it may be dangerous until Bethesda fixes the underlying problem. Please don't start spreading bad information that everything would break because then you'd have to extend that logic to ALL mods that do ANYTHING, which clearly isn't a valid scenario.

 

Cait's quest has nothing to do with any of this. We fixed one issue with it where it expected you to have Danse as a companion for it. If there's OTHER bugs though, we are not aware of them because nobody has reported them to the tracker. Or if they have, not in enough detail to act on.

Link to comment
Share on other sites

This is somewhat unrelated, but should not be forgotten:

 

Someone needs to tell our users that it is a bad idea to spawn settlers via console. It's their own decision to do this, of course, but they should be well informed on waht they're doing. It's a relatively minor problem that those settlers will never be properly added to the workshop. A bigger problem is that all spawned settlers will run a WorkshopNPCScript, which is only partly functional. Partly because the workshopID is never set. The scripts react to all events all other settlers do as well, and their WorkshopNPCScripts will call WorkshopParentScript to let them handle. From this point on, everything goes wrong though, because WorkshopParentScript cannot handle them when the workshopID is invalid (i.e. never set). Those calls will clog the scripts (because they lock out other threads from getting in) and do nothing else than just fail and spam errors on the log.

 

 

I've maintained a 100% vanilla install (I.E. I don't even run the UFO4P) of the game and spawned settlers via console ages ago, before Survival mode was even in beta. Does what your describing still apply in my case? If so, how can I fix it? Kill all of my settlers and re-recruit from the Radio Beacons only? In my +300 hours on a single character the settlers spawned via console still behave the same as others.

Link to comment
Share on other sites

We basically unearthed a Balrog :P

And some people say you should wait with doing the UFO4P until Bethesda stops updating the game. :peer::rolleyes:

  • Like 2
Link to comment
Share on other sites

I find it kind of funny, how it always looks like these big companies have just one competent employee

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...