Difference between revisions of "Understanding Mod Conflict Reports"
Jump to navigation
Jump to search
Understanding Mod Conflict Reports (edit)
Revision as of 12:27, 27 September 2006
, 12:27, 27 September 2006→Intentional Duplication
imported>Motub |
imported>Motub |
||
| Line 130: | Line 130: | ||
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). | 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). | ||
=== Intentional Duplication === | === 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. | 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). | ||
=== Load Order === | === Load Order === | ||