WowAce

i haven't touched the inventory stuff in a few revs so if it was working before, i'm not sure why it would stop working now.  what exactly do you mean you just updated the data via altoholic?

new rev up.  i've moved the auction purchase system into the blizzard auction frame.

there's now also a list of reagents deemed "interesting" to the current queue.  what this means is that based on the items queued, these reagents could be used in some combination to create those items.  however, not all of them will be used by the queue depending upon the recipe pathway.

for example, if you queued up a single glyph, the reagent list would contain the ink used to make the glyph, plus the pigments used to make the ink.  in addition, it would include the different herbs used to mill the pigment and possibly even the ink, pigments, and herbs used to make blackfallow ink (for a conversion).

the idea is that this list is a short-cut means to scan for different combinations of reagents to compare prices.  i think it needs an intermediate list as well that indicates the equivalency in some fashion (like if you buy this, you don't need to buy these).

the recipe sort is currently sorting by the blizzard index.  i need to add additional sorting schemes -- alpha sort, difficulty sort (tho maybe with the skillup% that's not needed), etc.

maybe my order of operation is faulty with my math and my limited testing didn't reveal the issue... try r103.

hmm.... i just fixed the sorting code.  or so i thought.

can you tell me if any of the other columns sort properly?  turn off the single-column display in lsw and see if value and cost sort are botched or if they sort properly...

btw, that "error" error message actually confirms a suspicion i had about the skill scanning process.  the line should be self:warning() instead of self:error(), but that's not the issue really.  it's only there as a warning message about the trade skill scan taking too long.  people have complained about the scan process hanging at times.  the only way that can happen is if one of the api functions is blocking while waiting for a result from the server instead of silently failing (like most of the server functions will do).  if these functions can block, then i have to wonder for how long them might hold things up.  if you have 600 recipes that might block for a moment, the scanning process could look like it's totally stalled.

i think i might implement a time-out escape or something.  if the scan is taking too long, then just bail out and try again in a few seconds.

is it in the flat layout?  if it's in grouped layout, it will sort the recipes in each group, then sort each group based on the first recipe in each group.

can you post a screen shot?

cherish, you can sort by profit using lsw and gw.  probably should view in the "flat" layout mode and then right click the "cost" header in the skill list to enable filtering by profitability ("hide unprofitable" i think is the menu option).

you can also change the lsw display to a single column (right click on the column itself, select display options->single column mode).  then you can left click the profit column header to sort by profit.

finally, there's also a work-in-progress "queue profitable" plugin that will queue up all items that fit a particular profit making scenario (min proft as a percent and/or straight gold amount, only items worth X or more gold, only items that cost less than X gold to make).  it's not fully baked, tho.

yeoman, lemme think about how i can make things work better.  just so i understand better, how long does gw hang after doing a single iteration of a glyph when you have something like 800 queued?  if the glyph itself takes 3 seconds to produce, then as long as the scan is under 3 seconds, you shouldn't really affect you too badly except for the final iteration.  but that would imply the length of time to craft is at most 27 seconds (24 + 3).

i could probably add some sort of throttle to the system so that it would wait a prescribed amount of time before executing a rescan.  if another event occurs that triggers the scan before the time has expired, it would reset the timer.  setting that to 5 seconds would mean that the queue would update only after it had been 5 seconds since the last attempted rescan.

what an ironic error.  i'll take a peek.  does a /reload fix it?

new rev *might* fix the unresponsive window problem.  i changed a bit of my code to avoid using a blizzard template for the scroll windows.  this means i'm being a bit more explicit with how i create frames.  might help, might not.  i also was able to remove a bit of frame level manhandling associated with this code.  could be that this was manhandling was part of the problem.  not sure.  anyway, hopefully it's fixed.  if not.  i'll try some other stuff.

also fixed a couple of lsw plugin things (value column recognizing bop and non-de items and sorting properly in single-column mode).