Oblivion Mod:Cobl/Projects/Archive 1

Alchemical CatalogsEdit

Scrolls of alchemical items and effects. An overridden version of this will be included by Wrye Bash during Bash's merging procedure and installed in the Bashed Lists esp along with the merged lists. Merging is needed the catalog compiles list of alchemical ingredients and properties form all loaded mods. --Wrye 00:51, 21 December 2006 (EST)

Alchemical SortingEdit

Moved to Alchemical Sorter.

Combat TokensEdit

Something that I've been mulling over which may be good ideas... or not. A set of tokens to assign Class (and possibly CombatStyle) which could be given to companion NPCs to change which skills they advance in as they level and so tailor your companion to your play style a bit. I haven't gotten as far as how you'd get the token to give it to your companion or how you'd remove an old one if you didn't want them to use it anymore. If it's a functional idea, defining the tokens in the COB file would make sense. --Daleth

Very similar to this, it would be very useful to have a common resource of CombatStyle tokens that could be assigned to various NPC enemies. Advanced combat scripting techniques (most likely via OBSE) could then recognize these tokens and alter the enemy behavior accordingly. I proposed this idea in the Deadly Reflex thread a while back, but it might be equally applicable to other mods like TalkieToaster's Adrenaline-Fuelled Combat. --Dev akm 14:31, 21 December 2006 (EST)

It would be pretty easy to assign a real class to a character via OBSE. We already know where it is - I just haven't taken the time to build the function. I also know a lot about the class already and could easily add functions to change a character's class definition. --Behippo 01:36, 22 December 2006 (EST)

Companion FactionEdit

Faction for companion NPCs. Useful for identifying resources (beds, etc.) which companions should use. Useful for dialog? Other NPCs talking with companions might have special dialog (What's it like travelling with the Hero of Kvatch? Is it true she sleeps in her armor? How can you work for such an awful person??) --motub

Motub 19:17, 21 December 2006 (EST) : Such a common faction, at first glance, does not seem immediately useful for the makers of companion mods, since they will still need to program the main issues of a companion, such as determining which AI packages they use, and creating any scripts that might be necessary. However, it might well serve to reduce their initial workload somewhat in that certain "hackarounds" would presumably no longer be required. The reduced amount of tedium and re-invention of the wheel over and over has the potential to result in modders being able to focus on giving their companions more and better real features, though, so while the workload of creating a companion mod wouldn't necessarily be reduced overall, it might well be ultimately more fulfilling for the modder and productive for the user, who gets a "better" mod.

Much of the benefit of a dedicated Companion faction would be felt immediately by users, who would then be able to play with multiple companions from different mods without fear that such companions will try to kill each other outright due to immediate disposition issues, or later-occuring ones, since the concept of "friendly fire" is in large part controlled by faction menbership, it currently does not exist between companions unless they're from the same mod.

Many benefits would also accure to modders who make mods that secondarily involve companions, such as house modders, vendor modders, and even quest modders who have to consider the effects of the events in their quest stages on any companions the users of their mods may have.

At this point, because all the various companions are of different factions, many kinds of mods that may affect companions either simply don't-- such as quest mods that advise in their readmes to "leave your companion at home before starting this quest", or house mods that are built for one, as if the player is of course solitary, not because they didn't think about the issue, but because there's no way to "give" any extra bed to any companion that may be present without knowing specifically which one it is, which you can't, so why build the room at all?-- or make the quest or house modder temporarily become a companion modder, to add a 'knowable' companion to the mod. In any case, temporary or dedicated companion modders are generally forced to jump through elaborate hoops in order to give the companion some semblance of a complete and developed existence. Some companion modders don't jump through such hoops, and say "This is a meat shield, or a maid, it has no features, personality, or independence of mind, get over it"-- but with common resources, all companions could be substantially better integrated into the world as a whole, and with each other, and this could be accomplished pretty easily, by both companion modders and modders whose mods might impact companions, with much greater immersion and much less stress for users.

Some examples:

If the player bought a house with an additional bed designated by the house modder as owned by the companion faction, the companion as created by the companion modder would not need an 'extra' package/script to tell it where to sleep, if the companion used a sleep package, and the companion would simply use the bed without the player having to break immersion by designating a sleeping place via a dialog (if the particular companion had a dialog to designate this, which some do and some don't). So the player might send the companion home to the house mod, and adventure alone for a while, come home and find the companion asleep in his/her bed, without having had to use a menu to tell them to sleep.... as if the companion had a life of their own, inside another mod entirely.

In the same manner, if objects in the player-owned home created by the house modder, such as books, food, and training tools were designated as owned by the Companion faction, companions set as members of that faction, no matter what mod they came from (as long as the companion mods had been updated to use the dedicated faction), could perform the standard "do stuff" packages such as "train", "read", or "eat", without having to have special scripts or items to do so, and without breaking the player's immersion with a command dialog.

This still leaves the companion modder perfectly free to customize the AI packages of their companion, choose which ones they have, and pretty much everything about else about the companion-- except this one thing, their faction. What it makes possible is for me, a house modder, to provide a house that their companion can interact with, if the user is using both of our mods. Because the items in my house are set to be owned by the faction that I know his/her companion is a part of, with any luck the companion will eat the food available to their faction, read the books available to their faction, sit on the Companion faction-owned couch by the fire, or at the Companion faction-owned desk writing letters-- all of which objects are part of my house mod, and not part of the companion mod itself. Meaning that the house modder has been able to make a Companion-friendly house without 1) the house modder having to know which companion was in use by the user; 2) the companion modder having to do extra scripting to make their companion "live" in the modded house; 3) the user having to do anything more than they would have done anyway-- buy the house and move in, with friend. All because we now know one thing that we never knew before; that if a companion exists, that companion is part of a specific faction that we all know which one it is.

