[Oblivion] Dealing With Persistent References

[Arthmoor]

This tutorial is meant as a companion piece to my original - Oblivion: Creating Compatibility Patches. If you have not yet read this, do so now, as it covers the basics.

At some point in time when making compatibility patches for mods, a situation will arise where you'll be forced to make provisions for persistent objects. Most often, this will be due to having to relocate a door from a building's original location to a new one that is more fitting with the surroundings. For the purposes of this tutorial, we will deal specifically with relocating a door. Just keep in mind that the same principles apply to all persistent references which are visible to the player.

The first rule of thumb: NEVER simply move the door to its new location! Persistent references are recorded permanently in the saved game file once the player has visited the area containing them.

The second rule: NEVER use a script to do ANY sort of edits on a persistent object, even to disable it. Any time a change is called for in a script, that change is permanently recorded in the save game file. This includes using enable parenting! This is important to remember because it isn't obvious. Any change to an enable state brought on by a script becomes permanent.

Since the two most useful methods for dealing with this problem are out of the question, this leaves you in the position of needing to do some more clever tricks.

You'll want to make sure you've unlinked the teleport from the original door to it's target location. Be sure to make note of where that target cell is, and what the formID of the door is it leads to before you unlink it.

The first and least harmful trick is to set the scale of the original door to an incredibly small size. The smallest size the CS will allow you to shrink something down to is 0.01. In general, this will be small enough to render the door invisible unless it is very large, like a city gate. If after downscaling the original door it is no longer visible in the CS, you are probably done. There's a good chance downscaling it may end up hiding the door entirely under or inside the objects it was conflicting with. This is ideal, because you can simply move on to setting up the new door.

The second least harmful trick is to simply mark the original door with the "initially disabled" flag. Generally speaking, this works well, but it has one slight quirk. If the player reloads the game without first exiting to the desktop, the door may reappear due to an engine bug which reverts objects to their original state. This is especially problematic when dealing with doors from the vanilla game. This method does however mean that the door will be guaranteed to be invisible. So if downscaling doesn't work, this is worth a try.

The final trick is dodgy but is useful in select cases where downscaling isn't working out and the disable trick isn't registering for some reason. If neither of the first two methods proves useful, then try this as a last resort. Remove the persistence flag from the door. Mark it as "initially disabled". Set the Z coordinate to -30000. Once the game loads and the player approaches, it will register that the door is no longer persistent and the Z coordinate will take it out of visible range. This has one major disadvantage though. If the player reloads the game without exiting to desktop, this method is guaranteed to revert itself back to the mod's original state. It's the same engine bug as the previous trick. There's no workaround method for this that doesn't involve advanced OBSE code.

If nothing above is working, the one tried and true method guaranteed to get the door out of your way is to delete it outright. You absolutely MUST be sure it's not still linked to its target door before doing this, otherwise the CS may crash. Save before you try this as well. While this is guaranteed to remove the door, it carries with it another danger in the form of the deleted reference this leaves behind in the patch file. It runs a high risk for crashing the game, even if no other mods tried to edit it. Oblivion does not play nice with deleted persistent objects of any sort, but most especially with load doors. The risk is generally very low if the door being deleted is from a user made mod, but don't EVER do this with a vanilla door because that would cause instability for just about everyone. If the door is being used as a quest target, an AI pack target, or a script is referencing it, attempting to delete it will prompt a warning. If you get such a warning, stop what you're doing and get out of the CS - do NOT save, because the CS has a bug where even if you cancel the prompts some of the reported data will still end up being unlinked. Tsk tsk Bethesda.

So now that the door has been dealt with, it's time for the easy part. You need a new one at the new location which leads back to the same spot the old door did. Place a new door at the new location, and make sure you link its teleport data up to the proper location and formID as the old door. Adjust the teleport marker, and then follow that marker to the target location and adjust it there too.

If necessary, make sure any scripts that reference the old door are updated to reference the new one. Do the same for any AI packs and quest targets which may have used the old door as a target. On rare occasions there may even be dialogue records that referenced the old door.

Now for the fun part! It's time to save your work and then load up the game to make sure everything is working as planned. If it is, the relocated door will show up properly on the player's local map and be sitting happily in its new location along with the building and other decorations that went with it.

Hopefully this sheds some light on the process of dealing with load doors in compatibility patches.