Jump to content

[Skyrim] Levels of Persistence


Recommended Posts

In past TES and Fallout games, there was a distinction between "temporary" references and "persistent" references. A reference was either temporary, which means it was only loaded if it was within the grid surrounding the player, or it was persistent, which meant it was always loaded in memory at all times. Temporary references could be relocated at will if needed. Persistent references could only have this done if the player had never encountered it yet. The most common way this ends up making problems for people are XMarkers and load doors - because they are by definition always persistent.

Skyrim has since broken this system down into more subtle distinctions which are somewhat important to understand because it changes the way in which you get to deal with things. It's a hierarchical setup, meaning the higher the level of persistence, the less you can do about it. A reference ordinarily in a low level can be moved into a higher one depending on how it's being used, so be mindful of this.

The levels are as follows:

Level 1: What I call "persistent in flag only". Basically this is holdover stuff from the older engine iterations. XMarkers and load doors fit into this. Certain other objects like water planes get flagged this way too. They are no longer rooted to their position, and you can move them around freely even if you are standing in the same cell they are. There's nothing actually preventing you from moving these around.

Level 2: Persistent because something else is referencing it. The reference becomes persistent and will be in memory at all times while it is loaded into memory in the cells surrounding the player. Usually this is due to being an enable parent for other objects, being designated as an AI package target, or being added to a Formlist. In some cases, you may not be able to get these to update their positions because the data may be temporarily added to the save game. It should be possible to relocate a reference at this level if the player leaves the area (more than 3 cells away by default). In some instances it may be necessary to have them stay away from the area until the cells are reset by the game.

Level 3: Persistence assigned to actors while loaded. A placed actor reference with a "Persist Location" assigned will be loaded into memory whenever the player is in the location the actor belongs to. For game data terms, "location" is a type of record (LCTN) that can contain a number of cells, actors, markers, and other things. Persist Locations do not prevent you from moving an actor to a new starting location.

Level 4: Persistence applied due to being in a quest alias. When a reference is assigned in a quest alias, that reference becomes globally persistent for as long as that quest is running. While the CK Wiki makes a distinction between "Forced Reference" and other types of aliases, experience has shown that all reference aliases are treated the same way. While the quest is off, you can relocate positions on these references at will. When the quest starts, this is no longer possible even if the player has never encountered it. The quest would need to shut down again in order to be able to move it. Actors who have AI packages run in the quest can do so in ANY location, even those outside of their normal persist locations.

Level 5: Persistence applied as the result of being a Papyrus property. Whenever a reference to something is added to a Papyrus property, that reference becomes globally persistent. It does not matter if the script ever runs, or if it's in a quest that's off. These references have their information permanently baked into the player's save game from the moment the mod assigning them becomes active. These references cannot be moved. If they are vanilla references, removing the mod which used them in script properties WILL NOT remove the persistence flag as that is in the save forever. Needless to say, one should use hard properties only when necessary.

This system may be a bit confusing, and I had a bit of a better writeup for this elsewhere but lost track of it so I may have missed something. The bottom line though is that it's a much more efficient way for the game to handle memory. It becomes easier to see why shutting down quests is important for helping to optimize memory use if the quests don't need to stay running.

Keep in mind, these levels of persistence only apply to references. Those things actually placed into the world, such as ACHR, REFR, PHZD, and anything else found under the CELL child branches. Base records such as _NPC, STAT, HAZD, etc are handled in other ways and usually have their own rules for what does and does not become permanent.

Link to comment
Share on other sites

  • 4 years later...

As a side note, you can move objects in script properties (level 5) by renumbering them with xEdit. I don't know what happens to the old object in the save file, but the new object will appear in its new position, and its script properties will be refreshed.

Usually, this means that the object with the script property will also need to be renumbered, so that its properties will be refreshed with the renumbered reference.

When adding script properties, you also must renumber any objects using the script, so that they are refreshed with updated properties.

However, dialogue TIF properties seem to be an exception. All their properties seem to be refreshed at time of execution. Perhaps they aren't normally kept in memory?

My current technique is to have quests only in TIF properties, with as few as possible hard coded references, using keyed linked references in objects as much as possible. Obviously, the keys themselves appear in scripts, but they are generally vanilla and unchanging.


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...