Difference between revisions of "Understanding Mod Conflict Reports"

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 :)

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 :)

by motub

by motub

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.

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.

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.

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.

What this means is that mods cannot (are strictly not allowed to) share information with each other the way they could in Morrowind. Period. 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.

What this means is that mods cannot (are strictly not allowed to) share information with each other the way they could in Morrowind. Period. 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.

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), most of which are stated in large letters in the special case mod's readme.

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), most of which are stated in large letters in the special case mod's readme.

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.

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 in conflict ''with 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).  

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 in conflict ''with 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).  

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). '''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).

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). '''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).

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.

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.

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.