Just because it is in the patch does not make it correct. Ultimately you should be sending this to the Patch team for making a change to the code incorrectly. Accepted I play on Xbox it might be different on PC, but there are many changes in the patch exactly like this one, not required, good reason not to use it.
Lets just deal with this one. Originally the game had mortal settlers and then Beth updated the game and changed it, I forget what date and that specific line may just be a leftover or maybe the origin report/request was before the update (Oct 2019).
Think about it, have you ever killed a protected synth infiltrator, during a settlement attack or during the suspected synth quest? The answer is no, or at least I never have, in the first they are always dead when I get there, in the second the settlers kill them so they are no longer protected and likely not even settlers any more just simply a synth. If you are using a mod that lets you find synths in your settlement, so be it, the other settlers would be upset their buddy just died, they have no idea they were synths, just their buddy. You should have moved them to an empty settlement and killed them there.
The other thing that could have been considered during development is maybe they are just mad because they let a synth infiltrator into their settlement? The multitude of these unnecessary changes is why the game plays so much worse on Xbox with the patch installed.
Just for me if there was something in the patch that was changed my a King mod I would question the patch change first as Kinggath seems a much more responsible modder. My guess is he actually plays the game and notices how the game plays.
I have looked into all three of these conflicts and they are both required fixes for a vanilla setup and properly implemented (at least within the Quest record. My papyrus is too rusty to swear the same for the underlying script).
Regarding the WorkshopEnemyFaction issue:
You seem to misunderstand both the underlying issue, UFO4P's approach to fixing it, and why they made that determination.
First, the setup & underlying issue/bug:
In the vanilla game, all settlers are normally protected—only the player can kill them. Without mods, this is still true in the most recent patch, as far as I'm aware, as settlers still have the Protected flag. When reading the comments left in the HandleDeathActor script (which is run when settlers die), there's an indication that the happiness malus is intentional on settler deaths. And the tenor of the comment at least implies that that particular Bethesda coder viewed it as being the player's fault, though whether it is or not is ultimately irrelevant. The main point here is that if a settler dies, the settlement is hit with a happiness malus (of I think 20 points, though I don't have that source in front of me this second).
For most cases, this is fine; it only happens when a settler dies, after all. The bug occurs with Synth Infiltrators. Until they "activate", the game treats them as normal settlers. When they blow their cover and attack the settlement, code in the game
removes the Protected flag. Now, those Synth Infiltrators can die at the hands of either the player or their settlers. This is why you mentioned always finding them already dead.
However, the game
still applies the malus as if the settler that just died had been an ordinary one, rather than a Synth.
Now, how did UFO4P fix it?
They inserted a new Property into the Quest record for WorkshopEnemyFaction (FormID: 001357E7). This faction is only used by Synth Infiltrators. Then, according to the documentation on UFO4P's bugtracker, they've added checks in the underlying scripts so that when an actor dies, before applying that malus, it checks to see if it was a Synth Infiltrator Settler (which would have that faction). If so, then no malus applied.
Lastly, why did UFO4P decide to fix it this way?
Going back to what I mentioned in the setup portion, the comments left behind in the code by Bethesda's coders give the impression that the malus was only intended to hit when a settler died because of the player. There's a reasonable disagreement to be had over whether this is an appropriate assumption on the Bethesda coder's part (see above, your alternative in-universe explanations for why that malus might occur). However, UFO4P tends to err on the side of trying to fix what they feel was
intended by Bethesda, in these cases. Therefore, they made the determination that the malus shouldn't be occurring in cases of Synth Infiltrators, and they implemented a fix to prevent it.
And the other issues in question are more cut-and dry with whether they should be implemented (on a vanilla game). One deals with the Vault-Tec Rep. All of the other named trader settlers that you can recruit are flagged as "Protected" as soon as you recruit them and send them to a settlement. The Vault-Tec Rep's flag was forgotten. As a result, for many players he dies along the way. Someone intentionally playing with mortal settlers might view this as fine, but for those playing with the default Protected settlers, this is a clear oversight.
The remaining two conflicts are part of a single issue involving Provisioners and their brahmin, based on the UFO4P bugtracker. The short version is that there's a vanilla bug where they aren't renamed and/or reassigned properly when you try to assign a Provisioner to something else.
Why report this to Workshop Framework instead of UFO4P?
Whether or not the fix
should be there is an entirely separate discussion. What I'm trying to figure out, primarily, is whether this issue is handled some other way in kinggath's code. For example, I know he's rewritten several code hooks to bypass buggy settlement behavior, so it might be that these issues have been handled by different means. But if they haven't been, then I'd like to find out whether there's an
intentional decision by kinggath not to implement this fix, or whether it was just missed.
And more importantly, within the purview of UFO4P, the above changes are all correct. UFO4P only deals with a vanilla game, and it's the responsibility of mod authors to either implement the changes or decide not to according to the needs of their own mods. All of the above changes were pretty clearly-documented (though it took me a while to track down the Synth one) and they've been in UFO4P for several versions. In contrast, the only documentation I can find in WSFW regarding this quest record is the following from v1.0.1:
- Eliminated all vanilla edits to forms. Now the only edits are to the Workshop Scripts, this should fix incompatibilities with multiple mods that were editing the WorkshopParent quest properties.
This works perfectly fine for downstream mods, but WSFW instructs users to place UFO4P
above it, which means it's creating incompatibility with at least one mod that's editing those quest properties.
-asp
github.com
