Persistence Question

[hereami]

 

 

Not sure, but is there a direct relation between a property being equal to NONE and persistence of an object, which is not referenced by this property at the given moment (for whatever reason)?

 

If a script property points to a reference, and this reference is loaded, you can call a function on it without problem, but when you call this same function, and the reference is unloaded, the papyrus log says something like "can not call (function name here) on a None object".

Ah, ok then. I assumed that the actual pointer value was determined to be NULL at runtime, so it looked a bit strange. That may be for good actually, forced persistence isn't always desired (e.g. dependent objects in a single cell).

 

This wiki is the official documentation.

Hm, official for public use perhaps, it's absolutely incomplete in what regards F4, well, ok. How about this (WorkshopParentScript title): General workshop documentation: http://institute.bethsoft.com/index.php?title=Workshop_Systems_Design - was it ever available anywhere?

[SKKmods]

A good way to check if an object has been forced to persist is to check the \Worldspace and \Cell in xEdit.

 

Normally the ObjectReferences I point at in Quest script Properties, FormLists and Quest ForceRefTo appear as modified records in those lists (record Flags: persistent) so they can be acted on.

[pepperman35]

Circling back to hereami question, did anyone ever have access to the General workshop documentation that is referenced in the WorkshopParentScript?

 

"http://institute.bethsoft.com/index.php?title=Workshop_Systems_Design"

Of course, the link doesn't work but was curious if anyone ever had access to the documentation.

[hereami]

Circling back to hereami question, did anyone ever have access to the General workshop documentation that is referenced in the WorkshopParentScript?

 

"http://institute.bethsoft.com/index.php?title=Workshop_Systems_Design"

Of course, the link doesn't work but was curious if anyone ever had access to the documentation.

Curious that game still has attention. It's great one still though. And currently is more important if somebody is able (or has already) to back up the existing creationkit.com contents at least, there is no guarantee it won't vanish any moment like old forums (which contained some curious data and was linked from wiki pages, all lost now).

 

PS. Ah, just suddenly stumbled upon a link here in forum https://ck.uesp.net/wiki/CreationKit:Copy_Notice . Clever.

Edited May 2, 2022 by hereami

[hereami]

A good way to check if an object has been forced to persist is to check the \Worldspace and \Cell in xEdit.

 

Normally the ObjectReferences I point at in Quest script Properties, FormLists and Quest ForceRefTo appear as modified records in those lists (record Flags: persistent) so they can be acted on.

Basically, this means that single thing which makes an object permanently persistent - it's checkbox on a REFR, "manually" set by Creation Kit according to user actions. Wiki silences this fact and provokes confusion. While using a reference in a script or hard alias fill etc. doesn't enforce persistence by itself, e.g., when done exclusively by XEdit and never saved in CK.

 

I don't quite understand another thing. Let's say Condition GetIsReference or alias force fill, they are said to require a persistent object and CK issues warnings, fine, but my rightful question now is - why on earth they happen to fail even if that object REFR is already loaded, obviously, that ID and its data is sitting in live memory structures, i guess. Just weird.

Edited March 11, 2023 by hereami

[RaidersClamoring]

You can always put information you are unsure of but want it to be known as a kind of 'heads up' on the talk pages. This is what I do/have done in the past.

 

Unfortunately it's been too broken for any edits or account-additions to occur for a number of years now. I spoke to one of the more involved accounts back in the day and he confirmed it is entirely broken, hence why there is a scraped version of the site that *does* work.. however it doesn't pull traffic as it should.

 

This link should really be worked into our habits (and could use some SEO I suppose):

https://falloutck.uesp.net/wiki/Main_Page

(It is currently no more accurate than the original one but *it can be edited* and *you can join*)

[niston]

there is also dppi console command, giving insight on persistence by script.

[RaidersClamoring]

The bracket-stuff next to Current Selection in console also means... stuff. I've been trying to understand it.

 

[EP] -- Turns up if you requested "bMakePeristent" when calling PlaceAtMe, but not otherwise, implying "P" stands for persistence
[PP] -- Should therefor mean "Permanently persistent" -- this turns up when calling "ForcePersistent" in the console, but also, seemingly randomly, on Refs that were created/placed in CK. However, these refIDs actually don't survive being stuffed into the inventory, which [EP]'s will. So are [EP]s created persistentlier?
[D] -- Seems to mean a thing is in the inventory.
And FF at the start of an ID of course means it's not const/static.

[PJMail]

[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)

[DieFeM]

I think that goes like this:

On non persistent objects, when you place an object in a container/inventory it becomes a base object without a reference, so the reference is marked as deleted, if you drop it back to the world it creates a new reference.

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

 

I asume this because of the behavior of the "OnItemAdded" event.

 

 

 

• akItemReference: The specific reference added to the container, if any. Will be None if a non-persistant object is added.