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

[Arthmoor]

 question is: does the package works without that specific flag?

I'll let you know when SMKVIper gets back to me on how to find that flag. I don't see anything in the CK labeled as "Be Scene Filler".

[McGuffin]

The is a beSceneFiller boolean value in

Package type: Package Template

Procedure tree->procedure sandbox

Type Sandbox -> value

[Arthmoor]

Yeah, I found it buried there, but thanks

[Deathbydestiny]

This seems to have gotten some media attention

 

History says that Beth can never ignore an issue when that happens

[McGuffin]

well, at least, that flag thing is a good news... somehow....

unless bethesda finds something else, that means the engine is not as borked as supposed... It 's just some kind of debug code that was activated.

[DontBlnkBadWolf]

What about the Unofficial Scrap Patch, who created that POS? It stops people from using scrapping mods.

[Bogdanov89]

It seems that the gods of bethesda are testing your dedication and loyalty to the bug-fixing war.

 

We all hope you do not falter

[Korentin]

What about the Unofficial Scrap Patch, who created that POS? It stops people from using scrapping mods.

 

That's hardly the concern of this team. If the mod doesn't work don't use it.

[Mussieman74]

Arthmoor just read part of th post on the Bethesda chat, is the pipboy glitch connected to the problem also? Th glitch that shows incorrect info about your settlement?

[Arthmoor]

No, it's not. Pipboy bugs are script errors we've been working to squash for 4 versions now

 

Settler issue was strictly the AI pack flag.

[asdffdasdf]

And does it seem that AI pack bug still encompasses the Automatron robots resetting?

 

(I know I asked you about this on Reddit before we knew the stuff about the AI pack; can you tell that particular bug really annoys me?  )

[Mussieman74]

Thanks I'm totally lost now lol but I get the fact that we wait for Bethesda to fix the settler problems ( well I think that's what you are saying lol). Like I say I'm not tech savvy so sorry for asking so many questions.

Thanks for all the help and info and keep up the good work guys.

Ps can I just say a big thanks to all the modders out there for making the game that little bit more interesting and fun!

[fireundubh]

What about the Unofficial Scrap Patch, who created that POS? It stops people from using scrapping mods.

 

I created it, but you should be blaming Bethesda.

 

Any and all scrap recipes added by mods will prevent the respective objects from being selected in workshop mode. That's why the radio scrap recipes were removed from the UFO4P.

 

PC players must use the Place Everywhere plugin for F4SE if they want to select the objects made newly scrappable by the Unofficial Scrap Patch (or any other mod.)

[form_d_k]

I'm curious why I haven't seen this bug. I'm playing on PC and am dozens of hours (if not more) into the game on my survival playthrough. My main settlement (Starlight Drive In) has a very high number of items via the drop-and-scrap method. There are 8 radio beacon-generated settlers & 4 that are recruitable. I'm using a large amount of mods (just under 100). I have all current DLC.

Here are the settlement-specific mods I have enabled: 

