I think a couple of us that use(d) PT3 for the InstanceLoot* sets created our own sets in lieu of a final decision being made on what would happen with the "official" PT3 sets. In ClassLoot i have PT3-Raidloot.lua which has a RaidLoot.* set for all raid instances with just itemid's and not drop rates.
I am now editing LibPeriodicTable addon which is used by Mendeleev. I've added ICC5, TOC5 drops and items purchasable with frost badges link because I like seeing where the gear that people I inspect comes from.
I can't figure out the right way to add drops from TOC10 and TOC25. Any ideas?
Are Tier9 sets and Tier10 sets part of the addon yet?
What is the general idea behind this addon? Am I meddling with things better left alone by a common WoW player?
Are you modifying the miner or simply adding items? The latter is no good since the info would get overwritten when the miner is run. The current issue is that the drop part of the miner needs a complete rewrite to be able to include the new raids.
I am adding items. I don't know how to operate the miner. I just like seeing where a piece of gear is from. I am satisfied with the results. I will not even distribute the files I fix if it is a problem.
I just don't know how to separate drops by raid difficulty properly
The translator who is merrily adding items to LibPeriodicTable-3.1 (LibPeriodicTable-3.1-InstanceLoot.lua & LibPeriodicTable-3.1-InstanceLootHeroic.lua) in builds 273 through to the current r280 is doing so improperly and &*^#ing up at least one mod that relies on those libraries.
His changes as of r280 cause (Phanx's) Tooltip Exchange to bug out (both the release and the WowInterface SVN versions), among other mods relying on those libraries.
Roll back to Kemayo's last build r272, no further problems.
I plan on committing a little lib that I have written to read JSON data and rewrite the miner to use that later today or tomorrow.
Edit: There are quite a bit of other changes in wowhead's format (even URL format). The update is bigger than expected, lots of small functions were added to the miner, some of them not using the internal API. I'm rewriting a lot of it.
regarding tradeskill data... why are we still using the weird itemID/-spellID format for tradeskill data? i realize mods probably are used to that system, but it seems really quirky and kinda of out-dated, no? tradeskills all have unique id's. why not use them instead of itemID for some and -spellID for others (those that produce no items)?
Wasn't the itemid used in order to be able to map items to tradeskills?
my guess is that the GetTradeSkillRecipeLink command came after this system of identifying tradeskills by itemid. keeping in mind that enchanting also used to use a whole different api (the old Crafting api). so for enchants, you could get an enchant link (probably why it was called an enchant link, now that i think about it) while for the other trade skills the only id you could get was an item id from the crafted item.
in that context, the system makes good sense. but once a generic recipe link system came to be that gives a unique id to each skill, then retaining this system is purely for compatibility.
you are right, tho, that as-is you can attach info to crafted items without having to use any of the tradeskill api. so there is a bit of utility here (otherwise you'd need another table of spellid to itemid) so maybe it's fine to keep. not sure if that's outweighed by the extra effort it takes to generate a secondary index for libpt inside a tradeskill mod that uses spellids internally...
Did a search for that item number/name (#34538 ) in both LibPeriodicTable & Mendeleev. Found it in a few locations; ones of interest:
In r283 & prior, "34538" did not appear in those two locations. Explaining why Mendeleev didn't report that incorrect tradeskill for that item. Seems to be confusing the item number with the spell number (which is "Create Item: Lionheart Blade").
Have seen a couple more incorrect tradeskills attached to items since your mining changes (through Mendeleev at least); the above is the last one seen. It may be more of a problem with Mendeleev incorrectly handling number incidents like the above. But wanted to post here anyway as post-r283 is the first time have been seeing these issues that can remember.