SKKmods

Hey Niston your curiosity and innovation will be missed. Thanks for all you brought to us and good luck with your onward ventures.

DisablePlayerFiring() is not a native function in the 3 installs of Fallout4 CreationKit I have. Using an InputEnableLayer to disable combat is in both Fallout4 and Starfield https://falloutck.uesp.net/wiki/InputEnableLayer_Script look at EnableFighting() or DisablePlayerControls(abFighting)

I spent a lot of time tracking loaded and unloaded actor travel packages. When unloaded they mostly straight line to the destination. When loaded they can take indirect paths, get stuck and do all sorts of odd things. When transitioning from unloaded to loaded because the player intersects their path they often teleport to the edge of the loaded area (qv settlement attacks spawning inside walls). If their travel target object is inaccessible they can teleport close to it (qv settlement attacks spawning inside walls). & other hilarity I forget. Having a bailout or force complete watchdog timer for travelling AI is the smart solution. If tracking multiple groups just store their start gametime and distance/eta as AVs on the actor.

If ((ThisActor as Actor).GetActorBase().IsUnique() == TRUE) (pWorkshopParent as WorkshopParentScript).AddPermanentActorToWorkshopPlayerChoice((ThisActor as Actor), bWaitForActorToBeAdded = true) Else Location ThisLocation = (pWorkshopParent as WorkshopParentScript).AddActorToWorkshopPlayerChoice(actorToAssign = ThisActor, bWaitForActorToBeAdded = true, bPermanentActor = false) Endif

I have found that if actors are not 3d loaded after the moveto it can affect AI packages establishing even after forcing EvaluatePackage() You may need to add an OnLoad() EvaluatePackage() to their collection to work around that.

Place a WorkshopCaravanHitchingPost or place any marker and add location ref type CaravanDestinationRefType

Again for not power grid (generating or transmitting) objects, else you will generate SCRAP CRASH conditions: thisWorkshopRef.StoreInWorkshop(thisObjectRef.GetBaseObject(), aiCount = 1) ; this does not trigger event OnWorkshopObjectDestroyed() thisObjectRef.SetLinkedRef(none,pWorkshopItemKeyword) thisObjectRef.Disable() thisObjectRef.Delete()

If you mean placing them then yes as long as they are not power grid (generating or transmitting) objects. After PlaceAtMe call thisObjectRef.SetLinkedRef(thisWorkshopRef, pWorkshopItemKeyword) then if it is a resource object call (pWorkshopParent as WorkshopParentScript).BuildObjectPUBLIC(thisObjectRef, thisWorkshopRef)

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 ?