Difference between revisions of "Understanding Mod Conflict Reports"

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