So, I remember a while back reading this on the wiki:

So to me, that says, never do this:

ObjectReference Property TempRef Auto

Because it's a temporary reference that I will not need later, I should not do that, because it will retain his reference forever, regardless of what I do.

However, the wording isn't completely clear on what flags the property as "permanently persistent".

Situation A:

ObjectReference Property TempRef Auto		; Ref is initially set to a specific reference through the CK properties menu

In the above code, the script declares a temp property. I set this property in the CK property menu to be a specific objectreference. In this situation, I am aware that the reference will be persistent forever. Even if I replace the original reference.

So what if I do this?

ObjectReference Property TempRef AutoTempRef = NewTempRef1TempRef = NewTempRef2TempRef = NewTempRef1		; Does the NewTempRef2 ref properly die, or is it now permanently persistent as well?TempRef = None			; Are both references still permanent? Or is only the first one (TempRef1) permanent? Once I clear the second ref, is it still permanent, or is it properly cleared?

Situation B:

ObjectReference Property TempRef Auto		; Ref is NOT initially set to a specific reference through the CK properties menu

In the above code, the script declares a temp property. I do NOT set this property in the CK property menu to be a specific objectreference. That is to say, TempRef initializes to None. In this situation, I am not sure what happens.

What happens if I do this?

ObjectReference Property TempRef AutoTempRef = NewTempRef1TempRef = NewTempRef2TempRef = None			; Are both references cleared? Or are they both permanent? Or, is the first one permanent simply because it was the first thing plugged into it?

Situation C:

What if, instead, I do this?

ReferenceAlias Property TempRefAlias AutoTempRefAlias.ForceRefTo(TempRef)DoStuffToAlias()TempRefAlias.Clear()		; Is TempRef persistent? Will any future Refs placed into TempRefAlias become permanently persistent?

In the above situation, I set the "ReferenceAlias" in my target quest to initialize with a specific reference loaded into it. Is that alias permanent forever, even if I dispose of it? And what about the refs that replace the original alias?

Situation D:

What if, instead, I do this?

ReferenceAlias Property TempRefAlias AutoTempRefAlias.ForceRefTo(TempRef)DoStuffToAlias()TempRefAlias.Clear()		; Is TempRef persistent? Will any future Refs placed into TempRefAlias become permanently persistent?

In the above situation, I do NOT set the ReferenceAlias to initialize with an objectreference.

When using referencealiases, the alias should always be persistent within the script, however, because that variable points to a "container" rather than a specific reference, I feel as though the property persistence rule does not really affect anything major when using this technique. As long as you ensure you clear the alias when you are done with it, there shouldn't be any issues...


Honestly, My main concern is Situation D, but If possible, I'd prefer answers to the other situations as well to better help me understand properties.

I have a quest that controls most of my scripted functions. This quest will never stop running once started, and contains a good 5 or 6 aliases as properties within the quest. The aliases start empty, and I fill them (and clear them) as needed. I am constantly swapping out the refs held within the aliases with seemingly random object references, and I want to ensure that this isn't going to cause any issues.

Is anyone able to confirm this for me?

Anyone?

I think that only refers to when you explicitly point the property to a specific object in the CK (You know, "Pick reference in render window") - if it's assigned at runtime, it shouldn't permanently flag anything.

That's kind of what I figured, but I wasn't completely sure. However, regarding referencealiases, I'm still unclear. If a referencealias is set to pick a reference in the CK, does the objectreference attached to said referencealias remain persistant forever? Or does it unload if I clear the alias?

Persistent Forever, so yeah try to avoid where possible. http://www.creationkit.com/Quest_Alias_Tab#Fill_Type:

Hi guys

I'm interested in whether this is a problem for QuestAliases with the other fill types e.g:

• Unique Actor
  
• Find Matching Reference

Or is it exclusively an issue with the 'specific reference' fill-type....?

Thanks!

ScarabMonkey

I have worried about this issue as well, and would have tried to test it if I had any idea how to find out whether an object had unloaded or not. Does anyone else?

