Ok, in the past couple of weeks there have been a LOT of discussions regarding converting ESPs into ESMs... And to be honest, I don't understand a lot of it.. so I am creating this thread in an attempt to get some discussion on this topic going.

1) Firstly, What are the benefits of having an ESM over an ESP?

-- In my view of things, there are three potential benefits of having an ESM.
i) Allows for multiple ESPs to communicate with each other as long as they are both associated with the ESM. Good for those who want to release multiple mods and want the mods to know if the player has one of the other relevent mods installed.
ii) Allows for other modders to be able to use your added content without using the mod which they are associated with. (example, you create a big mod.. which includes new weapons and armors.. other modders with to use your weapons and armor, but not the mod)
iii) Allows for plugins or patches.. say your mod creates a brandnew dungeon which is placed into the world - you could then have a handfull of ESPs which the player would choose from which determine various qualities of the dungeon.

2) Secondly, Is it better to have a single ESM file; or to have both, an ESM and an ESP file for a mod?
i) Obviously, having just one file makes it easier for a player to install and uninstall....
ii) but if that one ESM file contains a lot of Vanilla entries, then it will be overwritten by any other mod which also modifies these entries.



I guess my purpose in posting this is purely to generate discussion in a way which is understandable to new modders and allows for different approaches to this issue.

I'd hate to see a new player say "oooh, ESM seems better than ESP- therefore my mod, which changes levelled lists and alters the weight of all items in the game, will be an ESM because it is better." -- Because that modder would be severely disappointed to learn that not only would their mod not be better, it would almost certainly be completely overwritten by most of the popular mods out there... which could lead to frustration and giving up on modding.

I have noticed that lod isn't working with esp's when you have other mods as well. This would be solved (yet to try this out) when converting it to esm.

This is exactly the kind of thing which I would like more information on..!! test and post back specifics..

I'm interested in the general merits of esm's over esp's.

I'm skeptical of doing this just for the sake of it or on the expectation that this will make MODs somehow more reusable by other modders. One obvious advantage is that you can load esp's that are dependent on having the esm's in place. This is handy if there likely to be several such esp's made and used together, otherwise you are as well off just modding an esp to produce a new expanded version. I would say that there maybe some disadvantages to using esm's generally, e.g. requiring that your game be started from scratch, and so would not advocate using them with no good reason.

However, currently there are some re-load issues when you do a 'quick-load' of a game to the same area. In particular it seems some quest variables may get re-initialized unless you restart OB and reload. Using an esm may force your quests and persistant objects to be more reliably scriptable. (?)

Starting the game from scratch? Do you mean that you can't use an esm in an existing save game? If so, could you elaborate? I've never encountered this issue before and would be interested in the conditions that precipitate it.

I have to confess as to not knowing much about using esm's, which is why I'm intested in this thread. My understanding that esm it has to be in place form the beginning of a (new) game but I'm not sure where I got this info. from and it may be simply that typically an esm would be used when changing the vanilla game set up, e.g. when scripting base objects. Please feel free to correct me and give us the benefit of your experience.

I only used it once for the variable damage spell script. The idea was that the script implemented and debugged a portion of code that might be desireable to others so I made it an esm. I tested it by creating an esp that used it and then using an existing character to test the spell. I think I even forgot to unload the two mods so my sister ended up playing on for quite a while with them loaded. Neither of us noticed any problems.

I think I read on the Open Cities discussion thread that you can't use esms that modify existing content. Only to add new content. (They were unable to make Open Cities an esm because it was trying to replace the existing cities.)

^^^^
Thanks for this snippet. Unfortunately it does not add much to the discussion of why one would use an esm over an esp. Did you have to restart OB with the esm in place or did you just select as usual? (I assume the latter.) From this example I would assume that the only benfit was that coding in the CS was easier in that your esp could reference objects added by the esm? However, having never tried it, I'm not sure what happens when you are working on two esp's at the same time in the CS?

Anyone?

I've worked on two ESPs at the same time - when both are associated with the same ESM... didn't notice any problems on loading an existing game.

I've worked on both the ESM and an ESP which was dependent upon the ESM at the same time in the CS.. didn't notice any problems on loading an existing game.

But in both cases my playtesting wasn't very in depth - just spot testing for what I had changed.

And as for the Editting the ESM in CS - actually I converted the ESM to an ESP, editted that, Saved that, Converted back to ESM, then saved the ESP which was dependent upon it.

I'm not quite sure what you mean by this^^^. I feel like we might be talking about two different things. I thought you were wondering if esm files would not work with existing save games. The comment above was to illustrate that I was able to load the esm into an existing save game without any apparent problems.



More or less. I wanted to make the spell script reusable. It was a fair amount of work to implement and debug and I though that anyone else who would want to deal variable amounts of damage in any application (traps, weapons, or straight-up spells) might appreciate having a script that took care of the fussy parts (with my script, you set quest vars to the desired damage amounts, type, target, casting object (optional), and magicka cost (also optional) ). As you can see I went to a lot of effort to make it very general purpose. (And yes, I know you published a technique to deal variable damage, etc. I read the article after working out the mod.)

Because the mod was specifically intended as a modder's resource, it made much more sense to release it in esm format so that multiple plugins could be made from it without conflicts. This is a rare, but very good reason for using esm files.

As for the "two esp's at the same time" question, I assumed that multiple esps would be able to reference the same esm in the same way that they do for the main oblivion.esm file. I'll be done with my finals soon and will verify this when I get a chance.

Exactly; an .esp can reference or change anything in an .esm that it's dependent on.
The caveats to using an .esm are that you can't include changes to existing landscapes without royally screwing up the terrain, and more generally you shouldn't use an .esm to alter any records from Oblivion (or another .esm).
Apparently .esms may not even be necessary any more, if Malbulga's and Wrye's experiments with .esp dependencies are anything to go by. There's a recent thread about it.

You know what's really annoying? THIS problem http://www.elderscrolls.com/forums/index.p...501&st=160# which involves one of my characters games 'eating' anything that is dropped in the gameworld, saved and reloaded after Sunday...the issue got resolved when I converted OOO to an esm, but it sucked, because there was nothing from Oblivion.esm in the gameworld. So still not a fix.

Any ideas about my reloading = vanishing items (but only after Sunday) problem with this one character btw? Or how I could get around the esm conversion issue?

I've only used ESM for one purpose so far... for the Book Placement mod, I wanted to reduce the amount of duplicate data that the game had to load, so I separated out McLean's scripts and the one new book added and put those items in an ESM. This ESM can be called to assign the scripts by my Book Jackets mod or the vanilla books esp or anything else. I know at least MrDarkSim has made use of it in his book mods.

I'd like to see Harvest[Containers] doing the same thing, so that it could return to a modular format without so much fuss involved in the maintanence. The scripts would still exist in only one file so that's the one that would need maintaining, while players could decide again which types of objects they wanted to use.

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.

Good thoughts there, Wrye.

Some other things to consider.

* The CS. Having clean ESMs (with few if any changes to 00 records) is the only practical way to build "glue" ESPs. There's just no way around this yet. Sure, it's not necessary to distribute the ESMs if you're willing to hex-edit the MAST record after you're done working in the CS (to fool the game engine into thinking an ESP is really a master). But this means you have to create your own clean ESMs for any mods you want to enhance/extend/glue, and so does anyone else who wants to work with the same master like you did, etc. This adds up to a lot of wasted effort in the long run.

* Maintenance. Especially ease of maintenance for option plugins. Both Fran's and MMM make very effective and extensive use of optional ESPs to modify certain aspects of the master. This makes those mods dramatically easier for the creator to maintain, and at least MMM is already benefiting greatly from a bunch of community-created add-ons. You can probably do the same thing with the hex-edit bait-and-switch method, but why would you want to if you have the choice?

* Longevity. You will eventually get burned out and move on. It happens to all modders (maybe a few exceptions, but not many). Do you want other modders who may carry on the torch for you after you're gone to be forced to copy your work and re-release it, or would you rather that they mostly just create option plugins to extend and improve your original work?

* Size. Silgrad Tower and several other very large projects have discovered size limits to ESPs. This limit doesn't seem to apply to ESMs.

* Teams. Large mod projects like ST rely on ESMs and then use merge-to-master to fold the new work of each team member back into the baseline for each phase of the project. This is essentially the same process Bethesda uses (although we're obviously lacking some of the tools they have) and there's a good reason for it. A sound development methodology like this is critical for any large team project to succeed (and it's also beneficial even for smaller team projects).

JOG's thievery esm or Retro's Crafting esm might fit that category. They provide a base that the author has already built one mod on and expects to build on further with more mods in the same series. Other mods could reasonably hook into the same esm, at least in the case of the crafting mod.


I suspect that ParasiteX didn't report that he'd done something new because he didn't know it. If you don't know something's thought to be impossible, you don't think much of it when you accomplish it. Although it's possible that he reported what he'd found and no one listened. Since I discovered what he did in that mod, I've mentioned it a few times on the forum, and it never caused a wave.

Similarly I reported that mods couldn't interact on this forum a week or so after Oblivion was released, and that post sat without reply for months and finally evaporated. Maybe a month later, you reported the same thing and then everybody knew it. Sometimes it's not what's said, but who says it. (This isn't meant to be rude or argumentative... it's merely true. You were a known respected member of the community and nobody had ever heard of me, and people are more likely to respond to those they know. I do the same thing, and so can't be offended when others do it.)


This is the one I'm most focused on, lazy beggar that I am. If I can just convince Dejunai that I am more evil than he is, I may win out.

PhoenixAmon: Known, and I posted it on a couple of places and PM'ed some folks too I think. Anyway, credit now given! And, I think that you're right about PirateX not knowing it was impossible. However, remember too that at the time we were figuring out mod isolation, we didn't have the tools to easily try the bait and switch trick. (I.e., I kind of suspect that he used Bash to do the bait and switch trick -- so I get partial credit for it anyway )

By signalling I mean something mod that is specifically designed for signaling between mods -- i.e., that would otherwise not be necesssary. For LCV, one signal was a global that LCV watched in dialog, another was an "OffSchedule" token that an NPC might have. If an NPC has the token, LCV doesn't apply schedules to them. Neither of those was something that LCV needed for itself, they were both there purely to support integration with other mods.

I think what you describe with thievery or Retro Crafting is more of a resource mod -- i.e., it provides resources, which another mod can also use. (But I'm not familiar with the mod, so I could be wrong.)

But I think that I'm quibling over details here...

dev_akm: Well it's not necessary to hex edit anything anymore. Suppose I want to glue mods Alpha.esp and Beta.esp together...
1) Use Bash's "Copy to esm" command on both Alpha.esp and Beta.esp. This creates esm copies of both mods, while leaving the esp originals intact.
2) Build glue mod Gamma.esp with Oblivion.esm, Alpha.esm and Beta.esm as masters.
3) When ready to playtest Gamma.esp, use Bash's "Espify Masters" command on it.
4) After playtesting, if you want to re-edit Gamma.esp, use the "Esmify Masters" command on it.
Then repeat 3 and 4 as necessary.

A possible improvement would be to have a Bash command, which than rather applying "Espify Masters" directly to Gamma.esp, first copies Gamma.esp to "Gamma X.esp" and then espifies "Gamma X.esp". That would allow modders to skip step 4. The only problem with this would be with mods with BSAs and/or voice files, which are linked to the exact name of the mod. (There are ways around this, but it's a complication.)

Longevity Hmm... I'm not sure that I agree with your point. The esm/esp split is more imporant for allowing variations of a mod (no small benefit), than it is for supporting upgrades. I think that if someone came in and did a substantial upgrade, then it would probably be necessary (or at least strongly desirable) to update the esm, rather than just release a patch. My MW experience (updating LGNPC Seyda Neen, NOM and LCV) all supports that -- for each of those, changes were pervasive enough that updating the original mod was more desirable than releasing a patch.

Maintenance, Size, Teams All good points. No counterarguments there.

Summary We're certainly expert heavy on this topic! And in truth, I haven't done that much modding for Oblivion, so my expertise is less than others. I still think that patch and glue are easy enough to do for esp mods, and I would strongly lean to doing that. However, a lot good points about moving to resource esms have been made.

I am sorry if I sounded like I was talking about giving credit... I only meant to point out that sometimes things go unheard because we listen more closely to those we know there's a good reason to listen to. That's a good choice... a person can read only so much news, so you read the news you know is from a reliable source. You deserve loads of credit. There are plenty of things we simply can't do without Bash, and while someone like me can see a problem and describe what they see and complain about it, we can't explain why it's happening. And failing that, we can't hope to change it.

Actually when I first saw what ParasiteX had done, the first thing I did was look at Bash to try to figure out how. I hoped to avoid hex editing a single byte, and now from what you describe I can do just that.

Ah, yes, I see what you mean. The types of mods I describe are more for providing a framework for expansion by the author. They're not exactly meant as a public resource, but an internal one. Still, resource fits.

Just rambling a bit now...

I think ParasiteX's reason for use of the bait-and-switch is likely the best one... you want to provide interactivity with an existing mod as a third party. This happens after the fact, and you do not control the mod you want to interact with. If that author has not provided an esm, you have this option to provide compatibility.

You might also do the same thing when you do have control of the original mod, if the mod you want to use as master is something you've already circulated. If you update your old mod to esm so that you can make it interact with your new mod, you may cause problems for people who are already using it. If they upgrade to an esm version the name of the mod has changed, so variables stored in their savegame may not be carried over. Ownership of mod-added items may not be carried over. Rather than tell the users that they need to start from scratch if they want the add-on, you can use bait-and-switch so that they don't need a new version of the original mod.

It's taking me a long time to type this, because I keep thinking of permutations and "what would I do if...". If you're building a mod that you know you plan to produce in installments or if you're sharing a pure resource, these are the times when I think you'd be most likely to build an esm from the start. For a large mod like Fran's, once you go through the splitting process, I'm not sure if having the esm is useful anymore. You'd be putting so many modified vanilla forms into esp files that you'd have to use bait-and-switch for you add-ons anyway, so is separating them out really worthwhile? Having and esp master and an esm master rather than just an esp master? My brain's gotten stuck on that example, so I think I'll stop now.

Thanks. All good stuff to know. I was actually referring to 2 esp's being edited at the same time w/o an esm. But I assume that you cant reference stuff in one esp (in the CS) from another.(?) That is, they would both have to reference a 'parent' esm and that's basically why you would use one.(?) One o'these days I might get around to trying this stuff for myself - basically when I can work out a reason for using an esm wrt my mods.


I see. That would be a couple of reasons I guess, especially the idea of issuing a large MOD as components that all shared the same esm.

Just got caught up on reading most of this thread.

You guys should be a bit more explicit about 'the MOD isolation problem' and the solution discussed for esp's - there are no good links anywhere on this thread. It sounds like it could be very important or exceedingly neice. (I started threads on the subject of inter-mod (esp) communication a long time ago with recommendations for how to go about this but I've no idea if what's discussed here is in anyway related?)

Please add a little simpler discussion for those of us that haven't seen/followed these threads.

Only one of the mods you're working on can be Active in the CS. So you've got mod A and mod B open, B is the active one. When you have both open in the CS, you can use items from mod A in mod B. It feels like it's working. Everything appears just how you'd expect. Then you save mod B, and try to load it in the game or CS and discover it can't remember where it got those references. Nothing but errors for everything that was referenced from mod A. If you use Bash to add the "master" reference to mod A, I believe you'd resolve the errors. Now the engine would know where to look for the resources. But I haven't tried that yet.

EDIT: For a specific example, the first OB mod I did was add some new eye colors. Then I wanted to use a second mod to assign those eye colors to some NPCs. I opened the eye color mod in the CS but didn't make it active, and set about making a new mod assigning the eyes. It all looked great until I saved and closed the CS. It didn't work in the game at all. It couldn't find the eyes assigned. I can't remember whether I got error or if it just crashed, but I do remember that it plain didn't work.

I didn't see whether anyone had answered the question about esm's needing a new game. They don't. An esm can be added to a game in progress without a problem. Certain types of changes do require a new game (I think changing merchants' spawn lists is one of them) but that issue exists no matter what mod format you use.

