Persistence Question

[SKKmods]

^ this is the way, although I would offer a slight modification:

 

>But a persistent OR UNIQUE reference always keeps the same reference, even when it is placed in to an inventory or container.

 

Threre are non persistent (not always loaded in VM memory) unique object references such as spawned weapons with attached OMODs which "persist" their unique attributes in containers and still have an FF prefix. Persistence must have multiple contexts: loaded in memory, maintains reference in a container and possibly others ...

[RaidersClamoring]

[D] means MarkedforDelete (and also do not render).

Strangely all objectreferences that are placed in an inventory are actually marked for delete (but the game apparently won't delete an object in a container).

I suspect it is just some hack Bethesda did to make such objects not rendered while they are 'containerized'.

 

You can test this yourself by using "isDeleted()" script function on a containered objectreference (it returns true).

Obviously this applies to objectreferences (FFxxxxxx), rather than Base Objects, in a container.

 

(No doubt it is more complicated than this - but it is my working hypothesis at the moment)

 

I guess what all these things have in common is they are in a state of Disabled, so maybe D was left to mean both Deleted and/or Disabled. It makes sense for the persistent refs in the inventory. Could be that there isn't a huge difference under the hood between a deleted and a disabled reference as far as regular inhouse quest-production is concerned.

[PJMail]

As SKK50 stated - some objects DO keep their objectreference when in a container, and these were what I was talking about.

I did these tests moving objects between containers and examined them (as well as checking their ID in the onitemadded and onitemremoved events).

 

All I can say is the objects I was looking at retained their objectreference ID in all this, but an "isDeleted()" check while in a container returned "TRUE", yet before they were added (and after they were dropped) that check returned "false". I did not check "IsEnabled()" so cannot comment on RaidersClamoring's assertion.

 

I have done this check with PA armor (modified with OMODs), as well as partially used fusion cores (which have a "health" AV so must be objectreferences).

Not a 'thorough' test, just an observation that surprised me. Make of it what you will.

[SKKmods]

Since 2015 there has been a constant background issue of users reporting modified objects like weapons just disappearing from containers that has been attributed to settlers (nope empty workshop) or cell reset (noreset container) which MAY be the non memory persistent but UNIQUE modified FF objects in containers with the "markedfordelete" state that get hoovered up by cell reset RELATED scavenging/garbage collection. 8 years later .... hmmm interesting.

[LarannKiar]

From what I've seen, if you activate ("take") a takeable object that is either editor placed or in-game created but persistent, it gets disabled and marked for deletion and the inventory data of the actor that took it ("akActionRef") gets modified by the native code. If an in-game created taken object looses their persistency afterward, the game should remove it from the save (eventually...). A non-persistent in-game created object gets removed from the game right after the actor "takes" it.

 

Interestingly, when I called akActionRef.GetDistance(TakenObjectRef) on an editor placed/in-game created persistent object, GetDistance() didn't returned '0'. The object actually remained at its original position. TakenObjectRef.GetContainer() returned 'akActionRef' of course. On cell reset of their GetParentCell(), editor placed objects get reset (enable-undelete-reposition) but they shouldn't be removed from akActionRef's inventory. The only object that disappeared for me was the Gilded grasshopper. It was years ago so it's hard to tell what happened exactly but I'm pretty sure I didn't scrap it or used it as a component at a workbench..

 

As for the console flags, [EP] and [PP] tend for persistency. I usually see [EP] on objects whose persistency is derived from the "editor" (FO4Edit >> ACHR >> Record Flags: 'Persistent' checked), while [PP] on objects that have been set to persistent in-game (e.g., when one fills an object reference into a Reference Alias). (Never seen an object loosing its [EP] flag, [PP] can be added/removed in-game by the console or a Papyrus script). [D] just means deleted, that's for sure.

[PJMail]

That is very interesting LarannKiar, and fits in with with my working hypothesis that 'taken' objects (instantiated/objectreference ones) are not moved, but instead marked for delete by the game - but remain 'existant' as they are still being referenced via the container (so not garbage collected). The reverse happens when they are 'dropped' (they are moved and undeleted).

 

And as SKK50 mentioned, as well as your guilded grasshopper (and my odd items in inventory) shows - sometimes the game can really get to garbage collect those items in your inventory anyway. What sort of items that can happen to (PP or T), and under what edge conditions, who knows.

 

I could never test my 'odd' inventory item because when I dropped it (to examine it with better console etc) it vanished. And PRID failed. It only lived while in a container. And I could move it between containers, but only via a "ContainerA.removeAllItems(ContainerB)". A "RemoveItem(TakenObjectRef,1,true,ContainerB)" would fail with an error I had not seen before (sorry, didn't write it down).

 

Truely objectRefs in containers are in an odd state...