SKKmods

To see how the base game does it look at the VFT quest VFTScene which sequences a lot of different AI packages that have nothing at all to do with dialog.

Either extend the scene to run until the molerats are killed OR put a actor value condition on the package and set it on the actor thisActor.SetValue(myTravelPackageActive, 1) followed by thisActor.EvaluatePackage()

There is no native function available to Papyrus. You would need an SFSE based DLL to peek that data out.

The complexity of AI updates for travel and combat seem to be two DIFFERENT limits. The cases I have observed that have different results based on inferred complexity of behaviour tree and pathing calculations: A savegame will not load with > 300 actors in the loaded area (proven fact). NPC in the loaded area travel to a fixed target: lots ~128 ? NPC in the loaded area follow a moving target: not many ~32 ? NPC in the loaded area in combat with NPC: lots ~ 128 ? NPC in the loaded area in combat with player: less ~ 32 ? "In the uGridsToLoad loaded area" makes a massive difference, unloaded off screen its a simple straight line time/speed/distance calculation per tick no navmesh no rendering no behaviour tree evaluation.

[ setgs iNumberActorsInCombatPlayer ] defaults to 20 although I have watched 32 NPCs fighting another 32NPCs so not convinced thats the full story.

The Follow Player AI package is super expensive in resources having to constantly recalculate navmesh pathing to a dynamic moving target (the player). There is a limit to how many actors will actually update their Follow Player AI package before they just stand idle in place. I believe it is around 32 or 64 but have misplaced the testing notes and test harness when I profiled it for FeralNights back in 2021 Anyone else tested that and not lost their notes ?

The base game recruitment beacon implementation is a buggers muddle that would probably require hacks to WorkshopParentScript to emulate. It is far easier to write your own from scratch. Just one script attached to the beacon object would do the job: When switched on start a GameTime timer. When timer dings spawn actors, restart timer. When switched off stop GameTime timer. OnWorkshopObjectDestroyed stop GameTime timer. For the simple timer based template look at SKK_476WorkshopSpawnRadioScript For the more challenging logic of power state + switch state look at SKK_MWARadioBeaconScript

I wish I had bothered to learn C so I could poke the exe with IDA Memo to me in 1990: read that "Learn C Now" book you bought and will still have on the damn "to read" shelf in 2025.

Perfect-O Did you happen to already have this profiled or did you just take a quick peek at the code ?

I have a function that finds and removes local CK placed beds in a workshop area to a remote holding cell. Because they are generally unassignable in workshop mode and just disabling them does not actually do the full job as the workshop scripts keep finding and assigning them. Works for all placed beds (Abernathy, Tenpines & etc) but gets that error on 0013B35A which is a bed in Homeplate. That reference can be moved around in workshop mode and console [ 0013B35A.MoveTo 22050d77 ] the HoldingMarkerRef works fine. What would cause Papyrus MoveTo to fail with "cannot be moved " on valid source and destination ObjectReferences ?

With around half a million lines of Papyrus created in Notepad++ published and supported for 5 million unique PC and Xbox users, I can assure you development issues are 99.9% OPERATOR ERROR.

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.