I would like to know just a little more about this function. I know everything from MWSFD and have used references persist on all targeted objects in a script. However, I'm thinking I might have overused it in areas where it's not necessary.

For ages, I've been under the (perhaps false) assumption that if you check references persist on an object, than that object's local script data will be saved. So, for example, if I want to save a variable in that object's script and not risk having it reset by the 72 hour cleanup, then I check references persist.

I started doing this because of various secret passages and lifts that I created, where I want that activator's script-altered position to be saved so that the player doesn't come back days later to find the passage blocked after opening it. People complained that this sometimes happened, so I checked references persist on that object, and heard no more bug reports about it. Is this just coincidence? Have I been completely off the mark this whole time? Or does references persist actually work in this way?

Yes, I think references persist works that way. If you look inside a cell in a saved game, you can see that the script variables are saved per reference. So if you tell Morrowind not to garbage collect that reference, then its script variables should persist too.

I may be wrong, but I see little harm in making refs persistent. I think it was an attempt to make MW more memory efficient, but since it's common to run with at least 2GB of RAM these days, it's not so important. Of course there are things that clearly should not persist, like corpses of spawned actors.

There are actually cases where not making refs persistent will cause Morrowind to crash, such as the summoned creatures CTD (the MPP fixes them by making them persistemt). And in some case, things that cast spells via script can cause crashes if they are not marked persistent, so I would always make them persistent too (although I think this is now covered by the MCP "delayed spell crash fix").

Thanks for the info. In my experience it seemed to be so, but I just wanted to make sure because it's not really a documented feature as far as I could find.

If we are talking about the values stored by local variables in a script attached to an object (a local script), it does not appear necessary to make the object persistent for those values to be preserved beyond 72 hours. I have written many local scripts that function perfectly well without losing stored data across a great span of time. It would be complete chaos for even un-modded Morrowind if those values were lost due to the 72-hour effect.

Of course, when dealing with the Morrowind engine I do not depend on what is reasonable or logical - I test it. I created two objects wearing the same script, one persistent the other not. OnActivate set a value to a local variable and then I left. I hope you will derives some comfort from my tests that show after a couple dozen cell changes across ten days of time, my non-persistent object's memory was just as good as that of the persistent object. I also tested by assigning a value to the variable through the console, but not by setting though dialog results or another script.

I check 'reference persists' on an object only when I need to reference that object in another script. I believe that it the principle reason for it - so scripts can compile.

What about objects with stored positions? Say I move an object via script and want it to stay in the new position until it's moved back. That's usually when I've found references persist helps keep it there, because otherwise they seem to jump back into their CS determined position over time and it can break their scripts by making the objects move backwards through a wall or something the next time it's activated to move it.

That appears to be a different matter entirely. You are now speaking of the default properties of the object itself not the values stored by local variables in a script attached to the object.

I do not understand the matter well enough to explain what is going on or even to know what behaviors are triggered by the 72-hour effect triggering this latent object data. I read about companion modders lamenting how the game can 'forget' their NPC so teleport rings cease to work until it and the NPC associated with it are again in the same cell together. There appear to be issues with 'training' not being remembered - that skill and attribute changes made during the course of the game are lost if the 72-hour effect is allowed to have its way. There is no need to be too critical of my description of these problems - I am working from memory, and not a memory formed from my own experience since I have not work on companion scripts or tested them.

I have noticed that repositioning an NPC does not always 'take' and the NPC goes 'walk-about'. Presumably the NPC is trying to reach its default coordinates. When this is performed in a new cell the results can be very interesting. Perhaps a form of this behavior is what you were describing - object creep.

I cannot say that any of these issues are triggered by the 72-hour effect or if making the object persistent would help. My understanding is NPCs are by default persistent so the fact that they are particularly vulnerable suggests that persistence does not help, but the engine does have it moods. The behavior you described involving objects may or may not be solved by making them persistent. Someone may have to perform some tests.

I've worked with several companions and I did discover that checking corpses persist on them actually fixes the telepathy ring problem entirely. I got around the problem of their corpses being persistent by writing special burial scripts to clear their corpses should they die.

The object creep problem seems to be a little more complicated though. I performed a little test. In my tower elevator, the platform that raises and falls has to be persistent, because it's targeted in another script to start it moving. It actually requires scripting to keep it in its new position, so not only moving states are added, but position states. If its position is supposed to be the fourth floor, then it needs a script to keep the platform from jumping back to the first floor, otherwise its new position would be in conflict with where its variables say it is. So it seems that even persistence can't keep it there. It needs to use SetPos to keep it on the floor it was last moved to every time you enter the cell after 72 hours.