Balkoth wrote:Somnium wrote:As the existing script uses the gold value difference of the item before and after enchanting, there isn't really any easy way of calculating a static cost of a specific enchantment. Especially since the enchantment to be added, including parameters, is encoded into a three letter code value, which is then passed as a parameter to the different parts of the forge scripts.
I have spent some time on analyzing the format (creating three pages of code/decode tables in the process), and I now have a working prototype for charging a static cost
See my update in the forge thread for more info.
I think you're vastly overcomplicating it.
1. Set a variable when the specific enchant is chosen (base cost).
2. When calculating the final cost, find out how many different (aka, not the one you're trying to add) enchants already exist and add 1/2/whatever to that variable.
In other words, can tear out the existing scripts for those spots and put in much simpler ones.
I've also given some thought to making this work for multiple people simultaneously -- idea is that it triggers a private conversation for the player rather than having to actually talk to the NPC directly. Which also means you could store the variables mentioned above on the player directly (doesn't need to be on an item or in a database since the value is recalculated from the start each time you select a property and proceed to the next steps).
Actually, quite the opposite. The forge system conversation nodes set the enchantment type, the enchantment value and the enchantment secondary value independently from each other, and reuses the same conversation subtree for similar values (i.e. the same reused conversation tree for choosing the size of the enhancement bonus, no matter which kind of enhancement is being made).
Which was a quite brilliant construction by the original creator, since that means that instead of having a separate script and conversation node for each and every combination of enchantment type, subtype and secondary subtype, relatively few scripts and unique conversation nodes are needed. This also allows for the script to have a central place to define ALL costs (i.e. a central cost calculation method), instead of having to spread the costs around many "end nods" scripts in the crafting conversation.
However, this also means that a specific conversation node does not know how "expensive" it should be, hence there is no place to "set a variable when the specific enchant is chosen", since the action taken script does not know how expensive it should be. On the other hand, as all end nodes can then be powered by the exact same script, that is a "trade-off" that I'm willing to make - I'll take maintainable code which takes a bit of extra time to set up, over a simpler spaghetti-like copy/pasted mess, any day
This of course also means that I had to create code/decode tables, so that when I have to calculate the cost of "2-27-1" I know that this means "add a +1 bonus to reflex saves". Those are the tables I mentioned in my post above.
As for having this work for multiple people simultaneously, this is not just a manner of the local variables (which could easily be moved to the player as you mention), but also that you have to designate the item you want to enchant, in some manner which also prevent duping glitches. The easiest way to do this, is to force the player to relinquish the item (i.e. put it into the enchantment container). And in my opinion, the current method also has the added bonus of feeling natural. I.e. you give the item to a NPC which has the skills to enchant, speak with him about the enhancment you want, and then he performs the work. And multiple customers do not speak with the smith at the same time, as he can only work on a single item at a time anyway.
I agree on the "extra cost" calculation - we already have the logic to count the number of enchantments, so it should be easy to make a similar method supplied with an enchantment type as a parameter, which then disregards existing enchantments of that type from the total. What needs to be decided is what the added cost should be.