SKKmods

That method is in Scavver faction RedRocket workshops to scrap specific base game stuff only in those workshops. Look at SKK_RRBaseGameScrapList_co [COBJ:180044F0] in SKKRedRocketWorkshopsFaction.esp Also in a couple of my mods that open up Covenant to enable [ scrapall ] on statics there.

Not that I have found. so created a conditional function:

I apply a unique keyword to the locations I want specific scrap recipes to work and then condition LocationHasKeyword on it.

Not EZ but if you fire up a finder quest with a RefCollectionAlias conditional fill on known persistent objects or containers you can get ~ 200 to script placing in or at. Examples: ObjectType Container & LocRefType BOSSChest = 200 boss chests ObjectType Container & Haskeyword WorkshopKeyword = 30 workshops ObjectType Container & Haskeyword WorkbenchGeneral = 90 assorted workbenches. The difficulty is knowing what placed object types or classes are persistent and their conditional attributes to query. Since most base game placed objects are non persistent, they are not findable without being in the loaded uGrids around the player.

I have had it with disable and enabled references. When you ForceRefTo a base game placed non persistent object and the the Quest UI suggests "hey why not use an AutofillGeneric LocRefType to avoid creating persistence ?" I nope out as thats what causes my unpredictable object resolution. The game can handle 2 million persistent objects so my couple of adds are not going to break that bank.

Its an ongoing issue with non persistent references. Having suffered that unpredictable issue for years I don't trust unloaded nonperistent objects located via LocRefTypes and always ForceRefTo to make 'em persistent if the are non optional for my solution. The logic being that I am doing something to the object for a reason that has beneficial value which can carry the overhead cost of persistence. Philosophy moment: Every technical choice should enjoy a cost/benefit analysis.

When I use the word "persistent" I mean the object can be referenced in memory, or in that language "has an open handle" which many would call a pointer. ALTHOUGH that last line is concerning and confusing "persistent is actually loaded/doing whatever the thing would do". If something is not 3d loaded outside of the loaded uGrids what do thing possibly do apart form updating travel packages over ticks ? They are not 3d rendered (call Equip or Unequip on an unloaded persistent actor) so there is no collision or interaction or dialog or ... so what is the "thing" they would do ?

I don't know what your root issue is, but I can tell you that removing and reinstalling a start game enabled quest based mod or quest with dialog in the same save game will not work. It must always be a clean save that has never seen that quest before.

(1) Placed objects/actors saved by Creation Kit in an ESM format file default to non persistent to reduce memory and processing load when the object is not in the active uGridsToLoad around the player. (2) Placed objects/actors saved by Creation Kit in an ESP format file default to persistent so they are always loaded in memory. Anyone know why ... cui bono ?

A non WorkshopParent registered standalone workshop needs nothing to work with a default build radius of 5K game units. Test that claim with the console [ player.placeatme 000c1aeb ] and see what happens. Altho if there are hostiles nearby use [ cf "WorkshopScript.SetOwnedByPlayer" 1 ] to skip clearing the area. If your scripting the deployment its: Container WorkshopWorkbench = Game.GetFormFromFile(0x000c1aeb, "Fallout4.esm") as Container ObjectReference WorkshopRef = Player.PlaceAtMe(WorkshopWorkbench) (WorkshopRef as WorkshopScript).SetOwnedByPlayer(True) Set PlaceAtMe abForcePersist and abDeleteWhenAble to match your state management and cleanup needs.

Consider the Papyrus script array limit of 127/128 items. I apply that cap to settlers and work objects in my scripts to ensure they will never fall over.

Are these steps what you did ? Menu: View/Layers new PREFIX_DisableForPrecombineLayer (thanks to RedRocketTV for this) Make that layer active, lock all other layers. Right click add any stuff that needs to be excluded from precombine so it works (but is not scrappable) on that layer. (-) minus key to group select in the batch window set Starts Disabled [DO IT] Menu: World/PrecombineGeometry for each modified cell (B in the render window shows cell boundaries). Menu: Visibility/Generate Precombined Visibility for each modified cell. (-) minus key to group select in the batch window set Starts Disabled checkbox clear [DO IT]

Terminal text replacement is not an EZ thing to start learning on without a solid understanding of the form/object/script relationships. Attach script direct to the terminal to update when the player enters the terminal. If the values are dynamic and change WHILST the player is in the terminal, the terminal fragment or OnTerminalMenuItemRun needs to call the functions: Event OnTerminalMenuEnter(TerminalMenu akTerminalBase, ObjectReference akTerminalRef) ; this is not triggered by an activator with no animation. Debug.Trace("OnTerminalMenuEnter " + akTerminalBase + " " + akTerminalRef) Float fValueToSet = ; assign Global or Object.ActorValue Self.AddTextReplacementValue(asTokenLabel = "TheTokenTextValue", aValue = fValueToSet) EndEvent If you need a template look at SKK Outpost Attack Manager which dynamically updates names and values. Yes its horribly complicated.

If you put a unique condition on the dialog and it works for your actors you do not need to test further. Examples: If your actors are unique lvActor forms condition GetIsID that form. Add your actors to a quest alias and condition GetIsAliasRef that Alias. Add a unique keyword to your actors and condition HasKeyword. Add your actors to a unique faction and condition GetInFaction. & many other methods. Since no other actors can be in your quest alias, keyword, faction or whatever there is no way your dialog can infect their stack.

Other mods do not "conflict" to use your dialog. You need to constrain your dialog with conditions, otherwise it will "infect" other actors dialog stacks the voice type(s) apply to. OR if your dialog quest has a higher priority than the dialog quests it is overriding try a lower priority ... but this is not fullproof. TL:DR: its a you issue.