Mods creating new vendors to sell their new weapons and armors would have the opportunity to offer "Companion-ready" copies of those weapons and armor (owned by the Companion faction), simplifying or possibly removing completely the horrors of trying to share companion inventories.

Dremora Companion, for example, as well as CM Partners, I believe, and possibly others, have a function where you can tell the companion to "seek <whatever>". If the player was able to buy Companion faction versions of any mod-added weapons or armor, it opens the possibility of allowing the player to go to the companion and drop said items on the floor, and use a slightly modified (by the companion modder, or included in the ESM) "seek" command to say "Pick up your new armor"--- at which point the companion could pick up any "Companion faction-owned" items/weapons/armor found in the immediate area. This could perhaps even be scripted further-- on selecting an option in the companion dialog along the lines of, "Hey, I bought you a present. Here.", all items in your inventory owned by the Companion faction could be immediately transferred to the inventory of the Companion's to whom you are speaking-- without the player having to open their inventory. Currently, companions use 1) Toaster Says Share, 2) either the original or modified Reznod's Easy Companion Share, 3) their own unique methods, or 4) the kill/ressurect functionality to get the companion inventory open. There's got to be a better way for modders to accomplish such a relatively unimportant task wrt companion functions, and that better way most likely starts with getting all of these various companion actors into a common faction, so that we all have at least one common point of reference, whether we're the modder dealing with the actor, or the modder dealing with the objects that actor is meant to have access to.

