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.
2x GnomeWorks-106\Inventory.lua:49: attempt to index local 'invData' (a nil value)
(tail call): ?:
<in C code>: ?
<string>:"safecall Dispatcher[2]":9: in function <[string "safecall Dispatcher[2]"]:5>
(tail call): ?:
AceTimer-3.0-5 (DataStore):164: in function <...\AddOns\DataStore\libs\AceTimer-3.0\AceTimer-3.0.lua:138>
glave, that feature still exists. what i need to do is add some smarts to have the vendor conversions be considered "uncraftable" if you're not at the appropriate vendor so they'll be skipped. i'm assuming the problem is that you're not at the vendor but you have the mats for the conversion.
I'm trying to figure out how to re-enable a feature that once existed, but seems to no longer do so.
A few months ago if I queued a bunch of glyphs, if I didn't have all of the supplies, I could still press the process button, and it would process the next thing it possibly could with what I had on hand. Now it seem once I get to an ink conversion, it gets stuck there.
the first cycle is the bag scanning. i've added some code in the latest rev to automatically throttle to 5 seconds during a tradeskill iteration. so if it's crafting 5 of something, it will throttle down during those 5 crafts. also, i've added a (potential) time saver by checking to see what's changed and only recalculating items affected by the change. hopefully, things don't slip thru the cracks.
gw106, lsw108b
8 glyphs took 30.6 sec, instead of 24. Improvement, but still freezing after every glyph made. So, it's still scanning after every glyph made.
I am not getting any errors, but the GnomeWorks AH window is 'combining' with other AH windows in Auctioneer, so when GW is scanning the AH if you are looking at another Auctioneer windows, say the Appraiser window, you can see the GnomeWorks window writing over each other.
Get the same error as yunohu, and 'Create' seems broken. I put in a value for a valid create, and it just doesn't respond. If I queue the exact same thing, it will queue and work from the queue command. Alchemy, if that makes any difference.
since todays update... not sure how to troubleshoot.. total user here.. :-X
edit: xandora and i are having a similar issue i guess, it just clicked, when i had gnomeworks on, and was getting the error, i couldnt use the V key to turn on nameplates...
subxero, that lua error is probably short-circuiting the update function. but i'll make sure it's still updating things properly. i'm trying to avoid over-processing, but maybe i'm not processing something i need to process.
yeoman, i think you're seeing the same problem as subxero. the queue isn't refreshing properly on inventory changes. likely due to an error, but maybe it's a logic error, too.
anyway, try the latest version and see if any better.
Tried not to craft, but just move stack of ink from one bag to another with character autoruning. Hard to measure, but 106 feels a lot faster. It's like 1 sec freeze with 105 and 0.3 sec freeze with 106. Will try to craft later evening with my home PC.
edit: tried to get from mail some inks and parchments from vendor, and queued glyphs don't turn white even after half a minute waiting. Then i close inscription profession, reopen it (queue windows stays open), and now some glyphs turn white and craftable in queue window. Not tried to push Process button, when glyphs was red. But this is not an issue for me.
Now the queue list update wrong, like you have 3 items at bank .. press on first once and remain all items at queue, press the second and the first disappear, press the third and disappear the second but remain the last.
At action house tab can be a queue/char selection ? because my auctioneer toon its not the "crafter", currently I still need open GW to select character/profession to full the queue selection scan.
yeoman, there are two processing cycles i'm concerned about in your case.
the first cycle is the bag scanning. i've added some code in the latest rev to automatically throttle to 5 seconds during a tradeskill iteration. so if it's crafting 5 of something, it will throttle down during those 5 crafts. also, i've added a (potential) time saver by checking to see what's changed and only recalculating items affected by the change. hopefully, things don't slip thru the cracks.
the second processing cycle that could be eating time is the dynamic queue process. after the inventory has been scanned, the queue updates itself to see what needs to happen still. most of my work to optimize has been spent in the inventory side of things, but it's possible this process might be taking a while as well. i have some ideas on how to speed things up. a simple approach would be to record the items that have an impact for each recipe tree. if none of those items have been affected, then don't bother rescanning. that would probably make things go much, much faster without being too crazy in terms of memory usage.
anyway, try the latest version and see if any better.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
My enchanting lvl is 469. Not yet learned 470 lvl enchants, but they already shows up on my troll as craftable.
http://img27.imageshack.us/img27/3735/wowscrnshot010911025050.jpg
lilsparky- Yea that's exactly the situation I believe. I'm not at the vendor, but I do have Blackfallow inks in my inventory.
getting the following error
2x GnomeWorks-106\Inventory.lua:49: attempt to index local 'invData' (a nil value)
(tail call): ?:
<in C code>: ?
<string>:"safecall Dispatcher[2]":9: in function <[string "safecall Dispatcher[2]"]:5>
(tail call): ?:
AceTimer-3.0-5 (DataStore):164: in function <...\AddOns\DataStore\libs\AceTimer-3.0\AceTimer-3.0.lua:138>
-looks like i'm going to busy today.
glave, that feature still exists. what i need to do is add some smarts to have the vendor conversions be considered "uncraftable" if you're not at the appropriate vendor so they'll be skipped. i'm assuming the problem is that you're not at the vendor but you have the mats for the conversion.
I'm trying to figure out how to re-enable a feature that once existed, but seems to no longer do so.
A few months ago if I queued a bunch of glyphs, if I didn't have all of the supplies, I could still press the process button, and it would process the next thing it possibly could with what I had on hand. Now it seem once I get to an ink conversion, it gets stuck there.
Was this feature completely removed?
gw106, lsw108b
8 glyphs took 30.6 sec, instead of 24. Improvement, but still freezing after every glyph made. So, it's still scanning after every glyph made.
If you are using gnomeworks together with Auctioneers Compact AH Frame layout, the layout pretty much is messed up ;)
Funny. Logged in. Cast water shield, then cast Earthliving Weapon, and with that weapon enchant cast popped out error (i did not open my LW at all):
EDIT:
same error when i was logged in another time, and did Solve in arheology.
I am not getting any errors, but the GnomeWorks AH window is 'combining' with other AH windows in Auctioneer, so when GW is scanning the AH if you are looking at another Auctioneer windows, say the Appraiser window, you can see the GnomeWorks window writing over each other.
Still unable to change recipes with 106.
Get the same error as yunohu, and 'Create' seems broken. I put in a value for a valid create, and it just doesn't respond. If I queue the exact same thing, it will queue and work from the queue command. Alchemy, if that makes any difference.
with 106 Date: 2011-01-07 19:22:20 ID: 1 Error occured in: Global Count: 1 Message: ..\AddOns\GnomeWorks\Inventory.lua line 49: attempt to index local 'invData' (a nil value) Debug: (tail call): ? GnomeWorks\Inventory.lua:49: GnomeWorks\Inventory.lua:46 (tail call): ? [C]: ? [string "safecall Dispatcher[2]"]:9: [string "safecall Dispatcher[2]"]:5 (tail call): ? ...face\AddOns\Archy\Libs\AceTimer-3.0\AceTimer-3.0.lua:164: ...face\AddOns\Archy\Libs\AceTimer-3.0\AceTimer-3.0.lua:138 AddOns: Swatter, v3.2.3 (<%codename%>) AckisRecipeList, v2.1.0-6-g34f5354 ACP, v3.3.13 Archy, vv1.7b7 Atlas, v1.18.1 AtlasBattlegrounds, v1.18.1 AtlasDungeonLocs, v1.18.1 AtlasOutdoorRaids, v1.18.1 AtlasTransportation, v1.18.1 AtlasLoot, vv6.01.01 AtlasQuest, v4.6.0a AucAdvanced, v5.10.5043 (CrouchingKangaroo) AucFilterBasic, v5.10.5043 (CrouchingKangaroo) AucFilterOutlier, v5.10.5043.2531 AucMatchUndercut, v5.10.5043.2531 AucStatHistogram, v5.10.5043 (CrouchingKangaroo) AucStatiLevel, v5.10.5043 (CrouchingKangaroo) AucStatPurchased, v5.10.5043 (CrouchingKangaroo) AucStatSales, v5.10.5043.2842 AucStatSimple, v5.10.5043 (CrouchingKangaroo) AucStatStdDev, v5.10.5043 (CrouchingKangaroo) AucStatWOWEcon, v5.10.5043.2530 AucUtilAHWindowControl, v5.10.5043.3311 AucUtilAppraiser, v5.10.5043.2530 AucUtilAskPrice, v5.10.5043.3175 AucUtilAutoMagic, v5.10.5043.3142 AucUtilCompactUI, v5.10.5043.2530 AucUtilEasyBuyout, v5.10.5043.3583 AucUtilFixAH, v5.10.5043 (CrouchingKangaroo) AucUtilGlypher, v5.10.5043.2545 AucUtilItemSuggest, v5.10.5043.3108 AucUtilPriceLevel, v5.10.5043.2545 AucUtilScanButton, v5.10.5043.2530 AucUtilScanFinish, v5.10.5043.2530 AucUtilScanProgress, v5.10.5043.2530 AucUtilScanStart, v5.10.5043.4784 AucUtilSearchUI, v5.10.5043.3655 AucUtilSimpleAuction, v5.10.5043.4546 AucUtilVendMarkup, v5.10.5043.2530 Babylonian, v5.1.DEV.130 BankItems, v40000 BeanCounter, v5.10.5043 (CrouchingKangaroo) Configator, v5.1.DEV.282 DBMBurningCrusade, v DBMCore, v DebugLib, v5.1.DEV.275 Enchantrix, v5.10.5043 (CrouchingKangaroo) EnchantrixBarker, v5.10.5043 (CrouchingKangaroo) FBBroker, v1.6b (FB 0.9.9e2) FBMergeDatabase, v0.9.9e2 FBOutfitDisplayFrame, v0.9.9b FBTitan, v0.9.9 FBTrackingFrame, v0.9.9b FishingBuddy, v0.9.9e3 Flightmap, v4.0.3-beta FloTotemBar, v Gatherer, v3.2.3 GathererHUD, v3.2.3 GathererDBWowhead, v1.0.2010-12-19 GearScore, v4.1.02 GFWFeedOMatic, v4.0.4 Glamour, v1.2.0 GnomeWorks, v106 Informant, v5.10.5043 (CrouchingKangaroo) LightHeaded, v326 LilSparkysWorkshop, v LinkWrangler, v1.83 LinkWranglerAuctioneer, v1.51 MetaMap, v4.0.5 MetaMapWKB, v MobInfo2, vv3.83 MovablePetBar, v4.0.2 Omen, v3.1.0 Overachiever, v0.60 OverachieverTrade, v0.60 QuestGuru, v2.2.3 QuestGuruTracker, v1.5.6 QuestHistory, v4.0.1d Recount, v Reforgenator, v1.3.1 SlideBar, v3.2.3 (<%codename%>) Stubby, v5.10.5043 (CrouchingKangaroo) Titan, v5.0.1.40000 - Revision 485 TitanBag, v5.0.1.40000 TitanClock, v5.0.1.40000 TitanCurrTrack, v1.2.1 TitanGold, v5.0.1.40000 TitanGuild, v3.6k TitanItemDed, v4.0.13 TitanLootType, v5.0.1.40000 TitanMail, v4.04 TitanPerformance, v5.0.1.40000 TitanRecZone, v3.0.9 TitanRepair, v5.0.1.40000 TitanReputation, v3.6.8 TitanVolume, v5.0.1.40000 TitanXP, v5.0.1.40000 TomTom, vv40000-1.0.9 BlizRuntimeLib_enUS v4.0.3.40000 <us> (ck=b95)
since todays update... not sure how to troubleshoot.. total user here.. :-X edit: xandora and i are having a similar issue i guess, it just clicked, when i had gnomeworks on, and was getting the error, i couldnt use the V key to turn on nameplates...
I got the queue refresh problem too. For example it wont refresh if i buy parchments. No errors.
xandora, did you get any errors?
subxero, that lua error is probably short-circuiting the update function. but i'll make sure it's still updating things properly. i'm trying to avoid over-processing, but maybe i'm not processing something i need to process.
yeoman, i think you're seeing the same problem as subxero. the queue isn't refreshing properly on inventory changes. likely due to an error, but maybe it's a logic error, too.
Tried not to craft, but just move stack of ink from one bag to another with character autoruning. Hard to measure, but 106 feels a lot faster. It's like 1 sec freeze with 105 and 0.3 sec freeze with 106. Will try to craft later evening with my home PC.
edit: tried to get from mail some inks and parchments from vendor, and queued glyphs don't turn white even after half a minute waiting. Then i close inscription profession, reopen it (queue windows stays open), and now some glyphs turn white and craftable in queue window. Not tried to push Process button, when glyphs was red. But this is not an issue for me.
hey Guys,m
just gotta say r106 is working a treat for me and my Glyphs. Am using LSW latest and also KTQ and all is working just fine.
thanks LS.
cya
Bill
so far anyway...:-)
Now the queue list update wrong, like you have 3 items at bank .. press on first once and remain all items at queue, press the second and the first disappear, press the third and disappear the second but remain the last.
At action house tab can be a queue/char selection ? because my auctioneer toon its not the "crafter", currently I still need open GW to select character/profession to full the queue selection scan.
latest release broke keyboard use for anything but typing into the search box in Gnomeworks.
yeoman, there are two processing cycles i'm concerned about in your case.
the first cycle is the bag scanning. i've added some code in the latest rev to automatically throttle to 5 seconds during a tradeskill iteration. so if it's crafting 5 of something, it will throttle down during those 5 crafts. also, i've added a (potential) time saver by checking to see what's changed and only recalculating items affected by the change. hopefully, things don't slip thru the cracks.
the second processing cycle that could be eating time is the dynamic queue process. after the inventory has been scanned, the queue updates itself to see what needs to happen still. most of my work to optimize has been spent in the inventory side of things, but it's possible this process might be taking a while as well. i have some ideas on how to speed things up. a simple approach would be to record the items that have an impact for each recipe tree. if none of those items have been affected, then don't bother rescanning. that would probably make things go much, much faster without being too crazy in terms of memory usage.
anyway, try the latest version and see if any better.