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→False Positives
imported>Motub |
imported>Motub |
||
Line 124: | Line 124: | ||
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. | 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 === | === False Positives (I) === | ||
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 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. |