Version 1.0
by Ieldra
Classic mod
conflicts and how to deal with them are a well-known topic among players and modders
alike. Diagnostic tools and methods of repair are available, and the knowledge
about this is well documented.
However,
when playing a heavily modded game, even after dealing with mod conflicts in
the various possible ways, and without having done one of those things that are
known to produce errors in saved games (called “dirty” saves), many players are
still plagued by strange and totally baffling error messages that, at first
glance, seem to appear with no logic whatsoever and afflict in-game items
totally unrelated to any plugin content problems. In this document, I attempt
to pave the way to a game free of these error messages and their probable
causes. Since most of them are not real mod conflicts, but the consequences of
bugs – mostly in the Morrowind game engine, but also in plugins – that only
become apparent when many plugins are used, among which some fulfil a set of
specific conditions, I call this a debugging guide rather than a guide to
remove obscure mod conflicts.
This
document consists of the following chapters:
(1) What
this document does, and does not, deal with
(2) The
tools you need.
(3)
Technical Background
(4) The
causes of most problems
(5) A
testing environment – some practical considerations
(6)
Debugging, pass one: problems that appear without loading a saved game
(7)
Debugging, pass two: problems that appear when loading and re-saving a game
(8)
Debugging, pass three: illegal actions and remaining mysterious stuff
If anyone
who reads this finds any mistakes, anything that has been left out or should be
answered by this document, contact me by PM in the Elder Scrolls forums. I aim
to make this guide as comprehensive as possible. Constructive criticism is
always welcome, even if I might not always be able to answer to it, especially
if you feel that my language is too technical. I’m a programmer, and I feel
that technical matters need precise language, even at the cost of easy
understanding.
Many thanks
go to Wrye for his powerful debugging tool Wrye Mash, without which this would
have been impossible and I would not now be playing a game totally unplagued by
bad references so far, even of the invisible kind.
(1) What this document does, and does not, deal
with
Not covered
in this post are
§
Classic
mod conflicts. Classic mod conflicts are logical within the context of the
mods’ content. If two mods change the same aspect of an object in different
ways, they cause a conflict. If two mods place something in the same place,
probably they can’t be used together without editing one. Things like this are
well-documented and can be detected and removed by various utilities and common
sense.
§
Classic
dirty saves. Meaning the kind of dirty saves you may get by using an old saved
game with a changed mod setup or a changed mod. This topic is also well
documented, and with Wrye Mash, a
utility is available to remove most problems that result if you can’t avoid
changing your mod setup in a running game.
Now, if you’re
just a few hours into a new game, have never used an older save with a changed
mod setup, and if you still get baffling error messages and strange things
happen in your game that seemingly have nothing to do with anything that might
cause a classic conflict, then this debugging guide may help you. It
specifically covers the following symptoms and some of their possible causes:
·
Objects
are doubled, and/or objects that you have already taken reappear after loading
a saved game. If you really didn’t use an old save with changed plugins,
this should never happen to you. It is possible that some mod does this by
attempting something made illegal by another mod, but that is extremely rare.
Most likely it’s caused by a bug.
·
Objects
are gone after loading a saved game. Mods can’t easily, if at all, make an
object added by another mod disappear. If this happens, it’s most likely caused
by a bug.
·
Error
messages like “Can’t load <some spell>” appear when loading a saved game,
but not when starting a new one. Especially if the spell well known and you
suspect that many NPCs and/or creatures have it, like “resist disease_75”.
·
Error
messages “Can’t load script <some script name>” appear when loading a
saved game, but not when starting a new one.
·
Error
messages “Reference <some object > not found in master” appear in-game or
while loading a saved game. Again, if you haven’t changed your mod setup, this
should never happen.
·
Wrye
Mash reports “Bad Refs” for an area you have entered for the first time and
saved immediately.
·
Wrye
Mash reports “Bad Refs” in a savegame file you have saved after having loaded a
saved game (i.e. not for the first save in a new game), and these “Bad Refs”
reappear in your new save when you load the repaired save and immediately save
it again.
(2) The tools you need
In order to
fix the problems associated with the aforementioned problems, you will need the
following tools and utilities:
·
The TES Plugin Tool 1.3 (TESTool)
by Ghostwheel. For a multi-mod setup, likely leveled list and object merging is
necessary. You will have to remerge your objects and leveled lists often while
testing. Note that Wrye Mash’s leveled list merger seems to have a problem with
the Giants Ultimate plugin if you have used TESTool to clean it (not advisable,
I’m told, but I’ve had no ill effects), so I continue to use TESTool for
merging leveled lists. In that case, you will also need the Leveled
List Resequencer that corrects the results of a bug in TESTool.
·
Wrye Mash
version 0.60 or later. Version 0.60 adds the new function “Renumber
References”, so earlier versions will not help you with the two problems being
most often responsible for the aforementioned symptoms.
·
The
Morrowind Enchanted Editor (often abbreviated as EE from here on), version 0.91c, including its manual
(since the original link is dead, I have put in on my homepage). If you find
the time, familiarize yourself with the esp file structure somewhat. I’ll
explain the most important stuff below, but reading the manual may help you
putting it into a context.
(3) Technical Background
Sorry, but
this is really necessary. You can’t debug your mod setup, especially not if you
have the kind of problems that made you read this post up to this point, without
a detailed understanding of what you’re doing. You can get most of this
knowledge from Scripting
for Dummies, Wrye
Notes, Wrye’s Doubling
Explained, the Enchanted Editor
Manual and the UESP Wiki
(as I write this, the link is dead but will hopefully reappear soon), and if you’d like to go hardcore this ESP file structure
documentation (I don’t know the author – it’s not by me) will be very
useful – but I’ll cover some of it
again here. Here is what you should know:
·
Objects
and references and their differences. If you’re a modder, you will already know
this (and if you don’t, learn it before you make your next mod. Immediately!).
Anyway, familiarize yourself with the terms “object” and “reference” within the
context of the Morrowind game engine. “Scripting for Dummies” and other
documents cover this in detail, so I’ll give you the short version: a
“reference” is what you would call an “object” in everyday language –
everything that you see in the render window of the Construction Set, or in the
game world when you play, is a “reference”, a realization of a template. The
term “object” refers to this template, and these are what you see in the
objects window of the Construction Set.
·
The
Construction Set (often abbreviated as CS from here on). You should know how to
work in the render window of the Construction Set. The best guide to the
Construction Set is the Morrowind Mod
Maker Manual V2. You needn’t know about landscaping or dialogue, only about
the render window and what a “cell” is.
·
What
esps and esms can and cannot do (see Wrye
Notes). In short, esp files cannot change references added by other esp
files, and esm files cannot change references added by other esm files.
Attempts to do so may result in doubling, and possibly “Bad Ref”s reported by
Wrye Mash. Note that illegal actions attempted by esms or esps are rare. Those
I have discovered will probably have no negative in-game affect above the
cosmetic level.
·
The
in-game console. You should know some of the commands you can use here,
especially “coc”, “coe” and “ori” (see Scripting
for Dummies).
·
What
“master” files are. In short, within the context of the Morrowind game design,
a master file is any file that is necessary to be present and loaded into
memory for another one to load correctly. As a rule, a plugin file’s masters
are the Bethesda esm files and, if the plugin is an esp file, possibly one or
more plugins that come in esm format. Most importantly, the masters of a saved
game file (.ess) are all the original .esm and .esp files that were loaded when
this game was saved.
·
Mod
indices and object indices. Every reference placed into the world has a unique
identifier made up from a “modindex” and an “objectindex” (also see Wrye
Notes). This is most important for this document, so I’ll cover it in some
more detail:
o The modindex: The modindex is the
number of a mod in your list of activated mods. If you look into your
Morrowind.ini, near the end you see a list of file names preceded by
“GameFilennn=filename.es*”. If the list is ordered alphabetically, start
TESTool, select “manage active plugins”, and in plugin selection window hit the
“Load Order” button, then OK. Your Morrowind.ini will be updated to present its
plugin list sorted by load order. Look into it again: the number (given as
“nnn” above) following “GameFile” is the modindex for the plugin file activated
with this line. Note that the numbers start with zero. Wrye Mash presents this
modindex with an index base of 1 instead, so when you interpret the modindice
reported by Wrye Mash you must always subtract 1 from them to get to the right
GameFile entry in Morrowind.ini. Furthermore, the modindex depends on load
order only, not on the way the list in Morrowind.ini is ordered. If that list
is ordered alphabetically, you will not be able to interpret Wrye Mash’s output
correctly. Some utilities set the list order to alphabetical, most importantly
TESTool – so when using TESTool, remember to always hit the “Load Order”
button before you leave the plugin selection window.
o The objectindex. When someone makes
a plugin that adds at least one reference to the game (not all do so), the
Construction Set gives those references numbers to identify them within this
plugin. It numbers the added references sequentially, always (!!!) starting
with 1. Due to a bug in the Morrowind engine, this has some evil consequences
that are responsible for a whole range of the symptoms mentioned in Chapter 1.
The CS also follows the same “geographic” pattern – it starts with exterior
cells, from the upper right corner of the map in columns, so to speak, down to
the lower left, then follows up with interior cells in alphabetical order.
Unfortunately, this repeating pattern exacerbates the problems.
(4) The causes of most problems
The
symptoms described in Chapter 1 above may appear in an otherwise clean game
under certain conditions. Any one of the symptoms might result from any one of
these conditions, and it is not predictable which one it will be outside of
exactly defined testing conditions:
·
(I) Two
plugins place references in the same cell to which the Construction Set has
assigned the same object index, one of the pair has the “references persist”
flag set, the other has not, and the latter has been changed and included into
the saved game. This is covered in some more detail on the UESP Wiki under “Mod
Conflicts: Local References”.
·
A
plugin places a leveled creature into the same cell as another plugin places a
leveled creature or NPC in, and the CS has assigned the same object index to
both. This may be a permutation of (I), but current understanding is that
creatures are always persistent, so leveled creatures shouldn’t cause this. But
my tests indicate that they do. This usually results in vanished leveled
creatures or NPCs.
·
A
plugin adds a reference to an object with a script on it to an existing area,
or changes an existing object with references in an area to have a script, and
there is among these a reference with the same object index as any one
reference placed by another mod in the same cell. This may also be a
permutation of (I).
·
A
plugin attempts to move a reference out of its original cell, instead of
deleting it from its old cell and placing a new reference in the new cell.
Moving references between cells might or might not be technically legal, but
whether or not it is, it causes bugs. Doing this with the CS in exterior cells
is easy – and it’s almost as easily overlooked that you have done it. My
knowledge of the Construction Set is far from complete, but so far I have not
found a way to move references out of interior cells.
·
A
plugin creates a second copy of an existing reference added by another plugin
or esm file, but keeps it in exactly the same place and does not change it in
any way. As a rule, this is considered “dirty”, but it is technically legal and
should not result in any errors. But sometimes it does.
(5) A testing environment – some practical
considerations
This
chapter gives some advice to make testing and debugging easier in practice.
It’s mostly common sense advice, but if you’re frustrated by baffling error
messages you’ll possibly think of this only after all the work has already been
done. Make your life easier and set up your game and tools like this.
·
Setting
dates on your mods. Your plugins should consist of – for the purposes of
debugging – three groups: (I) the mods that should not be merged, like
MultiMark, Private Mobile Base and a few others. Set their file dates to some
day far in the future. (II) all other mods excepting merged_objects.esp and
merged_leveled_lists.esp (or mashed_lists.esp). Set their dates to some day(s)
in the recent past. Group and order as you prefer or as required by the mods
themselves. (III) merged_objects.esp and merged_lists.esp. Set their dates to
yesterday. If you use Wrye Mash for this, it will remember the dates and always
automatically reset them if some other tool changes them. The background for
this is that whenever you remerge your objects and forget to run Wrye Mash to
correct the dates (it happens in the heat of this work), the merged files will
keep their place in the load order anyway. It also makes deselecting the mods
which must be excepted from merging easier because they will always be at the
end of the list. You could use Wrye Mash’s list features for this, but in a
testing environment the lists change often, changing Mash’s load lists every
time is a PITA, and attempts to use lists that include mods that no longer
exist result in error messages and do nothing. I find it easier to use TESTool
and select and deselect manually.
·
Convenient
placement of tools. Place links to TESTool, Wrye Mash, Leveled List Resequencer
and Enchanted Editor onto your desktop. You will be able to work so much
faster...
·
Running
TESTool and Wrye Mash at the same time has some inconvenient consequences –
when you use TESTool to select/delect mods this can cause Wrye Mash to report
errors when you switch back to it. Since you must probably deselect some mods
before any merge operation, and only TESTool can merge objects, it is most
convenient to do both with TESTool. I always end Wrye Mash before any merge
operation, and restart it after.
·
You
will be starting many new games. The QuickChar
plugin will enable you to do this without reducing your computer to scrap metal
in frustration about the wasted time.
·
While
testing, you won’t like being bothered by long travel times, the inconvenience
of enemy encounters and suchlike. The BAR_RingPack
plugin will give you a set of cheating rings that enable you to fly fast and be
much less vulnerable. And using the Runestone
plugin for moving around is preferrable to using “coc” in the console for many
locations because you arrive at meaningful places, not below the landscape line
etc.. The RingPack will also very likely produce an additional error message if
any other mods are active that add things to the Census and Excise Office. I’d
say this makes for a good practice run for Debugging, pass two (see Chapter 7
below)
(6) Debugging, pass one: problems that appear without loading a saved game
One thing
in advance: if I say: exit the game, restart it and load the save, then I mean exactly
that. Never, ever load a save from within the game, however time-saving and
convenient it may seem. This is a good rule for all running games (which I
always follow when I play), but for testing it is essential. I won’t go into
the technical details here, but believe me, you won’t get any meaningful
results if you ignore this.
OK, now
into the gory entrails... er... the messy details. You have a mod setup that
should really function reasonably well together, you have played for a couple
of hours, saved and re-loaded a few times, and despite never having changed
your mod setup in this particular game, you get doubling and/or reappearing
objects, strange error messages etc..etc.. as described. I assume that you’re
using all three of the convenience plugins mentioned above. Here’s what you do
now:
(6.1)
Pass one, making the bugs appear
Start a new
game. Talk to the Legion officer, go back to the tutorial building and get your
ring of levitation and invulnerability from the small chest behind the table.
Leave the Census and Excise building. Save your game in a new slot. “COC” to
“Balmora, Guild of Mages”, then walk down and get the Runestone from the travel
platform. Walk out of the Mages’ Guild. Wait a few seconds and save your game
in a new slot. Teleport to the Sadrith Mora harbor (Runestone: boats M-Z). Walk
down to Wolverine Hall (until the cell name “Wolverine Hall” appears in the
lower right corner of the screen, meaning you have entered the cell named
“Wolverine Hall”). Wait a few seconds and save your game in a new slot.
Teleport to “Vivec, Arena”. Go outside. Wait and save your game in a new slot.
Teleport to Gnisis. Wait a few seconds and save your game in a new slot. Save
your game in yet another new slot Exit the game.
(6.2)
Pass one, diagnosis
Run Wrye
Mash. Click on the “saves” tab, look for your latest save and select “Repair
All” from its context menu. This will take some time. You will be “rewarded”
with a list of error messages. If no messages appear, you can count yourself
lucky. Unless you want to check some more popular locations like Dagon Fel or
Vos, you can now proceed to (7) Debugging, pass two. But if you have two or
more of Morrowind Comes Alive, Creatures, Vampire Realism and Amulet of Scrye,
to name only a few – namely, any two mods that add leveled creatures to many
locations, you’re unlikely to pass this with no error messages. If you get too
many error messages, that means that your game has many problems, and you might
get confused. It might be advisable to check and debug an earlier save first.
It’s your choice.
Anyway,
let’s have a look at those error messages. You will see one or more of three
kinds of messages followed by a summary of the number of deleted and rematched
references. In fact, it is possible that you get something very similar to this
combination (summary not quoted):
[18,4]
BAD
REF>>REMATCHED 9 1
vr_ex_aundae_town_rare 102
[18,3]
BAD
REF>>NO MASTER 9 9
_mca_imperial_soldiers_random
[18,3]
BAD
REF>>DOUBLED 128 9
_ivza_04_npc_merc3_1
The numbers
in square brackets point you to the cell where this error has occurred. In this
case, since you see only numbers, you know this is an exterior cell. For an
interior, a name would be given, for instance “Balmora, Guild of Mages”. “BAD
REF” does, of course, mean that a reference has gone bad. A “bad reference”
means that something in your saved game cannot be correctly matched to its
source in the esp and esm files you’re using. Since you haven’t changed your
mod setup, this really shouldn’t happen. REMATCHED means that Wrye Mash has
found another mod with a reference using the same ID and objectindex, that this
combination is unique, and that it has assigned the reference to that mod. NO MASTER
means that Wrye Mash found more than one reference in any of the savegame
file’s masters (including all active plugins) that correspond to this
reference, and couldn’t decide which one is correct. DOUBLED means that a
unique corresponding reference has been found in a game file but it was already
assigned to another reference in the saved game.
Now look at
the numbers following the text. the first number is the modindex of the plugin
that has placed this reference, according to the data in the saved game. The
second number is the object index of the reference, and the number at the end
of line in the REMATCHED message is the modindex of the plugin Wrye Mash has
assigned to the lost reference to repair it, using data from the saved game’s
master files (the plugin esms and esps). The name in-between is the name of the
reference’s object template. If you loaded all your mods into the Construction
Set you could see this name somewhere in the objects window.
What to
leave alone for now:
If you see any object indices between 100000 and 500000, ignore them!!! These
are references placed by the original game, and anything involving them will be
dealt with in chapter 8.
Now look
into your Morrowind.ini. Suppose an excerpt of it, using the modindex numbers
reported by Mash, looks like this:
GameFile8=Morrowind
Comes Alive.esm
GameFile101=Vampire
Realism II.esp
GameFile127=
Amulet of Scrye.esp
You have
now identified the mods that, in combination, cause the problem. To check this,
start Enchanted Editor. Load up “Amulet of Scrye.esp”. Select “Edit/Find All”
in the menu and type “_ivza_04_npc_merc3_1” into the search field. Then click
on “Find all”. You will get a list of instances where this ID appears in this
esp file. In this case, there are only two: an NPC_ record and a CELL record.
References only appear in CELL records, so the first one has to be the
definition of that NPC, the second one tells you where this NPC has been placed
in the game world. We aren’t interested in that NPC’s details, so select the
CELL entry in the list and click on “Go to reference”, then cancel the search
window. In the left part of the window, the CELL record for “Wolverine Hall,
Azura’s Coast Region” has been opened. Click on the header “CELL Wolverine
Hall.....” to make a list appear in the right part of the window. This list
contains everything this esp file adds to this cell, and everything from an esm
file it changes (nothing of the latter here – all references have low
objectindices). Note the numbers in the GridX and GridY entries: 18,3 (if “Find
All” finds too many entries and you don’t know where to look, remember that the
names of named exterior cells are shown in-game when you enter them. The cells
list in Enchanted Editor is sorted alphabetically). If you scroll this part of
the window down, you will find a NAME_NEXT subrecord containing
“_ivza_04_npc_merc3_1”, preceded by an FRMR subrecord with the objectindex of –
surprise – 9, and a flags field you can ignore. Do the same with the Vampire Realism
and MCA files.
You can now
interpret the error messages as follows:
·
A
reference in 18,4 falsely assigned to Morrowind Comes Alive.esm by the savegame
file was correctly rematched to Vampire
Realism II.esp
·
A reference
in 18,3 assigned to Morrowind Comes Alive.esm by the savegame file could not be
matched with a reference of any plugin with the same objectindex in a
non-ambiguous way. The reference was deleted.
·
A
reference in 18,3 assigned to Amulet of Scrye.esp was found to be already
matched. The double was deleted.
In-game,
you probably would have never noticed that a leveled creature and an
unimportant NPC have disappeared, but now you know. Take special note of the
combination of error message 2 and 3. A NO MASTER combined with DOUBLED tends
to be rather common, and if you see this and notice that the objectindices of
both references are the same and they appear in the same cell, you immediately
suspect that
·
a
modindex mixup has occurred – a reference was matched with a wrong mod (this is
called “reference mismatching”)
·
the
saved game is at fault, since you haven’t changed any mods in your setup, and
the mods you’re using are popular ones that should be reasonably bug-free.
·
this
wouldn’t happen if the two mods didn’t place references with the same
objectindex.
Indeed,
these hypotheses happen to be completely correct. The reference mismatching is
a bug in the game engine. I’ll tell you how to get rid of this next. For now,
save your list of error messages, especially if you have a long one. If you
forget this, this is what the double-save at the last stop was for :). If the
list is long and messages appear for many cells, you might want to look at one
cell after the other, group the error messages accordingly and deal with them.
Or, as I said above, deal with a earlier of your saves with fewer error
messages first.
(6.3)
Pass one, repair
As opposed
to pass two, for this there is only one way to get rid of the annoying, but
most likely not game-breaking errors: renumber the references in the afflicted
cells. You could do this manually – in fact, I had started to do this – but it
is a very time-consuming way to do it. Wrye Mash, as of version 0.60, has a
function that does this automatically. It is used just like the Repair All
function – start Wrye Mash, select the “saves” tab and select “Renumber Refs”
from the selected savegame file’s context menu. Here are some guidelines on how
to use it:
·
The
Construction Set automatically assigns objectindices when you save an esp file.
You have no influence on the numbering. So when you prepare for playing, try to
avoid using Renumber Refs on mods which you are likely to edit. If you must
edit a renumbered mod, then you must rerun Renumber Refs after you have saved
and cleaned the mod. The new version will only be compatible with old saves if
you haven’t removed or added anything. Since the CS adds extraneous entries,
this is a condition hard to fulfil unless you use TESTool’s cleaning function
before every renumbering. Getting things wrong might be repairable by Wrye
Mash’s Repair All function just like every other dirty save, but it might also
mess up your saved game beyond recognition. Be careful.
·
When
renumbering, you can type in a starting number of your choice. To ensure unique
indices, you should choose yourself. Start with 10000 – landscape mods with
higher counts are unlikely to cause problems, and quest mods of that size are
very rare. Add the number of renumbered references Mash reports when its
finished, and add an additional small buffer of 50-100 to get the starting
number for the next mod. Always remember this last number to have a starting
point for the next renumbering. Mash will remember all the starting numbers for
you.
·
To
renumber an esm file, change its file extension to esp (don’t use any
conversion utility, just change the file extension), then run Renumber Refs,
then change the file extension back. BUT: This will mess up all esp files that
depend on that master and change any of its references, resulting in *correct*
“cannot find in master” error messages. One example: If you Renumber Morrowind
Comes Alive, the mod that gives its NPCs names (MCAnames4.1lorecorrect.esp)
will still function because it changes no references (you can check this by
loading it into Enchanted Editor), but the Redesigned Vivec compatibility patch
will have to be completely remade because it moves leveled creatures. If you
run Mash’s Repair Refs on a mod affected thusly, likely the now-orphaned
references will be removed. As a result, the esp file will function without
error messages, but it will not do to the references what it intended to do.
EXTREME DANGER NOTICE: don’t do this do Bethesda esms. If you do so
accidentally, you must re-install the game and all expansions and plugins.
·
Within
pass one, the mods likely to cause trouble are those that add references to
many exterior cells. So, if you’re at it and you’re going to start a new game
anyway, renumber a bunch of them, as a prevention measure, just in case. I have
done this to MCA, Creatures, Expanded Sounds, Illuminated Windows, Redesigned
Vivec and Complete Trade Fix, among others, with absolutely no ill effects.
·
I
don’t know if Mash is limited to starting numbers below 100000 as Wrye said it
would be. Morrowind uses indices between 100000 and 1000000, so NEVER USE
THESE, even if you can. Avoid numbers below 10000 because they may be used by
too many other mods. If possible, I would prefer numbers above 1 mil. because
of the wider range, but if it is not possible, then you only have a range of
90000 and need to be selective. After all, landmass mods are highly unlikely to
cause these problems.
(6.4)
Pass one, extension and conclusion
It is
possible that you will find all bugs in one go. If you renumber a bunch of
wide-ranging mods after checking your first save, you might be reasonably sure
to never encounter the problems corrected in this pass again. Check this:
recreate your merged objects and merged leveled lists files, start a new game
and do the same as described in (6.1). Run Wrye Mash on the latest save. If
it’s clean, this pass has been successful for the locations you have visited.
You might or might not want to check other popular locations. You can be as
thorough as you like. Only remember this: if you load a saved game even once
and go on to save it again, error messages will appear that have nothing to do
with this pass. That may result in confusion. Anyway, it’s likely that you can
get to a point where no bad refs exist in a game you never re-loaded. It may also
be that the same problems, at another place, appear only in games that have
been loaded at least once. This is what you will deal with next:
(7) Debugging, pass two: problems that appear after loading and re-saving a game
(7.1)
Pass two, how to make the bugs appear
Start a new
game with a sneaky character. Go back into the tutorial building and get the
rings of Levitation, of Chameleon and of The Gods from the chest behind the
table. Make sure to empty all containers you can find, most especially any
added by mods (you can use the console’s ORI command to give you the name of
the file that has placed a reference). Pick up Fargoth’s ring and give it to
him. Go to Arrille’s. Buy and sell a few things. If necessary, cheat yourself
to some gold (console: player->additem gold_001 32750). If you have a mod
that changes Arrille’s, put on the Ring of Chameleon and steal one item from
every container in his house. You may skip this if it’s too difficult. Go
outside and use the console to unlock the door to Arrille’s storage. Skip this
only if you are sure you have no mods that place anything there. Go in and
steal one item from every container. Go out and use the console to unlock the
Census and Excise Warehouse. Go in and steal something from every container. If
you run any mods that place containers out in the open, make sure to steal from
every one. Save your game and exit the game (I said EXIT!). Restart it and load
your saved game. Error messages may appear during loading if you have problems.
Ignore them and continue - even if none appear that’s no guarantee. After your
game has loaded, wait a few seconds to give any delayed scripts the time to
kick in, and save your game again. Save your game yet again in a new slot (as a
backup). Exit.
(7.2)
Pass two, diagnosis
Run Wrye
Mash. By now you should know how to run Repair All. You should also be familiar
with the error messages you can expect. They are all of the same type as
mentioned above in Chapter 6. They are to be interpreted exactly as above in
(6.2). The only difference is that this kind of error only appears after a
saved game has been loaded once, the error messages may be localized, so
debugging many areas in one go will not always work, and there is an additional
method of removing the problems.
BTW: If you
have any other mods besides BAR_Ringpack that add anything to the “tutorial”
building, BAR_RingPack will probably appear in the error report – the chest it
places is not set to persistent, and you change it by removing the rings. Think
of invisible activators – this bug can make them vanish! I’ve had this effect
with the activator that starts Galsiah’s Character Development’s scripts.
What to
leave alone for now (it
isn’t Chapter 8 yet): If you see any object indices between 100000 and 500000,
ignore them!!!
(7.3)
Pass two, repair
Again, you
can always run Renumber Refs on any esp file that you find to cause problems.
But if you want to edit a mod, that has its disadvantages (see (6.3)). That’s
why I present an additional method of bug removal. Yes, it is more
time-consuming – but you will be able to edit the mod (this is also a good
guideline for new mods) without any ill effects.
You will
now want to find the references responsible for the errors. You should still
have Mash’s error report onscreen. Look up the references with the identical
objectindices, using Enchanted Editor (see (6.3)). In the case of rematched bad
refs, this is easy – the mod causing the problem may be identified by the first
modindex in the report line, and the target by the second, or vice versa. In
any other case, it might not be so easy. If the object is relatively rare, you
might be able to find the problematical one by doing a text search on all your
esp files. But if you can’t find both references in the pair easily, ignore it.
You only need to change one side to remove the bug.
When you
have found the problematic reference, check if it is a container. It should
appear in EE’s list of containers if it is one. If it is, then start the CS and
load the plugin in question if you haven’t already done so, focus on the object
window and select “Containers”. Look the ID up. Is the checkbox “References
Persist” checked? If no, check it and hit the “save” button. Go back to the
data file selection window and open up the “details” for this mod. Is there a
line labeled TEMP_REFs? If yes, look up the IDs of everything below this line.
If it is a container, or there is a script on it, then the “References Persist”
checkbox, if any exists for this object type , must be checked if it is
unchecked. Don’t forget to hit the button every mod tutorial tells you to avoid
– the “save” button in the object information dialogue. After you’re done, save
the plugin and exit the Construction Set. Run any necessary cleaning with
TESTool, TESAME or whatever cleaning tool you prefer, then run Wrye Mash to
make it reset the file date. Repeat this for every mod that appears in any of
Mash’s error messages.
...or you
could just run Renumber Refs on them.
Some things
to consider:
·
Mods
that add very many non-persistent containers and scripted objects are probably
better served by renumbering the references. Setting references to Persistent
may have an effect on performance, or increase the size of the savegame file,
or something more. On the other side, this method survives the Construction Set
intact, so if you’re making a mod or frequently editing one, this is one method
of avoiding future troubles for everyone who will use this “persistent-ized”
version of the plugin.
·
Making
things persistent will most likely not remove any bad reference problems that
appear without loading and re-saving a saved game. Only renumbering will do
that. But if any plugin has caused these and has been renumbered in Pass one,
it shouldn’t appear in this section at all.
·
If you’re
the creator of a mod that causes this kind of problem, you could also choose to
move the affected reference to another cell, preferrably one not often changed
by other mods.
·
I have
had at least one instance where my impression was that references in neigboring
exterior cells were affected as well. I have not tested this, and I consider it
unlikely that this impression is correct – but it should be mentioned.
(7.4)
Pass two, repeat for other locations
As I have
said, every location must be debugged separately. A successful debugging means
that you start a new game (yet again, I know) and do everything else mentioned
in (7.1), and Wrye Mash produces no more error messages that can be explained
by reference mismatching. After you have debugged Seyda Neen, you can, of
course, dispense with all the time-consuming stealing there and proceed to to
the same in Balmora or Sadrith Mora immediately. But remember to change the
contents of containers added by mods if you can identify them without spending
too much time on it.
Of course
you will not want to check all of Vvardenfell this way, do you? No, even I
didn’t get that obsessive. After Seyda Neen, I only did this in Sadrith Mora
and Gnisis, where many things happen out in the open, and in the Mages’ Guild in
Balmora, because many small mods add things there. In every other town I just
saved once without having done anything, exited the game, re-started it, loaded
the save and re-saved. This will not find anything caused by containers changed
manually, but it will find problems caused by items changed by a script.
(7.5)
Pass two, prevention measures
Mods that
make changes to popular locations, and among these, those that make changes to
exterior cells, might be treated with the Renumber Refs function as a prevention
measure. After those already mentioned, wide-ranging quest mods are good
candidates. I did this to Black Queen Chronicles, Amulet of Scrye, and Suran
Underworld. Maybe I should have done it to Illuminated Order as well.
Otherwise,
you will, very likely, now be able to run a game with an much reduced frequency
of baffling error messages, inexplicable doublings and vanishings, and equally
inexplicable CTDs. Most of your saved game files will have no bad references,
not even hidden ones that you never notice in-game.
(7.6)
Pass two: if anything happens after having played for 250 hours....
Then it
might just be possible to correct this... if it works, consider this your final
victory over the bugs in the Morrowind game engine. It might not work if you
have interacted extensively with the reference in question in a non-reversible
way, but then again, it deserves a try if that can prevent something important
from vanishing into thin air – just
backup the esp files you’re going to change and your saved games first (don’t
forget merged_objects.esp and merged_lists.esp). If it turns out that another
mod needs extensive reference renumbering, then your luck is bad, but most
likely it’s just one reference that’s gone bad. After you have identified the
reference in question (you should know how to do this by now), open your saved
game (!!!!!) in Enchanted Editor. Look for the cell entry for the cell reported
by Wrye Mash. If you find the reference in question in there, give it a new
objectindex, something like 1200003 – remember to use unique numbers, but don’t
use anything above 2147483647 (the biggest number for a signed long integer, if
that tells you anything). Save your ess file, then open the esp file that
places this reference (if you don’t know from the report, you can either ORI it
in-game or do a text search on all esp files in your Data Files folder), and
give it the same new objectindex. When you load that save you might get
doubling and even an error message. If you do, then save again, exit and repair
your save the usual way. After this the problem will be gone and will not
reappear.
(8) Debugging, pass three: problems caused by illegal actions of esp and esm files
If you have
a saved game, and Wrye Mash reports a bad reference on a reference with an
objectindex between 100000 and ca. 500000, i.e. a reference that the original
game places there, then here are two possible causes.
(8.1)
Pass three: illegal actions by esm files
You can
produce this easily by using the Unofficial Patch 1.6.3 together with the
Wolverine Hall Mages’ Guild Expansion (Clean Guild Expansion WHM.esp). I don’t
recall if it is really necessary to load and re-save to get this, but if you
load a saved game in which you have been to the Wolverine Hall Mages’ Guild at
least once (no interaction with anything needed), and immediately save it
again, with the aforementioned mods active, Wrye Mash will report something
like this:
Sadrith
Mora, Wolverine Hall: Mage's Guild
BAD
REF>>REMATCHED 11 369090
chest_01_v_potion_al_02 116
The
corresponding Morrowind.ini entries, in my case, have been:
GameFile10=Morrowind
Patch v1.6.3.esm
GameFile115=Clean
Guild Expansion WHM.esp
From the
number, you know this is a reference placed by original Morrowind. If you look
into the Unofficial Patch using the Construction Set, you will notice that it
attempts to change ownership of this potion chest. Ownership is a data item
that belongs to the reference, and one esm can’t do this to a reference placed
by another esm. Current understanding says that a new reference with the same
objectindex will be created, resulting in confusion when loading the cell into
memory. I suspect that things may be somewhat different because no doubling is
reported, but however you look at it, the esm attempts something illegal, and
if you use Enchanted Editor to remove the entry changing that chest from the
Unofficial Patch, the problem will be gone. Here’s how you do this:
Open
Enchanted Editor and load the Unofficial Patch. Go to the CELL record for
“Sadrith Mora, Wolverine Hall: Mages’ Guild”. There is one NAME_NEXT entry in
the list, and indeed it is this potion chest. Look at the items highlighted in
grey in the left part of the window. These are the entries that, combined,
would, were this an esp file, produce the desired changes of the reference.
Check the boxes left to all of them, from the FRMR to the DATA_24 entry, then
hit the DEL key. The entries will be removed. Please note that NAM0 is
highlighted brown, not grey, so don’t touch it. This entry contains the number
of objects in the cell and will be updated automatically. But to be economical:
It seems this is the only change attempted in this cell by this esm – the only
thing that could change anything else here is the AMBI entry (ambient
lighting), which most likely does nothing. In my case, I have deleted the whole
subrecord for “Sadrith Mora, Wolverine Hall: Mages’ Guild” from the Unofficial
Patch.
You have
now removed this bad reference problem, but you have to forego the (probably
plausible and desirable) ownership change attempted by the Unofficial Patch. Or
you could go really hardcore and edit Morrowind.esm (this is – need I
say it – not recommended).
It might
also be that this problem never appears, even if the esm action is illegal,
unless an esp attempts a (completely legal) change of the reference in
question.
(8.2)
Pass three: illegal actions by esp files
I don’t
know if it is technically illegal for an esp file to change an original
Morrowind reference that another esp file has already changed – but I have found
at least one instance where this seems to have been the cause of a bad
reference. The best way to deal with this is to merge the plugins in question:
load both plugins into the CS, but mark neither as active. Select “Combine
Loaded Plugins” from the File menu and will be able to save the combined plugin
to a new file. Alternatively, you could use EE to remove one of the entries
from one plugin file as described above for the Unofficial Patch.
(8.3)
Pass three: remaining mysterious stuff
Sometimes
you get a bad reference on an original Morrowind reference for no detectable
reason at all. It is reproducible, it happens to the same reference every time,
but you track the mods responsible and can’t find anything wrong. In one
instance, I have been able to remove this by loading the plugin into the
Construction Set, and saving it again without any change. In one other case, I
have re-combined the plugins the affected one was made up from, and the problem
was gone. I don’t know the cause, but sometimes this helps. Anyway, all of this
kind have had no noticeable consequences apart from Wrye Mash’s error message.
This
concludes my debugging tutorial. It is, admittedly, somewhat technical, but if
you’ve experienced enough frustration, you’re probably ready for it. And many
modders will probably be happy to know that they have done nothing wrong. Have
fun and enjoy your game!!