SKKmods

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.

No problem, several folks figured out that method independently in their solutions.

(3) With fast travel fee enabled, if the player uses an internal/external load door within 1 second of closing the PipBoy that will be detected as fast travel and charged. Slow down.

If there are multiple matches on any condition fill whether its LocRefType, Keyword, GetisID or whatever a ReferenceAlias will just fill the first one. If you cant guarantee one result, redesign to use a RefCollectionAlias and set Initial fill to 0 to collect 'em all. If you totally want to avoid persistence redesign to start/stop a finder quest with a dynamic search/fill every Player.OnLocationChange or Player.OnDistanceGreaterThan a moveable datum object and put the found results in the persistent owning quest to mark.

MQ101 is hard coded into Fallout4.exe. You could decompile Fallout4.exe to find the offset and inject your own code, or just hack MQ101 quest/script to do what you want.

The quest will only be able to fill aliases with ObjectReferences if they are either: (a) Non persistent but in the active uGridsToLoad around the player when the quest alias tries to fill, or (b) Has a LocationRefType keyword associated with a Location and the Alias is configured to use it, or (c) Is persistent. If (a) is not guaranteed, you have not used (b) and you remove the persistent flag from the ObjectReference the alias will fail to fil. If its not an optional alias the quest will fail to start.

@LarannKiar full defect report here (submitted to BSG via the VC programme, zero followup). https://www.nexusmods.com/starfield/articles/338