Workshop Items Persistence

[kinggath]

 

Also to check if the object is summonable is not enough to go to another cell. It only unloads 3d. I have an object that is registered for hit event. If I go to another cell (i.e.Vault) I still can prid it. But if I make a save in the Vault, quit the game and load the save, I can`t prid it anymore.

 

So with the settlers and workshop scripted objects I can always prid them even after save/quit/reload. Does that mean they are persistent? Also, do things like actor values reset if you drop persistence on an item?

 

A lot of the information I'm finding is not just on the wiki but also from old skyrim posts, which obviously things have changed (by how much is unclear). In the skyrim explanations I'm finding, the difference between persistent and unpersistent is that a persistent ref basically keeps the ObjectReference around, whereas a non-peristent ref will just keep the coordinates/rotation data and the form ID and then when it's loaded a new ObjectReference is created there and then destroyed again on Unload. How that affects attached scripts, script changed actor values, and keywords - I have no idea. Since most of this information comes from Skyrim findings - I'm hoping someone can clarify how much of this is still accurate for FO4.

[kitcat81]

 

 

Also to check if the object is summonable is not enough to go to another cell. It only unloads 3d. I have an object that is registered for hit event. If I go to another cell (i.e.Vault) I still can prid it. But if I make a save in the Vault, quit the game and load the save, I can`t prid it anymore.

 

So with the settlers and workshop scripted objects I can always prid them even after save/quit/reload. Does that mean they are persistent? Also, do things like actor values reset if you drop persistence on an item?

 

A lot of the information I'm finding is not just on the wiki but also from old skyrim posts, which obviously things have changed (by how much is unclear). In the skyrim explanations I'm finding, the difference between persistent and unpersistent is that a persistent ref basically keeps the ObjectReference around, whereas a non-peristent ref will just keep the coordinates/rotation data and the form ID and then when it's loaded a new ObjectReference is created there and then destroyed again on Unload. How that affects attached scripts, script changed actor values, and keywords - I have no idea. Since most of this information comes from Skyrim findings - I'm hoping someone can clarify how much of this is still accurate for FO4

I doubt anyone can know this for sure. I think they are temporary persistent. While assigned to the settlement( they get alias applied to them when they are assigned). If you spawn a settler by placeatme, the settler will have no [pp] flag. They get this flag when assigned to the settlement. Workshop scripts handle all the stuff for settlements. As far as I understand settlements do not reset in a usual way. Different workshop scripts reset some settlement things, but settlers do not reset, resetting them would end up in losing all inventory and changing their look or even gender. This never happened in my game. Other locations reset and actors like raiders or supermutants reset. That command "forcepersistent" if used on persistent refs will return "some ref no longer forced to be persistent " and vice versa fs used on non persistent refs. Maybe you can use it check what is persistent.

[niston]

