The Elder Scrolls ESO




The Elder Scrolls

Hilfe & Diskussion

Hilfe & Diskussion

Ältere TES-Spiele
TES Diskussion
Oblivion Plugins
Morrowind Plugins

Taverne zum Shalk
Adventures of

Tales of Tamriel

Hosted by

13.11.2007 Compatibility and you: A short introduction into mod (in-)compatibility

1. What's this about?
2. The "one" rule
3. Three types of conflicts:
3.1. Overrides
3.2. Mod interaction
3.3. Mismatched resources
4. Quick "how to" avoid common incompatibilities

1. What's this about?
There are a lot of questions asked if *this* is compatible with *that*, can "XYZ" be used together with "ABC", or "halp, not working!!!". I explained the underlying problems many times, so I thought "why not summarize them in one place?". That's what I'm trying to do here. I'm trying to keep it simple, short, and using examples, so that even new mod users should be able to understand this text. I hope.

2. The "one" rule.
It's a rule of "one", actually. One entry can only be modified by one plugin. An entry is everything. This rule is the core to understand most incompatibilities. Please say it loud: "One entry can only be modified by one plugin!"
An entry is everything. A NPC is an entry. A piece of armour is an entry. A vendor chest is an entry. A whole race is an entry. Everything you see in the game is an entry.
Now load order comes into play: When several mods are changing the same entry, the last one loaded wins.
Example (letters = load order): Mod A changes the gold of Thoronir. Mod B gives him another face. Mod C exchanges his clothes, Mod D puts a new sword into his vendor chest., Mod E changes his vendor behaviour to selling spells and gives him a couple to sell. Mod F sets his level a bit higher.
Now what would happen to our favourite Bosmer?
He would have a higher level and sell the new item. Both of these mods would take effect - Mod D does change another entry, while Mod F is the last that actually changes him. All other mods won't have any effect.

There is one exception to the rule of the "one": Cells can be changed by any number of plugins. Let's say Clocks of Cyrodiil adds a new clock to Chorrol, Cats and Rats puts some new cat spawnpoints into the city cells. What will happen?
Both clock and cats will appear, because both plugins would take effect.

3. Three types of conflicts:
3.1. Overrides
These are the most common mod conflicts, and are often a direct result from the "one" rule. Let's say you want to use Spell Tomes together with OOO. Both are altering the same levelled list. So if you're loading Spell Tomes last, some parts of OOO won't work, because they get overwritten. If you're loading OOO last, you won't find any tome, because they won't be in the levelled list. Everything is an entry. Even levelled lists.
These type of conflicts are often very easy to spot: Do two mods alter the same thing? If not, then there won't be a problem. Even if they do, that's usually no problem. The last loaded mod "wins". Let's say you're combining Blood and Mud with Robert's male bodies. Both are altering races - if you're loading Robert's last, you won't be able to select some of the new hairs included in Blood and Mud (they're from Ren's beauty pack, nothing special). Nevertheless everything else in game will work fine. So as long as you don't miss something that gets overwritten, these conflicts are easy to solve.
"But what should I do, just in case, when I don't want to loose something to the rule of one?"
There are two possible answers, an easy and a hard one. The easy one is Wrye Bash. Wrye Bash is a powerful tool, and allows to integrate many common override problems into it's "Bashed Patch". Let's say you want to have WarCry's NPC levels and TNR's NPC faces? Without Wrye Bash they're mutually exclusive (one will override the other). With Wrye Bash? No problem using them both. OOO's armour settings and female variants for usually male only armours? No problem with Wrye Bash. Using both OOO and Spell Tomes? Again, yes, I'm stopping now. What I wish to say is that many common problems can be solved with Wrye Bash - even the dreaded race cosmetic issues. So if you have an override incompatibility, there's a good chance that it's solveable by using Wrye Bash.
Nevertheless there's a hard way, should Wrye Bash not (yet) support the kind of mod integration you need. That is actual merging of two plugins, using Tes4Gecko. This is not the place to explain either method, their respective documentation and release threads are way better places. Let's just say that when you can use Wrye Bash, it's usually safer to do so. Tes4Gecko's merge function is even more powerful, but you can create mod soup with it if you don't know what you're doing.
Oh, of course there's also a third way: Removing the incompatibilities yourself. I don't know how many times I had to put stuff into new vendor chests, because the default one was used. Now this is mostly an alternative for small mods - you would go insane if you'd try this with some bigger override issues.

3.2. Mod interaction
I start with an example this time: Let's say you want to use WarCry and Francesco's together. Both have some level and levelled list conflicts, which can both be solved with Wrye Bash. Now what will happen in game? WarCry adds some new Goblins. Francesco's does. And both are killing each other.
This is mod interaction. Two mods adding (or changing) something different in the world, which doesn't play well with each other. These incompatibility problems are (fortunately) much rarer, but much more difficult to solve. There is no easy way around them, except making (or looking for) a compatibility update or project. For the used example it would be FCOM. And here's even another face of these mod interaction conflicts visible: While WarCry does give common enemies a static level, OOO is giving them a small level range, and Fran's no limit at all. So each unique enemy from them wouldn't match the rest of the world (which would be set by the last loaded plugin). Again, FCOM is the answer for these problems, but that's not the point.
Important is to spot these kinds of incompatibility. Usually there are two sources for these kinds of problems: Different design philosophies on the one hand, tough luck on the other hand. Different design philosophies are easy to spot. If two mods are doing something similar in completely different ways, it's quite likely that there will be some inconsistencies in game. Tough luck on the other hand, well, there could always be some bad faction interactions or other things going wrong. While the design philosophies are somewhat common, obscure mod interaction is - luckily - very rare. So I wouldn't worry too much about it. Just look at two mods and ask yourself "could they do similar things in entirely different ways?"

3.3. Mismatched resources
Now we're coming to the real pain. Here we've got the true incompatibilites, which aren't solveable. They're resource related. You can't use two body replacers for the same sex without encountering problems in game. You can't use eyes for two different eye meshes for one race, without getting googely eyes. Usually ressource conflicts are indicated by graphical glitches in game, like distorted character textures, googely eyes, or other similar problems. There's nothing you can do about that, except choosing which one of the available options you're going to use. There aren't that many of them around. Body mods and eyes are the two most common ones.

4. Quick "how to" to avoid common incompatibilities
There are some really easy things modder can do to prevent incompatibilities. I think they come down to two guidelines:
- keep the "rule of one" in mind! Example given: Do you want to add an item to a merchant? Then create a new chest, and putting that chest into the store cell. Do not put that item into the vendor's original chest, or into the vendor itself. Cells can be changed by multiple mods, the rest can't.
- make your mods "bash ready" by including the bash tags in your mod description, encourage users to use Wrye Bash, and by Azura do not undermine the possibilities of Wrye Bash! I can't stress enough how important this is. Very many common mod overrides and even some ressource conflicts (like googely eyes) can be solved by it (by entry integration for overrides, or sorting out and removing mismatched resources).
You can't prevent mod some interactions, caused by different design philosophies, or because often you can't achieve what you're trying to do without creating some incompatibilities. That's alright. I just want to point out, that I think it is a good idea to avoid common override issues, if we're able to do so.
geschrieben von bg2408