Is there a way to edit WotC in FO4edit/CK to reduce the number of persistent actors?

[RolazLaguna]

2 hours ago, d4em said:

Unless the mod comes with source scripts (most don't), you can't edit them.

.pex files have been compiled, which means the human-written code is run through a program to translate it into something the computer can understand. To edit scripts, you need the .psc files

You can try using Champollion (https://www.nexusmods.com/fallout4/mods/3742)  to decompile the pex. I have done that to learn from others, but never to use the decompiled script: you need to check if the decompilation has worked fine and sometimes re-write some stuff as functions might be decompiled as events and so on. But don't listen to me, read the documentation and comments on the champollion page.

[NeinGaming]

Ohh I had no idea there are newer versions than the one on nexus!

https://github.com/Orvid/Champollion/releases

But even that old version is near perfect I think. It initializes floats as integers, sometimes puts a # where a : should be, and breaks some event registrations by adding "as scriptobject". hopefully newer versions don't, but it's easy to fix either way, once you know what the issue is.

Edited May 2 by NeinGaming

[NeinGaming]

Okay, so the new version still appends "as ScriptObject", e.g.

Self.RegisterForRemoteEvent(akTarget as ScriptObject, "OnKill")

I can't for the life of me guess why, but it's easy to spot and fix, just remove "as scriptobject" (the compiler will complain anyway)

But it now no longer puts "float x = 0" when it should be "0.0", that was kinda annoying. It also no longer uses # as a namespace separator -- it used to turn YourModFolder:Subsystem:ScriptName into YourModFolder#Subsystem#ScriptName). That confused the crap out of me, for a long time.

Speaking of, for those who don't use the CK: mods that have their scripts in the root folder (scripts/ that is) can usually be compiled trivially, but in the case of a subfolder structure, I found it easiest to compile the folder. Say a mod has

/scripts/modname/myfirstquest.psc

then the script would be named modname:myfirstquest meaning the first line would be something like

ScriptName modname:myfirstquest Extends Quest

But to compile it, the only way I could get it to work was to put them into a subfolder and compile that, e.g.

source/user/modname/*.psc

and then I point the Papyrus compiler at the user directory. Trying to compile the "modname" directory won't work, nor compiling the individual scripts one by one. At least I could not find a way other than this. I may have explained this badly, but since this utterly stumped me for a loooong time, maybe this can save someone a few, uhh, years...

Another thing, to compile your script, the compiler needs to know at least the function signature, variables and their types of the scripts you're calling. So if you want to use functions from other mod a lot, I recommend making a copy of the vanilla script source folder, and then copying all the script extender scripts (F4SE and mods that add functions via F4SE), as well as all scripts from all the mods you want to reference into it as well, and then use that folder for the -i parameter of the compiler (though you can also add more than one folder if you separate them by a semicolon, that string gets very long very quick if you want to add the path of every script folder of every relevant mod).

edit: even in the Champollion docs it says this

Quote

The Event and Function are not distinguished in the PEX binary, so all Event are decompiled as Function. It doesn't seem to be a problem to recompile correctly the script.

But both the old version I used for years, as well as the current one from github absolutely decompile OnSomeEventOrOther as Events, at least for me?! Maybe there are .pex files where it doesn't, so I guess it's good to keep in the back of your head, but I never ran into one.

Edited May 2 by NeinGaming

[SKKmods]

FALLOUT 4 PERSISTENT OBJECTS

Persistent means that the ObjectReference ID is referenceable when the object is unloaded outside the uGridsToLoad and uExteriorCellBuffer. This can either be a pointer to the ObjectReference or the full object schema is permanently loaded in memory. When Fallout4.exe tries to assign more than ~ 6Gb of RAM it falls over or fails to load.

ESM placed ObjectReferences default to nonpersistent, ESP *may* default to persistent (this is unverified).

ObjectReferences can be forced persistent by:
(a) add to a FormList.
(b) make them a papyrus script property.
(c) put them in a quest reference alias.
(d) make them a LinkedRef parent.

Selecting a object in the console will show if it is persistent via the [P] or [PP] or [EP] suffix.

Using LocRefType keyword is a workaround to be addressable and avoid persistence, BUT the LocRefType keyword must be added in the ESM/ESP at design time so the object is added to the location record. Dynamically adding a LocRefType to a non persistent object in runtime script does not seem to make the object addressable when unloaded.

[Qrsr]

On 5/2/2025 at 5:36 PM, gooboo said:

since the enemies usually just walk/run off of the buildings

Not directly BGSs fault, its probably because of missing Navmesh execution.

[NeinGaming]

I made Object Counter write the form ID and display name of persistent actors into a file (via papyrus common library), and that is very interesting. Just sorting alphabetically you can sort of divide into into chunks of vanilla/DLC, various mods, and script placed actors. For me, the script placed actors only like 3% of the total, while a major contribution are all those "raider/gunner/settler" face variety mods. The template NPC are all persistent, maybe because they're in leveled lists that are referenced by live actors, I have no idea. The other big chunk for me are placed spawns from mods that I naively had thought would not be persistent, since they're at least added to cells as temporary.

Also, I have Maria Summerset twice in that save (nobody else I spotted), and I haven't even been to Vault 81? But that's neither here nor there ^^

Edited May 4 by NeinGaming

[PJMail]

Now that is very interesting! I wonder what in those "variety" mods is causing them to become persistent? No doubt one of SKK's listed reasons, but I have no access to my modding environment so can't investigate. Hopefully someone does...

[DieFeM]

On 5/2/2025 at 3:21 PM, NeinGaming said:

when I experimented with grenades that spawn actors directly, I had to set the "placed object is persistent" flag on the explosion or they would disappear as soon as I entered or left an interior

In first place, sorry for the late response. 

I didn't experimented with this, but makes sense that whatever is spawned by a grenade is meant to be despawned on unload by default, therefore it has this flag, but generally speaking, the despawn or reset of actor references needs to be configured, for example the reset of actor references in dungeons is usually managed by the Encounter Zone record of the location (never reset flag), on the other hand the despawn of corpses that don't need to respawn again is usually controlled by a enable marker of which enable state is switched by a script.

Edited May 10 by DieFeM

[NeinGaming]

10 hours ago, DieFeM said:

makes sense that whatever is spawned by a grenade is meant to be despawned on unload by default, therefore it has this flag

Kinda figured it they do the equivalent to a simple PlaceAtMe (which has a persistence parameter) and not PlaceActorAtMe (which doesn't, and has Encounter Zone parameters). I guess it's a way to place non-persistent acors via script: don't place them directly, place an explosion that spawns them. (I haven't tested this tho)

I started making something log all the things. And I really mean all the things, anything I can think of (which is the bottleneck, I have no clue what to log). But just to give you an idea how *bad* this is getting, here's the headers of the CSV it generates haha

Spoiler

walltime,level,worldspace,location,x,y,z,DeadActorsLoadedDisabled,DeadActorsLoadedEnabled,DeadActorsUnloadedDisabled,DeadActorsUnloadedEnabled,FloraLoadedEnabled,LightsLoadedDisabled,LightsLoadedEnabled,LiveActorsLoadedDisabled,LiveActorsLoadedEnabled,LiveActorsUnloadedDisabled,LiveActorsUnloadedEnabled,StaticLoadedEnabled,StaticLoadedDisabled,MoveableStaticLoadedEnabled,MoveableStaticLoadedDisabled,Clone_LiveActorsUnloadedEnabled,Clone_LiveActorsUnloadedDisabled,Clone_LiveActorsLoadedEnabled,Clone_LiveActorsLoadedDisabled,Clone_DeadActorsUnloadedEnabled,Clone_DeadActorsUnloadedDisabled,Clone_DeadActorsLoadedEnabled,Clone_DeadActorsLoadedDisabled,Cloned_LiveActorsUnloadedEnabled,Cloned_LiveActorsUnloadedDisabled,Cloned_LiveActorsLoadedEnabled,Cloned_LiveActorsLoadedDisabled,Cloned_DeadActorsUnloadedEnabled,Cloned_DeadActorsUnloadedDisabled,Cloned_DeadActorsLoadedEnabled,Cloned_DeadActorsLoadedDisabled,HighActors,GameDaysPassed,TimeScale,REGlobalCooldown,base_Strength,Strength,base_Perception,Perception,base_Endurance,Endurance,base_Charisma,Charisma,base_Intelligence,Intelligence,base_Agility,Agility,base_Luck,Luck,base_experience,experience,base_Health,Health,base_Rads,Rads,base_ActionPoints,ActionPoints,base_SpeedMult,SpeedMult,base_CarryWeight,CarryWeight,base_DamageResist,DamageResist,base_EnergyResist,EnergyResist,base_PoisonResist,PoisonResist,base_RadResistIngestion,RadResistIngestion,base_RadResistExposure,RadResistExposure,base_ElectricResist,ElectricResist,base_FireResist,FireResist,base_FrostResist,FrostResist

I see if I can get it released this soon, exactly because I have no clue how to make this properly useful. But since it's for advanced users anyway, (more a little tool for advanced to find out what they might wanna log, than something useful/sensible out of the box), and it will take me a while to make a pic of a BloatFly with a detective hat or whatever, and since permissions are going to be completely open also, I figured I might as well attach what I got so far here for anyone interested to play around with.

to start logging, here's the console commands:

    cqf BloatSpy_Quick StartLogging "quick" 30.0
    cqf BloatSpy_Quick StopLogging
    cqf BloatSpy_Everything StartLogging "everything" 300.0
    cqf BloatSpy_Everything StopLogging

The "Quick" quest is stuff that doesn't cause a short freeze (at least on my machine, but it's old, so), the "Everything" quest is that plus stuff that does cause a short freeze (namely counting unloaded things). The parameter in quotes is the filename to use, the number after that is the logging interval in seconds.

The StartLogging command makes a new file from scratch (with column names), use it after you changed the form lists which contain the globals/actorvalues/finder quests a logging quest uses.

It writes everything into the Fallout 4 folder, haven't even looked into how to write it elsewhere, sorry. It also writes a file with the suffix ".last" which is basically just the latest logged line, the idea is that you could make yourself a kind of dashboard to display on a web page on a second monitor to just keep track of current values 

As I said, this isn't very fleshed or thought out at all yet, but since the basic mechanism of adding things to log and the editor ID being used as column names makes it quite simple to use and extend already, here goes nothing, have fun experimenting, or don't, it's all good

 

edit: forgot to mention this needs Garden of Eden as well as Papyrus Common Library, and the _MoreEnemies.esp just adds the finder quests to log things cloned with the mod of the same name.

BloatSpy.7z

Edited May 10 by NeinGaming