Understanding Mod Conflict Reports

Introduction

Inevitably, with the sheer volume and variety of mods from the talented and creative modding community, mods will and do conflict.

Or at least, that's how it appears.

Contrary to the bright red coloring of conflicts in Oblivion Mod Manager's (OBMM) conflict reports, not all conflicts are a bad thing. In fact, in many cases, they are very good thing indeed. This is your guide to understanding and interpreting the invaluable Conflict Report so that you can get the very best out of your Oblivion experience.

(Step One) There is no spoon: Conflicts are not conflicts

I know, crazy! No, this isn't reverse pyschology but rather recognising that, even though it's covered in OBMM's readme, the purpose of the conflict reports are still largely misunderstood.

The golden rule is this: OBMM does not report actual conflicts, it reports potential conflicts.

While OBMM looks for and detects two or more mods that alter the same record, what it can't do is determine if this is a conflict of interest or not. In some cases, a conflict actually shows that two mods are working as they should.

A great example is, and to draw on my own work, the Cats & Rats mod. In order to prevent guards attacking cats, a short piece of code is added to the guards. Because mods like OOO, Francescos and others alter guards as well, guards from these mods were imported into Cats & Rats. If you were to run a conflict report, it would be filled with potential red conflicts over the NPC entries for guards -- but these are not actual conflicts. In fact, if the conflicts didn't exist, Cats & Rats would not work properly and you'd have cities full of poor dead kittens.

Another example is Mighty Magick and, well, just about any mod that alters creatures and spells (OOO, Francescos, MMM etc). Does seeing a long list of red conflicts mean your game will break or you can't use the mods together? Not at all. Why? Because, again, the conflicts are not actual conflicts -- there is no spoon -- they are potential conflicts. That Mighty Magick alters some settings on top of those you might find in OOO or Francescos is entirely the point -- that's why you're loading the mod!

If you decided not to use a mod because you saw red conflicts, you would be missing out on a better Oblivion experience, and all for nothing.

These are just two examples of many many mods out there -- as stated earlier, the sheer volume and creativity of the modding community means mods frequently, regularly, and like clockwork will show up conflicting in the conflict report -- even when they actually don't.

-- DragoonWraith -- "I think the best term to refer to "conflicts" would be "overlaps" as this is by far the best succinct description of what's going on between the mods." Spot on! --

So how do you know if a conflict will prevent two mods working together, or enable them to do so?

(Step Two) Interpreting conflicts: It's up to you!

OBMM is a tool that works in black and white -- it can tell you when two or more mods alter the same record, but it can't tell you what this means. Without intepretation, the conflict report is just a bunch of colored lines.

So how do you work out what the conflicts mean? There's two ways of finding out -- the easy way, and the fun way!

1) The easy way: Ask for help

Not everyone likes to play with the CS, so it's perfectly ok if you just want to be sure everything will work fine without delving into it all. Pop into the official thread and ask about the conflicts you've seen -- and don't paste the entire conflict report.

Other users, and especially the mod author, will be more than willing to clarify what you're seeing and either put your mind to rest, or offer advice on what, if anything, you can do.

2) The fun way: Work it out for yourself!

If you want to learn more about how mods work, or if you're always been curious but haven't had the chance to explore, read on. Working it out can be broken down as follows:

• First, if you're not familiar with the mods in question, read their READMEs. You cannot interpret a conflict report without knowing what the mods are supposed to do. If don't like reading READMEs, this path isn't for you.

• Once you know what the mods do, look at the report -- you can completely ignore green and yellow conflicts, just focus on the red ones. Take a look at the records being altered and, from what you understand the mod is trying to do, decide wether the conflicting records will cause a problem, or in fact are intentional. You can work out, based on the purpose of the mod, the type of changes its trying to make to the record entries. But what do all those abreviations mean?

 NPC_ - NPC entry
 CONT - Container
 GMST - Global setting
 DIAL - Dialogue
 INGR - Ingredient
 CREA - Creature
 CSTY  - Combat Style
 CELL - Interior cell
 WEAP - Weapon
 ARMO - Armor
 AMMO - Ammo
 CLOT - Clothes
 SCPT - Script
 SGST - Sigil stone
 WRLD - World space
 MISC - Misc items
 SPEL - Spell
 LVLI - Item level list
 LVLC - Creature level list
 BOOK - Please

These are a sample, there are quite a few more, but you get the idea. Now, it won't always be clear the type of change a mod makes unless you open it up in the CS and look at the entry, which of course you can do. But again, you don't have to -- the author of the mod knows better than anyone else the records the mod changes and why, and will be able to answer if a given conflict is actual or not.