Thanks a bunch phoenixamon. Didn't want to seem stupid but with reems of text my brain starts to panic or something - I've always been a bit dislecix.

I've used multiple MODs in the CS (I've only have 3) but just for copy/pasting - always been affraid to find out what happened if I actually tried to merge them. Good to know I did the right thing in playing it safe here. (I'm very goal orientied - I'll find a way to do whatever I need regardless of difficulty but never try stuff just for the sake of it otherwise.)

Good tips! I didn't know about the Espify Masters/Esmify Masters function, so I haven't tried it yet, but from looking at your readme page it looks like this would work great if you don't mind re-arranging your data folders a bit before you run it. I'm assuming it makes the switch automatically for each master (i.e., without prompting the user) based on the files it finds in your folder. For example, if I have:

Francesco's leveled creatures-items.esm
Mart's Monster Mod.esm
Mart's Monster Mod.esp
Oscuro's_Oblivion_Overhaul.esm
Oscuro's_Oblivion_Overhaul.esp

Then if I want to make a new plugin that uses these masters but bait-and-switch the Oscuro's_Oblivion_Overhaul.esm to use Oscuro's_Oblivion_Overhaul.esp instead (since the ESM has not been publicly released), then to use your function I would need to first remove Mart's Monster Mod.esp from the directory (since I don't want to change that master reference). Right?

I think you're better off leaving Step 4 in that process.

It would be really useful to also have an "Add Master" function in Bash. I currently have to do this in a hex editor (TESsnip has a bug that can sometimes mangle your mod), so it would be a very useful feature for anyone trying to follow my Creating Clean Masters tutorial. I guess this request would be better in your Wrye Bash thread, but it might not make much sense without the context of this discussion.



I agree that variations are a much bigger point, but consider the case of OOO for a moment. I've been supporting it while Sotobrastos is away, but I haven't been able to reach him to get permission to release some bugfixes. This means I have to release binpatcher files, which are a royal pain (takes forever to compile and confuses the heck out of the kids). It would've been massively simpler to just release an ESP with a few fixes in it. If I do it again I'll probably use the bait-and-switch method.

Also, although I agree with your point, longevity isn't just about upgrades and fixes. If you have a mod that adds some really cool new content/feature/tweak/whatever, chances are that eventually someone will come along with another mod that adds some other really cool new content/feature/tweak/whatever but is incompatible with yours on some small but critical points. If you're not still around to upgrade your mod, and you never released a clean master, then it's going to be significantly harder for somebody else to come along and create a bit of glue to fix this incompatibility. Not a huge problem for most mods, to be sure, but certainly worth thinking about.

Dual Editing
Open two instances of TESCS. Edit the resource master in one and the addon master in the other. Then save both and reload the addon when you need it to use the updated master. Definitely not as convenient as doing all your work in one mod, but it's doable.


Correct.

Adding Master Function in Bash:
Well ordinarily, if you add a master, you need to jack up the formids belonging to the mod itself by one modindex number. This is pretty nontrivial operation. ScripterRon figured it out for his tool, but I'm trying to avoid doing it. But if you're thinking of doing this in the context of splitting out material to a master resource esm, so that the modindices don't need to be jacked up... Hmm... Just adding another name to the master list is trivial -- I'm only concerned about safety for general Bash users. Anyway, if that's the goal something can be added to Bash one way or another.

Previous discussions for those looking for more background
* ESF: Mod-DeIsolation
* ESF: Dealing w Dirty Masters
* UESP: Mod Integration
* UESP:FormId
* ESF: FormId Problems

Yes, specifically, this is known as "Master Injection" and is needed when you split a mod into an ESM/ESP pair. No correction of FormIDs is needed. Just add the MAST record to the TES4 header and update the record count. All records that were previously local (i.e., new content) will now be considered change records for the new master you've injected. Any further new content you add to the ESP (when working in the CS) will now be given a higher modindex (+1).

BTW, Timeslip has just released a fixed version of TESSnip that shouldn't lose data anymore, but it would still be a lot easier to do it in Bash using something like the interface you already have for altering savegame masters. TES4plugin lets you remove masters, but does not let you add them.

dev, do you happen to know where I could read more about "Master Injection"? I keep seeing the term, but what you've just said is the closest I've yet seen to a description.

Also wanted to say thanks to everyone for a good discussion. This thread has got me thinking a lot. I feel less sure now that I'd know what to say if I were writing a generic list of "best practices" but more sure that I'd be able to decide what to do in a specific situation.

