59 replies to this topic

[bg2408]

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. Everything you wanted to know about load order.

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?

Spoiler

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?

Spoiler

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. 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 Wrye Bash and tes4edit (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 Bashed Patch. 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 Bashed Tags 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: Clean your mods! 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 "resurrect" 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:

Wrye Bash - Import Race Info - Avoiding Googly Eyes
When creating a cosmetics mod, do not replace the vanilla eye resource with a different eye mesh resource. Instead, create a new eye mesh resource and use that. Note: If you're using one of the standard alternative eye resources (e.g. Rens) then use the standard path for that. When bash does its filtering, it determines what eye mesh each eye is using, and then filters the eyes for a given race to so that only eyes using the same mesh will be used. This is why it's important for mesh resources to be consistent.

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

Edited by bg2408, 30 November 2008 - 02:33 AM.

[Kestor]

Very helpful. Thanks
w00t first post !

Edited by Kestor, 13 November 2007 - 03:30 PM.

[wiz0floyd]

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.

[paw-prints-in-the-mud]

Ow. My OOO potions are hurting.

[agiel]

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

[Mikel Pyrex]

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

[X'tyfe]

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

[kyoma]

Very very handy thread

[Pepsi]

This SHOULD be pinned!

Useful indeed! Thanks.

[IBitUrHeadOff]

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

[bg2408]

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 .

[Leandro Conde]

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.

[thePOSTALdude]

There is one exception to the rule of the "one": Cells can be changed by any number of plugins.

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.

[Myxale]

Sticky!!

[FrozenAffairs]

Bump, can we get this pinned?

[Gold_Dragon]

Bump, can we get this pinned?

Only Administrators have that power. Such as Pete.


EDIT: nice info, however.

Edited by Gold_Dragon, 28 November 2007 - 09:31 PM.

[haama]

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 YourQuest
end

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, here are some brief Tutorials-in-progress on combining SI/non-SI, OBSE/non-OBSE, etc. mods into one. If two separate mods were created only because they needed 2 separate scripts, they can be combined into one again.

Edited by haama, 05 December 2007 - 01:39 PM.

[OblivionStalker]

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.

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

By the way, a great writing.

Edited by OblivionStalker, 09 December 2007 - 03:20 PM.

[how?]

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

Edited by how?, 09 December 2007 - 01:10 PM.

[Testlund]

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?

Spoiler

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.

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.

Edited by Testlund, 15 December 2007 - 01:48 PM.

[behippo]

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.

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.

[Lady Nerevar]

awesome thread, big thanks for posting!

[wiz0floyd]

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.

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

[giskard]

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

[kyoma]

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?

[DragoonWraith]

Each individual response is an entry. If they both modify the same response, they conflict, but if they are modifying two different responses to the same topic (or adding responses to the same topic), then the rule of one does not come into play.

However, you may still have a problem where greeting A and greeting B are supposed to happen under the same circumstances, so that you only see one and never see the other. I don't think there is any simple fix for that - you would have to merge the mods and mess with the dialogue settings to get them to both play some of the time, or something.

Also, bg2408, there is another thing modders can do to reduce incompatibility, if they like, though it's pretty difficult and requires OBSE if they're dealing with leveled lists - use scripts to place items. For example, I could have a script add a weapon to a vendor's chest with little difficulty, and this will not conflict with any mod that adds something to that chest. Obviously, this is not nearly so simple as putting the item there myself. And you can add items/NPCs/creatures to leveled lists in the same way, using OBSE, preventing conflicts.

Obviously, though, for this much work in most cases it is probably preferable to just tell users to use a Bashed Patch.

I only bring it up because a fairly significant Morrowind modder named Chris Woods always did this, and it did mean he could claim, without hesitation, that his mod would never conflict - at least in terms of overwriting - with another mod, which some may like to do as well. I'm using this kind of system for my own mod, though the mod I have designed has little choice in the matter.

[kyoma]

I got another question. Something about the one rule and cells. I know that multiple mods can add stuff to a cell and it'll all show up ingame but isn't it true only one mod can alter/contain info on certain flags on the cell? I'm asking this because a while ago I tried out Natural Interiors and it had to load after mods such as OOO else it wouldn't work. Cause NI requires setting a flag on the cell to true or something. So although the items NI added to cells were loaded, this flag was not. (because if OOO was after NI, the game would read the cell's flags from OOO and not NI) thus it stopped working.

Is this line of thinking correct or is it completely wrong?

[Aoshima Michio]

I think every mod that somehow alters interior cell, either by adding or removing items, contains also all those flags and other cell settings. Because there can be only one instance of every setting, it means that last loaded mod wins. I noticed that when i solved mod conflicts with Darker Dungeons.

Edited by Aoshima Michio, 04 January 2008 - 10:43 AM.

[haama]

I got another question. Something about the one rule and cells. I know that multiple mods can add stuff to a cell and it'll all show up ingame but isn't it true only one mod can alter/contain info on certain flags on the cell? I'm asking this because a while ago I tried out Natural Interiors and it had to load after mods such as OOO else it wouldn't work. Cause NI requires setting a flag on the cell to true or something. So although the items NI added to cells were loaded, this flag was not. (because if OOO was after NI, the game would read the cell's flags from OOO and not NI) thus it stopped working.

Is this line of thinking correct or is it completely wrong?

The Oblivion Land Claim thread might have some more answers for the question. At a glance Landheight can only be modified by one mod. To backup Aoshima Michio - that's certainly what it looks like in TES4Edit and the Details screen in the CS.

Edited by haama, 04 January 2008 - 12:34 PM.

[paladin181]

Introduction

There are many threads out there requesting people to look through load orders, and some of them are experiencing problems (graphical errors, CTDs, etc) while many are just looking for reassurance that their load order is "good". This is time consuming, both for the poster, who must wait for someone to read his entire thread, and the helper, who must assess the load order and decide if there are any "fatal" errors. This is a brief guide designed to help simplify the process of troubleshooting your own load order, and how better to expedite the process of getting help from others if you find you can not.

This is not a FAQ with all the answers to every load order problem; that would be impossible to do in any one thread as everyone has a different machine and different mods. I will explain the use of OBMM and Wrye Bash for obtaining a current load order, as well as the best way to post it in your thread. I will also list available resources to help you on your way to finding your own sweet spot on the load order. Always, of course community feedback and corrections are welcome, as I am no "Load Order Expert" and nor am I a great Modder.

Q1: What exactly is load order?

A1: Load order is exactly what it says it is: the order in which Oblivion loads your particular plugins. It is determined by the date the plugin was created/last edited.

Q2: That's great, but what does that really matter? I can just add plugins and make sure they're checked in the Data Files to play right?

A2: Yes, actually you can with a very few mods, and still certain ones will need adjustment. When two plugins that modify the same thing are loaded, the one that loads last is the one whose changes will actually take effect. The other plugin will retain its edits on any other reference in game except the ones that are overwritten by later plugins.

Q3: So. How do I edit my load order then?

A3: Well, for starters, you need Wrye Bash or Oblivion Mod Manager (henceforth known as OBMM). Both of these tools will help you to set the proper load order. I will not go into in depth instruction on these tools beyond how to use them to display load order, and that is later.

Resources

There are several documents online for you to look at when determining a load order. These shouldn't be followed as concrete and "correct", but rather used as a guideline. Remember, they have a different set up than you do and something that works perfectly for them may cause you some problems. But these load lists are a great place to start. The pertinent documentation is as follows:

1: No link for this one. The README of the mod is the first place you should look for load order information, as some mods have special load order. You may want to check this resource after the others to keep you from putting a mod in the wrong place by blindly following another guide.

2: dev_akm's General Load order Guidelines is another place to look. This lists general categories of mods with some basic examples of what constitutes each type of mod. This is great for starters and generally a good guide.

3: Agiel's Annotated Load Order Guide. This guide is very specific, it is actually Agiel's load order that he has tweaked to perfection (for him) and a very good place to get some detailed information. The list contains several popular mods and is color coded for ease of deciphering. It gives a brief description of many mods too, so even if your mod isn't on the list, you may find one that is similar in concept or execution that could make placing some of those more obscure mods easy.

4: dev_akm's FCOM Standard Load order. You only need this if you have FCOM. This load order details how FCOM is placed into your load order (or since it's so big, how your load order fits around it). Even though this is linked from the FCOM readme page, I thought I'd post it here since it is so big, and isn't covered by any of the previous load order lists.

5: Mod Readme: Remember what I said earlier? Check these again to make sure you haven't sloughed some mod off into the wrong spot because a guide said that those type mods go there. Again, these are rarely wrong and have a good reason for it.

Tools

Ok you have set your load order, and now you want to play. But when you do, things aren't working out quite right. You start getting "Crash To Desktop"s (or CTD)! Now what? Let's run to the forums and ask for help!!!

Whoa whoa whoa there. Slow down a second. Let's think this through a little better, and see if we can solve this problem ourselves. Really, though, let's look at some tools that will help us find these conflicts.

1: Wrye Bash. Yeah, I listed it earlier. No, I'm still not going to tell you how to use it. Wrye's readme covers that quite well. You will want this tool.
2: OBMM. Yup. I listed this one before too. Get it. it has a conflict detector, but really the functions you want from this are the ability to see your load order and easily reorder your mods.
3: TES4View. This tool will let you see conflicts between mods and possibly make changes needed if you're capable. It also will give you a read out you can post on the forums for help. You really don't need to use this until you know you have a conflict (ie graphical discrepancies, CTDs, or NPCs behaving oddly to name a few).

Now that we have the tools to see the conflicts and change our load order, let's see if moving a mod up or down on the list causes some of those conflicts to become nonfatal. There is a good guide about conflicts and compatibility of mods here(but if you're reading this, you likely know that). It may take some extensive tweaking and play testing to get it perfect, but nothing worth having is easy to get. Well, we've tinkered with our load list a bit, and now the CTDs are a little more frequent than before. Thanks Paladin, your advice has made my game even worse!!

Well that leads us to our next topic:

The Forums

Every now and again, we encounter a problem we can't solve or have overlooked the answer to. Thankfully, there's a community here willing to help you get past these issues. Posting on the forum may seem simple, but read these few tips before clicking that "New Topic" button.

First, we need to know what the problem is, and make sure that our topic title reflects that in a concise and accurate manner. Threads titled "HALP!!!!1" or "Can't fix it" aren't helpful and will lead to people over looking your topic rather than reading it and trying to help you.

Next, we need a description of our problem, like "I keep getting CTDs every time I try to load a game", or "My game crashes instantly whenever someone hits me with a spell". These descriptions are simple, but to the point. If there is any more information, you should include it here, much like "The crashes don't occur when others are hit by the spells, only me" or "The oblivion gates aren't closing properly either." Believe it or not, two seemingly unrelated problems can be caused by the same mod being out of place.

Now we want to post our full load order. First, we want to open a codebox. You can click on "Insert Special Item" and select it from the pull down menu, like this or simply type codebox in the [ ]tags.

NOTE: You only need to use ONE of the following Methods!

1:Here's how to get your load order in Wrye Bash. Open Wrye Bash, then Right click at the organizer tabs (File, Load Order) Let's right click on file, and on the pull down menu, let's click on List Mods. It will look like this. A window will pop up, and your load list will automatically be copied to your clipboard.

2:To do the same thing in OBMM, we'll open OBMM and click Import/Export like this and select View Load Order like this. A window will pop up. Hold ctrl and hit A, then hit C (without releasing ctrl) you may now release ctrl. You now have copied your load order to your clipboard.

In your post, place your cursor between the codebox tags (if you inserted them instead of typing it) and hold ctrl, and press V. You have now pasted your load order in the codebox. The result will look like this:

Oblivion.esmFrancesco's Leveled Creatures-Items Mod.esmFrancesco's Optional New Items Add-On.esmAWS-Core.esmOscuro's_Oblivion_Overhaul.esmMart's Monster Mod.esmTamrielTravellers.esmFCOM_Convergence.esmHorseCombatMaster.esmHrmnsOblivionScriptOptimizationv1.0.espUnofficial Oblivion Patch.espFrancesco's Optional Chance of Stronger Bosses.espFrancesco's Optional Chance of Stronger Enemies.espFrancesco's Optional Chance of More Enemies.espFrancesco's Optional Leveled Guards.espFCOM_Francescos.espDLCShiveringIsles.espUnofficial Shivering Isles Patch MOBS.espDLCThievesDen.espDecoratorAssistant with OBSE v1.1.espDLCOrrery.espDLCFrostcrag.espDLCVileLair.espDLCMehrunesRazor.espDLCSpellTomes.espDLCHorseArmor.espDLCThievesDen - Unofficial Patch.espDLCOrrery - Unofficial Patch.espDLCFrostcrag - Unofficial Patch.espDLCVileLair - Unofficial Patch.espDLCMehrunesRazor - Unofficial Patch.espDLCSpellTomes - Unofficial Patch.espDLCHorseArmor - Unofficial Patch.espSymphony of Violence.espAWS-ShiveringIsles.espNatural_Habitat_by_Max_Tael.espBetterImperfectWater.espNo psychic guards v1.2.espMaleBodyReplacerV3.espP1DkeyChain.espSkip Tutorial.espIWR - Windows Lights Shutters - Optimised.espBob's Armory Oblivion.espFCOM_BobsArmory.espOblivion WarCry EV.espFCOM_WarCry.espOscuro's_Oblivion_Overhaul.espMart's Monster Mod - Additional Enemy NPC Vars.espFCOM_Convergence.espFCOM_SpawnRatesReduced.espFCOM_SaferRoads.espMart's Monster Mod - Less Bone Loot.espMart's Monster Mod - No Undead Rise.espMart's Monster Mod - Fran's leveled quests.espTamrielTravellers4000.espFCOM_TamrielTravelers.espFCOM_MoreRandomItems.espFCOM_FriendlierFactions.espFCOM_Archery.espKnights.espKnights - Unofficial Patch.espLost Paladins of the Divines.espmythsandlegends.espGhogiels Armor.espBlack Guard.esppale_rider's Paladin Equipment_unenchanted_eng.espChoices and Consequences.espFCOM_UOP.espFCOM_Knights.espFrancesco's 10 days respawn time - 1-20 day lenght rescale.espOOO-Level_Normal.espOOOHangoverRemedy.espFCOM_Vampires.espMart's Monster Mod - Vindasel.espCSR - Fine Iron.espspMerchant.espHair and Eyes.espDarkUI Fix.espDarNified Books.espJump Adjustment-TESSource.espToaster's Legendary Mastery.espToaster's Legendary Skills & Stats.espSupremeMagicka.espSM_NoSpellLights.espSM_EnchantStaff.espSM_DLCSpellTome.espSM_ShiveringIsles.espSM_MOBSCompatability.espSM_OOO.espSM_MMMCompatability.espnGCD.espbgMagicEV.espbgBalancingEVCore.espbgBalancingEVOhmesRobertsBodyModFix.espbgBalancingOptionalUpdateVanillaCharacter.espStreamline 3.1.espBashed Patch, 0.espDeadlyReflex - Combat Moves.esp

Now we put any other pertinent information, such as posting the read out from TES4View (also in a codebox, as above) or any other error messages you may have received. It may also help to post your computer specs. If you don't know them, it isn't often important in load order problems anyway. But if you find it necessary to post it, there are guides on the net about how to obtain your system specifications.

Conclusion

This concludes my "tutorial." Hopefully, you'll be able to find problems in your load order yourself, and if you are still stuck, you now know how to post a help thread here to get answers to your problems. If you have any comments or suggestions, I'd be happy to read them. Gratuitous monetary donations can be sent to my Swiss account.

Edited by paladin181, 27 January 2009 - 01:28 AM.