• The latest version of UFO4P,
• Better Settlers,
• Don't Call Me Settler,
• Place Everywhere,
• Child Settlers (which for whatever reason isn't spawning a thing),
• OCDecorator
• Gruffydd's Signs of the Times - Gruffydd's Signs of the Times SKE 1.015
• Spring Cleaning
• Some adds that only add workshop items but nothing heavy-duty.

The settlers definitely remain persistent. I do notice that when I approach a settlement, there is a lengthy delay (~5-10 seconds) where the game freezes. After this time, settlement assets begin loading in. I assume this is due to some mod's script acting up.

 

Any ideas why this issue isn't manifesting itself here?

[Arthmoor]

As I posted on your Reddit thread, probably because SMKVIper identified the cause, told us what to avoid for now, we removed the offending AI pack, and UFO4P 1.0.4c is no longer able to cause the problem that was initially discovered.

 

The underlying "old code" we tripped over is still there, so other people could accidentally unearth it too. It's not that likely because most people won't have a need for making AI pack templates, but that doesn't mean there isn't some other hidden pathway to triggering it.

[Jebbalon]

So, my interpretation of the "Be Scene Filler" flag is that if a quest scene needs a group of random settlers or townspeople to come running over to hear a speech then as they are generated by the game they will reset their looks and clothing then attend the event. Thus allowing a random crowd of spectators.

 

This is probably what's used in the Mayor's speech in Diamond City (over by the green wall) after you meet him at the gate with Piper.

 

The UFO4P inadvertently enabled this on a package that caused all settlers to repeatedly trigger that function causing the script overload and stuttering.

 

Does that interpretation sound plausible?

 

By the way... I've been going around and killing affected settlers. This works pretty much right away. The stuttering will start as I approach a settlement with around 18 members. Then I use ~ tdetect so I don't get in trouble with anti-culling rebel types. After getting rid of about half the population I'll notice much better performance. Before I leave, I make sure the radio beacon is running and let the new herd of cattle wander into the web    muahah

[Arthmoor]

I'm not sure precisely what the flag is used for. Since the FO4 CK wiki is badly lacking in basic documentation it's very hard to know the specifics of stuff this deeply buried. Your interpretation sounds about as reasonable as any other.

 

There are vanilla packages where the flag has been set so who knows. dAb ran across one in a vanilla random encounter, so it seems logical to assume it's used in situations like that. It may even be that it sticks to the save data because it's intended to only ever be used on temporary actors like those initiated for random scenes who get deleted afterward.

 

Settlers are generated, but for all intents, once they are they're permanent. Likely why this situation never came up before we accidentally unleashed it.

[McGuffin]

I got a small discussion with the guy from Don't call me settler, and I ran some tests on my own 

I am afraid he is right:

Adding an arg even at the end of the args list actually break the call from another script, because papyrus need to match the right number of args when compiled.

This is why there are issues with settlers beacon right now all over the place.

 

So i guess it would be a good move to completely revert back the change made to the public functions in the workshopParentScript 

Is that (bool Bramhin=false) arg really needed? if yes why?

[Arthmoor]

That's really REALLY poor design then, and doesn't explain why I'm not seeing these issues in my own game considering I'm using the UFO4P myself and see no errors of any sort being thrown for recruitment beacons.

 

This is also a step backward from Skyrim since you could do this without tripping up anything in existing scripts. No idea why they'd change that.

 

The bBrahmin is needed because the public function didn't take it into consideration when passing it through and some instances of it being used were causing new Brahmins to end up with synth components and/or weapons in their inventories that did not belong there.

 

If this really has to be fixed then I guess a crude variable toggle can be set up and then any instances where this thing gets called can just set the variable as needed, call the function, then set it back again.

[chem]

I got a small discussion with the guy from Don't call me settler, and I ran some tests on my own 

I am afraid he is right:

Adding an arg even at the end of the args list actually break the call from another script, because papyrus need to match the right number of args when compiled.

This is why there are issues with settlers beacon right now all over the place.

 

So i guess it would be a good move to completely revert back the change made to the public functions in the workshopParentScript 

Is that (bool Bramhin=false) arg really needed? if yes why?

 

That's really good information to know!  I bet the UFO4P team finds an appropriate workaround.

[McGuffin]

The thing is, if a function is changed and called *in the same script* this isnt an issue, because the whole script is recompiled, of course, but in that case the issue occurs because the function is called from outside.

But here it is, I just made a simple esp with 2 scripts calling each other, and if I add 1 arg without recompiling both scripts, the function call is broken. Of course you could also recompile everything, but mods will be broken anyway unless they offer both versions for and without ufo4p, so this is a bit of a nightmare.

 

 

Also, when i say there are issue with beacon, I mean mostly for people who are using mods that call those functions, (and maybe you have some scripts on loose file that have been recompiled that preserve you from those errors, i don't know... just digging )

 

I am not sure this limitation was there in skyrim, however.

 

 

Edit: just to be clear: you can still call a function with a partial number of args in your source, the compiler will fill the missing args by nil/default value as it always did. But if both "cross-scripts" don't match while compiled, then the error throws up.

 

(i hope I am clear)

[Arthmoor]

That's the thing though. I know plenty of people who did exactly what we did here and tacked new args onto the ends of existing functions. Absolutely no problem with scripts that existed before that calling to those new versions.

 

Plus, as I said, my own FO4 Papyrus log does not throw errors of any sort about this and my beacons are working properly. Which means even if I go in and undo the extra argument change I'm never going to know if it was actually broken to start with because for me it will still be working.

[McGuffin]

but are they calling the function inside the same script? if yes, this is working. and until now I would have think this was working in every cases.

 

Now that I am thinking of, this is the first time I encounter that situation.

 

But it's easy to test for yourself: make a simple quest, and 2 scripts,

1 quest script that contains a small public function with a debug notification

1 script  that call this function (can be a stage fragment or whatever)

compile both

observe the notification in game

now add an arg to the public  function, and only recompile this script. (and not the other one)

 

This won't work anymore

[Sclerocephalus]

Have told you before that this would happen, and posted here that it happened indeed:

http://www.afkmods.com/index.php?/topic/4425-relzwipz-unofficial-fallout-4-patch-ufo4p/page-14

 

The latter post also explains why you may not be seeing any errors, but I'll explain it again:

 

What has been termed 'radio beacon recruitment' by modders does actually refer to two very different processes. In both cases, recruitment only works when a radio beacon is installed at a settlement, but the calls to create those settlers come from different scripts:

(1) The daily update function on workshop script will check for each workshop on every game day whether a beacon is installed. if true and the maximum population limit is not yet reached, it will decide on a random chance basis whether to create a new settler or not. If a settler is created, it calls the CreateActorPUBLIC function on WorkshopParentScript. This still works without any problems.

(2) When you clear a settlement and install a beacon, you will immediately get 1-3 settlers for free (always one, a second one at a 40% chance and a third one at a 20% chance). Those settlers are created by calling the CreateActorPUBLIC function from WorkshopRadioBeaconRecruitScript, and this has stopped working. To test it, clear a location, install a beacon and yoo will get errors on the log for sure (with no settlers showing up, btw).

 

A third process of creating new settlers by the workshop system has stopped working too, for the very same reason:

(3) Minutemen quests in which people at one settlement (the one Preston will send you to) ask you to clear another location. When you have cleared that location and report back to the settlers at the first location, the game will create two settlers for free without having installed a beacon there. In this case, the call of the CreateActorPUBLIC function comes from QF_MinRecruit05_0015F03F.

 

Solution is very simple: just recompile the following scripts (no need to make any modifications to them, just recompile them):

- QF_MinRecruit05_0015F03F

- WorkshopRadioBeaconRecruitScript

- TestWorkshopNPCSpawnerScript

 

The third script on this list is not used by the game, but it provides an easy solution to modders for creating new settlers: That script is attached to an intercom object (not used in the base game either) that can be placed at a workshop and will spawn a settler upon activation. Unlike console spawned settlers, those settlers will be properly registered at the respective workshop.

[Jebbalon]

Two things:

 

1 - I posted a link to here in the Don't Call Me Settlers mod comments. 

 

2 - Will there need to be similar adjustments / recompile of the scripts in VaultTec Workshop DLC ?