Fine. Okay. "Add Master..." now available in Wrye Bash 0.36. (Note that it's on the context menu for the mod itself, not on masters list details.) It was easier to code that way.

Oh, and I threw in a merge leveled list feature too.

LOL. Sweet! You rock!



The only one I know of is my Creating Clean Masters [TUTORIAL]. If that doesn't explain it well enough, then let me know and I'll try to expand it.



Agreed. Good stuff all around, folks!

As I've hinted at the Bash merged list thread, I've developed a feature which will build alchmemical catalogs updated to the currently active mods. Here's how this will work:

Base Mod: Alchemical Notes.esp OR "COB Main.esm"
Bashed Lists, xxx.esp

The catalogs are scrolls which are defined in the base mod. Then, during the bashed list merging process, I rebuild the catalog text based on the actual loaded mods and insert it into Bashed Lists, xxx.esp so that it overrides the original version. Basic code is already done. I just need to clean it up and integrate it into the GUI. Here are a couple of excerpts:

So, policy question: I could just go ahead and have an "Alchemical Notes.esp" mod with maybe some minor quests, etc. to ge the mod. But I'd like to take this opportunity to start using a common library mod, which we've discussed earlier here. E.g., rather than having my own special mod, I'd like to use something like "COB Main.esm" (COB = Common Oblivion).

As far the alchemy catalogs are concerned, COB Main would only contain the catalog scrolls (a separate esp could be used to place the scrolls in the world). However, for this to be worthwhile, I want COB Main to become a general standard which can hold various "before the fact" integration data (basic leveled list definitions, etc.). I.e., it needs to be a group project.

Who's interested?

Nice! Great idea, man! I'll be happy to sign up for this effort.

Actually, this is very similar to what I was proposing in my original spec for a split/merge tool. The COB Main.esm would essentially serve as a template for other modders to use when they want to add stuff to leveled lists.

Martigen and I are already in the process of working on something very much along these lines in order to create a better MMM for OOO mod (more closely integrated than the current FranOOOMMM version).

The big question in my mind is whether this can be done with a single "template" (i.e., list structure) or if we will need several different ones to accommodate various design goals. It seems there are at least four popular approaches right now:

1. Fully Leveled Random (Fran/vanilla style lists)
2. Random Risk/Reward (MMM style)
3. Static Risk/Reward (OOO style)
4. Mixed Static/Random (compromise, ala FranOOOMMM!)

Perhaps if the base lists are structured correctly, we could manage to have only one baseline and then several optional variant ESPs that adjust the level settings and counts to match the player's preferred style.

I'm not sure this list includes the Critters model.

What do you think?

As an aside, Wrye, for the next time you update your site:

Latest version of wxPython is 2.8.0.1.
The unicode version definitely doesn't work, at least with Mash. (Haven't tested with Bash, no much point to it since my laptop can't run Oblivion anyway. Stupid shader-allergic Intel chipsets.)
Unicode error report.
Worse, I get that even when I tell the ANSI version to be the default wxPython. wxPython unicode has to be completely uninstalled before Mash or Bash may work.

Gez: I've replied on the Wrye Bash topic.

COB Main.esm: So, should I just go ahead and do it? (Might wait a day or so to see if anyone else has comments.) My first version would just have six to eight scrolls in it. Other stuff (e.g., leveled list templates) can be added later. (A strong consideration is that stuff should not go into COB main until we're pretty sure about it.)

Leveled List Templates
If you want to accommodate different leveling styles, then I think that the best solution is to have a single template with a consistent style (default to Oblivion style, I think), and then have esps that patch that default style to other styles as desired.

In doing this, I think that you could simplify the amount of patching work by leaving the sublists unleveled (e.g., all at level 1), and letting the highest level lists do the leveling work (or not do it as style dictates). (But this is not my area of expertise -- I'm probably either stating the obvious or missing some equally obvious flaw.) However, you set it up, you need a guidelines for modders who want to add stuff to leveled lists about how/where to add their items.

Now, suppose that a modder adds his cool new weapon set following vanilla Oblivion leveling rules. How do you morph that to a different set of leveling rules? Well, he could supply patch esps that patched the mod to each of the different leveling styles.

Or the end user could use Bash to automatically apply a leveling style while merging. E.g., Bash could take a given leveled list (after merging) and flatten, scale (current level x 0.75), cap (max level == 20), randomize, or partially randomize the levels as the user specified. It wouldn't be desirable for Bash to do this to ALL lists, but rather only to a specified set of lists. Note that for such scaling to work, the original lists need to be leveled in a consistent way. In particular, the source list can't be flat or randomized (have random levels, I mean). For bash's style morphing coding, scaling, randomization, etc. would all be pretty simple formulas. However, with custom python code you can mangle the lists in much more interesting ways of course.

For example: Random Population: Suppose that families of NPC lists are named in a consistent way, e.g. (Amazon10, Amazon20, Amazon50), (Bandit10, Bandit20, Bandit50), etc.. Bash can now recognize each of these as a family of lists. Now, suppose that a modder puts spawn points in cave "Foo", but rather then putting a particular type of spawn (e.g., "Amazon") at that point, instead uses empty lists named like (caveFooXX10, caveFooXX20, caveFooXX50). Now, Bash merge comes along and what it does is randomly assign a single spawn family to the caveFoo spawns (e.g., Amazon10 to caveFooXX10, Amazon20 to caveFooXX20, etc.). Now you have a cave randomly filed with a consistent type of NPCs. Do the same thing with campsites, etc. Do this and you'll shuffle your Oblivion experience every time you do a Bash Merge. Note that cave Bar a couple of cells over would have different spawn names (caveBarXX10, etc.) so the family that it received would be randomly different than cave Foo.

The last is something of an alternative to PirateLords's approach. The plus is that it's somewhat simpler and more flexible. The minus is that it requires using Wrye Bash merge whenever you want to swap populations (i.e., you have to step outside of the game world).

And if some people are foolish enough to refuse to use Bash, it's always possible to someone else to bash the lists together and release that.

Wrye: Yes, go ahead and make your COB. We can add to it as we go.

I'll give some serious design time to the template issue in the morning (just woke up for a snack, need to go back to bed).

Corepc: I'll also put some time in on the issue you raised about making neutral factions. This is a pretty big issue with merged lists and it might actually be an area where something like COB could help out. However, this would probably need to be a tool for mod-makers rather than mod-users I think. The problem is we almost certainly do not want to try automatically generating a massive integration mod that copies NPC records from all the merged mods.

Just random thoughts here. Perhaps a single NeutralFaction.esm could be shared among all the major mods and then you could use the batch edit function in ObEdit to easily assign this faction to all the right NPCs? If you got Fran, Martigen, Soto, etc. to all include this as a standard element with their mods, then their NPCs could already be members of those factions and all you'd need to do would be add yours as well. Wouldn't this work?

I really like this idea. I've been hoping that a nice "Oblivion Mod Standard" would come along for a while, to lessen the amount of conflicts people have with larger mods. Along those lines, having a nice "Community Expansion Mod", along the lines of the CEP for Neverwinter Nights would be phenomenal, more for a modders resource type idea, so they can put new items/areas/characters/scripts etc. into the game world as they wish all from one large mod so they don't have to have millions of small mods adding each seperate thing, with the possibility of overwriting other files. I've kind of been trying to do it myself with just the mods that I have, and boy is it a "fun" undertaking... Keep up the good work!

Shouldn't these factions be defined in COB, then?

Yes, I was just about to bring up factions as well.

My personal interest in the issue is that atm I'm making house mods. All my house mods have extra bedrooms/sleeping areas, in the event that the player has a companion, or more than one, and doesn't want to make said companion or companions sleep on a bedroll on the floor somewhere.

But I cannot, of course, know which companion any user might be using-- I don't necessarily know which companion(s) I might be using in any given game.... and all the companions are different factions, so I can't even designate a bed as useable by a "Companion" faction and hope that any companion, whether a CM Partner, or Gabrielle, or Vincente/Valeria, or Hunl'aa/Elwen, or Amoz (Dremora Companion), or a companion created by Unique Companions, or only Dexwood's Daughter, would recognize it.

If at least companions had a single faction, contained in such an common ESM, it would enable "me" or the modder or whoever, to make all the companion mods dependent on that ESM and set all the companions to that faction, which would 1) help companions get along even if they were from different mods, and 2) allow me to designate beds in my houses to that faction easily and quickly.

The more complex faction issues occurring in mods like MMM I don't know about, but I do feel that some elements of 'factionalization' should be under consideration for communalizing.

Dev - Yes the single Neutralfaction.esm just along these lines that could be used by modders. Just not by npc, but, for creatures, objects, basically anything that you can set ownwership over.. like motub said..

Give it some thought please

I haven't been replying because I don't feel I have clear understanding of what's being discussed at this point. Since I'm not getting a whole lot clearer on the matter, I'm just going to post my thoughts and see if you can set me straight.

On the issue of the COB.esm file, I'm not really sure whether I understand the idea. I imagine it becoming a large resource mod that adds items and can be called by other mods to add those items to the game world. The first example we have for this is Wrye's ingredient recipe scrolls. It might also have some creatures and some furniture and a collection of activators to emit creepy sounds. So say I want a new hounted house mod, and it pulls on some of the creatures and some of the creepy sfx. I don't choose to have a mod that uses the recipe scrolls. If this resource really becomes big, might I not be loading a lot of data that I'm never using because of my mod choices? And if I am, will it matter much?

I do understand the GenericFaction and CompanionFaction ideas, and those would both be excellent resources. Is this the basic idea behind the templates? I'm just not clear on what templates means.

COB Main.esm Contents: I think that we'll need to figure that out a little bit. I would like COB Main.esm to be kept relatively small, but in truth I'm not sure how much this matters (many esm entries don't use up that much space in themselves).

Here's what I'm thinking right now:
COB Main
* Alchemical scrolls (8 items): These will usually be overridden by a later esp (Bashed list.esp)
* Generic Factions
--* Companion faction
--* Neutral faction??
--* Amazon faction (etc.) (Maybe)
* Expanded Lists (Blank in esm, filled by creature mods, later merged by Bash)
--* Amazon10 (a low amazon)
--* Amazon30 (intermediate amazon)
--* Etc.
* Standard activators/scripts
--* Bed, well, scripts, templates (for HTS (Hunger, Thirst, Sleep) type mods)
--* Standard companion script??
--* Standard well, water bell activator (again for HTS type mods)

Most of that stuff is just an idea at this point. The only thing I'm sure about at this point is the alchemical scrolls. I'm fairly sure that COB Main would NOT include creatures -- though it would probably include standard creature lists. I'm not sure about something like standard tiling sets. I think maybe a separate "COB Tiling.esm" for that -- if such things ever appear.

You could argue that COB XXX could be quite large, which would be useful for people building house/area mods. E.g., more books, more ingredients, more furnishings. I'm just not sure where to draw the line between what COB adds and what various mods (OOO, etc.) add. And those other mods are already being "resourceified". I think that will come out of discussion.

Anyway, I'll set up a project/discussion area somewhere later tonight when I have some more time.

I've searched high and low in this thread, and found the info about what COB is, but where the hell did the acronym come from???

Edit: aah, finally found it.

This sounds good wrye,

I have been working on my own esm / esp for my mod and it is working well. In my mod I place my merchants/npcs, creatures, xmarkers directly into cells. These changes causes problem with in and esm but not in a esp format..So, I have had to strip and rebuild using mainly the editor with tes4plugin to strip out data and copy over to a new esp the world data and x markers and packages that point to these, but, I have everything work just fine has along has world cells changes are kept in and esp not an esm...I just re add the npc from the esm to the esp with the ai packages and replace at those locations that are needed..It worked out quite well..

Thanks for this thread and these ideas

Corepc

Okay, I've started a discussion page at UESP: UESP: Common Oblivion. In particular, note the Proposed Additions section of that page. If you want something added, please suggest it there. I've put in a brief discussion of Companion Faction, and I've just put in a header for the Neutral Faction -- I don't really understand what the point of this is or where it would be used. CorePC and motub, I hope you'll expand both of those sections.

There's a plus and minus about UESP wiki. The minus is that it's another place to go to and a slightly different editing tool to use (but still pretty easy, especially for plain text). The plus is that it's easier to keep the discussion in place and pretty focussed. E.g., on this forum, I might reply to three different suggestions in one post -- which means a reader has to go back and put the pieces together. Whereas on the wiki, all of the comments on a single issues (e.g., a companion faction) are kept tightly together. Plus, by indenting your replies to other folks, the flow of the discussion is made pretty clear.

Thank you Wrye, I will check the page out..

The main purpose of such a faction.esm would to be able to assign ownership over cells, npcs, items, whatever, that can be used by the faction and it could be used by all for a large community project..in short!!

Okay, folks, I'm going to head over to the UESP Wiki in a few minutes and see what's up there. I haven't had a chance to post much on this yet only because I've been quite busy with holiday preparations and other projects, etc. (more on that below).

KomodoDave and myself have just finished the beta version of an extension to ScripterRon's TES4 Plugin Utility that will let you automatically create a clean ESM/ESP split mod from an ESP. KomodoDave has done a fantastic job on this (with a little help from me) and it's looking really good already. I was able to split the OOO.esp into a clean master/plugin pair and load it into both the CS and in-game without any errors or savegame problems, so I'm really excited about this new tool.

I mention all this here mainly because the ability to easily create clean master files is critical to more widespread mod integration and compatibility, much along the lines of what we're already discussing here. KomodoDave and I will post more details on this new tool after I contact ScripterRon regarding how he would like to see it released (i.e., whether he wants to post it as a new version of TES4 Plugin Utility, which is basically what it is, or if he would rather have us branch the functionality into a separate tool release).

I'm sure many of you will be away visiting family and such over the holiday weekend, as I will be myself, so have a merry xmas everyone!

this should people out thank you KomodoDave and Dev_Akm, everyone have a jolly holiday!!!

Heh. Well there you go, I have posted to a Wiki and the sky has not fallen. Yet. I'm still looking up.

Wiki: Thanks y'all. Looks like it's starting out nicely. I moved stuff around slightly just the so the page design is kept consistent. Combat tokens like a good idea, but it's outside my area of expertise, so I won't have much to say on it. And thanks for the links dev_akm...


Well, ummm... Basically you just described what a "faction" is. Why would there need to be one "neutral" faction that would be shareable by multiple mods?

For companions mods, I get it. You got a bed, and you want whoever your current companion is to sleep in it. There are a lot of companion mods, and you want them all to have the same faction so they're all ready to sleep in that bed.

But what's the corresponding argument for a "neutral" faction? Why would it be useful for different mods to share this?

Now I can see arguments for various types of standard factions e.g., Amazons, or Daedric. E.g. mods other than OOO might define their own Amazon npcs, but otherwise not build on top of OOO. So a common Amazon faction would be useful. By why a generic "neutral" faction. What types of creatures/npcs would belong to it, etc.

YW

I think rather than a GenericNeutral faction, what Corepc is looking for specifically is a TravelingMerchant faction so that his merchants won't get killed by bandits and marauders. Yes?

Hehe. still have a split conversation. I just posted my thoughts on the neutral faction to the Wiki.

I don't speak Wiki, so be patient with me while I try to get my bearings over there.

Well If one common neutral faction was shared by serveral mods, then any one of companion mods could use this faction for other mods, anything that a faction can be added 2 could be shared, houses, npcs, chest, objects, those types of things..and the faction relationship can be altered through and esp

Example: Mod Maker take faction above and makes a new mod, using the common.esm faction, he then could alter the faction relationship with an esp and with thus creates the so called actions that are needed, if they wanted bandits to attack them, or amazons, or whatever from any mod..

this is what I have done in my esm / esp split for my merchant mod..Dev_AKM & Wrye

Thank you for this thread and USEP page

I've added "Bandit Protected Faction" at UESP. I think that this plus the Companion faction would cover what's been talked about here.

If that doesn't cover what you're envisioning, then I think that I'm still pretty fuzzy on what you're suggesting.

PhoenixAmon, you're doing fine. I just have to keep remembering that you're PA here, but Daleth there. Please pardon my slight reorganizations, it should stabilize before too long as people get used to the wiki and we figure out what the main areas of discussion are.

The reorganization is fine. I'm just feeling my way around and sorting out how to do clever things like links. I feel like I'm doing the Wiki equivalent of a "Hello World" excercise.

I have the read the UESP and that is exactly what I have envisioned, a faction that does not fall under attack from bandits, marauders, etc..Like they have paid them not to attack them..Expect daedra course, when the gates open up the mess up the economy and world!!!

thank you Wrye and Dev_Akm!!! have some

Corepc

Here's my general thoughts: 1) I don't want to kill Cob with too much process. It should be possible to add stuff fairly quickly. 2) On the other hand, I don't want to risk throwing stuff in that's a mistake, or for which there's going to be a lot of dispute over. And 3) I don't want to do too much work! So, with that in mind, when it looks like discussions are might be long, and/or is outside of my area of expertise (which may be much of the time), I'll ask other folks to take the lead.

Also, the wiki tends to be best for short to medium length discussions (and final conclusions/information pieces). So, other forums may be useful for various discussions.

So, with that in mind, I'm asking:
* Behippo to take the lead on OBSE support in Cob on the forum of his choice.
* Daleth/PhoenixAmon to take the lead on alchemy sorter on the forum of her choice.

When/if there's a consensus on these, I'll add whatever is suggest to Cob Main.esm (or maybe to another cob mod, if that makes more sense).

Sounds good, man. I'm still working on getting some other recruits in here.

I'm also going to attempt a mock-up of some leveled list variations as I get time over the holidays.

Being as I have no idea where to begin a discussion about this sorter business, I'm just going to start doing what I know how to do.

The idea seems to be to create a sorter that can pull all of the ingredients from your inventory and put them in a single container for storage. When retrieving them, you can either just open the container and take them or you can choose a desired potion effect and sort out only the ingredients that have that effect visible at your skill level.

There should be 2 versions: Vanilla and OBSE. The OBSE version would be in an ESP file that overrides the Vanilla version in the COB esm. If a modder attaches the vanilla script to a container in their house mod, and the player has the OBSE esp installed, he'll get the benefit of the OBSE script. The modder only has to create one version to provide both options.

If anyone disagrees with this summary, kick me (gently).

I suppose a lot of people aren't going to be around for the next week or so. I will because I'm boring. But for those who are doing the family thing, here's hoping your obnoxious Uncle Fred falls just ill enough that he can't make the party.

I'll lead up the effort for OBSE support, but it willl probably be a bit before I get to do much with it. I'll thik about it while I get v0010 out the door and start to play a little again.

QUOTE(phoenixamon @ Dec 23 2006, 02:12 AM)

I suppose a lot of people aren't going to be around for the next week or so. I will because I'm boring. But for those who are doing the family thing, here's hoping your obnoxious Uncle Fred falls just ill enough that he can't make the party.

I'll be around In fact, I'm spending Christmas day alone in my student accommodation house, programming Oblivion-related stuff. Cool huh?

QUOTE(Wrye @ Dec 19 2006, 09:47 PM)

As far the alchemy catalogs are concerned, COB Main would only contain the catalog scrolls (a separate esp could be used to place the scrolls in the world).

So AFAICT it's not implicit that the COB record set be entirely distinct from vanilla Oblivion, right? In that case, Gecko should be a useful tool when dev_akm and I have released in the not-too-distant future. Automated splitting of ESPs into ESMs is obviously a great time-saver.

I think it'd be beneficial for the community to have a repo of script templates as a sidedish. I'm not sure what people think of this... perhaps regular scripters like Xcom, scruggsy, hrmn, guidobot101 and sarkandar could give their opinion? There are so many posts about people needing help with scripting that a few templates for things like a weapon that triggers a spell upon hitting a target, or an item that unlocks a container when added to a different container, would be very helpful. I'm mainly thinking of the script comments being of great use to newbie scripters who don't want to wade through the CS Wiki but would instead like to build from simple examples.

It would be easy enough to categorise scripts into a single-level folder hierarchy. As a sidenote, this integrate work well with Si!K too, since if we had a downloadable archive containing these folders, users need only unrar it to their Si!K directory and immediately the scripts are available from inside the app. I'll be adding template support within the next month too, so if we decided to go ahead with the script template repo, it could be imported into Si!K and immediately every template could be pasted into a new script with a single click.

I mainly mention this in relation to Si!K because I know a number of scripters use my editor already, and since I'll be making templates exportable, there should be a repo somewhere for them to be available. So why not alongside COB?

Ahh kids... Remember, in the old days we had lonely dorm rooms AND no internet connection. (And my grandmother had to walk twenty miles through the snow to reach her lonley dorm room with no internet connection.) :0


Not sure of your point here. Cob main.esm will have oblivion.esm as its master, and may of course refer to it in places. However, it won't change any oblivion.esm records (esms can't safely change records from other esms).

Re automated splitting... First I'm sure that you've checked back over the whole thread -- there's a lot of good discussion about, esps and esms. One of the basic problems in esm splitting is that you end up using two slots of a limited number of mods. And believe me, advanced players with Morrowind DID hit the 255 limit, so this is an issue.

Personally, I think that major mods will continue to benefit from splitting, but I hope that we'll be able to avoid a fair amount of it through cob. For example, look at mods that want to add a moderate amount of objects to standard leveled lists (e.g., the polearm mod, or spell tomes). These don't need to have esm forks because their contents can be merged into the game using Bash. Or an alchmemy sorter mod -- again, these types of mods don't need to be split, because cob will contain an alchemy sorter definition, which can then be overridden by particular implementations.

Hmm... Don't know anything about silk. Wouldn't the template despository best go with the silk distro? I'm just not seeing the connection to Cob yet.

I didn't mind the lonely dorm room and no internet connection. I had better drugs back then.

For the templates, I also don't see the relationship to COB unless these are functional and useful scripts as well as templates, which seems unlikely.

[censored] forums jamming, triple post

[censored] forums jamming, triple post

QUOTE(Wrye @ Dec 23 2006, 06:13 AM)

Not sure of your point here. Cob main.esm will have oblivion.esm as its master, and may of course refer to it in places. However, it won't change any oblivion.esm records (esms can't safely change records from other esms).

Re automated splitting... First I'm sure that you've checked back over the whole thread -- there's a lot of good discussion about, esps and esms. One of the basic problems in esm splitting is that you end up using two slots of a limited number of mods. And believe me, advanced players with Morrowind DID hit the 255 limit, so this is an issue.

