Oblivion Mod:Cobl/Projects/Recipe Updater Engine

Cobl: Old Project Page: This is an old and now inactive discussion article for a Cobl project. If you have questions about this or other Cobl projects, do not edit this page, but instead discuss it at the official forums on Relz topic.

Goals and Background

To provide a way for the Products of Recipes to automatically update. For example, a potion/Alchemy recipe should automatically update as the player's Alchemy skill increases as if they had made it in the standard Alchemy menu.

Essentially this will require modders to specify the required Materials and the Product they produce and place them in an array. From there, the engine will make a recipe that the player can click on to recreate the Product (using the Materials). This is not a Crafting Engine, and handles everything after Crafting.

This recipe will have the ability to: (with some examples of how they'll work for Alchemical Formulas/Recipes):

An Automatic Update System

The potions' strength will automatically update as the player increases their Alchemy skill, get new apparatuses, etc. The strength will be based on the vanilla formula by default, but you can set up different formulas. Again, this won't be limited to potions and it won't be limited to magic effects - you can use formulas to dynamically set a weapon's enchantment, an armour piece's max health, potion price, etc.

A (mod) Customizable Default System

When the player first installs Alchemical Formulas all potions will use 2 default formulas to determine the Price and Potion Strength as the player levels up. You can change the formulas by changing a quest variable. These "formulas" are just references to activators with scripts that return a couple of numbers based on the player's stats, game settings, etc. Set up a new script, put it on an activator, and change the reference and all potions/products will use the new default formula.

A Modification System

For any numeral flags on the items (i.e., Weight, Price, Effect Strengths) you will be able to add modifications. For instance, say you have a quest that will make the player more "Fire aware" and able to produce better Fire potions - with one array and a script all fire potions can have a +5 magnitude bonus and/or +50% magnitude bonus, be worth more money, weight less, etc.

Allows Formulas/Functions to be used to Determine Update

For instance, the vanilla formula will be used to determine the strength of the effects of a potion. This requires an activator to act as a function, and could technically be expanded to test and set anything an Oblivion script can.

Works for any Item

As long as it has a FormID it can be used. Should even be possible to allow summonings/NPCs to be directly created.

NPCs can use recipes as well

NPCs will be able to use the recipes with most of the same benefits as the players. No information will be stored for NPCs, and the functions will be expected to take less processing load, but otherwise they will be the same.

Automatic FormID management

To reduce the amount of save bloat, a new item will only be created if the effects or the strength of those effects have changed. This is exactly as handled by vanilla Oblivion, and will not add any more save bloat then vanilla Oblivion.

Ability to Modify Previous Products (for mods)

Allows modders to change previously made products. For instance, if the player starts using a mod that changes some of their ingredient's effects this will automatically change all of the potions using the ingredients to use the new effects, as if the mod had been installed all along.

• As of now, I believe this would require too much extra information to be practical. Essentially, any and every piece of information (stats, game settings) would need to be stored whenever the player creates a new product. It is hard (technically impossible without a few gross assumptions) to guess backwards from the product to the original stats, and impossible to guess what piece of information the new formula would use.--Haama 14:57, 19 February 2008 (EST)

Requirements

This will require Pluggy. Pluggy adds arrays to Oblivion and will be necessary to store all of the information.

As with OBSE, it would be easy to test whether the player has Pluggy installed. There should also probably be a Startup script that will check for OBSE and Pluggy, initialize all of the necessary information, etc.

Current Functions (working, to be included in a future version of COBL)

• Alchemy recipes - use 2-4 ingredients to create a single potion
  • Create 3 arrays: one for the Materials List, one for the Products List, and one for the Product Defaults. Add the ingredients to the Materials List array, the potion to the Products array, and the global cobRUEDefAlchemy to the Product Defaults array. Use the cobRUEFuncSetupRecipe function to set up the recipe, and cobRUEFuncOpenSetupRecipe to use the recipe. (More soon and an example script--Haama 23:04, 2 April 2008 (EDT))

Current Limitations

• Can't create recipes for products with scripted effects.
  • Once they can be created, they will require Tibixe's String Function Collection - required as Pluggy can't grab the name of the scripted effect.
• The only automatic updates in place are Alchemy updates.

In the works

• Get the scripted effect recipes working
• Generalize the scripts a bit more, from Alchemy specific to any default type
• Set up the mod-set system
• Set up other default types - Leatherworking, Smithing, etc.

Discussion

Original discussion thread: (Should I) Extend Alchemical Formulas into a Crafting Engine?

Loots very cool. See my reply on RELZ Cobl topic. --Wrye 02:39, 20 February 2008 (EST)

Thanks Wrye. I've added a Limitations section - it should include everything my reply on the COBL thread did and some more.--Haama 15:38, 20 February 2008 (EST)

Alright, I've given some serious thought to whether a recipe can "fallback" to non-RUE - it would require too many other headaches to do.

In short, each recipe needs to store a cloned product in a reference variable. There can be multiple products so there needs to be an expandable number of reference variables. That can only be done one of 2 ways: Pluggy Arrays or Linked Lists. Given that RUE will only be removed by removing Pluggy that option is out.

Linked lists would require RUE to always use them instead of arrays. I have dealt with linked lists more than I'd like to - they require some abuse/tricks of the CS, can lead to unpredictable behaviour, cause timing issues, and create a bottleneck.

So, as you suggested in the thread, the modder will have to decide before-hand whether to use the RUE system or not.--Haama 01:37, 22 February 2008 (EST)

Sounds reasonable. Always best to avoid nightmarish implementations. =0 --Wrye 04:14, 22 February 2008 (EST)

Design Question: Who determines a new cloned product?

Whenever a product is updated (i.e., the player gains some Alchemy levels so they can make a stronger potion) several things may change - price, effects, effect strength, weight for the sake of argument, etc. Some of these changes may require a completely new base product (clone; for potions, this would be new effects and/or effect strength) and some will only change the product (for potions, the price doesn't change until the effects/strength change). So, some of the updated flags will require new products while others will just change the product. So, I need to determine which flags are in category 1 and which in category 2.

There are 2 ways to do it

1. The modder can determine and change which flags require new products and which require changes
2. The flags will be pre-set and only certain flags will get new products (effects, strength, damage, speed, reach, etc.)

The first is more flexible. However, I prefer the second as it will be a bit easier for me to handle and would let me curb any potential save game bloat.

This isn't a decision I can go back on, so I'm hoping for some feedback first. --Haama

Just to let you know I saw this, but don't have an opinion one way or the other. --Wrye 00:48, 8 March 2008 (EST)

Thanks Wrye - I put it up on the COBL thread too but it was quickly covered up.

To the point, though, I've decided that it will be pre-set. Too many unknowns otherwise.--Haama 11:07, 14 March 2008 (EDT)

While I'm thinking about it (and taking a break from debugging :) )

I'm about to finish a preliminary RUE, so few questions and updates:

1. It will let modders add Alchemical recipes that will follow the vanilla formulas (for the most part), and has a bit of WIP otherwise. As such, I'll say most of it's off-limits but write up how to create your own recipes (of the Alchemy variety).
2. This will include 3 functions: MagicItemsHaveSameEffects, MagicItemsHaveSamePotencies, and MimicPotion. The first two determine if two magic items are the same, and the last one makes one potion into a replica of another potion. The main thing is I might mark MIHSEffects as off-limits for now - I'm thinking about updating how it handles script-less scripted effects. As well, there will be a few common globals and items - 3 I/O globals for passing ArrayIDs between functions/activators (needed to be able to use RefVar.Activate player, 1 correctly) and an item that can be used for temporary string storage (passing between OBSE/Pluggy functions).
   • Each function needs it's own Labels so it won't force modders to use different Labels (or interfere and cause errors). So far, I've never written a script with more than 2 nested loops, so I'm requesting 254-255 be reserved for functions. The RUE scripts also need a range of Labels, but I haven't decided how much will be available to modders yet (i.e., Open Recipe will be available to modders, but the ProductTypePotion function it uses probably won't be).
3. Scripted effects will require Tibixe's - I need to be able to store the name of the scripted effect and there's no other way to get to it as of now. If the player doesn't use TSFC and tried to create a recipe using scripted effects, they will be told they can't make it.
4. At least one of the scripts will have a lot of temporary variables (that are only used by itself). Should I try to create a separate, trash-able script for this instead?
5. A bit down the road, but... The default system will be a bit particular - COBL will be the ultimate default and include a basic way for each type of crafting to be updated. For instance, with Alchemy the effects change as your rank changes, effect strength with Alchemy skill and Luck, Price is dependent solely on Alchemy skill and Luck, it requires a Mortar and Pestle, and you gain a Alchemy skill point each time you make a potion. At some point, I hope others will step up and create ways of handling Leathercrafting, Enchanting, etc.
6. There's probably some more, but I can't think of it right now. More later--Haama 20:06, 26 March 2008 (EDT)
7. Ah, yes - I'm thinking of making the modders handle the Pluggy checks. For example, when the player opens a recipe it's script will start up the RUE system's Open Recipe. The pluggy check should be on the recipe, rather than the Open Recipe function. Yea/Nay?