Arthmoor Posted July 9, 2016 Share Posted July 9, 2016 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 knowTo 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 More sharing options...
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
Already have an account? Sign in here.Sign In Now