Actually I wasn't talking about ESM splitting. I should've been clearer . Let me rephrase: do you think that COB will solely be a single/multiple ESM distribution? Or will there be ESPs thrown in with the mix too? If the answer to this last part is 'yes', that's where automated splitting might be helpful, since it will guarantee the maximum content possible in the ESM you split to.

QUOTE(Wrye @ Dec 23 2006, 06:13 AM)

Personally, I think that major mods will continue to benefit from splitting, but I hope that we'll be able to avoid a fair amount of it through cob. For example, look at mods that want to add a moderate amount of objects to standard leveled lists (e.g., the polearm mod, or spell tomes). These don't need to have esm forks because their contents can be merged into the game using Bash. Or an alchmemy sorter mod -- again, these types of mods don't need to be split, because cob will contain an alchemy sorter definition, which can then be overridden by particular implementations.

Sure thing, I understand.

QUOTE(Wrye @ Dec 23 2006, 06:13 AM)

Wouldn't the template despository best go with the silk distro? I'm just not seeing the connection to Cob yet.

Well, you said that COB is a library resource. A library is generally considered a collection of standard programs/routines/types. So I figure, if you're going to have a set of 'standard' scripts, ie. templates, then why not have them tied up with COB somehow. If COB will have categorically segregated ESMs, template scripts might be divided into the same categories and offered for distribution at the same dl locations.

I don't think that, if you're planning on having a 'common' resource that's useful to all, it's sensible to just ignore a huge part of the mod-making process. Practically every interesting change you can make is script-driven, so why not facilitate the process and offer templates that can be used as building blocks?

Back to what I said before. (Not the part about being able to talk to my snake.) If the templates are functional and useful scripts, it makes sense to include them in COB.

But if they're just templates, certainly they're a valuable resource, but distributing them as part of an ESP or ESM file doesn't seem the best way. Why compile them when it's actually easier to read them outside of the CS? It's easier to read them in Silk or on a Wiki page or even a text file.

I'm seeing COB as a set of scripts/items/whatevers that are playable as soon as they're placed or referenced in a dependent mod. As a resource, they can be cloned and altered and expanded, but they don't require any changes at all to do something useful.

Heaven knows I'd love to see the various companion activity scripts added to such an ESM, so that new modders could mix and match (and not have to re-invent the wheel, likely causing yet new incompatibilities in the process). I've just proposed a similar ESM resource for a project I'm involved in (Cyrodiil Real Estate), because it's just silly for one modder to create objects that cause exterior windows to light at night, but if I also want to do that, I have to either create them myself (reinvent the wheel) or send my mod to that other modder so s/he could add them for me, wasting their time and delaying release, whereas if everyone on the project had a common base of such objects, I could submit a completed section, rather than a mostly complete one.

I think it really just depends on whether modders are willing to offer their unique base objects/scripts to other modders in the same "field" (presumably quest modders wouldn't care about dynamic day/night lighting in a house, but other house modders might want the objects needed to create the effect), which I have no idea if they generally are, or if they would be willing to be persuaded to be, but it was the hidden agenda of my Wiki text, to suggest some of the possibilities that would open up for all kinds of new and current modders, if the modders shared their resources and completed functionalities via such an ESM as CoB.

QUOTE(phoenixamon @ Dec 23 2006, 07:29 AM)

But if they're just templates, certainly they're a valuable resource, but distributing them as part of an ESP or ESM file doesn't seem the best way. Why compile them when it's actually easier to read them outside of the CS? It's easier to read them in Silk or on a Wiki page or even a text file.

Well, if you read what I'd said about distributing them in a folder hierarchy, you'll see I didn't actually oonsider them being distributed inside the ESM. However, as motub says, that might actually work pretty well.

QUOTE(phoenixamon @ Dec 23 2006, 07:29 AM)

But if they're just templates, certainly they're a valuable resource, but distributing them as part of an ESP or ESM file doesn't seem the best way. Why compile them when it's actually easier to read them outside of the CS? It's easier to read them in Silk or on a Wiki page or even a text file.

Hey, I never said anything about them not being functional! I call them templates to indicate they're a pattern from which a design is created. I'm thinking of them more as building blocks though; they could very easily be fully functional too.

QUOTE(phoenixamon @ Dec 23 2006, 07:29 AM)

If the templates are functional and useful scripts, it makes sense to include them in COB.

I'm glad you think so

QUOTE(motub @ Dec 23 2006, 08:43 AM)

Heaven knows I'd love to see the various companion activity scripts added to such an ESM, so that new modders could mix and match (and not have to re-invent the wheel, likely causing yet new incompatibilities in the process).

I think it really just depends on whether modders are willing to offer their unique base objects/scripts to other modders in the same "field" (presumably quest modders wouldn't care about dynamic day/night lighting in a house, but other house modders might want the objects needed to create the effect)

I agree with that sentiment I think modders ARE willing to share; this community seems very happy to muck-in and show what they've got. This being the case, it would be great to produce some robust, well-commented scripts in parallel with COB that utilise what's there already. Since COB itself will be a skeletal structure, scripts using its contents will inherently be limited in their complexity, which is swell.

More opinions are welcome; no point me making a wiki entry about this unless it's going to get the go-ahead.


Edit:




LOL!

There's something that we're not picturing the same way. I'm not sure what it is though, or what version others see.

I wrote a template script for someone a week or 2 ago. It's a crafting template. Click item X in your inventory, and have the option to read the "blueprint" for the object you want to make (find out what pieces you need) or actually create the item in the blueprint (remove the required pieces, add the completed whatsit). The script is 80% comments to guide someone new to scripting. It's a good template for his project and had I bothered to look up actual item names instead of put in placeholder text it'd be functional, but it's completely useless as anything but a template. That's the sort of thing I'm thinking of when I say templates.

I've been seeing 2 basic goals: a unification project to to allow other mods to play together better, and a resource for the types of scripts/items that modders tend to do over and over again... so they can spend more time building their house and less time worrying about how to sort alchemy or more time giving their companion a personality and less time on how to get into his inventory.

There are other types of resources; I released a resource of my book meshes with template textures so others wouldn't have to go through the same process I'd already done, but I wouldn't think that'd fit. Like my crafting script template, it's completely useless until a modder does something further with it.

This is just my take on the project. Like I said, I don't know what other takes people have. I do think people will contribute to a script resource project, whatever name it falls under. It'd be very useful.

QUOTE(phoenixamon @ Dec 23 2006, 01:59 PM)

I wrote a template script for someone a week or 2 ago. It's a crafting template. Click item X in your inventory, and have the option to read the "blueprint" for the object you want to make (find out what pieces you need) or actually create the item in the blueprint (remove the required pieces, add the completed whatsit). The script is 80% comments to guide someone new to scripting. It's a good template for his project and had I bothered to look up actual item names instead of put in placeholder text it'd be functional, but it's completely useless as anything but a template. That's the sort of thing I'm thinking of when I say templates.

There are other types of resources; I released a resource of my book meshes with template textures so others wouldn't have to go through the same process I'd already done, but I wouldn't think that'd fit. Like my crafting script template, it's completely useless until a modder does something further with it.

Ok. All I mean is the same as the above, but with the placeholder refs being actual base refs in COB. Hence the scripts would be potentially useful even if you didn't modify them.

QUOTE(phoenixamon @ Dec 23 2006, 01:59 PM)

I've been seeing 2 basic goals: a unification project to to allow other mods to play together better, and a resource for the types of scripts/items that modders tend to do over and over again...

I agree with your vision. Are you saying that in relation to COB though? Or are you implying that COB does not aim to achieve both of those goals though? IMO COB is the intersection of those goals; it would/will be a common record resource, which will by its master-based nature enable those mods that use it to more smoothly run in parallel.

I'm not fussed whether or not template scripts will get put into COB or be available alongside it; either way, I'll be pushing forward the idea of templates, if only to reduce the fairly overwhelming number of script-related posts in the forums. If they're not bundled with COB, I'll bundle them with Si!K so they'll be available as templates OOTB.

I meant to say those 2 ideas are what I see COB trying to create, both the unification and the base for common features. So I think we're agreed.

I also imagine that everything submitted as part of COB is intended for reuse or modification... that if I submit this set of alchemy scripts, I'm implicitly giving permission for anyone to use that or base their own code off of it. I'm mentioning this because I don't know if it's been said or if I'm making it up out of my own rosey "free stuff is good" outlook, and it'd be good to know.

Whatever distro is chosen (and I hope they'll go up on the CS Wiki as well), the templates are important. Don't kid yourself that they'll cut down on questions. They'll just allow shorter answers, like "Click Me". Do you have a list in progress of the template types that should be included?

sorry for the delayed response phoenix, I fell asleep. d'oh.

lol, you're probably right about the forum post volume

I figure there are 4 options for the categorisation of script templates.

(1) Wiki Function breakdown . This would be the least favored option for me... the categories don't seem like the most obvious ones to have.

(2) Block type categorisation - so eg. all 'begin onAdd....end' scripts would be lumped together, and all 'begin gameMode' scripts would go together. I kind of dislike this choice since it doesn't permit scripts with more than one block in them. At the same time though, it is not clumsy as (1) is: it would create a nice and clear filter for new template scripts added by the community. Option (4) on the other hand might not promote the same clarity of choice.

(3) Identical to COB - so every sub-ESM in COB, assuming there'll be one for each type of 'library' (I know this is still under discussion) has an associated script group.

(4) Spontaneous categorisation - ie. I or someone else just decide a decent set of script categories, and stick with them.

If script templates aren't included with COB, I'll be going for (2) or (4) when packaging templates with Si!K . If script templates are included with COB, then I'd go for (3) assuming ESM segregation occurs, and if not then (2) or (4) are the only real alternatives.

Skimming 'cause I got a bunch of stuff to do today. Check the beginning of the wiki discussion. What exactly goes into cob is still up in the air, but I differentiate between "really needs to be unique" (e.g., a companion faction). The former would definitely go in; the latter might go in.

More comments later when I have time.

What Goes In: See UESP: Common Oblivion: Overview. Note that there are basically three categories:
1) Stuff that strongly needs to be unique in order to be useful. E.g., a companion faction.
2) Stuff that really should be standardized in order to work right (e.g., lore ingredients).
3) Stuff that that don't need to be unique, but are convenient to have as a resource.

The are in order of most desirable/likely to be in Cob. Note in particular, items in category three "should be very, very likely to be useful, not just might be useful." I'm assuming here that the items are defined are complete, finished items that are immediately usable as is -- so no templates.

Nothing wrong with templates, sounds like a good idea, but it's just outside the scope of cob. Perhaps that will change in the future, but for now, I'd like to be a little conservative about what goes into it. Secondary consideration: if the templates are very closely associated with Silk, then it makes more sense to me to distribute them with silk.

But perhaps, I'm misunderstanding something about what you mean. If so, give me a specific example of how a template would need to be in cob.

Number of esps/esm: Right now, just one or (maybe) two: Cob Main.esm and (maybe) Cob Resources.esm. I definitely want to stay away from large number of esps/esms. I suspect that modders in the Oblivion world are underestimating the max mod slots problem -- 255 slots will start seeming very limited in another six months -- especially if major mods keep using up 5-10 slots each.

License: I'll think about it. Whatever it is, it will be open. If you put any resources into Cob, expect them to be open to modification by other users.

I don't really understand that distinction, since as discussed above, templates WOULD be immediatley usable, although the likelihood is that they'd be used as a base to build from, just as COB records will be used as a partial base for a mod.



There's no need for them to be in. Equally there's no need for ANYTHING to be in COB, lol! I'm not being facetious (at least not intentionally ), I just fail to see what you're getting at. There's absolutely no necessity for scripts to be in with COB, no. But everything going into COB is a matter of choice, so it depends whether you choose to include script templates or not




That's fine, I just wanted to ascertain things one way or the other. The main reason I would have liked a script template repo to be included with COB is that users who don't want to use Si!K or don't need to don't have to dl it just to access the script templates; they could get them alongside COB.



I agree totally with your conservative approach there... it's worrying how quickly those slots get filled, isn't it :S

What I'm about to say may be bullcr@p because I'm very sleepy, but isn't it true that once automated splitting is available, a useful accompanying tool could be written to take a group of plugins and their associated masters, then merge all the masters into a single master, modifying the plugins as necessary? It's possible FormIDs would need to be changed, but as long as the change is reflected in both the master and the plugin file, that wouldn't be a problem... If I'm not talking out of my bumhole, then I'll add this to Gecko with dev_akm's help, once we've got the first release out.

What I understand the concept of COB to be is a collection of resources that can be used as is by a variety of mod to allow compatibility, sharing and exchange of certain things between the mods dependent on it. Things like AI packages, factions, tilesets (if ever made), books, ingredients and other items can be used directly out of COB by the dependent esps without changes. They can just be referenced directly from COB by the esp like it would Oblivion.esm

For the scripts to be useful they would have to be modified to fit the purpose of the dependent esp, hence changing it or duplicating it for your purpose. This would then remove the need for it to even be in COB at all as it should be in the dependent esp. Though a template library somewhere, such as with S!LK or the wiki, of useful scripts like those for companions, armour set bonuses, ingredient sorters, nested message boxes etc.. would be very useful, COB isn't the place for it . In fact if there's one thing that is likely never to make it into COB it would be a script (though in the future there may be some rare case, the exception to prove the rule!).

Hope that makes some sense (I'm tired too!)


EDIT: that exception for scripts could be something like, though I'm sure there are others, a resource added by COB that has a script attached to it (for example something like PA's wonderful ingredient shelves), but in that case, there should be no need to modify the script.

QUOTE(Elessar_VPR @ Dec 24 2006, 02:59 AM)

For the scripts to be useful they would have to be modified to fit the purpose of the dependent esp, hence changing it or duplicating it for your purpose. This would then remove the need for it to even be in COB at all as it should be in the dependent esp. Though a template library somewhere, such as with S!LK or the wiki, of useful scripts like those for companions, armour set bonuses, ingredient sorters, nested message boxes etc.. would be very useful, COB isn't the place for it . In fact if there's one thing that is likely never to make it into COB it would be a script (though in the future there may be some rare case, the exception to prove the rule!).

