Tracking Down Corrupt Spawn Points

From Nexus Mods Wiki
Revision as of 14:40, 30 January 2012 by Dark0ne (talk | contribs)
Jump to: navigation, search

Overview

This tutorial covers methods useful for diagnosing and (sometimes) fixing corrupt spawn points.

Requirements

  • A map of the game's cell structure: [1]
  • TES4Edit, or TESGecko.
  • The Oblivion console
  • Patience

Finding the Culprit

So there you are, on your way to someplace cool. Minding your own business. Then, suddenly, the screen goes black and Windows throws an error. As your screams echo into the void, one thought crosses your mind. "I haven't changed anything here recently." So what happened? Why did the game just up and crash? Undaunted, you load back up and proceed to the same area again, only to be met with the same fate. Why does this keep happening?

The answer is probably simple enough. You've got a corrupted spawn point. If you'd like to find out what mod this came from, rather than ignore the error by hiding in the testing cell for a week, read on.

So I hear you ask, how does one go about tracking this down? It's not as hard as it may seem, but it does take a bit of patience and some reference material to make it easier. Here's a list of things you'll need to start your hunt:

You'll need to start by using the console and having it display debug information as you're walking. Open the console with the ~ key, then type in "sdt 0" and hit enter. Then type in "tdt" and you'll see a bunch of information on the screen. The stuff we're concerned with here is the PC Cell data. Slowly approach the spot where the game crashes, keeping an eye on what cell it reports you are in. A corrupt spawn will crash the game very shortly after the cell location updates, so be ready to write it down.

Once you have the proper cell handy, you'll need that big map. Look closely, you'll see small white numbers. These are cell coordinates. You can't use the cell the game crashed in, you have to keep in mind that data ahead of you is being loaded into memory. With a default ini file for the game, this is usually two full cells. So for example, if you're in cell 8,33 and you notice the game crashes upon entering cell 8,34 going north, then you'll actually want to look up cell 8,36 on the map file because that's the one that's two cells ahead of you. To be on the safe side, also keep cell 7,36 and 9,36 in mind because they're also being loaded into memory.

Now you need to open up TES4Edit. Allow it to load whatever your current load order is, the mods should all be checked. While you wait, look at the map, the cell you're after will be in one of the large colored green blocks. These are storage markers for the internal data of the file. Note that cell 8,36 is in Sub-block 1,4 of ExtCellGroup 0,1. When TES4Edit signals it's ready, open the branch for Oblivion.esm. Scroll down to the Worldspace block, and open that branch. Open the worldspace you want, in this case Tamriel. Notice the block sections under it. Find 0,1 and open it. Under that will be several sub-blocks. Open 1,4. On that list of cells will be cell 8,36 "BrumaTamrielExterior07". If you highlight that cell, the right pane of TES4Edit will list all the mods which are affecting that cell. Take note of which ones are listed. While you're in here, check cell 9,36 as well "FGC05BanditCampTEMP". You'll also want to find cell 7,36 - you should be able to figure out how to locate it using the big map file.

So in the example, lets say you notice that Unofficial Oblivion Patch, TIE, Crowded Roads, and Open Cities all touch cell 8,36. Since we're looking for corrupt spawn points, it doesn't make sense to suspect the UOP because it doesn't place any (though it may move some). It also makes no sense to suspect Open Cities, because it does not use spawn points. This leaves you with two possible suspects: TIE and Crowded Roads. You may find the same set of mods also touches 7,36 and 9,36.

In order to confirm suspicion, close out the programs. Deactivate one of the two mods and load the game. Walk toward the crash point. If it dies again, try deactivating the other. Keep doing this until the game stops crashing as you cross the cell boundary. Once you can make it through without crashing, you can exit out and reactivate your other mods, then load the save without the offending mod. Cross your cell boundary, then save again and reactivate it.

You should take care to note whether it is safe for your game to deactivate a mod with spawn points. Crowded Roads is, since you are unlikely to be holding important items from it. TIE should be safe to disabled for a short period, though your item stats will revert to vanilla during this time. You should only keep the crashing mod disabled long enough to be sure the game won't crash.

Don't bother the mod author with reporting a corrupt spawn, there's likely nothing they can do about it. It's a general annoyance of the game. Eventually one comes up. The above long drawn out procedure is also unlikely to be necessary unless your respawn timers are very long, or you're playing mods which prohibit the usual tactic of hiding in the testing cell for days on end getting it to reset. This will allow you to identify the suspect, and once you're familiar with navigating TES4Edit and reading console data, this will almost certainly be faster than interrupting your journey with a trip to the testing cell. The added benefit of this is that you won't have to remember how you got to where you were.