I know this is off-topic, but you could extend this plugin to deeds as well.

Just two things I noticed at a glance. After the last recipe in a Tier, there's no need for , after } (might actually cause a parsing error, not sure). Also, I would probably do it so that the recipe count starts at 0 for each Tier. Could also use integer keys as recipe identifiers, so [1] instead of ["Recipe1"]. I'm just a bit nervous about that because of some localization issues but it should work as long as this file would only be read, not written to.

-Chiran

I can help with testing as soon as there is something up. I greatly appreciate the work you are doing!

Not sure if those changes "NEED" to be in place, but here is a copy of it with those changes.

When you said about integer keys for the recipe numbers, I can see using that. But just 1 question..
if there was 10 recipes per crafting tier, and there is a total of 2 tiers, would the recipies numbers still be 0-18 going by the TypeOfCrafting, or would it be better to go with TierDependent, being 0-9 for tier1, 0-9 for tier2 ? (did that make any since, because i just gave myself a headack typing it.. lol) :p

EDIT:
oh, also, I was just thinking (from a programing word, unfimilar with lau).
If it's seting up variables, i assumes that's easier for coding, but when happens when there is a newer LAU code with newer recipes that comes out. If the Lau code is simply referencing the integer to pull the data, I could see issues with that because Number120 recipe might not be the same 120 in a newer recipe list. Unless there is something with LAU that i'm not aware of being able to loop back and reference different data for confirmation. But again, even with "Recipe1", "Recipe2" ,etc .. ya really have the same issue I guess, as it's just an incrimenting number. ohh well, we will have to see what others come up with.

You could also discard the Tier as a table key and put it as a property of each recipe. It all depends on how you plan to use it.


Yep, would be nice to have a unique id for each recipe that does not change when new ones are added. Actually, you could even use the recipe name as the key, though it is rather long.

P.S. It's Lua, not Lau or LAU (or LUA for that matter), sorry nitpicking but I was schooled about that once by a dev :P.

-Chiran

what would be the easiest way to import the file, can you just import the file and refrence the table? going to try a few things tonight, but pointers would be very helpfull.

A good start would be:

Recipes = {}; -- creates empty table
Recipes = Turbine.PluginData.Load(Turbine.DataScope.Characte r, "Recipes") or Recipes; -- This makes the data scope character specific, tries to load Recipes.plugindata from characters PluginData folder (that's where the file needs to be placed) and defaults to the empty table if not found

Then you can reference to it, for example:

Recipes.Cook.Tier1.Recipe1["Name"]

and so on (depending on how it's structured)

-Chiran

well, since we are going to be doing some kind of referencing, would it be best to remove the section "RECIPE1" from the main data file?

example::
I can see how having RECIPE# in there can cause issues with later updates, if thge Recipe# changes due to new recipes being added in the middle then it would be trying to reference the wrong recipe. Let me know if it would be best to remove that, and I'll repost a data file without that section if so. Thanks for the feedback on this.

I dont see the Recipe# being an issue since more then likly we wont be pulling a single item by hand should be pulling them dynamicly, and once you have the specific table values to display you could reorder them before display anyway.

but I am pouring over the information right now and seeing how best to bring it all up...

gotcha, well.. just let me know either way. I allready created a prorgam to parse out all the CSV files into the current format. I figure I can release that once we are 100% sure that it's parsing it correctly so that the dev (you..hehe) don't want to maintain a database releases for every little change/update. You would only be asked to keep the script updated, but the database will be easily created by the users with only 1-2 clicks.

I always get concerned when it comes to accessing databases, because if it's going to reference a single variable that is due to change later with different data, it always seems to lead to pulling the wrong info into the wrong field (at least in all my coding... darn loops, and whiles ... lol)