Oblivion Mod:Mod Integration

Outdated Tech: The info in this is either outdated or so well known that it should be described in a simpler/different way.

With Oblivion, Bethesda introduced the use of formids in their data file structure. While formids have a number of advantages (including the near-total elimination of mod conflicts!), they make mod integration fairly difficult.

Update: Esm/Esp Bait and Switch

This remainder of this article is somewhat out of date and should be updated at some point.

While it's true that TESCS does not allow you to build mods that integrate with other mods, the game engine will accept such dependencies. This leads to:

1. A bait and switch strategy in which a mod is initially built on top of esm versions of other mods, and then has its masters switched to the esp versions.
2. Mods built entirely by outside tools with esp dependencies. E.g., Wrye Bash's leveled list merging function.

For discussion, see ESF: Mod De-Isolation.

Isolation Cost

The ability for mods to communicate (i.e., to not be isolated from each other) is very important: many mods for Morrowind, both major and minor, rely upon it. For example:

• Resource mods. One mod might define a set of resources for use by other mods. E.g., clothes, hairstyles, sounds, food models, tiled blocks for building rooms.
• Synchronization. One mod might provide a global or other features that allow other mods to adjust to its presence. E.g.:
  • Necessities of Morrowind sets a number of variables which indicate the hunger, fatigue, etc. of the player.
  • Living Cities of Vvardenfell allows NPCs to be taken off schedule by placing an 'OffSchedule' token in their inventory. This supports compatibility with other mods that 'grab' NPCs (e.g. Vampire Embrace).
• Patch mods. Two mods that are incompatible can sometimes be made compatible by the addition of another mod that patches their differences.
  • List merging patches. A special, automatically generated patch mod that merges changes to the same list by different mods.
• User tweaks. A user might create a new mod that tweaks an existing mod. E.g., Adding new NPCs or items to a house mod.

Not only do FormIds eliminate communication between mods, they also eliminate merging of mods -- which has a huge impact both on large projects (which need to merge contributions from many members) and individual users (who merge mods to keep from exceeding the 255 mod limit.)

Mod Updating

One of the uses for mod communication is patching mods. E.g., the mod creator might release a patch esp for their existing mod. Mod isolation makes that impossible. However, in a bit of good news, such mod patching is (probably) not necessary anymore. Instead, given the nature of Formids, the mod creator should be able to update that esp directly and not cause problems with savegames that depend on the previous version of the mod.

Note: There are still some limits as to what can be changed -- in particular, changing existing scripts is likely to be dangerous. In addition, it might not be safe to delete any existing data records. (This depends on whether the formids of deleted records are reused for new objects.)

It should be noted that this ability to mod and safely re-release has not been tested yet.

Conversion to ESM

Given the nature of Formids, it seems that the only way to allow mods to communicate is to make one of them into an esm (master file). However, there are several problems with this:

• One mod must become dependent on the other. Contrast this with Living Cities of Vvardenfell and Vampire Embrace which communicate as peers. The user can run either by itself, or both together. But if one file is chosen as the master of the other, then the non-master mod will no longer run unless the master mod is also present and running.
  • One solution to this would be a common master -- a mod that would just store synchronizing elements (e.g., probably mostly globals, with a few objects thrown in). Other mods would become dependent on this mod, but not each other. This mod would be fairly small, but it would require coordination between modders to build and update, and it would have to be updated fairly frequently to handle new additions.
• Morrowind did not allow masters to be removed from savegames. If the master were not present, then Morrowind would refuse to run the savegame. Tools were later developed that allowed users to remove masters... However, it's not clear whether that will be possible with Oblivion.

Mod Merging

CS3 (Construction Set for Tes3/Morrowind) had an ini setting, that when turned on, allowed mods to be merged. CS4 apparently does not have that setting -- and given the nature of FormIds, merging of mods is likely to be moderately difficult (any formId conflicts must be resolved at merge time, and formids are used extensively in many different places). Moreover, any save games that depend on the mods being merged would also need to be adjusted. The savegame problem is actually more of a problem for end users than for large mod projects since end users have more need to merge mods that savegames depend on. (E.g., merging hair, body, armor, etc. tweak mods in order to keep the active mod count below 255.)

The main problem in merging mods is that conflicting objectindex numbers (see FormId) have to be changed. Just changing the objectindex for a record would be fairly trivial -- however, changing all of the references to that objectindex/formid would be more work and require a pretty complete understanding of the mod file format.

If it's also necessary to adjust the savegame file, then it would be necessary to build a mapping of the old objectindex numbers to the new objectindex numbers and use it to remap formid numbers in the save file. Hard enough in itself, but again it would be necessary to completely understand the save file format -- and in Oblivion, the save file format is completely different from the mod file format.

While this sounds like a fair amount of work (and it is), it's not impossible. Wrye Mash does something similar (but on a smaller scale) for Morrowind save games.

Fortunately, ScripterRon's TES4 Plugin Utility has solved a lot of these problems.

For more info, see Mod Merging.

Large Mod Projects

Given the above, a scenario for building large mod projects for Oblivion might go like this:

• Create a base master file.
• Project members then build their contributions solely on top of this master file.
• As items that need to be shared are created, they are merged into the master file. The updated master file is then sent to project members who continue to build on top of it.
• After team members complete and test their component mods, those components can be merged into the master file.
  • It might be wise to delay merging as much as possible, since once something goes into the master, you probably don't want to change it.
  • Accordingly, project design should try to divide the project into components that are relatively independent, thus allowing them to be worked on separately as much as possible.