This is an old thread, but: Persistence in this context means that a specific instance of an object (with a given ID) is persisted into the save and then restored to memory on load (the ID won't change). With non-persistent objects, only the base type is stored and a new specific instance (with a new ID) is created on each load.

[Wolfpack49]

Hey, I know this thread is old,and good to know about temporary vs. persistent objects -- I guess one question I have is, why practically would you set something as temporary vs persisent? Would it affect things like Dyndolod or other in-game rendering, or is it simply how the object is saved?

[niston]

Persistent objects may unload their 3d, but the data structure describing the object itself will always be loaded in memory. So they still consume some resources, all the time, even when they are not near the player. But you can create them and not worry about them. If the player leaves the cell they reside in, and then comes back later, they will still be there.

 

A non-persistent object, on the other hand, will cease to exist on cell unload. It's getting purged and is from there on no longer available or accessible or simply - existent. If you spawned such objects from script for, say, decorative purposes - your script would have to respawn them all when the player returns to the cell, or they would be gone.

 

As you can imagine, it would be a very bad thing to create persistent objects while not keeping track of them meticulously. They never disappear and remain in every save unless explicitly deleted.

 

Another use case are NPCs. If you have random background NPCs (they fill the scene but have no special purpose otherwise), those would be good candidates to have them non-persistent. Because you can generate them new each time the player visits, and it won't matter. A character NPC however, possibly with a name, might be a candidate for persistence. Incidentally, this is also what the Game does. The random supermutant is not persistent, it's in fact being generated from a template, so is technically a new character/object each time you visit. Paladin Danse however exists all the time, stuffed into a "holding cell" until his appearance on the world stage. It is a persistent NPC and always the same character/object, every time you visit.

[SKKmods]

The MASSIVE pro for persistent objects is that they can be FOUND when outside the active uGridsToLoad around the player. If they are non-persistent and unloaded they can not be found and managerd by any means at all (story manager alias fills, linkedreferences ... nothing).

 

Example: find and map mark all base game waterpumps placed in the commonwealth. Cant be done as most base game/ESM objects are non persistent (Fallout4.esm only has 62,700 persistent references). This is the impact of non persistence on workshop resources.

 

The overhead of an object being persistent is 14 bytes of save file, and there is apparently a hard limit of 1,048,576 persistent + temporary object references loaded in memory.

 

The DANGER is that scripts attached to any object run regardless of loaded state, so that includes unloaded non persistent objects. So badly constructed loops, timers and wait scripts can to build up in the save game chowing up the ever limited script time slices. And they will be rather difficult to find and clean up once published.

[Zorkaz]

Just saw this sentence

"They never disappear and remain in every save unless explicitly deleted.". With that do you mean that they are still there if the mod's been deactivated and the only solution is a ".delete()" line?

[niston]

No.

If you yank the mod from the load order, any objects defined by plugin records in that mod will vanish from the game world (with exceptions pertaining to master dependencies). Which is also the reason why u get scrap crash after removing mods with powered objects in them that you had wired up in your base. The sentence was meant with respect to stuff spawned in by script. If you spawn in persistent stuff, you'll need to clean up on your own and the engine wont de-spawn these objects just because player has left the cell.

 

Scripts attached to Objects that have been purged by mod removal may however linger on and even continue to execute, for various reasons. Scary enough, this is even true if you actually removed the mod BA2 (with the script PEXes in it) or any loose files completely from your system, because a running Papyrus loop gets baked into your save. This peculiarity may lead to utter savegame destruction, if coder does not pay attention. It's perfectly possible to start enough unbound (running forever with no viable exit condition) papyrus loops to utterly monopolize available Papyrus timeslices, so that all the other scripts in the game start lagging like hell and/or fail execution completely. Once started and baked into a save, it's usually not possible to kill such unbound loops (resaver works sometimes, but mostly just results in CTD when loading the edited save). The only thing worse that may happen is, if some script starts such unbound loops multiple times, like whenever you visit a particular cell or something.

 

Automatron DLC has such an insidious bug, which may be triggered when you take the back door entrance (holotape voice samples method) into the Mechanist's Lair. If you get the bug, then a new, unbound loop will start each time you visit the Mechanist's Lair, because the loop's exit condition is tied to some data on a remote object that becomes unavailable and the exit condition thus may never become true. The deadly poison is not noticeable at first and Papyrus engine works hard to distribute timeslices to all the running scripts. But it'll get baked into your saves. And after you've been visiting the ML a whole bunch of times, you'll have a whole bunch of unbound loops in your game. Papyrus engine eventually runs out of timeslices to distribute, everything script related (workshop updates, settler assignment, quest scripts, everything....) starts lagging like mad, it gets worse each time you visit the ML which is kind of a big deal because the ML is your early-game main base and the last known good save is 12+ hours back. Luckily, there is a fix for this hideous problem in the unofficial patch.

 

Papyrus offers the IsBoundGameObjectAvailable() function, to see if a script is still attached to something. It can be used to prevent the kind of disaster outlined above in the first place.

[SKKmods]

Seperate to object persistence, for persistent scripts imagine building a thing and an attached script starts running a While loop, Wait state or Timer and then the object is destroyed. Like on mod added harvestable plants for regrowth. Even with an IsBoundGameObjectAvailable() test on return/completion there are still runaway unbound scripts hoovering up resource.

[niston]

That's one thing were resaver can help quite consistently: Identifying the culprits.