Oblivion Mod:Intro to Mod Conflicts

The UESPWiki – Your source for The Elder Scrolls since 1995
Jump to: navigation, search

There are many ways in which one could break down the issue of mod (in)compatibility, but this section only focus on the common conflicts users have to deal with and a single preventative method.

Data File Conflicts[edit]

Most mods consist of plugins and/or data files. Plugins contain records that hold the information for how things in the game are rendered, from tree placement to NPC sleep schedules. Data files comprise the things that are rendered in the game. Mods can either modify or extend the game's content. Most mods do both to a certain extent, but there is a big difference between those two types of modifications, the former being the more troublesome, as far as mod conflicts work.

Data file conflicts (i.e., overlapping mesh and texture files) are usually not a big deal. When do data file overlaps matter? They matter when you care about which version of a file is rendered in game. However, if you accidentally install the wrong mod last (and the content of the mod you wanted to show in game was overwritten) it is unlikely that the game will break. Of course, there are exceptions, and the effect of mixing these up is noticeable.

Many mods use new content, custom data files, or only use the vanilla content. Replacers, however, are mods, primarily composed of data files, that replace the original content, aesthetic mods. The most common and most popular types of replacers are those for textures and/or meshes. Texture replacers can usually be installed in whichever order you wish, in order to have the right content loaded in-game. Installing mesh replacers or mods that replace the vanilla meshes require more attention.

For example, a large percentage of mod users use body replacers, mesh replacers that replace the game's male or female body. Using a body replacer can add quite a bit of work (but many of us agree that it is worth it) because using they have a very different structure from the original meshes. The changes require different maps in order to have the textures display properly on the new bodies. Installing these alternate NIF files, requires different DDS and _N.DDS files as well. Now, as the body-mod user installs additional mods, he or she has to make sure that compatible clothes, textures, etc. are not overwritten.

There are other kinds of data file conflicts, but most of them are not game-breaking (albeit they might be immersion-breaking.) This is just a matter of installation order. Plan for which textures you want to see in-game before installing a ton of random modifications. Plugin conflicts have much more variety...

Plugin Record Conflicts[edit]

Bad plugin conflicts break things. Plugins that only extend the game's content by adding completely new content, new records, are much less likely to conflict with other plugins. However, overrides are hard to avoid for many types of mods (i.e., replacers.) Conflicts may arise when plugins override the same records. It depends on how important the override is to a mod's functionality. Some plugins contain (many) accidental record changes (which are problems on their own) but as the changes are not pertinent to the mod's functionality, the mod should still work. It would be bad if there were another plugin in the modlist that needed to make a specific change to that same record and has it changes stomped upon.

This is where the concept of load order is important. Unlike data files for which only one version can be installed (loose) in the Data folder, plugin records are "hidden" in ESPs and ESMs. The game, in this case, loads the record of the plugin with the most recent timestamp. A load order is the time-ordered list of all active plugins. By modifying that order, the user can control which changes win.

Knowing which plugin needs to be loaded later (as the winner) requires a good understanding of a mods makeup and purpose. Fortunately, there are tools that aid users in doing this, as well as managing installation order. It takes time to learn about mod interactions, but the learning can be done much more leisurely with the aid of mod management tools.

Script Conflicts[edit]

Many plugins contain scripts to do checks, trigger changes, etc. Script conflicts can cause fairly harmless, irksome issues such as container resets; on the other end, they can cause seemingly random crashes. Script conflicts can be very hard to track down because scripts run in the background. Certainly, testing between adding mods to your established setup can help avoid all types of conflicts, but script conflicts can be time-specific or place-specific, and you can hardly test all add content and locations. In the event you cannot narrow the conflict down to one of the first two types, check your script-centric plugin's mod thread to see if such conflicts have been reported.

Avoiding Conflicts[edit]

No, the answer is not to use few mods. Although that may help, it does not take many plugins to break a game. In addition to maintaining good installation and load orders, the user can take preventative steps before getting to the installation component of mod management. Mods are usually packed with the very, very important but often overlooked documentation. ReadMes describe the mod and the installation steps. Good ReadMes also give information about compatibility issues and update information.

Even if you do not read the entire ReadMe, at least pay attention to the mod's type (or description.) If a mod list happens to be without data file or plugin record overlap, installation order and load order do not make much of a difference. If you can be sure of any conflicts in your mods list, even without knowing much about the data within the plugins, it is most likely that if it contains multiple mods that make the same sorts of changes, it has conflicts.

Examples of Common Mod Combinations to NOT Use[edit]

  • COBL Races and Race Balancing Project - both are cosmetic mods that overhaul the vanilla races

See Also[edit]

External Links[edit]