Fine, I'll be constructive, heres your design doc. It's doable.
So if we assume you have a function that does the following-
Checks for Enchantment
Checks for item type to determine value table for how much enchantments cost
Checks for the existence of a value/item type to determine if an item is gilded/lined/plated to clarify which exact cost is being used- after all you have to figure out if it is redsteel..
Then you need to create at most probably 2 new sets.
Set 1 is a colloquial name table- this table will assign colloquial names to variables- E.g.
"Adamantium" = AD or 01 or whatever (You may also want in this dataset to assign the item # for the raw material form here as well as a sub-flag/ID thingymabob, if that is not included in the crafting attributes themselves)
Arcane Steel = AS or 02
Bodak Hide= BH or 871...
"Electrum-Gilded, "Electrum Gilded", "Gilded with Electrum" = EL or E018257825825827
flag is gilded= (More on this later)
Copper, Copper-gilded (CP or e82472487247828472)
Flag as gilded= Yes
This will direct your program now to have a specific reference point for item qualities that should be hopefully listed out in the crafting ID table itself. I am going to assume that each individual item has 'innate' qualities- we are not concerned with the specifics of WHAT those qualities are numerically here, only that they exist in some form on the item. We don't care if there is a cold save of +1 or +7000, just that there is a cold save for our purposes.
The reason you would make this dataset is it should sniff for an items main material component- if it can find this main material component, then it references the dataset, and then call directly on the variable in question. If it cannot find a main material component because the name is custom- do not pass go, spit out an error to the player stating that items with customized names cannot be disenchanted.
So- for example A Fever Iron Breastplate lined with Bodak hide....
and somewhere in the description is the word electrum. or is it electrum-gilded?
You just need to have the program sniff for exact sequences of words- case sensitivity doesn't matter, but spelling does obviously. The order of the materials is always the same too, so Steel always comes first in an items name, then the hide, then the gild. If there is a hideless armor, and it just says gild, then we will need to create an exception for this for armors, but the way you would do this is going to be a bit convoluted and covered in data set 2.
IF you are worried about shenanigans, that a DM somehow let a player make an adamantium sword when it was named steel- which is super cheesy, then you can check for qualities here as well in the description. If this is an arcane steel weapon- does it do magic damage? If this is arcane steel equipment- does it save against spells? If this is a white dragon helmet, does it save against cold?
The last part is only necessary if you are concerned that DMs are allowing some shenanigans to roll around. Frankly, I assume most customized items are flagged- like renamed/redesced- so I'd just exclude those entirely.
Set 2 will be more concerned with assigning material costs for all items- you may actually be able to just have it sniff these specifics out already using the call function that is likely already implemented, if not, you may just need to assign specific expected variable payouts based on the armor type. Regardless, you can also make the set-
Full Plate=8, 2, 1
Half plate=7, 2, 1
Studded leather =4, 2
Boots = 1, 1
Staffs, 2, 1 (I think)?
etc.
We will assume all items have 3 variables- with expected payouts, but only require number 1 be properly filled, variables 2 and 3 are optional and can be assigned a null label which will set their payouts to 0, or can be overridden based on a specific flag.
Your function should already be checking for the exact type of xp value, it may be doing that easily if that variable is stored in the armor, but it may also be calling on a table and doing a cross reference- I don't have access to your code. IF it does the latter, you should be able to differentiate these things without writing a new function from scratch and then create exception cases basically assigning slightly different values allowed for the payout. If you stored the xp locally on the item, then you'll need to create all of the above by scratch.
Either way, there are now three different values that need to be clarified, but how would you clarify these things- This is why dataset 1 was created- Data set one is concerned with colloquial names as they exist on equipment.. so we'll be able to call them once dataset 2 is pulled.
We use datasets 1 ID's, assign them to data set 2's variables, giving further clarification of what the armor is now made up of. For the hide/gild situation, you assign any gilding metals a maximum value that it can ever output as 1- but only in slot 2 or 3. This will override the items payout. This will account for Arandur and Copper. This will only create some messiness on an wood/arandur staff. Or wood/copper staff. The former of which I'd do a quick check to see if anyone ever bothered to make one of. If my understanding of how Arandur works is correct that is. (I assume it is a base and gild metal like copper)
This is why the flag exists in the calling/assignment dataset 1- when assigning material costs to the item will then call upon the variables its sniffed out- and check for if an item it is calling is a gilded type- if the metal type is flagged as gild only, then it overrides the variable it assigned to as 1. . So if we have a full plate with gilded only, the program will read it as 8/1/0. Not 8/0/1, if we have a copper plate gilded with arandur, it'll read as 8/X/1 or 8/1/0, because the gilding can only ever override payout values in the 2nd or 3rd slot.
We mix 1 and 2 and we should end up with this was made of 8 bars of X, 2 patches of y, and 1 bar of z. You'll have the program then call/assign raw material type form which should be hopefully assigned if not in the base crafting database, then you will need to add them as details to dataset 1. If neither of those work, thats another set that will need to be created.
Bam, pay it out. IF there is ever a failstate, spit out an error and do not payout period.
So to clarify,
You get an item.
It calls on dataset 2 to get the expected maximum material value make up of the item- these are your prelim payouts, it can only go down from here.
It scans the name/desc of the item to grab the material names- assigning them in the order they appear.
During this scan, if one of the material types is flagged as gilding only, override variable for assigned payout to 1.
IF no value is set to a given call- e.g. value 2 or 3 is not given a material type or outputs as null- set that variable to 0.
Call Xp
Payout.
If done as expected, every item will end up with a virtual table that you can have it print out during testing that should look something like-
This item is a <Item type> -
It is made up of-
X of <Material type 1>
Y of <Material Type 2>
Z of <Material Type 3>
I've written the basic design doc. It's definitely doable. If you can't get it working with a blueprint, because it's either not possible in the unique ravenloft coding language, or too labor intensive then I'd suggest backing out of the planned course of action. This has a rather significant impact on a lot of people, myself included (obviously), so if ya'll arn't willing to back this up with some concrete action here to make things fair.. then you shouldn't be going down this path. Because if you won't be able to fix it, it IS going to go onto the DMs, because guess who I'll be asking every day to replace my gear with?