In-game recipe checklist per character

[cwsonline]

I understand that the API won't currently allow you to export your recipes but what about an in-game checklist? Using the recipe lists from Lorebook or Missy's checklist (http://forums.lotro.com/showthread.php?321316-Recipe-Checklists-%28Updated-V3-B1%29) allow each character to select their vocation then just check off the recipes they have. Allow characters on the server to view/search for recipes either to have something crafted or if a recipe is already known by another character.

[Temil2006]

I 2nd this.. if someone could put together a plugin similar to this, I am willing to convert the those lists into the CVS files, XML, etc so that the list can be easily updated without having to update the plugin it's self. All it would need to do is look at the file with all the data, and then display it in game, with checkboxes next to each one. I'm a programer, but not a Lua programer. Not interested in trying to learn it if i dont have to as I have alot on my plate right now, but converting the database info is relitivly easy for me to do.

[Chiran]

Quite possible if someone would convert all the recipe lists. They should be in Lua script format though for the plugin to read. Something like:


return
{
["Cooking"] =
{
["Tier1"] =
{
["Recipe1"] =
{
["Name"] = "Recipe name",
["SingleUse"] = false
},
["Recipe2"] =
{
["Name"] = "Recipe name 2",
["SingleUse"] = true
}
}
}
}

Depending of course what suits the end purpose and how elaborate you need/want to be.

-Chiran

[Temil2006]

well, I could convert it to something like that, just need someone to go over all the details and work out the layout, and I could convert the data. If anyone wants to take on this project, lets talk and we can go over what format you need everything in.

[cwsonline]

Maybe we could save off Missy's checklist (https://spreadsheets.google.com/ccc?key=0Ag5kxd8jRWlvdGswOC1wakpGaGliUnc3ZUxIb3RYZ 2c#gid=0) as CSV or text then just parse it out with a simple script (Perl, etc) into whatever format is needed?

[Temil2006]

yup, 2 steps ahead of ya :D ... I allready did that part of it exporting it to CVS, and working on a script that will auto-parse the data, and then readd it into a correct format usable for either a script, or something similar. I'm just not fimilar with LUA at all, so I'm really unsure on the format it would need to be in to be most usable.


Taking the example that Chiran posted earlier in this post, I can easily convert it to that format. BUT, is that truly the code structure and usability for LUA to use? Chiran, not dounting you at all I just dont know how good you are at coding or anything, and I want to sure I'm parsing this correctly before hand, so I don't have to redo it all over again later. I hope you understand. ;)

[Chiran]

Taking the example that Chiran posted earlier in this post, I can easily convert it to that format. BUT, is that truly the code structure and usability for LUA to use? Chiran, not dounting you at all I just dont know how good you are at coding or anything, and I want to sure I'm parsing this correctly before hand, so I don't have to redo it all over again later. I hope you understand. ;)

Yes, that is essentially the data format. Of course, you can make the file more compact by removing tabs and such. Also, you may want to choose data structure and keys differently and the structure doesn't need to be as deep necessarily.

-Chiran

[cwsonline]

I think Chiran covered all the bases in his example. Recipe name, profession, tier, and single or unlimited use is what I have normally tracked on a checklist.

[SanDBoX]

yes, that is how lua tables (complex data structures) are layed out when saved (like the user prefrences) and it would be very easy to impliment into Crafters if the data stucture were converted over to that format for me, but I am not sure how I could import it correctly since the plugindata.Load function pulls from the charicter/server/account directory, other than that one little issue it would be very easy to impliment.

will start working on it tonight and see what I can do.

[Temil2006]

I had a post up, and deleted it quickly as I saw an issue with the output file i created. sorry about that to anyone that downloaded it.

Anyways, here is the total converted Missys Crafting List into usable LAU format (at least i think). Let me know if there is any issues with it, or want it in any other format.

including a screenshot to show how many of each crafting type it converted over to this format, just in case you needed it at all.

[Hazado]

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

[Chiran]

I had a post up, and deleted it quickly as I saw an issue with the output file i created. sorry about that to anyone that downloaded it.

Anyways, here is the total converted Missys Crafting List into usable LAU format (at least i think). Let me know if there is any issues with it, or want it in any other format.

including a screenshot to show how many of each crafting type it converted over to this format, just in case you needed it at all.

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

[cwsonline]

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

[Temil2006]

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

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.

[Chiran]

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

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.


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.

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

[SanDBoX]

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.

[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

[Temil2006]

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::
Recipes.Cook.Tier1["Name"]


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.

[SanDBoX]

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...

[Temil2006]

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)

[SanDBoX]

Yea, I know what you mean... as for automating it that would be nice, but how would we load the new data files unless "Missy" keeps them updated in a singlure place... but that would be something that I will let you figure out :D

One thing that would be nice is to have all the data in the recipe level including teir, profession, ect, that way it can all be refrenced at once when you pull that one element I know it would increase size and amount of memory required a lot so we will have to see how well lotro can handle the increase.

By the way, there is a bug in your converter, teir6 does not get closed before closing the profression. with xml it wouldnt be a problem, but lua is annoying about it closures.