Content:

1. What's this about?
>> Mod Users <<
2. The "one" rule
3. Three types of conflicts:
3.1. Overrides
3.2. Mod interaction
3.3. Mismatched resources
4. How to use programs to spot and / or solve incompatibilities
>> Mod Makers <<
5. How to avoid common incompatibilities as a modder
5.1. What's this about?
5.2. The "one" rule - avoiding overrides
5.3. Mod interaction
5.4. Mismatched resources
___________________
6. http://www.gamesas.com/bgsforums/index.php?s=&showtopic=775917&view=findpost&p=11605486

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. This text has two parts. The first part tries to explain what incompatibility is. Why? So that you can understand how compatibility works. Everyone not knowing this should read it. The second part is for modders, some tricks and general things to prevent compatibility issues.

______________________________________
>> Mod Users <<
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?


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?


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 six 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. How to use programs to spot and / or solve incompatibilities:
There are two main tools you can use if you want to prevent, solve or spot incompatibilities. They are http://wrye.ufrealms.net/Wrye%20Bash.html and http://www.tesnexus.com/downloads/file.php?id=11536 (rename tes4view to tes4edit to have it's full functionality).
- Wrye Bash: That's the most important tool. It's essential - if you use more than ~25 mods chances are good that you already have an incompatibility issue solveable with Wrye Bash. Main component is Wrye Bash's http://wrye.ufrealms.net/Wrye%20Bash.html#BashedPatches. It can integrate several mods changing the same record (see rule of one), so that all changes are there in game. Example given: OOO and Spell Tomes do both change the same leveled list. Without Wrye Bash only the last loaded one will win and overwrite the other, but by simply using Wrye Bash's bashed patch both will work. Wrye Bash's most prominent areas are leveled lists, race and graphic records. Most override issues you'll meet fall into this categories, and they are all solveable very easily by Wrye Bash. To spell out the sad true, if you don't use Wrye Bash, sooner or later you will run into some bad incompatibility issues, and noone will be able to help you.
- Tes4edit: Tes4edit has a completely other use. You can't trust automatic conflict reports at all, they produce too much "false positives" (meaning they report too much stuff as conflicting, which doesn't conflict at all - on the contrary, often these overrides are intended and no compatibility issues). Tes4edit lets you see what a mod does, see what other mods are affecting the same entry (remember the rule of one). And you can look for yourself if the change to that entry is intended or not. And if it's not, you can simply drag and drop settings from one .esp into the other. That sounds a bit complicated, but it's not.
So in summary Wrye Bash allows you to solve most incompatibilities you're going to meet, and tes4edit allows you to examine plugins and correct potential overrides if you see them.
______________________________________
>> Mod Makers <<
5.1. What's this about?
Some time ago I wrote a little text to help mod users understanding what kind of conflicts there are, so that they get a feeling for compatibility. This is, of course, the text above. Now my little text here tries to be something different - a starting point, maybe a summary for methods to avoid common compatibility pitfalls. This is written for you as a modder, not a mod user, so that you can prevent a few issues both for you and users of your mod. By it's very nature this can't be complete, I don't know about all tricks and methods to prevent all kinds of preventable problems, please think of this thread as a starting point .

Another important note, we can't prevent all possible compatibility problems. That's neither reasonable nor adviseable. If you're going to make a new overhaul mod, it will conflict with Fran's, OOO and already existing mods. If you're designing a new eye mesh with new textures, it will conflict with existing mods. These conflicts are no reason to be afraid - mod users have to choose sometimes . This thread is not about unpreventable conflicts - which you will have, and which you'll have to live with. This is about conflicts which can be prevented.

5.2. The "one" rule - avoiding overrides
(Note: Cells are an exception!)
As written above a single entry can only be changed by one plugin. An entry is defined by EditorIDs/FormIDs. This is very important to keep in mind - while a single entry can have multiple options to customize, all it's options are saved into it. A NPC has many tabs: His statistics, his face, his inventory, his AI, his hairs, eyes, his spells, and many things more - nevertheless he's only one single entry and can only be changed by one mod - the last loaded.

