Morrowind Mod:Mod Conflicts

IntroductionEdit

Even clean, perfectly designed mods can cause problems if they conflict with other mods. Mod conflicts happen when different mods: modify the same object; place conflicting objects in the same cells; or sometimes, for more obscure logical reasons. (E.g., one mod might cause you to die of hunger if you don't eat at least every other day, while another mod locks you in a cell with no food for three days!)

Diagnosis

• Use TESPCD, TESTool or Tes3cmd to detect data conflicts.

Repair

• Change the mod load order.
• Merge changes from the mods. E.g., merge the leveled lists, dialog, or objects.
• Create a patch esp to resolve the conflict.
  • Many mod authors provide patches to resolve conflicts with other popular mods. (E.g. Morrowind Comes Alive comes with a patch to resolve a conflict with Necessities of Morrowind.)
• See below for additional solutions for particular types of conflicts.

Exterior Cell NamesEdit

If two different mods rename the same exterior cell in different ways, then the last mod wins. Possible problems would be:

• Dialog fails to fire.
  • E.g., Haldenshore adds a town next to Seyda Neen, and names the cell. But Firemoth adds some objects in the same cell and has that cell name set to the default (None). As a result, dialog that is supposed to fire for NPCs wandering around Haldenshore doesn't fire, because the cell name no longer matches the imposed cell test.
• Scripts fail to run as expected.
  • If some script action is triggered by your presence in a cell, then that script may fail to fire.

Avoidance/Repair

• Change the load order of the mods.
• (?) Use TESTool to merge changes to the cell from the two different mods.
  • This would resolve the Firemoth/Haldenshore problem, but not a case in which two towns conflicted. Of course, if two towns are occupying the same area, then cell names is probably only part of the conflict.

Interior Cell NamesEdit

If two different mods contribute interior cells with the same cell name, then hmmm... I'm not sure, but I imagine that their contents would go into the same cell. Possible problems would be:

• Spatial collision between objects placed by the different mods. But this might not be too bad, since cell space is huge, and placed interiors can often be far apart.
• See also Local References below.

Avoidance/Repair

• Avoid obvious interior cell names. E.g., "Abandoned House", "Seyda Neen House", etc.

LandscapeEdit

If two different mods change landscape in the same cell, then the last mod to load wins. This is likely to cause several problems:

• Landscape Tearing
  • If the first mod changes landscape in cell 10,11, and 10, 12, but the second mod changes only cell 10,12, then the landscape will "tear" between cells 10,11 (taken from first mod) and 10,12 (taken from second mod).
  • Objects from the loser mod will likely end up either floating above the ground or buried within it.

Avoidance

• Don't modify the landscape unless you absolutely have to. Do not modify the landscape in popular areas (Seyda Neen) at all.
  • For placed structures whose bases threaten to float out of the landscape, you can place a platform under them. E.g., some landscape rocks, or one of the Imperial platforms, etc.
  • Example: Living Cities of Vvardenfell adds some extra buildings in Seyda Neen and places them on new platform meshes.
• Place your spiffy new area out at sea.
• Don't modify landscape in any more cells then you need to.
  • Turn on border view and flatten the vertices at the edges of your mod down to sea floor level.
  • Use the TESCS detail view to eliminate accidental changes to cells/landscape.

Repair

• Use TESFaith to move cells of different mods so that they don't conflict with each other.
• Create a patch mod which manually stitches together landscape changes. (However, this won't fix he floating/buried object problem.)
• Use the merged_lands tool Merged_Lands

Local ReferencesEdit

As part of its savegame loading process, Morrowind will sometimes misassign changes to a ref from one mod to a ref placed by another mod. This is a bug in the Morrowind engine, and cannot be corrected, only avoided. The results of this bug vary, but can include mysteriously disappearing objects, containers whose contents don't change, and CTDs.

The conditions under which the misassignment occurs are:

• The two mods (A and B) place references into the same cell with the same objectIndex number.
• One of the references is for a refs persist object, while the other ref is not.
• The non-persistent ref has been changed, i.e., is recorded in the savegame file.

Under these conditions, Morrowind will modify the savegame's record of the non-persistent reference so that it has the modIndex of the persistent object placed by the other mod.

Note that while Wrye Mash's Repair All function will fix the reference Morrowind will just break the fixed reference as soon as it runs again.

Notes

• Doors, NPCs, creatures are automatically persistent. (That's why they don't have a "Refs Persist" checkbox.)
• You can distinguish persistent from non-persistent refs in the Details view of TESCS. Anything under the __TEMP_REFS__ line for a cell is non-persistent, while anything above it persistent. If there's no __TEMP_REFS__ line, then all of the refs are persistent.
• Local ref conflicts are usually seen in popular cells (Seyda Neen, Balmora), and the usual effect noticed is a missing door or NPC.

Diagnosis

• Using Wrye Mash:
  • Start Wrye Mash and run Repair All on the savegame.
  • Start Morrowind, load the savegame and save it again.
  • Quit from Morrowind, start Wrye Mash and run repair on the new save game.
  • If Mash has to repeat a repair that it just made, then that reference is suffering from a local ref conflict.
  • You'll be able to determine the problem mods from the modIndex numbers in Mash's repair report. (Match those numbers against the numbers in the masters list.)

Avoidance

• Don't place items in popular exterior cells! Obviously, this is not always desirable or possible. But if your mod allows you the choice, then it's safer to put it in a new or unpopular cell.
• Place a non-persistent object which is guaranteed not to change state. My Portal orbs and Mystica activators are an example -- they use the 'dontSaveObject' command, and thus should never cause a problem. Of course, statics should be safe too.
• Place a persistent object. If it's not naturally persistent, make it so. (I.e., check the "refs persist" checkbox. Of course the problem with this approach is that while now the object might not cause a misassignment, it might instead become a target of misassignment. And misassignment targets tend to disappear. Still, you've made the world a less polluted place, and overall chances for conflicts should drop.
• Somehow guarantee the objectIndex number is so high that ObjectIndex overlap is unlikely. However, I bet this is hard to do given the existence of mods like Balmora Expanded which place a huge number of refs in popular towns.
• If the non-persistent item is a merchants storage chest, you might be able to set the quantity of items in the chest to negative. Negative items are permanently in stock, so the contents of the chest don't change when "used". And so, perhaps it wouldn't be recorded to the savegame. But that's a lot of 'perhap's and it's probably easier to just check "Refs Persist" on the chest.
• Use Wrye Mash's Renumber Refs command (new in version 0.60).
  • This command offsets all local objectIndex numbers in the esp by a large random number (between 1,000 and 10,000), thus greatly reducing the likelihood of a local ref conflict.
  • The approach has limitations: TESCS will reset the numbers back to starting at 1 every time it's used to edit the mod, and if the esp is already in use, then you have to create and use an updater to prevent doubling.
  • The limitations suggest that this solution be used only as needed to fix observed problems.

Master ReferencesEdit

If two different mods modify the same master ref, discrepancies can arise. While you would think that the last mod to modify the ref would win, this doesn't seem to be true.

Example:

• Alchemical Warfare nudges one of the room blocks in Arrille's Tavern.
• Living Cities of Vvardenfell does an in-place replacement of that same room block with another type of room block.
• If LCV runs after Alchemical Warfare, the change made by AW dominates over the change made by LCV -- even though an ORI on the room block claims that it was placed by LCV.

Avoidance/Repair

• Don't modify existing reference unless you have to. In this case, AW's modification was accidental and unnecessary.
• Run TESTool on mods to remove non-changes.
  • But note that TesTool won't remove references that have been modified at all. I.e. if there's just a small change in position, TesTool won't remove the reference.
• Order mods so that the mod you want to "win" loads first. Note that this is backward from the usual mod ordering rule.
  • [I don't know if the earlier change dominates in all ways or only some ways. E.g., perhaps the change to id is accepted from the earlier change, but a change in position is accepted from the later change.]

Object NamesEdit

If two different mods give the same name to different objects, then the last mod wins.

Avoidance/Repair

• Use namespaces unique to each modder/project when naming objects, globals, factions, journal topics, etc.

PathgridEdit

If two different mods change the pathgrid for the same cell, then the last mod wins. The problem with this is that NPCs may end up trying to walk trough buildings placed by the losing mod.

Repair

• Only solution is to manually coordinate changes to pathgrid. Either the mod authors can do this in creating their pathgrids, or the user can create a patch pathgrid mod.