(Step Three) Resolving actual conflicts: It's in the load order

When you have two mods that alter the same record, and it's not a case of intentional overlap, then only one mod or the other will have its changes show up in the game. This is not necessarily bad thing, it just means you have to decide what you want in your game. There are two options here:

1) Use one or the other mod: Sometimes, that's just the way it's gotta be. Check with the mod author to be sure the two are mutually incompatible.

2) Adjust the load order: There's about a thousand examples of this, but lets use Mighty Magick again -- Mighty Magick alters the summonable creatures to the authors view of what they should be. It obviously will conflict with most mods that also alter summonable creatures, like OOO.

Is this a game-breaking conflict? Not at all -- loaded after OOO, the creatures Mighty Magick changes take priority over those in OOO, but the creatures Mighty Magick doesn't change show through from OOO before it. This doesn't mean it's a match made in heaven though -- if the differences between the two mods are, say, the strength of the creature then you simply get MM's balance on what this should be. If the differences are what the creature carries in its inventory, then you'll be getting what MM puts in there instead of OOO. However the differences are contained, and nothing stops the rest of the two mods working together beautifully. This is why it helps to understand what a mod does and what conflicts mean -- so you can decide for yourself which ones you want to take priority.

The bottom line is, for the majority of cases, two mods that alter similar properities in the game can and usually do work together, so you can have (most of) your cake and eat it too.

Oh, there is one other option -- mod merging. Rather than overlapping mods you can merge two or more together and, for the most part, the records from both are combined -- in the Mighty Magick example, this might mean getting the inventory of OOO in appearing in MM's creatures, for e.g. Merging, however, is beyond the scope of this piece (though I could easily write a guide here too).

Conclusion

If you love your mods enough to download and install them, love them enough to understand what they do, and you will never have a problem with conflicts. In summary:

• OBMM reports possible conflicts, not actual conflicts
• Conflicts mean nothing without interpretation
• Understand what the mods do, and the nature of the conflict
• Ask for help in official threads if you're unsure about a conflict

And, when you ask for help in threads, for the love of the nines don't post the entire damn report, just one example of each type of conflict is more than enough.

Finally, this piece is by and for the community -- additions, updates, fixes, and omissions welcome. Oh yes, and the CMG is just a bit of fun :)

(Addendum) Technical Details

Why, why, why???! Believe it or not, the Conflict Detector isn't broken; it's supposed to work this way

by motub

The Technical Side of Conflicts

No one wants problems with their game, of course. But what many people don't take into account is that this is the fourth game in the Elder Scrolls series. Bethesda has made many changes in the underpinnings of Oblivion to adjust for issues recognized from previous games-- most notably TES 3: Morrowind, which is still being played and modded today, four years after its release.

In Morrowind, you could (and can) share information between mods. If one mod wanted to use resources from another, such as scripts, or objects, both mods could be loaded in the CS, the second mod could reference the scripts/objects from the first, and when the user loaded both mods, the second mod would use the scripts/objects loaded by the first, without the hard necessity of merging or any such.

It was convenient for modders, and often for users, but it just as often led to hard, irresolveable conflicts between mods, corrupted saves, and massive instability (and Morrowind wasn't all that stable to run in the first place; a stray breath could knock down your whole house of cards with that game, frankly. Loveable as it was and still is, stability was not one of its strong points).

So in designing Oblivion, and likely expecting a similar or even more expansive mod explosion than that which Morrowind still enjoys, Job 1 was clearly to ensure that mods would not increase the instability of a game that was already teetering on the brink, due to its heavy resource use.

Enter "module encapsulation"

Module encapsulation is the very heart of the base Oblivion game's relationship to add-on modules (official as well as third-party). What it means is that mods cannot (are strictly not allowed to) share information with each other the way they could in Morrowind. Period. In Oblivion, if a mod wants to use a resource, that resource must be included in that mod's *.esp or *.esm. Period. If two mods want to change the same setting, the first will change it its way when it loads, then the second will change it its way (again) when it loads, because each mod's settings are separate, unique, and individual entities, like snowflakes, and Oblivion will load each mod in a series of discrete changes occurring in a logical, consecutive sequence, not a cumulative blooming of a coherent whole. OB never sees the snowy landscape that results from each of those snowflakes falling, just each snowflake, out of context with all the others. In fact, the other mod 'snowflakes' don't exist for the engine-- each mod is 'encapsulated', a tiny independent bubble of information, existing in a void, its only connection being to Oblivion.esm.

False Positives I (Illusory Incompatibility)

This idea that each mod is an island would be OK, except for the way OB is structured technically-- in categories of information, as Martigen has listed above. If one considers the major category of RACE, for example, it seems perfectly logical that the sub-categories would include such items as 'Hair', 'Eyes' and "Abilities' (since every race has hair, eyes, and many have abilities specific to the race, such as the Khajiit's Night Eye, or the Wood Elf's Detect Life). The problems start, however, when one mod changes information in a sub-category of a major category (like eyes), and another mod changes information a different sub-category of that same major category (like hair). Because module encapsulation is a gross, blunt tool, rather than a precision tool (a cleaver, rather than a surgeon's scalpel) these two mods will be considered as conflicting, because they make changes to the same major category (RACE), without reference to what they change within that major category.

This results in the first, and most common, type of 'false positive' in the Conflict Detector; mods that in fact work fine together (because they change items in different sub-categories of the major category and therefore dont really affect each other), but are listed as big red major conflicts simply because their changes occur in the same major category. These conflicts are unremoveable (they will always appear, irrespective of load order, unless the mods are physically merged into one), but are almost always ignorable, except in a few special cases (such as the Elaborate Eyes mod, or any mods containing Elaborate Eyes, for example), which are usually stated in large letters in the special case mod's readme (and if they aren't, they should be).