That's why it's important to not change entries if you don't have to. Common examples:
- If you want a store to sell new items, add them to a new unique chest and place it into the store. Cells are an exception, so adding items this way won't cause any problems. Instead adding to a default vendor chest would create possible override issues.
- Similar if you want a spell vendor to sell a new spell, do not add it to him directly, but use a one-time running quest script or other means.

This is kind of common knowledge, nevertheless it can prevent a lot of problems. Although these are not the only overrides that can be prevented. Let's say you're making a quest mod, and you want your NPCs to have new hair styles. By doing this you're changing race entries, which can easily lead to a many compatibility problems. Now there's a trick: Keep a development version, and a public version - and delete all race entries in your public version plugin with tes4edit. Your NPCs will still have your new hairs, but you just have removed dozens of potential problems. Of course you can't edit your NPCs in this version anymore (without seeing them reverted back to standard hair styles), therefore keep a development version ready. As you see, there are some tricks you can also use - and I'm pretty sure there are more!

Not all times you can prevent overrides, though. Here comes another important aspect: Embrace Wrye Bash, and recommend your mod users to use it as well. Whenever you're changing leveled lists, NPC faces, races, or whatever, Wrye Bash can solve most incompatibilities resulting from this. What you should do is familiarize yourself with http://wrye.ufrealms.net/Wrye%20Bash.html#BashTags and tag your mods accordingly. Also mention Wrye Bash in your documentation - people should use it, because (and please forgive me for being honest) as soon as someone is using more than a couple of mods, without using Wrye Bash he or she is a lost cause. There's simply no other way to prevent many overrides.

Another important aspect: http://cs.elderscrolls.com/constwiki/index.php/Mod_Cleaning_Tutorial! It's easy to create unnecessary entries in your mod - you change something by accident, then change it back - but it'll stick in the .esp. You're testing something, delete the tests - but some rests stick in the .esp. These residues can pile up - I've heard of mods which consisted of many thousands unnecessary entries, which then in turn could cause issues with other mods. While the CS can be a start to look for conflicts ("Detail" button in data file view), usually you're better off with using tes4edit. It allows you directly to see what has changed, if you have actual changes in the .esp (yellow) instead of completely unnecessary no-changes (green), and you can also look at which changes were done. This allows easy and efficient cleaning. Especially important for scripts, because, well, see below.

A last note: Never hit "Recompile All" when editing scripts. And never use an existing script for your custom one, alsways create a new script! Renaming a script doesn't create a new entry - you will end up overwriting that script!

5.3. Mod interaction
While most minor overrides can be prevented, mod interactions are a whole different matter. You won't be able to prevent most of them. Don't let this shatter your hope - mod interactions are rare, and are usually the result of two (or more) mods doing similar things in entirely different ways. Not all mods can be used together, and mod users have to choose between some. When they want to use them together, usually a compatibility project is necessary - like FCOM for using both Fran's and OOO together.

Nevertheless there are some interactions which can be prevented. Although usually one mod will have the short end of the stick, because if you fear there will be interactions, one mod has to make compromises - both in best cases. Let's say you want to make a house mod, somewhere in the wilderness. While you can use in theory any location, it's not a bright idea to use a Unique Landscapes place. They are very popular, and things like distorted landscapes can happen if your house mod overlaps with their cells.

If you have to use script effect spell casted regulary at the player, simply use a silenced Script Effect (i.e. choose as visuals "None"). Do not choose any other visual - many popular other mods are using these resources (magic modder can't create new magic effects, so they don't really have a choice), and your users would end up with the thumping sound you tried to prevent. Many mods are already using a silenced Script Effect, so you can be pretty safe that no other mod will unsilence the Script Effect. On the other hand don't get the very bad idea to unsilence the Script Effect (e.g. overriding it without silencing it).