I'm concerned about this as well. They did away with the old debugText in the console, so we can't see what's loaded/etc anymore. I dunno of anyway to do it in Skyrim. You may be abole to do it by checking properties and variables by selecting an object and doing a showvars... AFTER having left the area. This still shows my variables/etc, but I know my ref's are perma-persistent so dunno if this theory works yet or not.

I was hoping to change my script over to an alias-based system, which I've been trying to learn the past day or so. The documentation isn't very helpful, and I haven't checked forums yet. I was under the impression that only "pick ref in window" was what causes it, even if an alias is filled that way. This is the problem I just ran into... how to create a dynamic reference from a baseObject. I'm going to try the "create ref to object", but I haven't rewritten my script to reflect this yet... so I can't quite test to see if it works. I'll let you know as soon as I find out though.

unique actor type will only be persistent in the specified location (found in the ref's edit window), otherwise it will not even fill at all if this info is not specified.

im not sure about find matching reference




another important but often overlooked aspect of persistence: once you upload your mod to the internet, anyone who uses that mod will will have persistence permanently embedded into their save games.

so just know, that when you hit that upload button, its a 100% full commit. if you edit the script later on, even if you clean your properties the right way with no errors, the old properties remain persistent in the save game file. something to think about the next time in case you upload an unfinished WIP mod that will eventually grow and continually change. (i found out the hard way)

one thing i just remembered, when using objectReference properties, i'm not sure it's always "permanently persistent"

going back to another thread about using the MoveTo on references, it doesn't move the object if the object's 3D has unloaded. AFAIK persistent objects should not be affected by lack of 3D, as using a forced ref Alias which is guaranteed perma-persistent can be moved anywhere even without 3D loaded.


just some food for the brain to chew on

I agree that objectReference properties don't guarantee perma-persistence... but the problem I have on that other thread (why I'm posting in this one) is that I have statics placed in Vanilla worldSpace. Each of these is specifically addressed in the property name (and subsequently auto-filled before saving the ESP). The wiki leads me to believe that these would all be perma-persistent, but they aren't... only the mapMarkers and collision boxes seem to be (and possibly xHeading/Mark but I looked into that more yet). That's what makes the situation so frustrating... that it SHOULD work but doesn't... and I tried about everything I could think of.

But you may be happy to know that properties changed or deleted in scripts/mods do NOT necessarily stay resident in the saveGame. I just tested this last week - in conjunction with working on my mannequin mod (spodum, not the script fix). I found that YES, they are stored and will cause errors on loading (and for that game session if they are cyclic and/or they are called repetitively)... but when you save a NEW saveGame file (or possibly just overwrite the old) with the new version of the mod running, then exit Skyrim & load that saveGame... all the errors are gone, which leads me to believe that one can 'save away' the errors.

I'm still gunna test this some more, so it may be too early to tell if ALL script errors can be wiped from the saveGame; or if they're gone at all, as I haven't looked at the raw data. It's possible that the data is still in the saveGame, simply not referenced anymore - but rather than causing in-game errors, I think that would just cause 'harmless' saveGame bloat... potentially slowing down the time it takes to save/load. I think that'd be noticed most prominently if auto-save were turned on (if anywhere); the game may seem to hiccup because of the extra delay. But at least the cyclic errors would be gone.

Some interesting tidbits of info I've noted during my travails:
- collision boxes don't seem to be able to be translatedTo, only movedTo
- I can't call a moveto on my custom statics, only translateTo... but someone once mentioned that may be because of my NIF file structure (missing and/or wrong data). I haven't looked more into that yet, but I know moveto doesn't work presently - whatever the cause is in my case.
- You can only moveto an actor to a non-attached cell... you can't moveto it back from said cell (it gives the no3D/parent error).
- You cannot call a command on a disabled() ref that was enabled() in the preceding line of code; there must be a wait() in between. I'm not sure if other lines of code would serve the same purpose or not; my setup didn't allow that possibility, but I suppose I can induce it for testing..