That's a terrific explanation mate I guess I'm reluctant to disregard the idea of adding scripts because it's possible you WOULD want to modify COB components, even though you don't have to. I think the key point I was missing prior to reading your post was the fact that the very objective is to make modification as unnecessary as possible.

Thanks for that I'll keep templates tied up with Si!K then, when I've coded support in.

Thanks. I'm not sure whether the shelves will be included or not. They're available if they're wanted, and I'll leave that choice to others. For the script, I'm going to make at least 2 changes.

One will be to make it more flexible. It'll have a trigger script and then separate scripts to do the work. The trigger script will work as-is if it's placed on the storage container. It'll need modification (at least persistent references) if it's called by a separate object. (For instance if the modder wanted a pet imp to put away your ingredients, the imp would run the trigger script and he'd need a persistent ref to the container.)

The other thing is to add the ability to sort by the potion effect you want to make. That'll be a separate script that can be called by the same trigger or another or left out.

Once I have this working, I can share it and look for feedback and suggestions. First thing is just getting all the words typed out.

Yes, that would work from a technical standpoint, but there are practical reasons why it would be problematic. First, you wouldn't want to do it with any mods that you had already used for a while as standalone plugins since changed FormIDs for things would make it incompatible with your savegame. The same would also be true for updates -- you would only want to do so with mods that are in a final/stable state -- i.e., no longer being updated. This is because if you had to remerge them again later, then such an update might not be compatible with your existing savegame due to changed FormIDs for things.

Unfortunately, I doubt this would be a very attractive feature for reasons like this.

However, I really don't think the max mod count will be an issue for the vast majority of players, regardless of any proliferation in large mods. Typically, the players who run anywhere close to that many mods will be pretty savvy to begin with and thus likely to be competent enough to use SR's merge tools selectively where appropriate.

Windowlights is a perfect example of a great COB script IMHO. I think this would be very widely used by house mods and it doesn't require any changes to fit the plugin using it. In fact, any very widely attractive script that only affects the parent object it is attached to would be a good potential candidate for inclusion in COB.

A universal ingredient sorter that doesn't require OBSE would be another ideal COB script, since COB could also include ingredients. However, this script would require a lot of maintenance to keep up with all the ingredients and target containers.

This sounds like a really good idea! The only thing I worry about with the vanilla version is whether the containers targeted by the script need to be identified by reference EditorID or if some other method is possible -- to avoid having to change it everytime it is used in a mod.

I'm beginning to wonder, since we can make esps depend on other esps, if you're making a mod that you know can't be a "clean" esm, what's the value of splitting it over releasing only esp?

The detriment is using up more mod slots. The only value I see at the moment is saving a few minutes another modder who wants to interact with your mod. Yourself, any time you'd save on editing the dependencies you'd use on the splitting process. But if I want my mod to be able to interact with a mod that's been split, I may still have to spend that time anyway because I want to use the part that's in the esp.

Fran's for example is already a massive beast with multiple ESM and ESP files, and at least one of the ESMs (I think more) modifies vanilla content or content from another of its ESMs. Would it be more valuable to split Fran's ESM files into esm/esp pairs so it uses even more slots or to just make it an esp and edit the dependencies of the other esps?

What I want to know is, is there a value to splitting beyond potentially saving other modders a couple minutes if they want to make a mod dependent on yours?


GetSelf. If the storage container is the trigger object, the trigger script won't need to be changed for reuse. If another object is used to call the sorter, though, the trigger script will need to be duplicated and the reference added in place of GetSelf. I'll just add comments for what to change and what's optional. Hope everybody knows I don't fancy myself a scripter much at all, and that if I do this the stupid way, it's Wrye's fault for giving me the task.

I think the scripting templates would be a very useful common repository for mod-makers regardless of whether they use silk or not. But it's not something mod users would be interested in. For this reason it would most likely not be appropriate in the cob "core" distro, but maybe appropriate for a separate distro under the cob "banner".

Good point. In most cases, the ESM format is not appropriate for distribution because it creates more issues than it solves (given what we now know about mod de-isolation). But there are caveats to this.

First, there's really two separate issues here. One relates to distribution and usage (the mod count issue) and the other relates to mod-making.

So, you shouldn't think of it in terms of "what's the value of splitting it over releasing only esp?". Unless we discover some limits to mod de-isolation (ESPs that are made to act like masters), there's really no benefit to using ESMs at all unless you're working in the CS -- at least for most mods.

I think clean ESM/ESP splitting is mainly attractive to mod-makers rather than mod-users. However, for very large mods that want to become a platform for further add-ons, options, etc., it is probably advantageous to distribute in a split format purely because it lowers the bar for people who want to make add-ons.

Once our splitting tool is released, the value of actually distributing in a split format will decrease significantly because then it really will only be a matter of a few minutes to make your own split version for use in the CS. Right now this just isn't the case. Using current tools to switch an ESP into an ESM for the purpose of making an add-on or a bit of "glue" is not at all simple --- it's not just a "few minutes" work -- unless the mod you're adding onto is extremely simple, you're not trying to work with more than one at a time, etc.



Ah, so this sorter would use a single storage container?

I need to take time to process your response to my ESM/ESP issue, so for now I'll just reply about the sorter.

At the moment I'm working on the sorter using a single container for storage and proxy/token objects for sorting. Once I get this base working (lots of words in it!) I'm going to try to add options for multiple containers by name and multiple containers by effect. I think I know how, but until I try to do I can't be sure.

As far as I know (as Daleth's Ingredient Storage Shelves mod is released and available; I've followed it, just haven't had the chance to play it yet), it always has-- I know that I am not the only one who, as far back as Morrowind, loved the idea of ingredient sorters in principle, but in practice found the idea of having to remove ingredients from the individual separate containers that they had been sorted into extremely tedious.

As I understood it (and obviously, if I'm wrong, phoenixamon can correct me, but I don't think I am), the visual impression of several jars is only cosmetic; the container itself is a single object, The main thrust of the scripting seems to be to add the ability to collect all your ingredients and move them to the container without opening the inventory--- hey!!! Didn't I just dream of doing something similar to that to equip companions without opening their inventory?

I'll have to look at how you did it, but thanks, phoenixamon (and dev_akm)-- even though there are other mods that have similar function, it never occurred to me that you were utilizing the basic sort of functionality that I've been looking for (I'm going to have to make companion mods at some point, aren't I? Meh.), and I probably wouldn't have ever thought about whether it was adaptable to my "needs", if we hadn't been having this conversation (and the 'hook', a dedicated faction for a group of actors, hadn't been proposed).

Thanks, all!

Yep, the jars on my shelves are just there for looks, so they're not separate clickable meshes. I always liked the way the Morrowind sorters looked, but I didn't like having to click all the jars separately to take things out.

I wonder how the same sort of thing can be done with companions. I can see scripting a companion to take everything that belongs to their faction, but I don't know how to set the ownership to that faction in a non-fussy way.

I've been thinking about that a bit (which is tough since my entire experience with modding consists of a bit of editing, a bit of merging, and 1.5 house mods), and I thought I would investigate the mechanism by which Open Cities batch-operates on all NPCs and moves them out of CityWorld into Tamriel, which seems like it might be useful to at least give me an idea for a methodology to perform batch operations of this sort on a large group of whatevers (in this case Actors, but if it can be done on Actors, it must be doable for Objects one way or another).

Then I thought.... heck, if that turns out to be possible, then the existing companions wouldn't even necessarily have to be updated themselves to work with Companion faction operations (although clearly that would be preferable in the end); in the interim, since it is a knowable quantity to know who all the currently-existing companions are, they could be "handled" by a similar script to the one for OpenCities, which would search for all of these known quantities on load, and if found, set them to the Companion faction. Which is the first hurdle overcome at least, not that there aren't more to follow.

But I almost feel like there's sufficient foundation which hangs together just well enough to justify attempting a Proof-of-Concept mod displaying

1. the ability to transfer previously-existing companions to the Companion faction
2. the functionality of a new companion within the Companion faction using standard AI packages
3. the ability to designate saleable objects as owned by the faction
4. Give such bought objects to members of the faction without opening the companion's inventory

at the very least.

Mind you, I don't necessarily know how to do all of this atm, but the fact that what I do know encourages me to look deeper into the existing resources and see if I can massage them into complicity with my nefarious plans suggests that it might very well be doable.

Of course, its the holidays, and I'm in the middle of another project as well, but this whole concept is setting me on fire (as you might have noticed)-- and that's got a good chance of being some kind of sign as well.

I'd like to start banging away at something next week (when things calm down a bit) and see how far I get, but I'm wondering if I should start a WIP thread of some sort on the "main" forums (you know, the one where the people actually are ) to see if I should get some input from the modders whose work would be influenced by it, or wait until I see how far I get before getting their hopes (or their ire) up. Plus of course, I'm not sure if CoB, or any aspect of it, is prepared to go 'public' just yet, so that's also a concern.

What do you guys think?

Very cool.

We're outgrowing this thread so I've started a few new topics:
* COBL Main
* COBL Alchemical Sorter
* COBL Companions
* COBL Lore Items

Note that I've changed the name from COB to COBL. (Cause you can search for four letters more easily and reliably than three.) (Think of it as "cobbleing" stuff together!)

Motub, please have at the companions topic. I'm sorry abou UESP being down (I knew it was a slight risk when I went there -- the site's been having some server problems recently, Dave Humphrey is the only one with access and he's kind of unavailable over the holidays, but maybe the cron server restart job will fix the problem). Anyway, I would suggest being a bit more concise -- I though that you made good points -- but you made them several times! I have no expertise in companions, so I'll pretty much just watch, throw in a few comments, and look to see if there's consensus. Remember, whatever goes into Cobl needs to be very stable. However, I expect that I'll include a cobCompanionFaction with the initial release -- hard to see how that could go wrong.

KomodoDave: If you'd like to discuss templates some more, please start a new topic "COBL Script Templates" (either this forum or mods forum, your choice). I think the answer is "no", but in truth I still don't know exactly what you mean by "template". By definition a template is NOT immediately usable, but you say it is. So obviously we're miscconnecting j somehow. If you want to go further, please post a example (code in a BB CODE block) plus a description of how specifically that example code template would be used.

Awesome! Which thread should we use for faction discussions?

I've added new topics for factions and leveled lists. Links to these and any new COBL discussion pages will be listed on the first post of the main COBL page.

Just in case anyone's interested, here's a technical breakdown of the ESP/ESM splitting logic that KomodoDave and I are working on in the Gecko project.

1) A record is considered Local New content or Remote Change content depending on whether its modindex matches a MAST record in the TES4 header or not. Remote Change Records are those whose modindex matches an existing MASTer. Local New Records are those whose modindex does not match an existing MASTer.

2) GMST records ignore Rule #1 and should always be considered Change Records regardless of modindex (the EDID is all that matters in this case).

3) Remote Change Records must always go in an ESP.

4) Local New Records should go in an ESM, unless they are children of a Hierarchical Top Group whose parent is not local. See UESP Top Groups and Hierarchical Top Groups for details on this structure. Types for which this exception may be true are: DIAL, CELL, WRLD.

5) Records within Hierarchical Top Group structures are only valid when the entire parent structure is represented. The parent structure is block proximity/order-dependent and includes some nodes which are actually elder siblings rather than direct parents (they are related by block proximity/order and FormID rather than node hierarchy). These special cases are:

* DIAL
* Group: Topic Children

* CELL (interior)
* Group: Cell Children

* WRLD
* Group: World Children

* CELL (exterior)
* Group: Cell Children


In each of these instances, the first block (e.g., DIAL, CELL, WRLD) may exist alone in some rare instances, but child groups are only valid if they follow a previous matching parent block ( i.e., one with a matching FormID). So, for example, you might see a WRLD record on its own without a following child group, but you should never see a world children group on its own (i.e., without a previous matching WRLD record). This means the only way to do anything with the children is to bring the parents along for the ride.

6) Direct bidirectional teleport links (XTELs) are not allowed from one master to another. This is due to the fact that one end of the link will create a change in the remote master (i.e ., altering or adding an XTEL subrecord to a REFR within a remote structure). In these cases, the XTEL must be removed from the local master output and then included as a change in the plugin output.

Hmm... What if a non-master script refers to a reference placed in a master owned cell? The script gets moved to the new esm, but the reference it refers to does not, which would cause problem if you tried to recompile that script. You'd have the same problem with dialog scripts and maybe some other dialog tests if such tests can refer to references.

I (potentially) finished the code a couple of hours ago; Aubrey's testing it now. I split the latest OOO ESP and it looks fine structurally from the brief look I had, and also loads warning-free in CS. If you know that a) at least one instance of what you're describing exists in OOO, and b.) that the flaw you describe would initiate a warning dialog in CS, then the code already accounts for what you're suggesting. If one or neither of those is true, then dev_akm will no doubt let me know and I'll code in the appropriate logic.

I can't tell you for certain whether or not it's accounted for, because I haven't taken the time to look too closely at the relation axioms holding for ESP/Ms; I've relied on dev_akm's seemingly flawless knowledge of such things instead, and let him look at the big picture while I focused on implementing one chunk of logic at a time.

Edit: Why do the godd@mn forums force a 'b_)' minus the underscore to be a capitalised b and thus a shades emoticon, hmm? Tell me what could have possessed the creators, Wrye

How are you going to recompile a script that's in the ESM? If you want to recompile it, you have to do so in the ESP, which of course works just fine. Otherwise it stays quite nicely compiled in the ESM and everything works great.

Yes, it creates a codependency between the ESP and the ESM, but the only alternative would be to remove such scripts from the ESM, which seems less than ideal. New AI packages also have this issue if they reference objects you've added to 00 cells.

Do you think it would be better to keep everything that has references to new objects in vanilla cells from going into the ESM?

In the case of doors it's relatively easy to alter the base object to remove the XTEL (essentially leaving a neutered version of that REFR in the ESM), but I'm not sure it would be possible or even desirable to do the same with scripts or AI packages.

EDIT: Forgot to mention that scripts like this work fine and give no errors in the CS as long as you load the ESP along with the ESM. If you load the ESM by itself you will get some warnings, but they can safely be ignored.

The spirit of Sheogorad. Or perhaps it's an injoke from Bethesda presentation guidelines. "Point b must always be cool." (Yes, I've been caught by that one before.)


That resolves it.

