Making objects persistent - so what ?

[SKKmods]

I remember waaaaay back when I started modding (probably last Thursday) there was much advice that using ObjectReference properties in script is bad because it makes them persistent.

 

I use form lists of ObjectReferences to allow my mods to dynamically alter the world without changing the base game database objects, thousands of them of them for my 4-76 open world. I also tend to manage objects and actors in RefCollectionAliases so I can dynamically attach OnLoad() and OnDeath() type event scripts to them. All of that makes them persistent (as seen in xEdit for the script property and formlist stuff).

 

So what is the *ACTUAL* impact of holding ObjectReferences persistent is on the game platform and its resource budget ? ... Anyone ... anyone ?

 

Given the thread and memory measurement tools are scrub, I have been estimating the overhead just looking at the size of the savegame as a running VM snapshot. Average values in Kilobytes from 10 runs:

 

(1) Take a clean vault exit and save baseline 3,606Kb

 

(2) Move to the top left hand Wliderness corner of the map that is 20K units from the vault exit well outside the 10K uGridsToLoad. Save baseline 3,570Kb (less loaded objects ?)

 

(3) Move back to the vault exit. Save 3,606kb to validate baseline.

 

(4) Generate 4096 randomly placed Workshop_WoodCrate(s) in a RefCollectionAlias takes 485 seconds. Save 3,949Kb so each loaded persistent ObjectReference is 86 bytes. (Create nonpersistent same size)

 

(5) Move to the top left hand Wliderness corner, test 3D is unloaded on boxes. Save 3,892Kb, so each unloaded persistent ObjectReference is 81 bytes.

 

(6) Make the 4096 remote objects unpersistent by removing from the RefColectionAlias. Save 3,859Kb so each unpersistent unloaded ObjectReference is 72 bytes.

 

(7) Delete the 4096 remote objects . Save 3,570Kb which is the original wilderness baseline. Demonstrates 100% cleanup.

 

Summary:

Each loaded ObjectReference is 86 bytes

Each unloaded persistent ObjectReference is 81 bytes

Each unloaded non-persistent ObjectReference is 72 bytes

Disable() & Delete() cleans up 100%

 

Spawning crap loads of actors with complex event scripts is nasty, but 14 bytes of memory/storage for persistence ... so what, and why should we care ?

[hereami]

Think, it's more critical for processing load, as the persistence is not relevant to 3dLoaded state, - for scripted object's activity, e.g. running timers, receiving events etc., and for NPC, which possibly keep doing all their "purposeful and intelligent" things in background, while persistent. Suppose, there was good reason for using ApplyToRef technique for Worksop NPC packages, rather than holding'em all inside a live alias collection.

 

Actually, interesting then, if making everything related to buildable manufacturing machinery persistent, will keep the production running even if player leaves the cell/world. Originally, all stops.

 

Hoping the persistence could be a remedy for an annoying armor/weapon enchanting issue, tried to place a mannequin into an alias at runtime (making persistent supposedly), and equipping a VFX ring on him, e.g fire. But still the effect quits working after leaving the cell - as always. So it doesn't seem to keep enchanting alive on NPC, not sure though, if that's a bug or was intentional.

[SKKmods]

Two things are being conflated here:

 

(1) Is3DLoaded() will only be TRUE within the uGridsToLoad radius around the player. When the ObjectReference is outside of the uGridsToLoad then 3D will unload and the object stops receiving any external events. Yes attached scripts can be called and will still run their loops, but they don't receive any external events. Exactly why Is3DLoaded() can be an important test in non event driven loops to help control the buildup of script lag.

 

(2) Running scripts have nothing to do with the attached ObjectReference persistence, consider that a quest is never "loaded". An object with an attached script that is spawned (abForcePersist = false) will still run its loops and timers even when 3D is unloaded and outside the uGridsToLoad radius.

 

There is a consideration that script OnInt() can fire for referenced persistent ObjectReferences when the game starts, the classic telltale from elevator control scripts is: "model was not loaded when we tried to play an animation on it (most likely you're calling for animations in OnInit.)"