I'm mentioning these things because all of which, theoretically, should be possible... shouldn't they? Keep in mind that these are ALL using the aforementioned 'perma-persistent' refs (an actor, several statics, a few collision boxes, a couple xMarks, an activator, and a mapMarker; all specific refs in the mod). So I think either there's something wrong with the persistent-flagging (or whatever may cloak or nullify that attribute), there are mistakes in the wiki or ambiguous wording which may need correcting, or I am somehow mistaken or doing something wrong (heheh.. I ALWAYS keep that as a possibility).

awesome. thats good to know because i have a crap ton of loose properties that give errors on my old mod

BTW, marking "reference" in a ai package target (the one where you pick specifically from the render window), is basically the same thing as an objectreference property... it marks it as persistent. you should avoid using this if possible.

and easy way to test whether or not you are flagging something to be persistent:

in a test esp, try pointing the reference to some arbitray non-persistent item in vanilla skyrim, and see if it creates an edit asterisk next to the reference record in the cell window. if it does not, then it has not changed that reference's persistence flag (either it is already persistent, or your reference pointer is not flagging it as such). if it does create an edit, it is flagging it as persistent.


Edit: Linking a ref to an object also flags it as persistent. FML there is no way to avoid it. i think the best way to avoid building up tax burden, is if you must use a specific reference, linked, pointed or property'd or otherwise, try using whatever has the least amount of subrecords, i.e. a marker of some sort (as those are generally auto-flagged as persistent anyway). actors seem to be a bit more heavy data-wise according to the wiki notes (at least in regards to alias persistence, but i imagine the same applies to actors in objrefs etc)


Edit 2: to make matters worse, when you point to a reference and you change your mind along the way, the item you originally pointed to will KEEP its persistence flagged as a dirty edit forever (and thus be loaded as persistent when you play the mod in game), even when nothing is pointing to it. you have to delete the item in the CK and replace it (if its an item you created in the esp), or mark it as ignore in details (if its an item you are editing from an esm). so yes, it is possible to unknowingly dirty-edit your own esp.

you can use tessnip to comb through the records to see which ones are flagged, then double check in the CK to make sure that item is supposed to be flagged or not. its a good idea to name all your refs something that makes it easy to recognize that it's being pointed to by a script or linked ref etc.