False Positives II (Intentional Duplication)

The second result of mod encapsulation is that because mods cannot share information with each other, if mods need to work together (modular mods, for example, or mods that need/desire to be compatible with specific other mods), the settings or resources have to be replicated in both mods, because the second mod cannot take the settings or resources from the first (each mod is independent from all others, and OB doesn't 'remember' what it just loaded in the previous mod). So if Adventures Gear adds a cooking pot that allows you to cook the ingredients provided by Axebane's Hunters 2.5, Adventures Gear has to include those ingredients inside its own *.esp, as they cannot be read from the Hunters *.esp the user likely also has installed (because the modules are 'encapuslated' from each other). However, this of course means that both mods change/add the same ingredients (obviously, they're exactly the same), and the conflict detector will understandably see this as a major conflict. But just as understandably, nothing is in fact broken.

Similarly, with modular mods, such as the oft-referenced Mighty Magick, because the modder cannot know which of the several 'modules' of the mod the user may choose, the base (general) settings of the mod must be included in each modular part, so that no matter which module you choose, you will get those base settings-- but as soon as you choose more than one modular part of the mod, the conflict detector will see that these settings are being changed again, and so will register the mod as in conflict with (another part of) itself (which quite rightfully confuses a lot of people, since it makes no intuitive sense). But again, there is no real conflict, and this is in fact an example of the second most common type of 'false positive' in the conflict detector-- mods that change the same settings, but change them to the exact same values as each other. And again, this is a completely ignorable major conflict, as long as the user knows that both mods are using the same values (usually noted in the readme, if it's not patently obvious by the mod name, which is usually something like 'mod_name-other_mod-compatible.esp' or the fact that it's a part of the same mod; obviously two modular parts of Francesco's leveled items and creatures are going to change any given settings to the same thing).

Semi-False Positives III (Load Order Conditional)

The third result of module encapsulation does work to the user's benefit to some extent. Because only one mod may effectively change any given settings, it makes it clear what to do when the major conflict is not a 'false positive' but a real one (two mods change the same setting, but to different values). Certain types of real conflicts are user-solveable, however, and therefore not as mission-critical as a red major conflict tends to suggest (which muddies the waters in terms of the effectiveness of conflict detection). The mod that loads last "wins" is fairly easy to intuit once one understands what module encapsulation does, and is usually successful in resolving such conflicts-- although 'successfully resolving the conflict' doesn't include 'removing the conflict from appearing in the Conflict Detector', unfortunately.

Final Conclusions

Whether module encapsulation accomplishes its purpose, I couldn't say, but it does work as designed, since the majority of red conflicts that you see in the Conflict Detector are a result of module encapsulation at work. Module encapsulation does 'force' the user to pay much closer attention to the mods they install (no 'just dump it in and go'). Since the output from the Conflict Detector requires interpretation to eliminate the huge number of false positive results that module encapsulation causes, one needs a fairly in-depth understanding of what the conflicting mods are attempting to change, why, and to what values, in order to do so. This is not necessarily a bad thing, but may be more work than many users are expecting to do, or are prepared to do; it does, after all, cut into one's play time.

I will point out, however, that as of this writing (27 september 2006), the OBMM Conflict Detector is being re-written; hopefully in the near future, it will provide somewhat more fine-grained detection of real conflicts and a significant reduction in the 'false positive' syndrome that the current tool (which is based on Bethesda's original tool) offers.