Common Bugs

These are annoying problems with the CS and game engine.

The Ghostly NPC Bug

“NPCs walk through some obstacles and fall through ground and floor”

Place a continuous fence or wall around a building, add a switch-activated gate, then enter the game and:

• Stir up some monsters or bad guys outside the walled area
• Lead them (but not too closely) to the gate
• Open the gate while they catch up
• Go through the gate and
• Close the gate behind you before they catch up

This leads to two problems:

Pursuit Teleportation

If you enter the building NPCs in pursuit and presumably trapped outside the walls, teleport with you inside the building. This occurs despite the fact that the door is spatially beyond their reach. This bug can be circumvented by adding the following script or similar to access portals that lead to locked player worlds:

ScriptName PlayerLock
Begin OnActivate
  If (IsActionRef Player)
    Activate
  EndIf
End

A fairly simple aspirin for Player owned house and castle mods where doors are made to stay locked. This can also be modified to be key dependant.

Burrowing or Ghosting through Obstacles

If you wait outside long enough, one of two things happens:

1. Your pursuers sink through the ground and pop up right next to you
2. Your pursuers walk right through a point along in what appears to be a continuous barrier.

To date, there is no publicly documented solution or workaround for this aspect of the “Ghostly NPC bug”.

This may have something to do with developer assumptions about user familiarity with the construction set. The last thing that needs to be done prior to release of an expansion pack or "mod" is to manually correct all the paths in the modified cell. This is because "AI"s in the Havoc engine are restricted to two dimensional navigation. Pathways reduce a three dimensional environment to a two dimensional topology. So the scope of actor movement needs to be defined manually and this makes path editing one of the most important and perhaps most overlooked aspects of expansion pack development using the TES4 Construction Set.

If a collision surface obstructs direct access between path nodes, an NPC will attempt to penetrate the collision boundary, and after a time-out of 5-10 seconds will be moved to the target path node. By disconnecting path nodes on either side of a wall or other intentional obstruction, the chances of ghost-walking may be reduced.

Ambulatory Mode is Not Always Corrected to Destination on MoveTo& SetPos

The engine doesn't always check and correct the ambulatory mode (whether actor is swimming, walking, running, or flying) to the mode appropriate to the teleport destination. Although a water-based door that leads to a land-based destination corrects the ambulatory mode on teleport, this correction does not occur after other in-game processes have run. However, functions such as MoveTo and SetPos are not the complete teleport package and do not check and correct ambulatory mode.

While an actor transported using MoveTo or SetPos from a land based environment to a water based environment winds up in swimming mode, an actor moved from water to land or air remains in swimming mode. For example, a sea-bourne boarder ejected from the trigger zone surrounding the ship to a point in mid-air will continue to swim through the air with a gently decaying altitude, instead of falling into the water and making the intended splash.

This problem is solved in modifications by using the IsSwimming function to filter for ambulatory modes prior to triggering MoveTo or SetPos functions on actors. The use of a hidden inaccessible pair of doors, one of which is script activated on the player with it's teleport destination in the desired position will also correct ambulatory mode.

In an example involving engine behaviour, if a collision surface exists between a swimming actor and a land-based path node targeted by that actor, the actor will be relocated to the target path node after a brief time out but will sometimes still be "swimming" in mid air above the target. The best solution, although not perfect, is to ensure that preferential water-based paths that lead to unobstructed secondary land based nodes are deployed to divert swimming actors away from obstructed land-based nodes.

Touchy Cells in Tamriel

Some worldspace cells in Tamriel are especially prone to problems. Almost any changes in these cells can cause strange problems in the game, so mod-makers should generally avoid making changes to these cells.

One of these cells is listed separately under Crashes: Edits to Tamriel cell (-47,-7). Others are listed below:

Random Vanishing Landscape in Tamriel

The cells 20,-17 and 20,-18 (along the road between Bravil and Leyawiin, between the small bridge and Fort Nomore). Even small changes to these cells may cause the landscape to randomly vanish. If you quit the game, restart, reload and return to the same spot the problem usually goes away, but it may randomly return on future visits to the spot. Entering these cells slowly may reduce your chances of encountering the bug.

One of the causes of this bug has been identified as Havok-enabled object refs. placed in a cell rolling into an adjacent unloaded cell. Because of this, if you are placing Havoked items (items that the player can move with the Z-key; this includes weapons and armor) into the world, ensure that they are not near cell boundaries if they roll easily.

Markers Missing from Local Map

The cell 3,3. If a mod alters ANYTHING at all in the cell 3,3 in any worldspace, the player's local map will stop showing the player marker and other markers on the local map. However, this local map error can also happen randomly when going through certain cells without any mods at all, but in this case it's only temporary. No fix is known for the latter bug.

This bug will also happen with cell 4,4 if uGridsToLoad is set higher than 5 in Oblivion.ini. However, since increasing uGridsToLoad causes other bugs as well, cell 4,4 should be considered safe to edit.

Vanishing Landscape in a New Worldspace

