Workshop Items Persistence

[steve40]

I think you guys are misinterpreting what the PP (Papyrus Placed) flag means. it simply means that the reference has been placed using a script as opposed to being placed using the editor. The main distinction here is that you can use the papyrus Delete() command to delete Papyrus Placed references, while it is impossible to delete editor placed references (except by deleting them in the Editor itself). It has nothing to do with persistence, which is mainly whether the object unloads its 3D when you leave the area.

 

Edit: so some of your stairs and stuff had the PP flag simply because they were built using the workshop (i.e. scripted) rather than placed by the CK editor (REFID begins with FF).

 

Edit2: I don't remember if EP means "Editor Placed" or if it simply used to mark essential actors (I think it can be both). I think non-essential actors can be marked as EP if they have a quest alias pointing at them that is marked as Essential (even though the Actor itself isn't essential).

 

Edit3: [P] by itself usually means persistent.

Edited January 10, 2017 by steve40

[kitcat81]

I think you guys are misinterpreting what the PP (Papyrus Placed) flag means. it simply means that the reference has been placed using a script as opposed to being placed using the editor. The main distinction here is that you can use the papyrus Delete() command to delete Papyrus Placed references, while it is impossible to delete editor placed references (except by deleting them in the Editor itself). It has nothing to do with persistence, which is mainly whether the object unloads its 3D when you leave the area.

 

Edit: so some of your stairs and stuff had the PP flag simply because they were built using the workshop (i.e. scripted) rather than placed by the CK editor (REFID begins with FF).

 

Edit2: I don't remember if EP means "Editor Placed" or if it simply used to mark essential actors (I think it can be both). I think non-essential actors can be marked as EP if they have a quest alias pointing at them that is marked as Essential (even though the Actor itself isn't essential).

 

Edit3: [P] by itself usually means persistent.

Great thanks for the info, It makes more sence now. I remember there was a console command to check if 3d is loaded so may be it can be used to check persistence. Though the EP flag is still misterious. Almost all my "esm" settlers have EP flag (may be even all, hard to check now because I have many dlc settlers ). But they are 100% non essential. They are all "protected." Can be killed accidently killed by me.

[steve40]

To check persistence, open console, select a reference or use prid, then type DPPI. it will dump all the persistence info (what script properties etc are making your object persistent) into your papyrus log.

 

Edit: it's quite possible that EP means "essential or protected".

Edited January 11, 2017 by steve40

[kinggath]

P standing for Placed makes a lot more sense.

 

I'm still struggling with understanding what is actually persisted and what that actually means. I was under the impression that persistence was what allowed an item to maintain a permanent ID so that it could be referenced from anywhere.

 

If so, then all settlers, and any workshop objects that are actors (turrets) or work objects (anything that has worker assignment - crops, vendor stalls, guard posts, etc) appear to be persistent - at least in my tests. I can jot down the form ID of any of those things and access it from anywhere even after hours of playing.

 

I've been doing a lot of testing and those things definitely appear to have permanent IDs, while other things like power connectors and decorations do not. If persistence is not causing this, could someone explain to me what is?

[kitcat81]

To check persistence, open console, select a reference or use prid, then type DPPI. it will dump all the persistence info (what script properties etc are making your object persistent) into your papyrus log.

 

Edit: it's quite possible that EP means "essential or protected".

Thank you, very useful option.

 

 

P standing for Placed makes a lot more sense.

 

I'm still struggling with understanding what is actually persisted and what that actually means. I was under the impression that persistence was what allowed an item to maintain a permanent ID so that it could be referenced from anywhere.

 

If so, then all settlers, and any workshop objects that are actors (turrets) or work objects (anything that has worker assignment - crops, vendor stalls, guard posts, etc) appear to be persistent - at least in my tests. I can jot down the form ID of any of those things and access it from anywhere even after hours of playing.

 

I've been doing a lot of testing and those things definitely appear to have permanent IDs, while other things like power connectors and decorations do not. If persistence is not causing this, could someone explain to me what is?

I had some issue with persistence not long ago . I had a thread about linked refs somewhere here . I had set linked refs ( 2 objects) and one of them became persistent( not just that you can prid it, it became undeletable) . Removing the linked ref and setting it to none did not help, it could not be scrapped. It dissapeared when I scrapped it, but it was still there and I could prid it. DPPI command did not show anything that could make it persistent. I tested it another few times and got the same result. Had to use use "forcepersistent" console command and it fixed the thing, the object was finally removed.

Not sure what caused the issue but as I unerstand linked refs normally create temporary persistence( untill they are removed). WorkshopObjectScript removes linked refs on Unload and in devs comments it says that it`s to prevent persistence. Maybe linked refs are only supposed to be used for between actors and objects and it was my bad using it for 2 objects ... or maybe it`s a bug. But if you set any object persistent with that console command, it becomes not only PP, but also undeletable. Many usual PP objects objects can be deleted with no problems.

The command "forsepersistent" makes things persistent or not persistent if used on them again. This does not really answer the question, but maybe this info can be useful.