BTW, KomodoDave has also added a sweet comparison tool that lets you easily see the differences between two mods. Although primarily designed to help us verify the results of the splitter against our reference set, it will also be very useful for lots of other things (like comparing an updated mod against the original to see what has changed, etc.). It uses SR's TES4Plugin navigation tree to let you browse the record structure of two mods at the same time with color highlighting for records that are different.

Comparison tool -- nice! May need to use that on COBL...

And drifting even further OT, I've just posted a brief intro to programming to Wrye Bash Programming. The nice thing about Bash is -- if you understand it (big iff) -- you can very quickly whip up little function for batch modding. E.g., I had a little program there that quickly copied all Oblivion sigil stones from oblivion.esm to my rational names mod. (Then used bash to export names, batch edited them in a text file and reimported them.)

Carrying on the tradition of being off-topic, in case some people are following this thread who are not following the individual COBL WIP threads, I've posted a demo of the vanilla alchemy sorter over here. So far as I know, only one person has tried it, he found it at leat slightly confusing, and that' just not enough for me to be comfortable. I'd really appreciate if others would give me their impression on the function... whether it makes sense.

Whether COBL was ready to go "prime time" on the Modding Forum, I do not know. I can say with certainty that I was not.

Here's some very disturbing info about landscape files.

Looks like this will require yet another automated tool if the poster is correct.

Has anyone else had a chance to look into this yet?

A bump for this because I had to come here and read some info once again..I loved this discussion on esp vs esm it helped me with my handmade esm / esp mod..

Maybe this should be pinned somewhere..

so that it does not get lost and people can use for later reference..

along with this mulit-mod land lod what is says thread also..

Corepc

Bump -

So If you read through this thread it is very helpful has been ..Page 2 to be exact..is when this thread kicked off

Using some of the tools that have come out of this thread tes4gecko and theory's some great things have been done in mods..

the use of esm vs esp or combination of two is explained heavily in threads here and ones linked to this thread..

Corepc

Thanks for the bump CorePC, and yeah this probably ought to be archived somewhere. Maybe trim it down and archive at UESP or CS Wiki. Now... Onto cool new stuff...

I'm in the process of upgrading Wrye Bash's List Merger in a more general patching feature called "Bashed Patches". First a little background...

Basic Modding Approaches
1) Independent Mods: You have mods. Modders create mods, then give them to players, who then add them to their load list, and voila! modded game.
2) Mod Cooperation: Mods are made specifically to work together. At this point, end user configuration consists of choosing which mods to load. E.g., basic mod + patch A + patch D.
3) Programmer gives end user a tool which allows him to directly modify existing mods. I think I'm the only one who has done this in the ES world. Mash had a Replacers feature which allowed you to "NOMify" another mod (replace static ovens with NOM type ovens, etc.) Bash has several such features: import names, import npc levels, etc.
4) Programmer gives end user a tool which allows them to compile a custom mod. Leveled list merging tools do this. More advanced examples were TesTool's object and dialog merging features.

Bashed Patch
Most of Bash's special features are type 3. What I'm doing now is expanding Bash's category 4 feature (list merging) into a general patching facility. I.e., Bashed Lists >> Bashed Patch. The idea of this facility is to provide something somewhat like TesTool's object merging feature, but much more controlled (and somewhat more limited). As with Bashed lists, you can have multiple patches, and you'll update the patch by right clicking on it and choosing a menu command. The menu command will present you a preferences dialog, in which you can turn off various components (e.g., a leveled lists merger, a TNR faces merger, etc.) and configure them as needed. You'll be able to have multiple patch files -- there are a couple ways to use this, but I think that most people will have one patch file per used loadset. (E.g., if you've got one PC for which you used mods A, B and C, you'll have one patch mod for that. Then for another PC that uses mods B, D and F, you'll have a different patch mod for that set of mods.)

Right now, foundation coding is done, and I've mostly ported the existing list merging to work with the new approach, plus added a TNR face patcher. (The previous TNR importing facility was a type 3 importer, this is a type 4 merger.) I'll have the conversion finished soon, at which point I'll remove the Bashed Lists feature and replace it with this.

Completed Components:
* Merged leveled lists
* COBL alchemical catalogs: Update COBL's alchemical catalogs to include ingredients from all loaded mods.)
* TNR face merger: Include all TNR faces, merging them on top of changes to those same npcs made by other mods.

Possible Components:
* Name patchers: Modify names of objects to preferred name. E.g. patch in my Rational Names, or (more popularly) translated names for other languages.
* Racial eyes/hair: Merge changes from an eyes/hair mod on top of other changes to a race from another mod.
* Merge in "Better models" (e.g., Kafeid's Better Rings and Amulets).
* Merge in Magic effect visual/etc. effect changes.
* Robes with pants, More than two rings at once.
* Configure GMST settings: Compass, chameleon effect, etc. Rather than use up a mod slot for a mod that changes a single GMST, instead just set it in Bashed Patch.
* Mod specific components (e.g., pick your spawn rate, turn on/off certain
features)

More Background
There are a lot of advantages of a type 4 patch over a type 3 importer/modifier. A good comparison type 3 TNR face importer (current Bash) vs. a type 4 TNR face importer (new Bash):
* For importer, you need to import to every mod that modifies the npcs (which for my moderately modded setup is four mods). Moreover, you don't know apriori which mods need the faces imported, so you'll probably have to guess (and maybe miss some, or import into some which don't need it). Vs. Patcher, which only has to be built once, and doesn't require you to know apriori which other mods modify faces.
* Importer modifies the original mod. This causes support problems for the creator of the original mod (since you're no longer quite running his mod). Moreover, you can't mod it differently for different PCs. E.g., suppose that for one PC you want giants taken out of the spawn list. If you imported the changes, then you'd be stuck with them, but if you do them in the patch mod, then different PCs can use different patch mods.
* Also, if you want to upgrade the original mod to a new release, you'll need to remember and redo all the imports you previously did. Vs. using a patcher, you don't need to redo at all (patch should still work), plus it's easy to rebuild the patch (two clicks and you're done).
* Importing is hard to reverse. E.g., if you import faces, you have to re-import to get back to original faces. This may not always be possible. But with patcher, this isn't an issue -- just discard or rebuild it with a different configuration.
* Sequence of importing changes has no memory (e.g., import names, then import faces, then import levels, etc.). Vs. patcher, which will maintain memory of the way it was built last time.
* Importer doesn't remove mods from your mods list. But with patcher you can. E.g. for the TNR face patcher, the changes from the source mod(s) are automatically aggregated in the patch mod. So you clean up your load list, and perhaps more importantly, free up some mods slots.

Limitations
* Patch mod can't contain any new object definitions -- only patched versions of older object definitions.
* User has to install and use the program (Wrye Bash) that builds the patch. While there's a fair amount of whining that goes on over installing python + wxPython the first time, it's actually not that hard, and you only have to do it once. Moreover, I think that once the cost of not doing it becomes too high (lots of problems where the only or best solution is Wrye Bash), people will endure the cost of doing it. This fits my experience with Mash -- I kept throwing in new features and each new major feature (list merging, replacers, map fixing) pushed more people over the install fence.
* Once you start hitting the very late adopters, you get people who want very simple stuff. (The "Oblivion for Dummies" folks.) There's no way around it -- building a patch mod is inherently more complicated then clicking buttons in the launcher's mod listing. OTOH, there are some things that can be done, and besides mods like FranOOOMMM are already complicated to install (mods in order like so, then pick these patchers, etc.), so a Bash patch component that configured that stuff might actually be a bit simpler.

I've been talking privately with dev_akm about about a patcher component that would replace combat behavior for NPCs with improved combat behavior definitions. (Note that combat behaviors are separate objects from NPCs in the mod file -- the npc record just links to the combat behavior assigned to it.) Since Patcher feature is public now, here's my reponse to his latest question...

I don't think that I've talked about replacers directly before -- I guess that I'd say that that sort of thing is somewhat implicit in having Bash be opened up and have fairly general record type access. Essentially, once you start thinking "What I want to do is take an existing file and munch it in way XXX." then if way XXX can be stated programmatically, you can probably do it with Bash (so long as it doesn't involve dialog or cells, which aren't handled yet).

Partial list of things you can do:
* Merge specific changes to specific formids. E.g., TNR face merging: "For the specific npcs that are modified by TNR mods, extract that face data and apply it over the changes made by any other mod to those specific npcs." A lot of other stuff falls in this same category. E.g., object name translations (and/or rational names), race eyes/hair.
* Replace contents of fields for a certain type. E.g., replace combat behavior of any npc, mapping combat behavior XXX with new behavior YYY. Or you could go into their inventory and replace a certain object with a different one. Replace one faction id with another. Etc.
* Add stuff to variable lists. E.g. add items to inventory or spell lists. Add factions to lists. E.g. on one of the topics back in January I talked about the possibility of adding clothing switching tokens to npcs. This might be useful for that.
* Set specific flags. E.g., for wearing pants with robes, set the flag that governs what part of the body it covers.
* For programmatic changes/additions, you can make the change/addition be dependent on other fields. E.g. a member of necromancer faction of rank z gets a specific leveled list item. E.g., for robes with pants, you need to figure out if it's a robe -- the way to test that seems to be look for "robe" in the model path.
* Make the patch be dependent on the actual mods that are loaded. E.g., rather than have people pick the FranOOOMMM relevellers to use, have something that scans the list of loaded mods and simply adds FranOOOMMM modifiers as necessary.
* Configure a specific mega-mod. E.g., have an OOO patcher which allows you to just just specify the configuration you want and thereby makes the additions as needed. The major limitation here is that a patcher built in to Bash not add any new objects, but only make changes to objects added by other mods.
* Instead of placing/replacing a specific item, you can choose something from a random collection of items. E.g. for the combat replacer, you could replace behavior XXX, with (randomly) one of the behaviors YYY, ZZZ, AAA.

Man, you continue to amaze me. This is earth-shatteringly HUGE!

All of these features create amazing possibilities for players and mod-makers alike.

You did manage to answer my earlier question -- I had forgotten that your Mash replacer was fairly specific to NOM.

One thing I'm curious about -- actually several things all related to the no-new-items restriction (which makes perfect sense, BTW):

1) How will the player be able to determine which source plugins are no longer needed after making a patch?

2) Have you thought about providing an automated way to backup and deactivate the unneeded plugins after creating a patch? Or, alternately, let the player use a "Patches" directory to hold these so they don't need to be active in the first place?

3) Did you have some other mechanism in mind to help the player keep track of patch source files?

4) Will this mechanism have trouble with mods that use "master record insertion"? I'd probably better explain this. Some mods, like Martigen's Monster Mod, use an ESM/ESP pair but rely on the ESP to actually add new records into the master modindex (i.e., records with the same modindex as the master but which do not actually exist in the master). Or will it only work with mods that are either all in an ESP or are cleanly split with TES4Gecko?

I hope that last question makes sense.

Great stuff, man.

Might be worth some effort to see if your Bash Patch could automatically create a bit of "glue" to overcome the multi-mod landscape bug (like ImperialDragon's patch ESP linked in that post).

Actually, Mash Replacer function is generic (specific replacers are defined by text files), but I'm the only one who made any. (Aside from NOM I did a small MCA one for LCV Wolverine Hall, but that required adding placeholders statics to the locations where MCA NPCs could go.) If you were doing this sort of thing with Oblivion, you'd probably do it differently -- define the spawn type in COBL, make the mod dependent on COBL and then let other mods fill in what goes into that spawn point.

Questions 1-3:
Those have been in the back of my mind. Still need to mull them over a bit. Considerations include:
* Should be easy for modders to create and modify source path mods.
* Data directory shouldn't get too cluttered.
* Patch configuration should be as simple as reasonably possible.
* Should be easy to get a report on patch configuration after the fact. Part of this happens by writing the patch log to the readme for the patch, but a shorter patch description would be good. Probably I'd want to expand the the "Copy Masters" function to make the larger report.)

How this works will probably tie in a little more with where and how patch components work.

Master Insertion:
I thought briefly about this a couple of months ago -- and I'm pretty sure that it's not a problem. Essentially, the esp claims that it's overriding the esm (when in fact it's adding something new). So long as there's no formid collisions, then that should continue to work.

Multi-Mod Landscape:
Problem is handling cells which would probably take me a little while to figure out. Anyway, that would probably be separate from the patcher. I'll keep it in mind.

Bashed Patches is now available. First components cover:
* Merged lists
* COBL Alchemical Catalogs
* TNR face merging.

See [RELZ] Bash.

New Bash options thank Wyre

Awesome, man! The new patcher rocks!

Bump...To keep alive..

I finally got the opportunity to read through this, great stuff guys. Sorry I missed it! Heh.

I suppose my one question, now, is whether there is anyway to do peer-level mod communication, i.e. avoid dependencies. The VE global is a great example - for instance, my Assassination mod would check if a certain global defined in both my mod and Cortex's was set to 1 - if so, I knew the player was running VE, and I could offer the player the opportunity to Embrace an NPC instead of snapping their neck. This was done all with one .esp, there was no VE-specific version. Is there any way to achieve this kind of effect in Oblivion? Or would I have to make a special .esp dependent on VE for VE users, and another .esp without that dependency for non-VE users?

This is of interest to me, as there are a number of features that I've seen others do that I would like to actively call in my mod, if the player has those mods available, but I don't feel like creating versions of my .esp for every possible combination of mods I'd like to use. For example, Omzy recently released his excellent Spell Deflection mod - a feature I've considered for my mod is randomly spawning shields that have this ability on them, but only if the player is using Spell Deflection already - I'd like to simply use functions he already has running in the game, as opposed to copying his stuff over, and I'd like to do it without creating a dependency if possible. This way if he updates his mod, people can update it (or not) independently of my mod, and I would just use whatever functions he's got running, without requiring him to specifically support my mod.

As far as I can tell, this is still impossible in Oblivion, and likely will remain that way. Can I get a confirmation on that? Obviously, there are other ways to achieve the effects I've described, but that's just an example (I haven't even talked to Omzy about it, just something I had been thinking about - my mod has a bit more work on my end before I start integrating others' work), and I think it's an example that illustrates my point well.

Only way for one mod to know about another mod's global is by establishing some sort of dependency between them. Of course, (as discussed here) there are several major ways to establish that dependency. (Which I won't recap because existing descriptions are quite good.) There really are a lot of options -- what's practical and which you use will depend on what you want to do.