This general problem is also listed under Common Mistakes because it can also be caused by using an ESM to alter the landscape for another master. In this case, however, it occurs whenever the current modindex for the plugin differs from the modindex of the plugin during creation in the CS (because the end-user's load-order will rarely be the same as the load-order during creation). This usually means that the only way to get the plugin to work in-game is to make it the very first thing that loads after Oblivion.esm, which is a terrible limitation.

TES4Gecko now includes a Move Worldspaces function to help deal with this issue by "injecting" new worlspaces into the 00 modindex.

Remove Item and Selling Stackable Items with Extra Data

The 'remove item' function doesn't always work properly with more than one item, especially stolen stackable items. The in-game message (produced by the game) is correct, but the number of items the player loses is not. For example, you may get the message '5 ogre teeth removed', but only 3 were actually removed from your inventory. Mods can exacerbate this by manipulating the 'Extra Data' fields, such as the Ownership field in the CS. Because there is no known way around the problem (short of scripting thousands of items by hand), and it may also be caused by in-game actions (i.e., damaged equipment), you should not be surprised if this happens to you.

This problem is fairly common with mods that do a lot of inventory manipulation, such as ingredient sorters. Similar problems also happen when selling items that have Extra Data. The frequency of the problem is increased by mods that assign ownership to more things in the game, such as Guild Item Ownership, Clutter Ownership, and Oscuro's Oblivion Overhaul. In a few cases this problem can lead to crashes, as with Selling Stolen/Duplicated Alchemy Equipment.

Oblivion Realm Resets

Whenever the player closes an Oblivion gate, the entire Oblivion worldspace and everything inside of it is reset. This includes inventories of containers and NPCs, and for NPCs their spell list and location. Variables on world objects may be reset as well (NPCs seem to be reset, but not activators).

One side effect of this is that is it inadvisable to move the player into an Oblivion worldspace with MoveTo rather than using a proper gate door. The worldspace may not reset properly, so the next time the player visits it, the Sigil Stone may be missing or other problems may occur.

Adding Multiple Items with the Same Script

There are some oddities (well, the right words for it I won't use here) when you

1. add two or more items
2. with the same script
3. to the same container
4. at or about the same time.

This seems to happen for several situations:

• You add an item, which in turn adds another item
• An item that runs when the player adds them to a container, or the player takes them from a container
  • For example, if you have 2 of an item in a container (same base object), and the player double-clicks them, thus adding one after the other, you'll hit this bug
  • But using 'AddItem SomeItem 2' seems to work without hitting the bug
• More examples.

What exactly is going is anyone's guess, and the problems that can occur are very, very bizarre making them hard to trace. Also, the bug seems to be intermittent, sometimes working and sometimes not, and some scripts don't seem to run into the problem. The a few points to take away from this:

• Adding two or more items with the same script can produce weird results
• If you're adding multiple items and getting weird results, put a frame or two between when you add one and when you add the other
  • In the right situation, you can avoid the problem by changing the Scriptname of the items
• If there is a possibility of the player running into this situation, be sure to test for it

Activating an object every frame

This didn't cause a CTD with me, but as it causes unpredictable results there is a chance CTD's might occur.

When you have a script that constantly activates a certain object (in my case, to wait for a result that was published inside that object and could be retrieved in this way), other scripts might become unresponsive. I had several onadd blocks in other scripts that weren't executing anymore.

If you have to do this, build in a timer.

Weight Updates

The encumbrance of the player won't be updated if you change the weight of an object (SetQuestObject, SetWeight, etc.). You can add/remove an item to force an update.

MoveTo Oddities

When using MoveTo, you should be careful to avoid several problematic situations, described below.

MoveTo Crash on Loading Destination Cell

This bug is triggered when an object script causes a quest update that moves the player to another location. The game freezes on loading the MoveTo destination. Workaround is to have the object script add a scripted ability to the player and then have the ability script trigger the quest update containing the MoveTo.

MoveTo in Dialogue Result Script

Using MoveTo on the player in a dialogue result script triggers in a hidden bug that silently causes the player's viewing axis to be inverted. The player speaks to the NPC and the screen does a violent spinning motion on the viewport as they're zoomed in for dialogue. This is the only way you'll know that the bug has struck. If the player does not speak to another NPC before saving, then reloading that save will cause the game's viewport to be inverted. The ground will be on top, the sky on the bottom. Moving about becomes difficult or impossible. The affected savegame will probably not be salvageable. Do not use MoveTo in a dialogue result script. Instead, set variables in an NPC or quest script and use those variables to determine where your script should move the player.

MoveTo on Containers

If you use MoveTo or PositionCell on a Container(a chest for instance), even if you update the world art of the Container using GetPos and SetPos, the collision information of the Container will not be updated. Example: If your script moves a chest to different positions inside a room, the chest will visibly move, but the player cannot open it. In order to open it, the player has to go to the chest's starting point. There the player cannot see a chest, but the chest's name will be displayed on the screen, and as soon as the name can be seen, the "invisible" chest can be opened. As a workaround, instead of moving one container around, you can create identical copies of the container, and then enable/disable them. In this case, a script should be attached to the containers which handles the containers' content. This is to ensure that each copy contains the same items at all times.

Another workaround (works also on other 'unmovable' objects), when you get the object at the destination, is to Disable the object in one frame, Reset3DState in the next frame and Enable it in the third frame. The object will flicker, though.

MoveTo for Actors may require pathgrid

In some situations, using MoveTo on an Actor may appear to not work right unless the destination has a valid pathgrid to guide them. The symptom of this problem is that the MoveTo appears to work normally, but the Actor remains at the target only for a few seconds, then is moved to a nearby pathgrid in the same cell. The solution is to make sure the target area for a MoveTo on an Actor has a valid pathgrid, using World...Edit Cell Grid Path in the Construction Set. This isn't really a problem with MoveTo, but it can seem to be such until you realize the underlying cause.