Tes4Mod:Cobl/Projects/Policy

The UESPWiki – Your source for The Elder Scrolls since 1995

Most policy issues are now covered on Cobl/Policy. Also, technical issues and implementations are now covered on Cobl/Modding/Techniques. The rest of this page may later be moved to one of those pages.

[edit] Decision Making

OBSE is a group project led and (at this time) primarily driven/implemented by Wrye. Procedures are in place to support a consensus decision making process. However (experience says) we're all pretty darned busy and the Advisors have limited amount of time, and sometimes it helps to move fast anyway. So...

Generally speaking, the consensus process goes:

• Idea: Someone raises an idea and drives a discussion here and/or on the forums. If there's enough interest, then it proceeds to...
• Proposed: The proposal is stated fairly succinctly and submitted for voting.
  • At this point the proposer should know at least roughly how the idea will be implemented, and that implementation should be made clear to anyone who is interested.
  • Generally, there should be at least two 'for' votes (by advisors) and no 'against' votes for the proposal to pass. If some people are against it and/or if non-advisors are strongly for or against the idea, then the exact tally is fuzzier. But in essence, consensus should be achieved.
  • OTOH, if the choice is between A and B, but there's a lack of consensus on which -- then it may be best to just pick one rather than live with neither due to a standoff.
• Rejection: If the proposal is rejected, it is moved to Rejected. If the situation changes, it may be re-raised.
• In-Progress: If the proposal is approved, then it moves to in-progress. It's implmented, tested and then merged in as necessary.
• Complete: Once the project is implemented, integrated and released, it's moved to Complete. At this point, it should be documented at Cobl/Modding.

However, since all that takes time and advisors are pretty darned busy these days, Wrye may fast-track various projects in various ways. Wrye is likely to fast track a package if:

• If it looks like a brain-dead good idea, with little likelihood for controversy, and if it is likely to be easy to implement.
• If it seems like a very natural extension of an existing project.
• If it's just a reorganization of existing material.

If Wrye is unsure, or thinks that it's likely to cause controversy, or if it looks like it will take a long time to implement, Wrye will check for comments, feedback and/or consensus. The amount of consensus that he'll look for will depend on how sure he is about the project.

In short, the end goal of Cobl is to provide a tool that's useful to modders and players. Obviously that won't happen if potential users are strongly opposed to portions of it (hence the need for consensus). OTOH, too much time spent trying to reach consensus can make the whole thing painful and bog progress down. Hopefully, we've struct the happy medium between those extremes.

[edit] Push Down Technique

Generally mods either add material or modify existing material; new material can be easily distinguished from modification of existing material by the modindex (the first two hex-digits of the formid). E.g. if the modindex is 00 then it belongs to Oblivion.esm. If the modindex is 01 and the mod has no masters, then it belongs to the mod (i.e., it's new material). If the mod has two or more masters, then the 01 item belongs to the second master (the one after Oblivion.esm).

However, it's possible (with the right tools) to lie to the game engine. If you set the modindex of an item to 00, then the game engine treats it as if it were in Oblivion.esm even if it's not. This is called "push down" (or "injection", e.g. TES4View) and is used by couple of tools (notably for land, which tends have lots of problems if it's not in 00). The real danger with this method is a collision between formid that you push down into a master and the master already having something with that same formid -- which is why the technique is used vary sparingly.

However, for Cobl, pseudo push down can be used to avoid frequent updates (e.g. for signal variables). Procedure:

• When adding new material, always add it first to the master Cobl Main.esm.
• However, to avoid frequent releases, a mod can copy that record into itself. (This is particularly useful for signal variables.) Since the record is present in the mod, then even if the copy of Cobl Main.esm available to a user is out of date, then the global will still be present in the mod. If two mods do this, then they can use the global to communicate with each other -- again, even if the user's copy of Cobl Main.esm doesn't have it.
• With this approach, it might be useful to publish a "Cobl Signals.esp" which just copies all of the up to date signal globals into. This would be small and could be easily downloaded and used by modders.

A related approach could be used to trim Cobl Main.esm down (and thus possibly increase performance if necessary). The user would get the full Cobl Main.esm, but then use a tool like Wrye Bash to delete unused records from it. Presumably this deletion would decrease the load on the game engine.