There was a fairly long discussion on the FCOM topic regarding duplication of ingredients between MMM and OOO (starting around the bottom of this post). The discussion focussed on things like animal meats and pelts, but applies equally well to geomancy, gem dust and several other ingredients. The primary annoyance of this situation is the resultant plethora of ingredients that have the same name (wolf meat, dog meat, opal dust), but are otherwise different (different effects, different models/icons) -- a situation that is annoying to regular users ("Why is 'wolf meat' different from 'wolf meat'???"), but is even more problematic for alchemists ("I need opal dust, and I've got 10 opals in storage. Grind them up -- whoops wrong kind of opal, wrong effects.") Similar problems exist for books and several other items.

There are several ways to resolve this:
1) Push the common ingredients down into a common shared library esm, and modify existing mods MMM, OOO, etc. to replace all uses of their versions of the ingredients with uses of the common ingredients.

2) Same as #1, but rather than having a library esm, modify one mod to use records from another mod. Main problem here is that one large mod must be made dependent on another large mod. Another major problem arises if there are several mods rather than just two mods, and there are some ingredients/items which are shared between different sets of mods. The main advantages is that you don't have to push items down into a common library mod.

3) Same as #1, but rather than changing the base mod, create a glue patch which has the same effect. This might be done automatically by the end user though Wrye Bash or similar program, or might be released as a patch (which would not require a patch, but which is subject to becoming outdated).

4) Same as #2, but do via glue patch. Same problems and advantages as #2.

In the discussion on the FCOM topic, ElminsterEU favors option 1. Martigen favors option 4. Having experience with both approaches (COBL to serve the purpose of #1, and Bash Patches which could serve the purpose of #3/#4), I agree with Elminster and strongly favor #1.

1) Generally speaking, #1 is the cleanest, most flexible approach. You have a single, common mod defining the ingredients, which any mod can use while remaining independent of the major mods. E.g., if I want to create a hunting park mod, I could use animal meats/pelts out of the common mod to have it work well with any other mod that used such meats/pelts.

2) It minimizes (usually to zero) the need for end users to use additional tools to merge mods.

3) It allows complex uses of common items (e.g., in scripts, etc.). (Since complex uses often require manual tweaking, automatic patching tools would not be suitable for that task.)

4) It allows end users to have a cleaner experience. E.g. a user switching between mod A and mod B (thus never using a patcher to merge them) would nonetheless have a common experience in the common items. (Why should wolf meat change just because you switched from OOO to MMM?) It also allows users to maintain content across such transitions. Instead of losing all their meat, opal dust, book collections, etc. -- those items would continue in their save game despite the switch between major mods.

5) It makes for a simpler modding/playing world. The patch approach means that only a subset of users has the patch built -- which means that different players would have different versions of the mods. (Granted this happens anyway to a fair degree as players activate patch esps to turn on/off bone loot, spiders, etc. -- but it's better avoid such diversity when there's no need for it.)

6) It reduces likelihood of errors due to failing to rebuild an automated patch after upgrading a mod.

7) It avoids full automation costs of building a patcher. (For Bash, I could do replacements on scripts, containers, npc, creatures and leveled lists easily, but not replacements on placed items, dialog and quest stages. Elminster's tool might do more, but Bash has taken a year (and about 80 releases) to reach a moderately high level of success. Another tool would probably take roughly as long to reach same level of moderate acceptance -- end users are pretty resistant to adopting new tools.)

8) It avoids a performance/time cost of the end user running an automated patcher. Bashed Patch currently takes 1-2 minutes on my machine -- but a full patcher that replaced references, dialog, etc. would take much more time and ram (semi-informed guess: x10 factor in both).


So IMO, converting original mods to use a common library is the clearly preferred approach. Under that route, workflow would come down to something like:
1) Push common stuff down into COBL.
2) Run automated tool on OOO, MMM, etc. to do most of the conversion work.
3) Finish conversion by hand editing as needed.
Do that once and you're done.

This is exactly the sort of thing that I created COBL for -- and while Bashed Patches raises some options for alternate approaches, the common library approach is definitely still the best for this sort of thing.

PS: It's been a while since I updated COBL. For curent status, see this post.

Most likely redundant, but for the record I would like to state that I'm in total agreement with everything Wrye said here here.

BTW, for those who haven't seen it: Modding Terminology. In it, I try to de-confuse some terminology used to describe objects and references. This is not just for newbies, but for advanced modders as well, so please check it out.

In particular, I cut the gordian knot in a couple of places by slightly redefining a couple of commonly used terms as well as broadening use of other terms (e.g. "record" and "item"). Aside from that, I cover some issues with object/reference lifetime (esp. for dyanmically created objects) that are not well known (I didn't know them until I did some testing while writing the article).

PS: Forum discussion for this is here. Alternatively (probably better) discussion can take place on talk page for the wiki article.

ah... great... I've so far always missed a clear Terminology guideline. I'll adapt the Terminology given there from now on. Especially I had trouble with what to call esp's/esm's without always saying "plugin or master"... Thanks!

On yet another topic (third info dump tonight)...

Spawn Point Wars and Rotating Populations: I still don't play with tons of mods, but I have been playing with OOO + MMM + FCOM (somewhat dated versions admittedly) and the spawn point wars really annoy the hell out me. Walking into a camp and being greeted by instant warfare, or strolling through a cave looting the corpses is not that much fun -- and not very sensible either. (Yes, there are varying groups, but it should be rare for you to actually wander into the middle of a gang war -- most should have been settled and turf established before you entered the area.)

Aside from that there's Pirate Lord's attempted approach of rotating populations -- something that seems to have fallen by the wayside and should be revisited. (The problem with pirate lord's approach was that it was pretty incompatible and likely to lead to bloating -- it involved spawnpoints placing new spawn points at their location and then disabling themselves.)

So, consider an alternate implementation... Families of triggered spawn points. E.g. suppose that my mega mod wants to have three rotating populations in a cave. Here's how I do it:
1) Have three completely different sets of spawn points. A: Bandits, B: wolves, C: Giant Crabs.
2) Each of the spawn points in a given set is parented to the master ref for that set. That way, by disabling the parent, I disable all of the spawn points in that set. So basically, to rotate, I'll want to disable the two of the masters, and enable the remaining master.
3) From my quick tests, disabling the spawn point will not disable any creatures that have already spawned from it -- I need to make sure that the master is disabled/enabled before the spawn points trigger. So, I place the master refs outside the cave.
4) Now at this point, all I have do is add some additional code which triggers one spawn point or another. But lets get COBLish instead...

Suppose that in COBL I define a "key" reference for each cave. This would be an invisible activator outside the cave whose sole purpose is to hold a reference variable in an otherwise blank script.

Now, I define the master ref for each of the populations so that 1) it's initially disabled, and 2) will not enable unless it can take ownership of the cave's key reference. Rules are: it cannot take ownership if the key reference is already owned -- i.e. if the ref variable of the key != 0. If OTOH, the key variable is free, then the master rolls a random number, tests against a number (random 100 < 10), then it claims the ref variable and enables itself (and thus its population).

Note that by having the random test be relatively low, each of the population master refs would have a chance at claiming ownership.

So when does ownership end? It's up to the population that managed to claim it. E.g., it might automatically free after a month or so, or it might only free after you've gone in and cleared out the population. (Gone down to lowest level and killed baddest bandit or something like that.)

Note too that in populating the cave, you're not limited to spawn points -- you could also include containers, beds, statics, hidden doors and parent them all to the population master ref. (Gotta be careful when you deactivate the master ref though -- you don't want everything disappearing as soon as bad boss is killed.)

Of course, same thing could be done for alternating populations of road bandits, camp residents, etc. E.g., camp residents could trade off between bandits and peaceful travelers.

In a couple of days the engine behind TES4Edit should be at the point where I can easily automate that for you. Look through Oblivion.esm (or any master), find all doors in exterior cells that match specific rules, and add the right REFR record in the right place inside a newly generated plugin. No need to do that all manually.

I need to check on this again, but I have a request if you go through with either plan (1/2 or 3/4): Alchemical Formulas uses the reference to the ingredients. If a new mod is used mid-game then (I think) the reference won't point to the new mod's ingredients. I know that using Bash's rename function worked for .esp->.esm, but I'm not sure if I tested with (for instance) Gecko's .esp->.esm, and if it would work only for .esp->.esm, or if you do something specific in Bash to insure this works. Is there something you can do to rename multiple files to one file... or, err... I think you know what I mean.

[edit] - actually, now that I think about it, you'll probably do this anyway to ensure the player's keep their current stash of ingredients, etc.

That's a general problem here. Because it's not a simple "everything moved from one file to another" there is no way to just change the master list of the save game and go on. If you remove items from the existing mods and instead make them all use new items from a different mod then when loading the savegame all instance of the old items will be gone.

Patching up the save games to redirect all references from the old items to the new items is most likely too complex (I'm not sure how much of the file format Wrye understands so far). It also wouldn't really help with Alchemical Formulas because the formulas are based on the assumption that the effects of ingredients don't change. If you currently have 3 different "Wolf Meat" ingredients in 3 different mods with different effects and all of them get replaced with a single new "Wolf Meat" ingredient in COBL then at best it will have the same effects as one of the 3 others, more likely it will have effects that are different from all 3 (depending on how the effects of the common ingredient are decided upon).

But Wyre already has this working for OOO...

I didn't get that from Wyre's post, though... are the ingredients going to be combined, or will the common names be renamed? For instance, will there be three versions of "Wolf Meat" (say "Pup Meat", "Wolf Meat", and "Tainted Wolf Meat") or are they going to be combined into one?

If you mean the "Rename a Master" function, that's exactly what I said will not work here. It works with OOO (and other mods which have been splitted into esm/esp) because the esm contains all the "new" records with unchanged FormIDs that previously where in the esp. In that case all that's required is to change a single entry in the master list of the save game to a different filename.

What we are talking about here is removing certain FormIDs from the existing mods, adding a new master to these mods, and all references in these mods that went to the now removed records go to the records in that new master.

To patch up a save game in this case would require adding an additional master to the save game and finding all references to the specific FormIDs that have changed and replacing them. If there is something in Wrye Bash that can do that then it's hiding well from me.


The whole point is to get rid of these different ingredients (and other items) that are defined in multiple mods as independant records but with the same name. All these records get removed from the existing mods and instead they reference records from the COBL esm. So yes, they get combined into one (more specifcally, all the existing ones cease to exist and a new one is added instead).

To me it sounds like Wrye's "option 1" is the only realistic solution here and using COBL is the most practical way to implement it...

Technically it doesn't sound like a problem, so the real question here should be: Is everyone working on FCON in agreement with merging the common items with COBL?

I'm still not clear on how the master lists are handled in updating existing saved games... If an automated save game upgrade tool isn't possible, what about auto generating a COBL upgrade script from a conflict report? Something like activating the COBL esm and a generated upgrade esp before upgrading FCON (or other mods), then have the player run around to each of their stashes to run an inventory replacement script on everything they want to keep. After that they could upgrade FCON to a newer COBL dependent version, remove the COBL-upgrade esp, and not lose anything.

After such a merger and upgrade, there wouldn't be multiple versions of anything unless its intentional (e.g. quest/special items).


-Burn

I would be surprised if any of the authors of the FCOM mods were opposed to the concept of COBL... the question is whether or not they can agree on what each of those items does.

It doesn't really matter what the specific effects of the items are that go into COBL. If a particular mod author disagrees he can easily override that record. The big difference is that when multiple mods are used together then you don't end up with multiple items with the same name but different statistics, instead all mods reference the version in COBL and whichever is the last loaded mod (in FCOM that would be MMM) that overrides the record wins.

wrt: COBL Ingredients
I have no invested interest in the topic (I use only Frans), but another option:
5. Leave vanilla Oblivion ingredients alone. Add a new ingredient if you change the effects, and give it a new name. Have a central database of names already given to new ingredients to make sure there aren't any ingredients with the same name.

No matter what the decision is, could you please post the outcome here? It would be much appreciated.

For the stock ingredients, anything modified by any of the FCON mods or TI would need to be included in COBL. Altho some stuff, like price increases or certain item scripts could be placed on items via scripts rather than touching the base item. Thats probably not practical for geomancy due to the number of items involved. MMM crafting might be an issue too but I haven't looked at it in the CS.

At this point I'm just guessing though, I used OOO since its 1.3 release but I'm new to the rest of FCON. So I'm probably missing a lot of stuff not covered in the summaries for the other FCON mods.


-Burn

Key Reference for Caves: Actually, I made a mistake there. You couldn't use a COBL esm ref, because the ref would have to reside in the COBL esm but be modifying an Oblivion cell -- which is a no-no. However, a quest which held ref variables for all the standard caves, forts, etc. would work instead. (It would be a dummy quest which just acted as a ref variable holder.) With that exception, same logic as before.

Replacing Ingredient Bases: Elminster is right (with some possible qualifications). E.g., both OOO and MMM have WolfMeat. COBL adds it's own WolfMeant, then you make OOO and MMM dependent on COBL, and replace all places where they use their own version of WolfMeat with COBL's WolfMeat. Then you delete OOO and MMM definitions of WolfMeat. The effect on the save game would be that all existing pc caches of those items disappear.

Now the qualification: It might be possible to go to an existing savegame and replace all cached versions of both OOO and MMM wolfmeat with COBL wolfmeat -- including record variables pointing pointing to bases. How might this be possible if most of the file structure is barely understood? Irefs. For all uses of non-dynamic (i.e. non-FF) records (e.g., contents of a chest, or record variable in a script), the savegame doesn't refer to the formid directly, but rather has an iref (4 byte integer) which indexes into a simple array of formids. So if the iref is 200, then the actual formid is at index 200 in the formids array. So, what you might be able to do is just go through the formids array and replace the formid for OOO wolfmeat with the formid for COBL wolfmeat, then do the same for MMM wolfmeat.

Now, problems with this:
1) First the approach may completely fail (just not work or cause CTDs). The problem is that the formids array is ordinarily 1:1 (no formid appears more than once in it). This would change that, and I have no idea how the engine would react. Might be fine, might CTD, might result in obscure behavior.

2) Logistically, it would be very difficult. You can only do formid fixup once, and that would have to be a savegame that already depends on the newer version of COBL (with new ingredients) plus the older versions of the mods. This is a pretty particular set of circumstances -- player would have to remember to do it at the right time for all savegames. Whatever else goes on, I think this alone pretty much shoots it down.

