This project is abandoned and its default file will likely not work with the most recent version of World of Warcraft. Whether this project is out of date or its author has marked it as abandoned, this project is no longer maintained.
GnomeWorks TradeSkill Frame -
a complete replacement for the blizzard trade skill frame.
yeah, that would be a problem. that solution might work kind of, but what really needs to occur is some kind of delay to the initialization until the UnitGUID("player") data is reliably available. i *thought* i had waited long enough with gw, but perhaps not. if "currentGUID" i nil, then the scanning code could fire unnecessarily any time this occurs which is not optimal.
I had a problem where UnitGUID('player') was apparently returning nil during login. This change seemed to make things work for me:
diff --git c/GnomeWorks.lua w/GnomeWorks.luaindex 3363a72..6b7c553 100644--- c/GnomeWorks.lua+++ w/GnomeWorks.lua@@ -1109,7 +1109,7 @@ do
if GnomeWorksDB.serverData and GnomeWorksDB.serverData[factionServer] and GnomeWorksDB.serverData[factionServer].guidList then
local playerName, otherGUID = next(GnomeWorksDB.serverData[factionServer].guidList)
- local currentGUID = string.gsub(UnitGUID("player"),"0x0+", "")+ local currentGUID = UnitGUID("player") and string.gsub(UnitGUID("player"),"0x0+", "") or nil
if otherGUID == currentGUID then
playerName, otherGUID = next(GnomeWorksDB.serverData[factionServer].guidList, playerName)
Re: the other changed I'd been thinking about; got busy with work and wow stuff got paged out. I'm not ignoring your PMs, just trying to gather my thoughts to properly answer.
if you get an error, try doing a "/reload" from the chat window. i suspect it may be an issue with client data not being ready on a fresh load vs a reload of the ui.
edit: okay, this goes a bit deeper. this will need a patch i think.
in the meantime, if you removed your saved variables file, gw should work. the problem is an unitialized table that trips things up when the rest of the data is available.
With the newest update, GnomeWorks no longer even comes up. I get the following error through BugGrabber:
5x GnomeWorks\GnomeWorks-r196.lua:1111: bad argument #1 to "next" (table expected, got nil)
<in C code>
GnomeWorks\GnomeWorks-r196.lua:1111: in function "initFunction"
GnomeWorks-r196\Libs\LIbTradeSkillScan.lua:933: in function "Register"
GnomeWorks\GnomeWorks-r196.lua:1140: in function <GnomeWorks\GnomeWorks.lua:1138>
<string>:"safecall Dispatcher[2]":4: in function <string>:"safecall Dispatcher[2]":4
<in C code>
<string>:"safecall Dispatcher[2]":13: in function "?"
libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire"
AdiBags-v1.5.4\libs\AceEvent-3.0\AceEvent-3.0-3.lua:120: in function <AdiBags\libs\AceEvent-3.0\AceEvent-3.0.lua:119>
Had a look at the code and am trying to keep up to date, which isnt easy when changes are happening daily. Hughescr and I discussed changing the base code as he and I had an idea to trim it down. i think we should discuss this further as I think this might solve some of our problems.
just added the live scanning code. because of the way the scanner works, you must scan on a valid guid from somebody on your server in your faction. the only reliable results will come from somebody not currently logged in (or somebody who has no trade skills). so what i've done is record guids of players per server-faction. to get skill data updated, you must log in with one toon, then log in with another on the same faction/server. once it's updated, it'll be fine for all players.
fingers crossed that this will work going forward...
i was fortunate enough to have a user donate me a copy of mop, so i'll be attacking cooking next.
there is a donate button on the top right of the page.
they really did some weird stuff with cooking. gw is based on the tradeskill linking mechanism. the new cooking specialties don't abide by that system, so gw won't be able to support cooking fully. i'm going to see if i can get it working for the current toon, but recording different toon's way's probably won't work.
I agree with lexusnexus, thanks everyone for their hard work on this. Any word on the cooking?
Also though, I'd like to know if there's a place setup where I can donate. I can't speak for anyone else, but I'd gladly give a little something for the work put in.
do you need to have MoP to see MoP recipes? cuz i don't have the expansion and even "all recipes" links fail to show any of the "way" recipes... i'm kind of at a loss there.
Many thanks for all the effort on this Mod. Its nice to see so many people take an interest in GW! I know you all are hard at work on updating it for MoP but I would like to add a special request that cooking be addressed soon. Blizz has really made a mess out of it and it is very hard to figure out what cooking way needs to be leveled. So far the only way to tell is with the std UI for professions. Blah.
yeah, the simple cheat of making a full bitmap by literally toggling everything on blindly no longer works in 5.0. this has complicated the level scraping code and also had the side effect of making a few trade skills react poorly when attempting to view all recipes (it will continuously look for more data).
i've fixed the all recipes code to use discovered spellid bitmap locations so it will function better. i will attempt to put the level scraping code into gw directly since it uses the same concept.
yeah, one reason i dumped libpt is that libpt still uses the inane negative spellid/itemid method to index tradeskills. also, wowhead data isn't always accurate. i actually was the person who put the tradskill level data into libpt originally, but then it sort of migrated away from my original formatting.
it seems like the "all recipes" links don't function now in 5.0. at least the simplistic method of sending complete bitmaps. i suspect it might be related to unreleased recipes never returning proper data. i'll have to modify how that works and use a more precise lists of recipes.
Finally got a chance to look at the LibPT stuff... definately wrong... it's indexed by recipe result id, but being looked up by recipe spell id.
Have a hacky fix at the moment, i need to do more testing before deciding if it's worth using or removing the LibPT code completely.
I opened jc earlier today as an "all recipes" list filtered as a category view and noticed that recipes seemed to be getting migrated to the first category over time.
the skillup data in gw is actually NOT from wowhead, it's scanned in game using a separate mod. i'm cleaning up that mod and will either incorporate it directly into gw or upload it as a utility mod. kinda depends on how clean i can make it. it's a bit finicky so i've kinda not considered it releasable and certainly not as a built-in for gw.
but perhaps with the caveats of its abilities known, it'll be worth including.
i'm finding jewelcrafting, tailoring, and engineering are not behaving. do the "all recipes" links in gw work for these tradeskills for everybody?
found this as well, i've got debug code to show which ones need to be fixed when i visit the trainers (values were originally scrapped from wowhead, but haven't been updated for a while). there's also a few missing recipes (even with LibPT, values also scrapped from wowhead and reasonably up-to-date). oh, and wowhead is behind on there data as well (eg heavy linen bandage is learnable at 40, wowhead still says 50 as of 12hrs ago)...
just checked again, wowhead now has that right. checking if the latest update to PT has them... it does. also has values for Heavy Windwool Bandage but that's not showing in the progress bar (hit 600 first aid a couple of hours ago, so will check on a lower level toon after some sleep :-) )
Those strange first values are being pulled by the r191 PT code as GnomeWorks doesn't save that value, but does temporarily store it after visiting a trainer. I was considering just using the PT values as they should be more up to date, guess I had better check that it's values are being interpreted properly first ;-)
r194 appears to have fixed most of the skillup colours for lower level recipes again, but I've found a few that show as red.
Looking at the progress bar (which shows when recipes turn orange/yellow/green/grey), in each case the first value (which should be the level at which the recipe can be learned?) is too high.
Found a few so far, but there are probably others scattered about (I only spotted these as I have alts with skills at the appropriate levels)
Enchant Weapon - Lesser Striking : 350/165/185/205 (learned at 140)
Silk Bandage : 225/150/180/210 (should be 150/180/195/210 according to Wowhead)
Heavy Silk Bandage : 230/180/210/240 (should be 180/210/225/240 ")
Earth Shatter : 375/0/150/300 (looks like it should be 300/300/300/300)
Fire Shatter : same as Earth Shatter
Anti-Venom : 245/80/115/150 (learned at 80)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
@hughescr
yeah, that would be a problem. that solution might work kind of, but what really needs to occur is some kind of delay to the initialization until the UnitGUID("player") data is reliably available. i *thought* i had waited long enough with gw, but perhaps not. if "currentGUID" i nil, then the scanning code could fire unnecessarily any time this occurs which is not optimal.
@lilsparky
I had a problem where UnitGUID('player') was apparently returning nil during login. This change seemed to make things work for me:
Re: the other changed I'd been thinking about; got busy with work and wow stuff got paged out. I'm not ignoring your PMs, just trying to gather my thoughts to properly answer.
if you get an error, try doing a "/reload" from the chat window. i suspect it may be an issue with client data not being ready on a fresh load vs a reload of the ui.
edit: okay, this goes a bit deeper. this will need a patch i think.
in the meantime, if you removed your saved variables file, gw should work. the problem is an unitialized table that trips things up when the rest of the data is available.
@lebanoncyberspace
same
With the newest update, GnomeWorks no longer even comes up. I get the following error through BugGrabber:
5x GnomeWorks\GnomeWorks-r196.lua:1111: bad argument #1 to "next" (table expected, got nil) <in C code> GnomeWorks\GnomeWorks-r196.lua:1111: in function "initFunction" GnomeWorks-r196\Libs\LIbTradeSkillScan.lua:933: in function "Register" GnomeWorks\GnomeWorks-r196.lua:1140: in function <GnomeWorks\GnomeWorks.lua:1138> <string>:"safecall Dispatcher[2]":4: in function <string>:"safecall Dispatcher[2]":4 <in C code> <string>:"safecall Dispatcher[2]":13: in function "?" libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire" AdiBags-v1.5.4\libs\AceEvent-3.0\AceEvent-3.0-3.lua:120: in function <AdiBags\libs\AceEvent-3.0\AceEvent-3.0.lua:119>
Locals: nil
Had a look at the code and am trying to keep up to date, which isnt easy when changes are happening daily. Hughescr and I discussed changing the base code as he and I had an idea to trim it down. i think we should discuss this further as I think this might solve some of our problems.
just added the live scanning code. because of the way the scanner works, you must scan on a valid guid from somebody on your server in your faction. the only reliable results will come from somebody not currently logged in (or somebody who has no trade skills). so what i've done is record guids of players per server-faction. to get skill data updated, you must log in with one toon, then log in with another on the same faction/server. once it's updated, it'll be fine for all players.
fingers crossed that this will work going forward...
i was fortunate enough to have a user donate me a copy of mop, so i'll be attacking cooking next.
there is a donate button on the top right of the page.
they really did some weird stuff with cooking. gw is based on the tradeskill linking mechanism. the new cooking specialties don't abide by that system, so gw won't be able to support cooking fully. i'm going to see if i can get it working for the current toon, but recording different toon's way's probably won't work.
I agree with lexusnexus, thanks everyone for their hard work on this. Any word on the cooking?
Also though, I'd like to know if there's a place setup where I can donate. I can't speak for anyone else, but I'd gladly give a little something for the work put in.
do you need to have MoP to see MoP recipes? cuz i don't have the expansion and even "all recipes" links fail to show any of the "way" recipes... i'm kind of at a loss there.
Many thanks for all the effort on this Mod. Its nice to see so many people take an interest in GW! I know you all are hard at work on updating it for MoP but I would like to add a special request that cooking be addressed soon. Blizz has really made a mess out of it and it is very hard to figure out what cooking way needs to be leveled. So far the only way to tell is with the std UI for professions. Blah.
yeah, the simple cheat of making a full bitmap by literally toggling everything on blindly no longer works in 5.0. this has complicated the level scraping code and also had the side effect of making a few trade skills react poorly when attempting to view all recipes (it will continuously look for more data).
i've fixed the all recipes code to use discovered spellid bitmap locations so it will function better. i will attempt to put the level scraping code into gw directly since it uses the same concept.
yeah, one reason i dumped libpt is that libpt still uses the inane negative spellid/itemid method to index tradeskills. also, wowhead data isn't always accurate. i actually was the person who put the tradskill level data into libpt originally, but then it sort of migrated away from my original formatting.
it seems like the "all recipes" links don't function now in 5.0. at least the simplistic method of sending complete bitmaps. i suspect it might be related to unreleased recipes never returning proper data. i'll have to modify how that works and use a more precise lists of recipes.
Finally got a chance to look at the LibPT stuff... definately wrong... it's indexed by recipe result id, but being looked up by recipe spell id. Have a hacky fix at the moment, i need to do more testing before deciding if it's worth using or removing the LibPT code completely.
I opened jc earlier today as an "all recipes" list filtered as a category view and noticed that recipes seemed to be getting migrated to the first category over time.
is anybody finding groups to be inaccurate? this might just be for the jc/tailor/engineer profession's "all recipes" list...
cool, i won't remove them then, i'll just make sure the backup data from LibPT is being read properly ;-)
the skillup data in gw is actually NOT from wowhead, it's scanned in game using a separate mod. i'm cleaning up that mod and will either incorporate it directly into gw or upload it as a utility mod. kinda depends on how clean i can make it. it's a bit finicky so i've kinda not considered it releasable and certainly not as a built-in for gw.
but perhaps with the caveats of its abilities known, it'll be worth including.
i'm finding jewelcrafting, tailoring, and engineering are not behaving. do the "all recipes" links in gw work for these tradeskills for everybody?
@brykrys
found this as well, i've got debug code to show which ones need to be fixed when i visit the trainers (values were originally scrapped from wowhead, but haven't been updated for a while). there's also a few missing recipes (even with LibPT, values also scrapped from wowhead and reasonably up-to-date). oh, and wowhead is behind on there data as well (eg heavy linen bandage is learnable at 40, wowhead still says 50 as of 12hrs ago)...
just checked again, wowhead now has that right. checking if the latest update to PT has them... it does. also has values for Heavy Windwool Bandage but that's not showing in the progress bar (hit 600 first aid a couple of hours ago, so will check on a lower level toon after some sleep :-) )
Those strange first values are being pulled by the r191 PT code as GnomeWorks doesn't save that value, but does temporarily store it after visiting a trainer. I was considering just using the PT values as they should be more up to date, guess I had better check that it's values are being interpreted properly first ;-)
And I'm babbling... definately time for sleep :-P
r194 appears to have fixed most of the skillup colours for lower level recipes again, but I've found a few that show as red.
Looking at the progress bar (which shows when recipes turn orange/yellow/green/grey), in each case the first value (which should be the level at which the recipe can be learned?) is too high.
Found a few so far, but there are probably others scattered about (I only spotted these as I have alts with skills at the appropriate levels)