Difference between revisions of "Understanding Mod Conflict Reports"
Jump to navigation
Jump to search
Understanding Mod Conflict Reports (edit)
Revision as of 08:08, 27 September 2006
, 08:08, 27 September 2006no edit summary
imported>Dev akm (→Introduction: link to OBMM) |
imported>Motub |
||
| Line 103: | Line 103: | ||
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 :) | ||
== (Addendum) Why, why, why???! Believe it or not, the Conflict Detector isn't broken; it's ''supposed'' to work this way == | |||
''the technical side of conflicts'' | |||
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. | |||
In Morrowind, you could (and can) share information between mods. If one mod wanted to be 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 Morrowind, and likely expecting a similar or even more expansive mod explosion such as 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". | |||
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 would be OK, except for the way OB is structured technically, by 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), 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. | |||
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). | |||
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. | |||