3) There might be a problem for ingredients with scripts attached to them. Starting fresh with unscripted items will be safe, but formid swapping could lead to script variables being misinterpreted. For more info, see Overriding Scripts and CTDs.

So, while there might be a way to save existing caches/records, right now it looks inadvisable for multiple reasons.

Megaburn: Hmm... Well, you could create a temporary patch esp which used something like master injection to retain the original ingredients for a while. [Make MMM.esm depdendent on updated cobl, and swap all uses of ingredients to cobl, but don't delete ingredients from cobl yet. Save. Duplicate MMM.esm to MMM OI.esp. Chop it down to just the alchemy elements that you're about to remove. Inject MMM.esm as master. Now you have records of all elements to be removed, but they're owned by MMM.esm. Go to MMM.esm and delete the items. Now if you load game with MMM.esm + MMM OI.esp, you'll still have formids for old MMM ingredients.] So this way, yould temporarily have MMM ingredients and run the in game swapping.

But logistically, that's still too much of a hassle, I think. Losing ingredient caches isn't that big a deal. The main problem would be for Haama.


Well if's meat from a wolf, it's "Wolf Meat", likewise a wolf pelt is going to be a "wolf pelt", likewise a crushed "opal" is "opal dust". Aside from that, there's just too many ingredients once you mix all of these mods together. It's bad enough having separe "snow lion meat" and "lion meat". As a player, I'm thinking "Why do I have 10 different types of opal?" It's ridicuolus. I.e., it's not just a problem with names, it's a problem with having too many types of itmes just because mods have different versions of what should be the same item.

Oh, I thought you were already doing that. Interesting to know, then.

Not so much, it's a moot issue if the ingredients will be given different effects. If you didn't go through the iref modifications, the player would only have to make a new formula, but if the ingredients have different effects then they'll probably prefer to make new formulas anyway. No big deal, I was just trying to mention the problem, as I thought it was already somewhat fixed.

[bump] - some good stuff in here.

What happened to the ingredients ideas? Any decisions, progress?

I had hoped to do an ingredient update for COBL, but I'm not sufficiently motivated, so I'm looking to find someone (or better several people) to take over COBL. For more info/discussion, see [WIPZ] COBL.

need to bump so that it help someone who was asking question about esm vs esp..

If this ever evaporates into oblivion, at least I had a chance to read it and download it today. This is golden information and collaboration that should be archived. Its also a bit sad that I have seen few COB based works to date, kinda like the feeling I get when I hear a train off in the distance or when I realize how old I really am.

Some 'How-to's on using 1 mod for OBSE/non-OBSE, SI/non-SI, Patch v1.1/v1.2, and Some other Mod/Not, figured this would be the best place to put them. They all have the same setup - When you need to tell what the player has installed, call up a Result Script (i.e., SetStage SITester 0); if the Installed variable on that quest script is 1, then the player has installed it; otherwise, it will return 0. I'll give the setup and then the explanation of how it works (sorry, just easier to do it that way). Since this is fairly advanced stuff, I've left out a lot of little steps.


How to tell if the player is using OBSE
First, create a quest (cobOBSETester in this case). Set it to 'Allow Repeated Stages' and uncheck 'Start Game Enabled'. Attach a script with these 3 variables to it

Next create the stage (Stage 0, in this case) and add this Result script

Now, how it works - When Oblivion comes across a function it doesn't recognize, that function acts as a return. If the player doesn't have OBSE installed, the script stops at the second line and cobOBSETester.Installed remains at 0. This is followed by another test to make sure the player has a high enough version (ReqVersion, as set from another script) of OBSE installed, and if they do, sets Installed to 1.

Each time you need to test for OBSE, use this snippet



How to tell if the player is using SI
This one works a little differently. Set up the quest as before, but you only need the 'Installed' variable. Here's the Result script

Each time you need to test for SI, use this snippet

How it works - Whenever a script uses a FormID that isn't loaded, Oblivion will ignore the entire script in-game. So, Installed must be set to 0 by the real script first, then the Test script will set Installed to 1 if the player has SI installed. This has been tested, and I'm sure that Oblivion will use the script once SI has been installed, even if the Test script attempted to run in an earlier save. There might be a better way to go around it - maybe

would be a bit faster, maybe there are other things to test (however, any FormID, whether Quest, Magic Effect, etc. will cause the script to basically 81b8 fail to compile, so I'm not sure what test would be truly different).

Again, Oblivion will ignore the script if it includes a SI EditorID - so keep your SI EditorIDs on a separate script. If it needs to happen at that exact line of the script, you can use either a Persistent Object/Activator with an onActivate block, or a Result script. onActivate blocks have a nesting limit, and only 4-5 can be called from one another. Result scripts don't have a limit (or, at least it's >250), but are non-reference scripts and have a very small characters limit.


How to tell if the player is using the v1.2 Patch
I have not tested this one (I don't have a way to short of re-installing Oblivion), but extrapolating from the OBSE test...

Quest - just the 'Installed' variable. Result script

How it works - As with the OBSE tester, an unknown function acts as a return statement. If the player doesn't have the v1.2 patch installed, the script will stop on the second line and Installed will remain 0. Otherwise, it will be 1.

Each time you need to test for OBSE, use this snippet



How to tell if the player is using a particular Mod(Credit to Opaj for the idea)
This one gets a bit wonky on the timing, and I'm hoping for some suggestions. However, as it gets rid of the need for dependcies and false-Mastering it's worth it. This requires the latest OBSE.

Set up a quest (cobOtherModsTest in this case) with 'Start Game Enabled'. Attach this script to it

Create the text file mentioned above, and put it in the Oblivion directory (not Data, just Oblivion), open it, add the line

How it works - RunBatchScript will run the line from the text file as if it were used in the console. If the mod is installed (and has the quest installed, more on that later) Installed will be set TamrIngTest.Installed, if it isn't it will remain at -10. Also, you won't be able to do as much as with the other tests - you'll probably be limited to whatever you can do in the console (as RunBatchScript is similar to using the console).

Here's where it gets a bit weird - first, you need to make sure the quest variable in the second mod is set to a number other than -10. Hopefully there will be some Init variable that you could use. Second, it would help to have a quest too If there isn't one, you could ask the author to include one.

A better solution would be to use an item from the second mod and grab a non-zero value from it. However, EditorIDs can't be used from the console, so I'm not sure how to make this work. Another possibility would be globals, but I haven't tried them, and I don't think they would be any better.


General notes
This can only be used for scripting purposes. You still can't take an item from another mod/SI into a container in yours directly - you'd have to add the item via script.

Remember that when a script uses a EditorID (including spells, quests) of something that doesn't exist when Oblivion is loaded, the entire script will be ignored. Therefore, keep any SI and other mod EditorIDs in a separate script (persistent Activator or Result script would be good).

Remember that when a script uses a function that isn't recognized by Oblivion, it acts as a return. Make sure all of your OBSE and Patch v1.2 functions occur after the test.

Comments, questions, suggestions? Especially on the last one?

I did something similar in the next version of Spell Renamer. Only I used activators instead of stages, guess that'll work too. And I used different functions/items, these are much better ones.

::edit:: Oh and there are other ways to see if a mod is installed, if they add spells you can try to change (or add) a spell (it should be ignored if the spell doesn't exist), same for creatures and items.

Cool, good to know someone else has tried these. wrt Edit: That sounds much better, but how would you reference them? Would you do the Master-bait switch, or do you mean in the batch script?

Both could work, but since I rather not spam the users Data folder I ust the Master-bait switch

True enough, I was just hoping you had already tried it I think I can try it later today, and if it works I'll put that in the Mod section instead (though behippo said he'd try to include a function for it in OBSE v14 :fingers crossed:).

I can give it a go aswell. I just tried the master-bait switch and it worked

Good enough for me. One last food for thought then - it might be nice to be able to get the mod version as well as whether the mod is installed. (sorry, not at the CS computer now, so this is somewhat speculative) I'm thinking a floating global of the mod name, but I'm not too familiar on how globals update (would a new initial value override the old one?). If that doesn't work, a persistent object with the mod name as the Reference Editor ID could be create and placed in the world (preferably in it's own cell or TestingHall/TestingQuest), and it's scale could be modified (not sure if scale is limited to 2.0 in the CS, or that's just as big as it gets in-game).

Yes good point. It would indeed be nice to be able to get a version of a mod wihtout having it as a dependancy. Only thing is, will you be able to use Persistant references in a RunBatchScript? If not, then the master-bait switch could also be used I guess. Oh and the scale isn't limited to 2.0 in the cs, you can go up to 10 or something (or even higher so that isn't really a problem)

That's right, if it's run as if from the console then you wouldn't be able to use editor IDs. Globals it is, then.

However, another question: I wasn't thinking clearly yesterday and kept thinking the bait-switch method removed the .esm file at the end, but all it does is switch the .esm back to an .esp. The goal is to reference the mod without becoming dependent on it. I tried Gecko but it wanted to delete all the scripts referencing the master. So, is there a program that would allow you to remove the master file without removing the scripts that reference it?

I just load up both esp's (mine and the target esp), then I make a script with a item/spell from the target esp and save. Then next time I load it I get an error that he can't find it but since it in a seperate script I just ignore it. Don't know how it works if you have an esm instead of an esp. Like you said, then it becomes a master. All I can think of is changing that master in Wrye Bash to either the esp itself or another esp. Then just load it in the cs can save again. Behold, no more master. And Wrye Bash should keep all the scripts intact when you change a master. Not sure tho

::edit:: So to be short, I use Wrye Bash to change the master into an esp master (any will do) and then just load it up and save it again.

Sounds pretty easy - if you ignore it, will it automatically try to 'erase' the script on you? That is, does this need to be the last step before release, and does it need to be done again if you enter the CS? I ask because of this thread and one other I remember but can't find.

Scratch this entirely. I forgot to test it after I removed the master. Now the script just terminated cause he can't find the item/spell in that script. Cause all things are converted to formID's. Now that I think of it, I had the same problem the first time I tried something like this with Spell Renamer and Supreme Magicka

::so In theory it works only because the item is in another esp it's formID begins with something else, thus my script doesn't recognize it as the same item as in the script.

::Sorry for the false hope

::edit:: One more thing, there are still ways to see if a person is using a mod that alters items and or creatures. Then you can just check a variety of stats from changed creatures or items. Cause their formID is still from Oblivion, even though another mod alters it, so you can refer to it all you want from your mod. Ofcourse this isn't foolproof but it's something

That's the great thing about brainstorming though You reminded me that mmmpld basically does this with the Keychain mod, and it works. I think the difference is that mmmpld used a base object that was already in Oblivion.esm. However, I believe the object he created was unique (I've looked, but it's been awhile) though, so in theory every mod could have their own object with it's own name.

The only bit, though, is that the modder would have to create the object and place it in their themselves. It'd still be nice if there was a non-OBSE way (or if everyone had OBSE, but ) to determine if a mod is installed, without needing the modder to create an object (though it'd still be necessary for version information) or creating a dependency (though I'm not sure if that matters, as maybe a test can be done without the need for a dependency, but if items from the mod still can't be accessed that limits the usefulness of the test).

That probably covers a good deal of the mods. Good idea!

I used the bug/limitation of GetSpellCount to detect if the player uses Supreme Magicka. Because it adds the spells through addspell they count towards the total spell count with GetSpellCount (it doesn't include spells that are added in the spell tab in the cs). So checking a couple of npc's to see if they have atleast the amount of spells SM adds to them is a pretty foolproof in this case. For L.A.M.E. I simply get the associated creature for magic effect Z009 and check if it's name includes Hunger or not, if it doesn't then L.A.M.E. is being used.

I'm curious to what mmmpld did then, is it still in the new version of KeyChain or should I try looking at the older version?

Oh and I assume you mean that if everybody had OBSE + the new pluggy cause stock OBSE doesn't have a way to determine if an esp is active (atleast not with one command)?

Nice

It's not used, but it's still in the new versions. It's in one of the Testing cells... I can't remember the name of it...
[ok, found them] - TestEnchanted and P1DkeyContainer02
Scripts from other mods were supposed to reference it by adding this script
['nother update] - looked at it in TES4Edit - the object itself was originally in Oblivion.esm, so that won't work either

to their keys. I'm pretty sure it could be modified in the CS afterwards.

I meant using RunBatchScript, but behippo said he'll try to include a function in the next version.

I tried this with a global, on the wild hope that it would work anyway - the script still runs, even when the 'master' mod isn't loaded, but for whatever reason it doesn't get the global value from the mod.

I'll try raising the issue on the Gecko thread, maybe I can convince them to allow a master to be removed even if scripts are using it.

Couldn't get a raise out of the Gecko crowd, but I tried it with some code from Wrye - didn't work. Seems that the SI trick only works because it continues to look at Oblivion.esm for the FormID, whereas when the FormID includes a master mod and that master mod is removed from the list, the dependent mod looks at the next master mod down the list (which is usually itself).

In summary, it looks like OBSE's RunBatchScript is the only way to detect another mod without creating a dependency on that mod. It is also possible to modify an unused object in Oblivion.esm, but eventually those objects will run out and there would be problems deciding who gets what object. [bump]ing for any more ideas.

As I suspected. Awell atleast there is a way.

Has this information been placed on the CS Wiki? This is some VERY good information! Thanks for sharing.

LHammonds

The information was already on the wiki, but I've updated and clarified it a bit. I might add a section describing the technique used by Keychain, however it's not a method that would always work and if heavily used mods would start to overwrite each other.

Oh my, my first post.

This thread is very informative and has plenty of valuable informations. But now I'm at a dead end.
My team and I started as the following: I built an esp and worked on it, then I wanted to convert it to a master because the other team members should be able to use my content. Now when I converted it, the CS crashed as soon as I wanted to save the new esp dependent on the master.
A friend of mine discovered the dialogues being the culprit. He deleted the dialogues off the esm and tried to save and ... it worked!
So my question is ... is it save to delete the dialogues, build the new esps dependent on that slim version of the master and eventually merge those esps with the original master (including the dialogues)?

What program did you use to convert it? Also, have you seen this - Version Control: A Primer

Ah, thank you for the links.
Didn't know the network functions of the CS are still there. Thought Beth wiped them all out.
I will try it out.