Edited February 10, 2017 by kitcat81

[kinggath]

Thanks for the input - I actually didn't know about the forcepersistent command, could come in handy for testing.

 

The WorkshopObjectScript only unlinks refs that are linked with a keyword set in properties for the workshop objects, it's actually only used for Guard Posts to make the NPC stay there during combat. Though that definitely gives some hints.

 

Another hint I've found is that WorkshopParent uses SetPersistLoc on settlers that were spawned into the game. As far as I can tell, the point of SetPersistLoc is to automatically persist when that location is loaded, though that seems bizarre to me because any references in a loaded location would already be persisted. I guess it could be a way to prevent unloading until an entire location is unloaded, that way, for example, if one cell of Sanctuary is unloaded, the NPCs would remain.

 

I guess there could be some engine level thing going on where certain objects, maybe those with scripts attached, are assigned unique IDs but aren't persisted. Which would make a lot of sense actually.

[kinggath]

Just found another clue that leads me to believe those things are persisted: GetWorkshopResourceObjects, which can be used to get settlers or resource objects based on an AV, it works no matter where you are even if the location is unloaded.

 

For example, checkout this tidbit in the WorkshopParent script

ObjectReference[] Function GetWorkshopActors(WorkshopScript workshopRef)
	return workshopRef.GetWorkshopResourceObjects(WorkshopRatings[WorkshopRatingPopulation].resourceValue)
endFunction

You can use that anywhere and it will return you references for all the actors that you can act on. Does that not require persistence? Again, these are the things I'm trying to understand so I can make informed decisions on how to proceed with part of a mod...

[kitcat81]

Just found another clue that leads me to believe those things are persisted: GetWorkshopResourceObjects, which can be used to get settlers or resource objects based on an AV, it works no matter where you are even if the location is unloaded.

 

For example, checkout this tidbit in the WorkshopParent script

ObjectReference[] Function GetWorkshopActors(WorkshopScript workshopRef)
	return workshopRef.GetWorkshopResourceObjects(WorkshopRatings[WorkshopRatingPopulation].resourceValue)
endFunction

You can use that anywhere and it will return you references for all the actors that you can act on. Does that not require persistence? Again, these are the things I'm trying to understand so I can make informed decisions on how to proceed with part of a mod...

It`s actually hard to know, there is no official info that would explain it in details. But I personally think that summonable does not necessary mean persistent. It`s my guess based on devs comments in the workshop scripts. They remove linked refs to prevent persistence (it`s written so in their comments, so I think they have a reason for it) , but the actor still stays summonable and the workshop still stores info about this actor , that he is assigned to this settlement, that he requires some amount of food and defence, etc. And my conclusion is that all persistent objects are PP and summonable , but not all PP objects are persistent. Can`t be sure about all this, but don`t have other versions.

Edited February 10, 2017 by kitcat81

[kinggath]

I guess that's not clear to me either then - what exactly is persistence? Is it just the 3D data? I seem to be able to access any properties on these objects remotely, I can move the objects around, I can even assign the actors to things, so far the only thing I haven't been able to do is rotate them without first loading the 3D.

[kitcat81]

I guess that's not clear to me either then - what exactly is persistence? Is it just the 3D data? I seem to be able to access any properties on these objects remotely, I can move the objects around, I can even assign the actors to things, so far the only thing I haven't been able to do is rotate them without first loading the 3D.

 

I would not fully rely on wiki info...Even though they provide a lot of useful tips but some certain things are explained really badly or incorrect. I saw somewhere on the package page that "allow swimming" should be unchecked to allow swimming which also makes no sence and looks like a mistake. That you are able to access properties is normal, the script can keep running even if the object is unloaded. Vanilla scripts unregister for some events on Unload, so the objects do unload even if they are summonable ( otherwise they would not even recieve UnLoad event). I tried some things and noticed that persistent things can`t be removed from the world ( those that are considered persistent in wiki). If you scrap them, they will still remain marked as D PP T(deleted (papyrus property? ) temporary) or PP T until some script (or something else that keeps them persistent ) stops to point at them. Only after this they will be removed. Though they can be deleted from the script that points at them but not from other scripts. So maybe persistent also means unremovable from the game world . But there is no way I can check this info.

 

I have read all the wiki info again and this is how I understand it:

Persistent objects can be of 2 types, temporary persistent and always persistent. Temporary persistent object are only persistent when they are registered for something or when some script keeps their reference as a variable (or some alias is filled with their reference ).

But they unregister for events when they do not need them anymore(i.e on Unload) or clear variables when they do not need them anymore (i.e OnUnload or when the object is Scrapped) etc. But when you need to point at something and to keep this info in the script, there is no way to avoid this temporary persistence. Just it`s better to remove it as soon as you don`t need the script to do anything with this object. And it`s also better not to point at any reference directly ( in the constant script properties) or it will make the reference forever persistent as you can`t change or clear constant properties from any script. Only variables can be cleared . 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.

Edited February 11, 2017 by kitcat81