Types Mod Integration

'''Thinking out loud... Expect some meandering with no clear conclusion...'''

Types of mod interaction: 1) Resource mod. Is specifically intended to be used as a resource for other mods. Modifies nothing in vanilla Oblivion. Is very stable. Possible examples: Eye/hair collection; room tilesets for dungeons; useful scripts; gameplay resource like Necessities of Morrowind.

2) Signalling mod. A mod that's specifically built to pass information between mods. This is "before the fact" integration. Morrowind example: Tokens and globals used for signalling between Vampire Embrace and other mods. I don't know of an Oblivion example.

3) Patch mod. A mod which is specifically designed to patch another mod(s). E.g., add additional portals to Frostspire, or remove the starting messages from the various official mods.

4) Glue mod. A mod specifically intended to glue two mods together. Typically this is relatively small compared to the master mods. E.g.: Dev_akm's FranOOOMMM leveled list mod. This is "after the fact" integration.

It's only recently that we've realized that esps can modify other esps, thus making 3 and 4 viable for esps as well as esms. (Qualification: PhoenixAmon reports that ParasiteX(?) figured it out months ago and used it to create a popular vampire patch mod, but didn't make a lot of noise about it, so it didn't become widely known.) Though this is still somewhat in testing, it looks good so far.

Types 1 and 2 should be esm mods, while types 3 and 4 should be esps. Given the possibility of esp-esp patching and glueing, it is not necessary for the master mods to be esms.

There is the consideration of which is better: pre-integration or post integration (i.e., signalling or glueing). The problem with signalling is that it requires a fair amount of coordination between different modders -- and most major modders are monomaniacs. So, realisitically glueing will happen much more easily than synchronizing. (Even in Morrowind, where signalling is relatively easy, there was very little of it. And by very little, I mean almost zero. However, glue patches were moderately common.)

To give some Morrowind examples: 1) MCA and NOM conflicted over beds. Solution was an MCA-NOM glue patch included with the MCA release. 2) A global for pc gender is used by several different mods. There was never an agreement on a standard global. 3) PC race number for custom races (used for dialog) might conflict. There was never a standard solution. 4) LCV Schedules conflicted with VampireEmbrace and other mods that had regular NPCs become followers. Cortex (VE) and I (LCV) implemented a signalling solution. 5) For new home/land mass mods to work well with NOM, they needed to include NOM resources (scripted wells, etc.). Some major home/land did, but most did not. (I did add a feature to Mash which allowed players to NOM-ify a mod, but I don't think that it was widely used.)

So that's my experience... Mod integration (to the degree that it happens) tends to be a second generation effort, often done by someone other than the original modder.

So, what's that leave? I think that if esp-esp interaction continues to work, then the only reason to esm-ify a mod is to split off the mod's resources so they can be used without otherwise using the integration of the mod into the world. E.g., to have OOO objects without having OOO otherwise in the world. Hmm... I don't know, seems like a lot of work for an only moderately desirable goal.

Splitting a mod into two pieces (esm and esp) has pros and cons.
 * Pro: It's easier to build on top of an esm. (However, Bash's espify masters command helps quite a bit.)
 * Con: You use two mod slots instead of one.
 * Pro: You can use the resource without using the esp. (But I'm not sure how desirable this is.)
 * Con: Two mods are more difficult to update and maintain than one.
 * Con: Greater chance of bad mixes, e.g., of an esp being used with the wrong version of the esm.
 * Pro: Memory consideratations. I think I'm hitting the ram limit (1 Gb) on my machine now that I've got the newer version of OOO (vs my original 1.23) plus KOTN plus other official mods. Havin separate resource mods might make that less of a problem (assuing that I don't load the esp of course).

Standard library esm:  Rather than having umpteen different resource mods, have just a few (maybe just one) to cover stuff that people really want shared. However, I'm not mod savvy enough to know what would go into it. As I suggested before, maybe tilesets, a NOM type game resource?

Like I said, I've just been kind of thinking aloud on this one.