Removing the necessity for companion modders to find a way to manage these technical issues enable them to focus on making their companions more full-featured (like with dialog and personality) and unique, instead of on how to get the PC to equip them. With this newly available capacity for creativity, someone might, for example, create a new package so that the companion could toddle off to the store and buy what they needed themselves (with the PC's money, of course).... Nekulor's NPCs with Jobs WIP might provide a jumping off point for something like this-- but only if the modders creating the items or giving them to vendors can designate some or all of these items as being available to the members of the Companion faction, so that transfer of any items could be carried out unattended, with some relatively lightweight scripting ("lightweight" relative to the difficulty of coding companion share functions in the first place, of course, not to mention the interruption to the player to have to shop for someone else and then get the items to that NPC).

Since creativity spawns more creativity, having such a self-shopping package would free the companion modder to consider ways to make the companion even more unique and individual-- how would the companion decide what to buy when shopping for themself, by themself? The companion modder might also use this as an opportunity to expand the player's relationship with the companion-- suppose the companion could ask if you liked what they bought, and depending on what you said, it affected their disposition towards you?

These seem to me to be much more interesting puzzles to solve when creating a companion, than "should I use Easy Companion Share or just kill and resurrect him/her?", and considering how to accomplish these kinds of modifications seem more fundamental to making a Companion able to fulfill their main function (being companionable), than these eternal technical irrelevancies. But due to the lack of a dedicated faction, which lack cuts the companion off from most parts of the world but the parts the modder him/herself actually adds or enhances for his/her companion's use (and only her/his companion's use, as this companion has no common point of reference with any other companion mod that may exist), the companion modder spends most of their time building not an individual, but a better meat shield. Which is fine, too-- if it's by choice. But at the moment, it's often not, because unless the modder is willing to go to a lot of extra effort (which any other companion modder would probably have to duplicate, and probably will, independently and slightly differently, making the mods incompatible with each other, which again blows for the user, who now has two companions that are don't work together effectively, though they individually work well with the PC), the companion NPC is boxed in by the lack of faction support which so severely limits their potential for interaction, that they can hardly hope to grow into anything more than a meat shield.

Quest mods that currently require you to leave any companions behind might have the opportunity to modify their stages to include behaviors that should be taken if a member of the Companion faction is found in a certain radius of the player-- as in "move(them_as_well)to wherever". I'm no scripter, as yet, so I don't know the precise syntax, but it's got to be simpler to check if one condition is true (is there a member of the Companion faction with/near the player) and add a supplemental action for that case, than the present situation-- which is, I suspect, that because companions added by other mods have no automatically 'knowable' qualities, a quest mod that wants to deal with them has only two choices: add its own companions, which then makes at least that companion knowable by the quest modder, or, if unwilling to do that, leave any companions that the player may have traveling with them out entirely, because there's no "hook" to catch such companions with to control them. Having one automatically knowable quality for all companions (their faction), no matter what mod they came from, has got to make things easier somehow.

As mentioned, overall immersion could be increased by adding general incidental dialog for random default NPCs encountering members of the faction; the companion modder could possibly use this functionality to make their companions more unique as well, since any given companion's response to the question "So what's it like travelling with %PlayerName%?" could (and rightfully, should) be different based on the companion's personality. Quest modders would have the potential to modify the disposition of the quest-giver towards the player based on the quest-giver's reaction to the companion, since the quest giver would now have the ability to detect that the player had a companion (member of the companion faction within a certain radius again), and determine if they had a grudge against the companion-- I'm sure there's a lot of people who would be suspicious /concerned about dealing with you if you were travelling with a Dremora. Again, it would be up to the quest modder to add such functionality or not, but at least they would have the option to include the companion into consideration, as if the companion was an actor with an existance that demanded consideration-- and the solution or results of such consideration is what makes mods interesting and unique.

In the end, if Oblivion is really meant to be a role-playing game, and the role of NPCs is defined by their AI, which is at least in part determined by their faction memberships (since faction membership to some extent defines the areas of the world that they may freely interact with using their AI), then the fact that companions have no standard faction of which they are all a part means they have a severely limited role in the world by default. Unless the companion modder goes to great lengths to expand that role manually, the companion is essentially non-existant except in a fight, both because the companion modder has to carve out a place for them and because the all the other mods out there have no way of knowing the "shape" of the companion's place even if the companion modder does make one, so cannot include the companion in their little addition to the world.

The entire point of factions and RadiantAI is to do give Actors a place in the world relative to other Actors and the PC automatically. Further, since most of the companion modders are replicating this work individually, without common resources or reference, in whatever way they find best, the resulting methodologies often conflict, which makes more work for the user, who has to troubleshoot before play, if they want to use two companions from different modders. All strategies are unquestionably of limited success in the end, since the minute a third party enters the picture, such as a house modder, the companion modder's effort to create immersion for the companion is lost, unless the companion modder has gone to extreme lengths. Even if we asssume that it's "immersive" to have to specifically tell your companion to sit, eat, "here's where you sleep", etc, which it is in fact not, that's limiting your choice of companions to those who have that functionality programmed in, which all of them do not. And even so, it's only a shadow of integration into the world. CM Partners companions can read books on their own time, because they keep books in their inventory (which is wasteful, if nonetheless impressive). Gabrielle probably can't. But neither of those companions nor any other companions will read the books specifically placed in a bookcase in "their" room, in a house mod, because there's no way for the house modder to communicate with any companion that these books are for them specifically to use, even if they do have the AI package to do so.

But such communication ability between mods of different types via faction membership could be easily implemented for even existing companions, if all that was needed to update them was to 1) make their ESP dependent on the CoB.ESM; 2) set the companion to the Companion faction from whatever custom faction it was; 3) add some bog-standard AI packages. It might even inspire the modder to expand on the original. Certainly the idea of a world where companions were a knowable quantity, so that I could consider them as independent actors in the world, gives me ideas for all the things I'd like to enable them to do, so hopefully more experienced modders would be similarly moved.

