Oblivion: Dealing With Persistent References

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.

Once you've read that, continue on after the jump.

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.
"It is pointless to resist, my son." -- Darth Vader
"Resistance is futile." -- The Borg
"Mother's coming for me in the dragon ships. I don't like these itchy clothes, but I have to wear them or it frightens the fish." -- Thurindil

Well. I guess that's that then.

« Unnecessary Modification
Carmageddon »

Posted on Jul 11, 2011 3:40 am by Samson in: | 10 comment(s) [Closed]
Samson said:

Just keep in mind that the same principles apply to all persistent references which are visible to the player

plus any not visible to the player but which are in cells which will be loaded when the player is nearby (i.e. x-markers and map markers)

One additional possible trick to hide a peristant door (or similar visible object) is to replace the base object for the placed object. Instead of using a door mesh, switch to using a collisionless invisible mesh (e.g. a collision box mesh with the collision data stripped out). Be sure to change the used base object, do not actually edit the base object itself otherwise every usage of that base object will be affected!

Yes, I forgot to mention the object-swap method, but that also has the same disadvantages as the -30000 Z method in that it will revert if the game is reloaded without exiting first.

Interesting, nobody has ever reported the base-swapped Bruma doors in BC reappearing as far as I recall, and they've been swapped out for a couple of years. Plenty of people report the Skingrad and Cheydinhal doors reappearing, but those are all just disabled, nothing else. I'm going to resize them for our next release, as you suggest.

In the next chapter: dealing with grass. Where Samson has a brain meltdown and will henceforth speak in limericks for the rest of his life.

By the way, I've had some issues with the Bruma doors getting swapped out for some time when I was using BC, Vorians. I just already knew this was an unfixable engine level bug and never bothered to annoy you with it. :innocent:

Well in BC v5 they're all shrunk to 0.01 as well as being base-object swapped and disabled (though the Bruma ones may not be disabled because I think that breaks the vanilla quest targeting pointed at those doors, which was the reason I base-swapped them instead of disabling them in the first place).

Shouldn't the grass thing be as simple as retexturing the offending landscape with a non-grass texture?

Simpler than that even. Using the "I" menu while in landscape mode and then substituting out any grass textures in each cell-quad with non-grass textures. Overkill, yes, but it's like nuking it from orbit: the only way to be sure.

Might be okay in CSE, but I found that in CS it had a tendency not to save such changes to the ESP, so the texture kept reverting back to vanilla. I did the same edit in TES4Edit instead where it stuck.

I've been using that landscape menu for far longer than CSE has existed though, and it's always worked for me.

You're so lucky. It kept reverting after saving and exiting and reloading when I swapped out textures. I could remove textures, but swapping just didn't get saved.

<< prev 1 next >>
Comments Closed
Comments for this entry have been closed.

Forgot Password?

 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30