Authors CurseForge

You'd need to write an addon (or add code to an existing one) to do that, but yes, there is an API function to get the names of sets a specific item is in. PT:ItemSearch(item)

Would it be appropriate to add required skill level information to PT? Specifically Milling and Prospecting, (Lockpicking meh).

I am asking because I'd like to see if there are any libraries (haven't found any yet) that contain said information which would be useful to have for one of my mods.

Lockpicking is in there somewhere but its hard to find. Not sure about other tradeskills.

Quote from dekimsey

Would it be appropriate to add required skill level information to PT?...said information ... would be useful to have for one of my mods.

Well, Pt3.1 is for sharing its contents among many mods and keeping it all updated collaboratively. If your mod needs Tradeskill.Gather.* to have useable level added then go ahead and add it. These have no ranking value at the moment anyway so you will not be stepping on anyone's toes.

it would be really nice to have a database of the orange/yellow/green/grey numbers of trade skills. how would one go about adding that data?

Quote from lilsparky

it would be really nice to have a database of the orange/yellow/green/grey numbers of trade skills. how would one go about adding that data?

There is already a set of:

["Tradeskill.Crafted.Alchemy"] = "118:1,2454:1,5997:1,3382:15, etc."

To be honest, I have no idea what the sorting numbers in there mean. I think they are one of the 4 numbers you need (red, ie. the first skill level available at I think). The numbers are mineable: http://www.wowhead.com/?item=31682#teaches-recipe.

So someone (you) needs to write a mining module and then stuff them into a set. So for instance if we call it "Skill" then it could look like this:

["Tradeskill.Skill.Alchemy"] = "...,31677:360#375#377#380,..."

So for http://www.wowhead.com/?item=31677 Fell Mana Potion as in the example, it has red#yellow#green#grey skill. You can trace TradeskillResultMats and the mods that use it for sample code for multiple values per item in a set.

You could also stick it in a separate file in which case it could just be
Skill.Alchemy etc.

If you do that then you can spam the file with stuff like
Skill.Suggested.Level.1.5 = ...
since Tradeskill seems pretty hefty already.

Finally, the mining will be horrendous since you need to hit up separate pages. You can contact wowhead to see if they can add a filter or view or something to let you get it in a list form instead of individually per item.

Also nice would be a way to rank them all so you can have a UI that shows the top 2 items per slot/category etc. since the vast majority of the time those are the only ones you ever need to cast and searching through a gigantic ocean of gray items sucks coconuts.

So for instance:
Skill.Blacksmithing.Head = ...
Skill.Blacksmithing.Chest = ...
instead of just Skill.Blacksmithing

Quote from Elkano

...there are some recipes that start at yellow or worse at the time you can learn them.

Good point. Well there you have it, this for sure calls for an entirely new data set.

okay. i might be able to put something together. i've used pt a few times, but i'm not at all confident i understand the data layout.

i'm not sure i get the "Skill.Suggested.Level.1.5" part.

i don't think the mining will be THAT hard -- the table view of spells includes a "colors" field which has the 4 difficulty levels.

it's also possible that the data is more compressible. i *think* the progressions are linear, in that you can describe the 4 numbers with only two -- when it goes to orange and how many more levels till it goes gray. the green/yellow are evenly spaced, i think. still, probably best to just stuff all 4 numbers in, yeah? or maybe have either 2 or 4 -- 2 means linear, 4 means "special"?

edit: wtf was that weird img stuff (that i just deleted)?!?!

Quote from lilsparky

... i'm not at all confident i understand the data layout....

Sweet, you can help debug the docs here then: http://www.wowace.com/projects/libperiodictable-3-1/pages/editing/

What about them sucks and prevent you from having a clear understanding?

As for 2 vs 4 numbers, I would keep it simple and just have 4 at first. After you have mined them it would be simple to see if they are consistent. I doubt that they are. Even if they are it could change. PT used to be compressed, but this was dropped in favor of faster load access, so go ahead and leave out any interpolation stage and just do 4.

"Skill.Suggested.Level.1.5" would be part of a series of sets that tells you which recipes to use at particular levels, so in this case level 1-5. This is strictly for the bonus round if you have a mod that can make skillup suggestions.

In terms of how to go about this I would suggest the following:
* make test set(s) in data.lua and hand type in 3 or 4 values.
* create the Output file (LibPeriodicTable-3.1-Skill), and change compresssplit.lua to update it.
* Add the test set(s) to the output file
* run compresssplit, it will rewrite the set(s) in the Skill file based on what is in data.lua for all sets Skill.* that match the ones in LibPeriodicTable-3.1-Skill

Finally, get the mining going, and have the miner dump wowhead data into data.lua. Once you are satisfied with the results, run compresssplit to create the output file and check the whole shebang in.

Since you are doing it in a separate file, and initially only for your mod you can check in at various stages (as long as you have not broken anything else) so we can help / comment on what you are doing.

While doing all this make a note of where the docs are failing for you so they can be upgraded for the next persons benefit.

Quote from Azethoth

In terms of how to go about this I would suggest the following:
* make test set(s) in data.lua and hand type in 3 or 4 values.
* create the Output file (LibPeriodicTable-3.1-Skill), and change compresssplit.lua to update it.
* Add the test set(s) to the output file
* run compresssplit, it will rewrite the set(s) in the Skill file based on what is in data.lua for all sets Skill.* that match the ones in LibPeriodicTable-3.1-Skill

Finally, get the mining going, and have the miner dump wowhead data into data.lua. Once you are satisfied with the results, run compresssplit to create the output file and check the whole shebang in.