Misc. FactionsEdit

Neutral FactionEdit

A neutral faction for shopkeepers, creatures??

I think the idea behind a global "neutral" faction is to assign it to enemy NPCs/critters so that if they are spawned together in a cave, they will not all kill each other, leaving the player free to wait for the battle to end, finish off the couple of survivors, and loot the corpses. If there's a common resource that modders can use to assign a faction that's agreed upon, 2 enemy types added by 2 different mods won't react to each other this way. --Daleth 15:13, 21 December 2006 (EST)

Problem with that is that certain enemies should whup up on each other. E.g. Amazon's should whip up on all men. Also, mob on mob action is actually a very cool and useful gameplay element. For example, at a low level, I ran into one of OOO's spectral ghosts (outside Fort Daria?) so I led the guy in Dzonot cave. Sure enough, the Amazons went after him. I ran back out, swam off and hid, while the Amazon's chased him out of the dave and eventually killed him. Great fun! Dev_akm's story had a similar element, where a fleeing npc ran through a bunch of imps who at least slowed the guy down so that dev and his companion could finish him off. So, I think that we definitely want to preserve such gameplay elements. There's still the consideration about not populating the same cave with antagonistic npcs/creatures -- but that can be avoided by correctly using leveled lists and using smaller standard factions (e.g., an Amazon's faction for amazon npcs no matter which mod they come from.) --Wrye 18:17, 21 December 2006 (EST)

Agreed. There are places in the Vanilla game that are designed to work this way, and even where it's not by design it sometimes allows for interesting strategies instead of just charging in and swinging a big stick. But avoiding this where it's not intended by modders is the only use I can think of for a neutral faction, whether it's a good idea or not. --Daleth 18:49, 21 December 2006 (EST)

Bandit Protected FactionEdit

A faction for travellers who have bought protection from bandits, or who for some other reason are generally free from attacks by bandits (but aren't themselves bandits). Especially useful for shady merchants travelling the countryside. While such a faction might be free from attack by bandits, it presumably would still be succept to attack by hostile Daedra, etc. --Wrye 19:05, 21 December 2006 (EST) (Idea by dev_akm, CorePC.)

Leveled ListsEdit

Since leveled lists is a big complicated topic, it gets separated out from other proposed additions. Discuss it here.

Leveling Style via BashEdit

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. --Wrye 00:51, 21 December 2006 (EST)

I suspect we'll need to set up a small but functional test of this model before we can figure out the best approach. --Dev akm 14:34, 21 December 2006 (EST)

Randomize Populations via BashEdit

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). --Wrye 00:51, 21 December 2006 (EST)