Don't create non hostile NPCs with a high aggression rating - normal citizen should have an aggression of 5, later becoming hostile ones of 10. Thing is, other mods could place another NPC into the same city, maybe of a race your NPC doesn't like. Now if that new NPCs draws his weapons (e.g. because he has a training package), there's another disposition drop and BAM! You've got NPCs running amok.

For an alternative start plugin, set quest stages accordingly. Many mods check for them (to see when the player is out of prison), and they wouldn't work if you don't set them.

Keep Shivering Isles in mind, even if you don't have Shivering Isles yourself! Example given don't include teleportation means which don't check if the player is in Shivering Isles (these checks work even without SI).

Keep custom races in mind. People will want to use them, even if you don't. A few examples: If your mod require races to have a specific ability, then write a script which checks if a player is a standard race - and if not, then add that ability. If you're making a "http://www.uesp.net/wiki/Tes4Mod:Resurrecting_the_Player" mod, don't use player.resurrect and add racial abilities gone missing later, but use a hybrid approach to prevent actual death.

5.4. Mismatched resources
There is a quite common error. I'm just quoting Wrye now:
You won't be able to prevent some mismatched resource problems. Example given people mixing up different body replacer.
A few others though are another matter - usually Wrye Bash can solve them. Important about this is to not sabotage Wrye Bash. That means tagging your mod correctly, and follow the advise I quoted above.

I have said to keep this short, so... I finally have a text ready I can point people to!

(Oh well, I just hope my English was good enough for this thread :blink: ).

Very helpful. Thanks
w00t first post !

This is a great idea. Let's just hope that this gets stickied like the mods faq did, as IMO, this is just as important.

I can't think of anything that can be added to make this better, but if I do think of something, I'll mention it.

Thanks bg2408 for compiling this.

Ow. My OOO potions are hurting.

Use TES4View if you want a detailed view of that 'rule of One'.

When TES4View shows you mod conflicts, each mod participating to a conflict is displayed in a separate column. The final values used for the entry are the last values that are not empty.

Very helpful to troubleshoot load orders, mods overrides, etc

Excellent post, BG. As you stated, the same questions are asked multiple times every day. I also hope it gets stickied and more importantly, I hope people read it!
Mike

i have solved most incompatibilities with a patch i created that
basically makes all mods as compatible as each other i possibly can
i use tes4edit to find entries that are incompatible, and fix them with this patch

Very very handy thread

This SHOULD be pinned! :nod:

Useful indeed! Thanks.

Thank you very much, BG! That's one great initiative you have there! :goodjob: This'll be very useful for references in the future. Thanks again!

Thank you all very much for your nice words .

I don't know, maybe I should expand the text to explain more about Tes4edit, how to solve specific incompatibilities, and a more detailed description what modders can do to prevent some avoidable gotchas.

The reason I wrote this text was to introduce what kind of conflicts exist, so new mod users can get a "feeling" for what is compatible, what not and why not. That is very important, I think .

Very important thread! It explains to users many common problems they found when installing mods ... I think this must be read by everyone, so they then know the causes of their troubles ...

It's greatly appreciated! Many thanks for writing this!!

Cheers.

And dialog topics. Two or more mods can edit the "GREETING" and "Imperial City" topics for example and still be compatible. Now I know "GREETING" is a "special" topic because it's always activated when you engage an NPC in conversation, but the "Imperial City" topic is just an ordinary one.

However, if you try to edit the same dialog line, (such as "Close shut the fla... I mean JAWS of Oblivion! ") there will be conflicts.

This is a great topic and I think it should be sticky. I'd even like to ask permission for me and my team to host it on our website.

Sticky!!

Bump, can we get this pinned?

Only Administrators have that power. Such as Pete.


EDIT: nice info, however.

One more quick "How-to" - Use Scripts! Instead of adding an item to the merchant or a new extra container, make a quest and attach this script to it

begin GameMode  NPC.AddItem SomeItem 1  StopQuest YourQuestend

Also, OBSE keeps adding new ways to avoid compatibility - use AddToLeveledList to add items to leveled lists. This way several mods can add items without overriding each other. There's still a bit of a Mod Interaction problem, just like the WarCry and Francesco's problem mentioned above, but at least it's not an override.


