Oblivion Mod talk:Cobl/Projects/Policy

OBSEEdit

Under Combat Tokens, dev_akm has brought up the possibility of using OBSE-scripted CombatStyle tokens. I think we need to discuss whether or not to allow OBSE content in a COB file. It's unfortunate that using OBSE limits the audience of a mod, but that seems to be true. For myself, I don't really care and consider it their loss if they don't want to take advantage of the tools available. But for a project that's intended to help unify modding, we might have to care, at least enough to separate out the OBSE content into a separate package. I'm advocating this, and at the same time I really dislike it. I don't want to be limited because other people choose to be limited. --Daleth 16:39, 21 December 2006 (EST)

I'd strongly prefer that we not put OBSE content into Cob (at least not cob main). Most players do not run OBSE and there's always going to be an interaction concern (did Oblivion just crash because of OBSE or was it something else?) (BTW, I personally don't use OBSE -- maybe with Scruggy's very cool looking thief stuff in the future, but not yet.) However, I think that it's a good idea to keep OBSE in mind -- Cob can be made OBSE friendly/ready without actually using OBSE it. Also, a separate "Cob OBSE" esm or esp might be desirable. --Wrye 18:47, 21 December 2006 (EST)

I agree that OBSE should not be part of the main COB. However I think a separate OBSE-enabled portion would be good. OBSE allows key-binding to invoke functionality in scripts. One thing I was wanting to do was to create a single quest script that watches all keys and then allows different call-backs into various other scripts (via a persistent object associated with the key) which could be overridden by other esps as appropriate.--Behippo 23:09, 21 December 2006 (EST)

Behippo, would you like to take the lead on this one? Figure out specifically what would be useful to put into Cob Main.esm. Be a bit conservative and take a little time if necessary. Talk with other folks on the forum that seems best (here, ES Forums, CS Wiki). If there's a consensus, I'll put it in. (If do the discussion elsewhere, put a link to it here. If you want to do it here, but the discussion gets long, then move it to a new page (e.g., "Tes4Mod:Cob OBSE"). --Wrye 23:37, 21 December 2006 (EST)

Number of ModulesEdit

I think two: Cob Main.esm and Cob Resources.esm. Cob Main would contain the necessarily unique items, while Cob Resources would be for the convenient but not necessary items. --Wrye 00:51, 21 December 2006 (EST)

Inclusion without BloatingEdit

ProposalEdit

Bloating and resource usage is a concern, but I think that I've been too careful about it in the past. As dev said, getting Cobl to the critical point is probably more important at this point -- which means putting a lot more stuff into it.

The problem with having multiple esms/esps (with different parts of cobl in different esms/esps) is:

1. It becomes a pain to work with, both in creating/managing Cobl, and for modders using Cobl.
2. It uses mod slots (always a concern).

An alternative solution is described at the bottom of the Design Guide. It's sort of a variation on the push down technique used for pushing land into the Oblivion space. But rather than "push down" you do more of a "trim off" as needed. In short:

1. Have a master Cobl Main.esm -- put everything into it that we want. Foods, furniture, wolf meat, ice cave statics, etc. Don't worry about bloating, just put it in.
2. For people with high end machines, we're fairly sure this won't be a problem, so they're happy and their life is simple.
3. For people with low end machines, where that many resources is a problem (and we're not even sure how much of a problem this will be yet), the user custom trims Cobl Main.esm to contain only the resources they need. This is kind of like Bashed Patch in reverse -- rather than putting stuff in, you take stuff out.

1. Wrye Bash users would right click on the mod, click "Configure Cobl". This would produce a dialog with a check list of various components which the user could include or not include.
2. For non-bash users, there are a couple of options: Perhaps some pre-built alternate configurations would be available. (E.g., Cobl Main.esm: Core+IceCave.) However, the need to support many different permutations limits the viability of this approach.
3. Or the user could have a core "Cobl Main.esm" which just has the main stuff (with everything else already pre-chopped out), and then the user has additional esps that add stuff back in (by push down method). These would still take up slots, of course -- but at least they're not permantely used (e.g., if user later gets Bash, they can discard the push down esps and just use method (a).
4. For [Cobl/Proposals#Signals_for_General_Use|signals], the user mods should make sure to include the globals (i.e., they would act in pushdown mode). One could do the same thing for other stuff (statics, etc.), thus avoiding the need for (c), but that would make it difficult to optionally override things in Cobl. This is a possibility, but it would be a hassle for modders adding the stuff (who have to remember to umm... "push up" the appropriate stuff from Cobl), and well... it seems rather unclean to me to unnecessarily push stuff into mods.

In short, I think the thing to do now is to just go ahead and add stuff to Cobl w/o worrying too much about bloating. When it becomes a problem, then we start implementing solutions above.

VotingEdit

• Support: (as proposer) --Wrye 00:32, 25 October 2007 (EDT)
• Support: Wow, Wrye, that sounds awesome! --Princess_Stomper (forum post)
• Support: Works for me... --CorePc (forum post)
• Support: Aye. (That's a yes) --Dev akm 17:51, 25 October 2007 (EDT)
• Support: Yes. Tarnsman

Okay, that's confirmed and is now policy. --Wrye 20:01, 25 October 2007 (EDT)