Building a new CraftingState and CraftingSimulator is currently somewhat annoying. Mostly because of the Recipe construction. You have to manually look up the item ID for the item you want to craft and copy the durability/progress/quality modifiers (or eyeball them so you get known values).
I think the best option here is to create a struct that can load Items.csv and Recipe.csv and create a registry that lets you build a Recipe from these values. I don't want to include them as tables, I'm still okay with the RLVL tables and such since they're not really much data, but directly including the whole item table would both bloat the binary and feels like flying too close to the sun.
A more complex option could be making a xivdata package that can get FFXIV data in various ways - runtime CSV parsing, querying XIVAPI, or compile-time embedded as tables like we have now with a friendly wrapper (with the datamined tables being passed as environment variables when a given feature is turned on). Not sure I want to commit to that undertaking now, however, but it could be worth it to just make a minimal version of that project with just the tables I need. Unclear if this should be further split into a lower level -lib type library that's just codegen and a higher level access library or not, but that's a minor issue.
That option basically supersedes #2, and the rlvl/clvl/condition lookup would be moved there.
Building a new
CraftingStateandCraftingSimulatoris currently somewhat annoying. Mostly because of theRecipeconstruction. You have to manually look up the item ID for the item you want to craft and copy the durability/progress/quality modifiers (or eyeball them so you get known values).I think the best option here is to create a struct that can load
Items.csvandRecipe.csvand create a registry that lets you build aRecipefrom these values. I don't want to include them as tables, I'm still okay with the RLVL tables and such since they're not really much data, but directly including the whole item table would both bloat the binary and feels like flying too close to the sun.A more complex option could be making a
xivdatapackage that can get FFXIV data in various ways - runtime CSV parsing, querying XIVAPI, or compile-time embedded as tables like we have now with a friendly wrapper (with the datamined tables being passed as environment variables when a given feature is turned on). Not sure I want to commit to that undertaking now, however, but it could be worth it to just make a minimal version of that project with just the tables I need. Unclear if this should be further split into a lower level-libtype library that's just codegen and a higher level access library or not, but that's a minor issue.That option basically supersedes #2, and the rlvl/clvl/condition lookup would be moved there.
Either way this likely relies on #10.