Finally, http://www.gamesas.com/bgsforums/index.php?s=&showtopic=604256&view=findpost&p=11367714 If two separate mods were created only because they needed 2 separate scripts, they can be combined into one again.

And I'd want to know if you can give me permission to make a PDF from this.

By the way, a great writing.

This is an interesting and helpful thread. I'd advise others to read it.

I don't see the logic why MOD A and MOD C wouldn't work here. I would imagine that those are separate entries just like MOD F. So putting a sword in his inventory shouldn't prevent the clothes or gold. :confused:

The logic is that there is only one entry for the NPC in the list. That entry contains many things, including the name, face and personal inventory (including clothes, gold, and other items.) The adding of the weapon to the vendor chest changes the vendor chest, not the NPC. Adding the clothes and gold affect the NPC directly, so any other change afterwards would cancel these.

This is the thing to understand about mod compatibility. It may not work exactly the way you would like, but it is the way it works. It also means to understand mod capatilbility you need to understand what constitutes a single entry or form in the CS.

awesome thread, big thanks for posting!

I don't think anyone does, but that's how it is.

bg2408

Great guide there, much needed and hopefully it will end a lot of the questions us mod makers get about common sense things. You have however forgotten QUEST mods. No surprise because most people think Oblivion modding is OOO and naked mods. Quest mods are the mods that have the most to work around and they represent the most difficult mods to make from a save game and mod compatibility point of view, as well as the days/weeks/months/years of work involved in their production.

In fact, if any mod maker out there doubts what I say, try making quest mod based on an existing guild your self.

So it's pretty important users understand the issues quest mod makers face and here I'll explain some techy issues that should make the player ask the mod maker about issues that may result from using his mod. To date NOBODY HAS ASKED ME ANY OF THIS and at least 40,000 players used my kvatch mod. And You should.....its info you need to know.

Common Quest Mod Problems.

All players and mod makers should understand these issues are mostly unavoidable depending on if your editing existing items or making your own quest mod from scratch, quests/npcs/locations all new etc.

Due to the way disable works, some items once disabled vanish from the game if a quest mod is removed, even trying to enable them later fails to work for some reason. Things like doors in the Bruma guild of my own OMG mod may never reappear if Origin of the Mages Guild is removed without me providing a "fix it man" in the mod to let you restore the game to its original settings before removing the mod. But that is like making a brand new quest and no minor task for most mod makers and it has to detect your current game state and progress in various quests too. My kvatch mod users who installed kvatch later in their own game would have seen my "old game detected" popup message, these types of updates are nessessary for compatibility because quest mods cannot simply be turned on and off unless they are totally original in nature.

To even assume you can is FOOLISH, you should always ask the mod maker about this before doing so!

So disable is bad for compatibility but we do not have a lot of alternative choices. Most move commands cause problems with saves and are not always reliable and a moved door still gets used by NPCs and can cause CTDs if the destination is unreachable. So moving may sound better but it leads to crashes that the disable method does no suffer with.

Deleted stuff reappears as if nothing had changed when a mod is removed, so deleting is good, but not so for mod compatibility. It does remain a safer option than disable but you cannot delete a door to a guild like bruma, you have to wait until the guild is burning before removing the original door to the old bruma, I do not recall a script comment for deleting an object, as far as i know, it can only be done in the CS. So delete is not always useful to us mod makers. It is how ever safer from a "no perminant changes to your save" point of view even if it does break all mods that use the deleted item.

Scripted Objects are useful, you can script something to appear and disappear on command using disable/enable, but once you release a mod, that scripted object can only be moved if the player does a mod reset for the version you moved the object in. Otherwise it appears exactly where it originally was.

Those are some reasons why players should ask Quest writers questions concerning those issues before installing a quest mod.

Quest Mod Compatibility and your Saves.