Since you are doing it in a separate file, and initially only for your mod you can check in at various stages (as long as you have not broken anything else) so we can help / comment on what you are doing.

While doing all this make a note of where the docs are failing for you so they can be upgraded for the next persons benefit.

i'll give it a shot. when you say "Skill" do you mean "Tradeskill" or are you saying i should start a whole new file? is that what you meant by "whole new file"?

so here's my dataminer code:

handlers["^Tradeskill%.Levels%."] = function (set, data)
    local profession = set:match("^Tradeskill%.Levels%.(.+)$")
    local filter = Tradeskill_Profession_filters[profession]
    if not filter then return end

    local newset

    basic_listview_handler("http://www.wowhead.com/?spells="..filter, function (itemstring)
        local levels = {}
        local recipe = itemstring:match("{id:(%d+)")

        local colors = itemstring:match("colors:%b[]")
        if not colors then return end

        for l in colors:gmatch("%d+") do
            table.insert(levels,tonumber(l))
        end


        if newset then
            newset = newset..","..recipe..":"..table.concat(levels,"#")
        else
            newset = recipe..":"..table.concat(levels,"#")
        end
    end)
    return newset
end

i *think* it works.

the datset names i went with are:

Tradeskill.Levels.Alchemy = ...
Tradeskill.Levels.Blacksmithing.Armorsmith = ...

so the specialization is built in.

the format is:

spellid:orange#yellow#green#gray, spellid:...


now, about usability....

with them broken up as such, you have to know what set the spell you're interested comes from, right? or can you do ItemInSet("Tradeskill.Levels") and it will iterate the children until it finds the item?

Quote from lilsparky

...are you saying i should start a whole new file?...

yes, I mean go ahead and add a new file. It will be fairly large and breaking it out is pretty cost free and helps keep things in bite sized chunks for other authors to pick and choose from.

It also has the added benefit of totally isolating your changes to only one result file and letting you run the miner on just that file (a full run is 8 mins on my machine so limiting the run is a very good thing as well.)

It could be another Tradeskill variation though so they are all grouped. So if you do TradeskillLevels for example then there would be 3 Tradeskill related files:

Tradeskill
TradeskillLevels
TradeskillResultMats

On the other hand stuffing them into the existing file is fine as well. There is no "correct" thing to do.

Quote from lilsparky

so here's my dataminer code: ... i *think* it works...

You need to get the miner up and running on your local machine which means installing lua5.1 which you need for compresssplit anyway, and then adding in the lua libs for html, database etc. Basically just Google for the lua5.1.dll and lua5.1.exe executables (assuming you are on a pc) or whatever parts are required for your OS. You will also need lua sockets which has a replacement dll and exe I think.

Quote from lilsparky

...the dataset names i went with are:

Tradeskill.Levels.Alchemy = ...
Tradeskill.Levels.Blacksmithing.Armorsmith = ... spellid:orange#yellow#green#gray, spellid:...

Perfect.

Quote from lilsparky

... can you do ItemInSet("Tradeskill.Levels") and it will iterate the children until it finds the item?

It should work like that.

Quote from Azethoth

You need to get the miner up and running on your local machine which means installing lua5.1 which you need for compresssplit anyway, and then adding in the lua libs for html, database etc. I thought I posted that somewhere.

yeah, i did and what i meant by i think it works is that i haven't really written anything to validate the data returned. it looks okay, tho.

It should work like that.

great. so basically when i get data, i'd be getting back a single string that's formatted like the data i stuffed in already, right?

so if i did 1212:100#110#120#130 as my format, getting item 1212 would return "100#110#120#130", right? is "#" the preferred delimiter for multiple values like this? are slashes something to avoid? cuz it seems if one were to simply print the values returned, 100/110/120/130 seems a lot more legible than 100#110#120#130.

Quote from lilsparky

...i haven't really written anything to validate the data returned. it looks okay, tho...
1212:100#110#120#130 as my format, getting item 1212 would return "100#110#120#130", right? is "#" the preferred delimiter...

If the data looks correct visually, then the only other thing to watch is the number of items returned. wowhead limits results sets to 200 (or used to, some result sets are larger now). If you run into the max return issue you would need to break the queries up into smaller chunks by concatenating smaller more specific queries into what you want.

"/" would certainly work. The only other sets that do this use ";"

Quote from Azethoth

If the data looks correct visually, then the only other thing to watch is the number of items returned. wowhead limits results sets to 200 (or used to, some result sets are larger now). If you run into the max return issue you would need to break the queries up into smaller chunks by concatenating smaller more specific queries into what you want.

"/" would certainly work. The only other sets that do this use ";"

i patterned my query after one of the other tradeskill queries (reagents i think) so i kind of assumed it had sorted out the 200 item limit already in the filtering mechanism.

i'll go ahead and add a reference to this new data in my skillet branch and see what happens. should be pretty obvious if data is missing or not.

in terms of docs...

i think you could explain the data.lua process a little more. it seems a bit counter-intuitive that data.lua is both generated and editable. i think maybe instead of describing the dataminer as scraping wowhead for data, perhaps you could describe it as scanning data.lua and updating tables that is has been explicitly programmed to update while leaving untouched all other tables.

i'm a little vague as to what happens between the data.lua file and the individual breakdowns. is it a hold-over from the old system where data was compressed?

i think it would also be nice if there was a requirement to provide a description of the data somewhere when editing/generating tables so people can know what the table is and how to use it.

okay, so i think the data is complete. should is push my files thru the svn or is there a different way to have somebody verify it's cool first? also, i decided to go with "/" instead of "#".

edit: i'm attaching my output file as a means for people to test its accuracy and make sure i didn't step on something else in there.