dr-scripts
dr-scripts copied to clipboard
[script][workorders] Added the new common-crafting method
This update will look for sigils and purchase if able. This will allow overrides to work for recipes that are not true and the user has the sigils.
Relies on #6071
I need to remove my remedy cauldron stuff from this version.
I want to humbly suggest we get away from enchant_stock#, and move to an array model for parts. The sheer volume of code required to handle individual items like this is reason alone, but readability plays a factor as well. Opening base-recipes doesn't actually tell you which sigils each item requires, only the order number, which requires an additional wiki lookup or trip to the society. An array of parts allows us to simply do for each from a single array, rather than a separate code block for every stock pair, while also providing all the information one might want from a data file. Finally, enchant doesn't care about these things, it fetches whatever sigil the messaging requests, so it seems to me we're making more work for no reason.
If you were to collect totems/sigils/etc under one variable:
part:
- 1st sigil
- 2nd sigil
- bone totem
we could send the whole list to your method, pick out and order the sigils and parts, all in one method call.
#6085 - base-recipes
added stock name for sigils.
enchant_stock1_name: permutation
enchant_stock1: 4
enchant_stock2_name: permutation
enchant_stock2: 4
enchant_stock3_name: clarification
enchant_stock3: 14
enchant_stock4_name:
enchant_stock4:
I want to humbly suggest we get away from enchant_stock#, and move to an array model for parts. The sheer volume of code required to handle individual items like this is reason alone, but readability plays a factor as well. Opening base-recipes doesn't actually tell you which sigils each item requires, only the order number, which requires an additional wiki lookup or trip to the society. An array of parts allows us to simply do for each from a single array, rather than a separate code block for every stock pair, while also providing all the information one might want from a data file. Finally, enchant doesn't care about these things, it fetches whatever sigil the messaging requests, so it seems to me we're making more work for no reason.
If you were to collect totems/sigils/etc under one variable:
part: - 1st sigil - 2nd sigil - bone totem
we could send the whole list to your method, pick out and order the sigils and parts, all in one method call.
We would need a lookup method then for to order the parts versus buying the parts. So, we would need to build additional code to figure that out. I added the actual sigil names in my PR.
I want to humbly suggest we get away from enchant_stock#, and move to an array model for parts. The sheer volume of code required to handle individual items like this is reason alone, but readability plays a factor as well. Opening base-recipes doesn't actually tell you which sigils each item requires, only the order number, which requires an additional wiki lookup or trip to the society. An array of parts allows us to simply do for each from a single array, rather than a separate code block for every stock pair, while also providing all the information one might want from a data file. Finally, enchant doesn't care about these things, it fetches whatever sigil the messaging requests, so it seems to me we're making more work for no reason. If you were to collect totems/sigils/etc under one variable:
part: - 1st sigil - 2nd sigil - bone totem
we could send the whole list to your method, pick out and order the sigils and parts, all in one method call.
We would need a lookup method then for to order the parts versus buying the parts. So, we would need to build additional code to figure that out. I added the actual sigil names in my PR.
Well, anything WITH a stock number gets ordered, anything without gets bought, thats in base crafting, and i believe thats how your workorders enchanting section works as well.
Saw the names, updated my pr to reflect, thanks again for the mention!
Converted to draft for a moment. I found a weird challenge that if no runestones are in the container, say looking for them in your backpack, the value for that is set to 1. I did a test from the command line and it worked as expected. Also, the same method works with the sigil scrolls. So, working through this. I made different variables for the components and parts. The same behavior happened. Trying a reget with a plus 1 if none found.
Working well now.
:question: instead of sending @bag in the calls to check for sigil, components, and parts, should I send @bag_items? This would put those into a person's items in crafting containing instead of general crafting container. Just a thought I had.
I will remove all the debug lines after some more people test. I have tested and it is working as expected now but would like it to work on others as well.
Removed the debugging messages and made sure to have all the latest PR merges in.