A sword mod may not do much, removing it probably will do nothing but remove a weapon your carrying. Armour and spell mods pretty much are the same, remove them, lose the items they added. Quest mods are completely different and much more dangerous affairs, adding a sword or some hair to a game is dead easy compared to quest writing, the list of problems you face is extremely long and only a real expert would know work arounds for every issue, IF ANY EVEN EXIST.

A quest mod makes perminant changes to your save, the question is, "What is being changed ?".

Take Lost Spires, all new material, quest scripts deal solely with Lost spires items and all terrain editing can be restored because it uses the delete trick. So it only suffers from the 2 mods occupying the same space problem. This is the benefit of a totally original mod. Its easier to make, causes less problems in your saves. Unfortunately it has ZERO interaction with existing game material. I sense its its own personal Shivering Isles, nothing that is not part of the Lost Spires mod may enter its world. Its a bubble that cannot be burst and that is the disadvantage to this type of original mod.

Kvatch Aftermath & Kvatch Rebuilt both edit the same city and edit either the kvatch seige and find the heir quest or kvatch NPCs, such changes make these incompatible and those users who think they can switch between them easily need to stop and think first. For example, if you do my mods version of the battle of kvatch, all the old doors will remain locked an Salvain will be disabled at the end of it, Kvatch Rebuilt uses the original Salvain so it will automatically break if you switch mods. Also, Kvatch Rebuilt uses a completely different system and must by its very nature edit scripted objects and as ive said above, those cannot be moved later. Any original item from kvatch will remain where that mod placed it AFTER it is removed.

But the benefit is these mods can totally intrigate in to the world around them but doing so adds more and more issues concerning compatibility. The challenge is know how to avoid problems.

So you can see the difference between a totally original quest mod and one that edits an existing location/guild/city is huge. The totally original ones are the easiest to make and cause the number of least problems. There are no work arounds they need to deal with. Quests that edit the original quests or locations in some way become hugely complex right from the start, choices made early on become perminant in your saved games. There is no way to edit kvatch for example without editing something that cannot be changed later.

So anybody who wants a kvatch mod, has to accept these limitations or should avoid such mods entirely.

But anybody who wants to avoid problems when mods get removed should avoid quest mods completely if they edit beths material because they represent the most complicated workarounds in the game. They usually do not work around every single problem either so somebody elses mod always breaks.

This may sound messy but if you want an expanded mages guild, there are very few choices available to a mod maker modding it, unlike beauty mods that merge each other over and over and so create problems for them selves and players. Quest mods often have no choice but to use whats available.

The words of one user stick in my mind when I think about adding a new location to a map, morrowind had so many new locations the map almost became one massive city...So I try and avoid that and reuse as much as i can. But in doing so, I am careful not to disturb anything at that location IF I CAN AVOID IT.

As a quest writer, I try and place new items and use those, removing them when the quest is over to leave a cell in the same state it was originally in. This is probably the safest work around I have found when editing locations. Enable your stuff for a quest, disable your stuff after the quest ends. My kvatch Mod has an option to modify bruma, this is an excellent example of how this idea works in practice. Also the Vanus quests in OMG use this trick too, its a well tested trick that works extremely well and is perhaps the best workaround quest writers can use when editing locations.

Trouble is, what happens if your making a Mannimarco mod, you cannot very well avoid editing the King of Worms can you.

That is the sort of problem all Quest Writers face, there is no "GOOD" solution.

So what can you do ?

The only thing you can do is choose your quest mods carefully, better yet, start a new character when you switch between conflicting quest mods. The worst thing you can do when using quest mods is to stick with the same character for 18 months and I know a lot of users who do that. Most have seriously problems which they come to me with.

Also do not assume "Setstage" cures all ills, if you use that command in Kvatch, you will need a mod reset to fix the damage you caused to your own game. Far too may players dabble with that command without knowing the mods design first. Ask the mod maker for a setstage command to skip something if you need one, do not try it your self.

Giskard

I got a quick question about the One Rule. Does it also apply to result dialogue, meaning if I have a mod A that edits, lets say, all the result dialogues of all the greetings and a mod B that does the same only a little different. Then when I load both A and B (B last) only the changes B makes are ingame?