eg. when i link-ref an item for an actor i will name that ref SomeActorNPCsWhateverObject so that i know it is supposed to be flagged. otherwise combing through an endless sea of unnamed REFRs in tessnip will be a pain (now i'm really glad i started my mod over from scratch lol)

Thanks very much for the tips, and the testing. I'll go and rename my refs directly.

It does seem extraordinarily hard to not to make things persistent. The wiki Persistence page says "If you can, pull references in from events or other locations to avoid permanently keeping them around." I understand using events in this way, I think, but it doesn't really give much scope. I don't know what it means by 'other locations'.

stuff like akActionRef and akSourceContainer are non permanent, they only hold persistence for as long as the event function runs (including any passed arguments to updates etc). you can also reference another scripts already-filled objrefs directly through papyrus without making a new objref property.

this is yet another reason why i think making bookshelves is a huge waste of time and resource. a single bookshelf that holds 20-30 books is probably more persistence/papyrus tax than 2 mannequins (graphics/texture video-card tax aside), for very little useful benefit.. unless you are a real book geek. the vanilla weapon racks are also hefty resource hogs.

speaking of weapon racks, i found a new way to cheat. since i am using a container-based system instead of a must-hold-weapon-in-hand type of activator, i actually am doubling the container as its own dummy marker. the script on the container uses no objref properties and when the dropobject is called, instead of moving it to a weapon marker, the container itself is the weapon marker (i am using a dummy sword as its model, which appears invisible in-game, and it is positioned in the cell exactly where the weapon needs to be). so i am essentially getting the container added on for "free". also instead of the triggerbox having to keep track of mounted weapons using its own OnTrigger events, i point to it as an objref property on the activator script and use only the gettriggerobjectcount() function within a condition in the onactivate block (this eliminates the need to put a script on the trigger, and you can use the default trigger object, no special trigger needed).

the whole system consumes a total of 2 persistent refs, 2 scripts and 0 on-load calls, which cuts the tax waaaay below the vanilla system. the vanilla system has several persistent refs and i think 3 scripts, with multiple load calls (these racks were never meant to be used more than a few loaded per cell). with the new scripts and setup i can load up the cell with much more racks wtihout too much worry, leaving more headroom for heavier stuff like mannequins (currently have about 60 racks and 12 mannequins running smooth as butter).

at the end of the day its going to be nearly impossible to avoid flagging stuff as persistent when you are using scripts, its just a game of keeping the refs as low as possible and cheat as much as you can. if you have to call something as an objectref, think of ways to recycle that persistent object in multiple roles, and try shoehorning markers instead of pointing directly at complex physical objects (like actors) whenever possible (this is easy for any kind of enable/disable script, its always better to enable/disable using an enable parented xmarker even if its only 1 object)

Food for a lot of thought. Thanks so much - again.

Using Run on Reference in a condition function will also flag persistence. i guess basically any time you get the crosshairs to pick something in the render window it will flag it for persistence.

most of the time, Run on Reference is generally going to be used on already persistent refs anyway (like xmarkers, player, already persistent actors/aliases etc) at least in my experience. i cant think of an instance where i have ever used it on a non persistent ref

ive been doing a little bit more experimenting and have found some things that may be useful:


If you have a ref that is not already flagged as persistent, and you need to call that ref in a script to do something, but you don't want to use ObjectReference property to permently flag it as persistent, you can try something like


ActorBase property SomeNPC auto

; in the event block use something like this:

ObjectReference TemporaryRef = Game.FindClosestReferenceOfTypeFromRef(SomeNPC, SomeReference, WhateverMaxDistanceAmount)
TemporaryRef.DoSomeFunction()




that chunk of code is a lot more to crunch than a simple ObjRefProperty.DoSomething(), but at least it doesnt permanently mark it persistent forever. it only holds it for the duration of the script function.

this would best be applied when you need a ref to do soemthing probably only once (or just not very frequently), so it would be a waste to declare it as an objref property.

Too bad they didn't add a little box to tick that says "Make this reference temporary?"

Will an actor that is dead but kept persistent in an alias ever have their corpse dissapear? Is there some way to "embalm" an actor?

i made a functional Manny-Me (player-cloned mannequin) so i would assume you could mummify any actor you kill. take them home as a trophy and taxiderm them LOL, and then use them as a mannequin

Has anyone noticed any changes in persistence with the 1.6 beta? I just tried deleting a clone of the player and I think it stayed persistent.

I could do "prid ff000853" and actually manage to select it and use MoveTo on it, although it has a [D] at the end of the reference ID. It did not disappear with the "pcb" console command, nor when quitting the game and reloading.

I tried with the clone assigned to a reference alias through the "create at alias" option, as well as using the ForceRefTo script command. Neither made a difference.

The clone does get deleted properly when it is never assigned to a reference alias.

Bump~

Anyone can tell me whether or not it's all in my head?

How did you duplicate the players' morph features onto the mannequin? That's the tricky part to duplicating the player, you can make the same race, you can copy over equipment, but I haven't yet figured out how to copy facial features, etc...

i cloned the player's base actor into a new reference. the base actor contains all face morphs, hair choice, skin color, etc (all the stuff you select in ShowRaceMenu). i sent the clone into an alias, and used the alias to apply all applicable mannequin-related stuff.

but since the player and the new reference(s) share the same base actor, any changes you make to your player character will also affect your new clone (good if you want the mannequin to update itself when you change your appearance, but bad if you are trying to "create" new NPCs dynamically).




i would check it out myself, but i dont want to touch 1.6 until the CK is also up to 1.6

but if persistence is somehow changed to remain permanent instead of temporary, that is a very bad mistake and i predict a lot of random inexplicable CTD's (memory shortage crashes) if this isnt addressed when 1.6 goes live.