Junkie

Have you ever wanted an easy way to track the junk in your bag, and to be rid of it on demand? If so, then Junkie is for you. Take a look at the screenshots to see how it works.

To elaborate on what you're seeing there a little; Junkie basically seeks out the cheapest trash (grey coloured) item in your bag and then displays that for you (along with the size of the item's stack and the overall price, taking the stack into account).

Junkie presents a number of options to you for managing grey items:

Clicking Junkie adds the item to a temporary ignore list, this item won't be considered again until the temporary ignore list is cleared or until the current session ends (logout/reload). The way this works is sort of like an inverse shopping list, it checks off the current item and then goes to the next item (on the most worthless list).

Shift-clicking Junkie clears the aforementioned temporary ignore list, going back to the first (and cheapest) trash item it found.

Alt-clicking Junkie destroys the item that's currently being shown to you.

If you want to be able to have Junkie consider certain non-grey items as trash, you can do that. Junkie has an exceptions management mode, which can be toggled on and off by control-clicking.

When in exceptions mode, the click and shift-click functionality remains the same, but alt-clicking an item adds an exception tag to an item. Alt-clicking the same item again removes its exception tag. When an item has an exception tag, it'll be shown amidst the greys in Junkie's default mode.

Once you're done managing exceptions, you can return to Junkie's default mode again by control-clicking.

Just to bring everything together, I'll provide an example of my long-winded explication: Let's say that I want Junkie to be able to consider Shiny Fish Scales for destruction. First, I'd control-click Junkie to put it into exceptions management mode, then I'd click it as many times as needed until Shiny Fish Scales are shown, once they are I'd then do an alt-click to add an exception tag to the Shiny Fish Scales. At this point, I'd reset the temporary ignore list with a shift-click, then I could return to normal mode with a control-click.

This might sound complicated, but give it a go and see for yourself. I really disliked how complicated junk-management systems with long, long fiddly menus were, and this is nothing like that. It does a similar thing, but it's a completely new way to handle it, and once you've used it for a while I feel it becomes really intuitive. All it takes is getting used to the click combinations.

And if you only want to destroy greys, then don't worry, you won't have to fiddle with the exceptions management system at all! It's completely optional.

Things to Consider

If you're after a mod that can sell all grey items, then you might want to check out Haggler (linked below). Haggler also has Junkie interoperability built in, so it can read JunkieDB's list of exceptions. Normally, Haggler just sells all grey items to the vendor whenever its button is clicked at a vendor, but if Junkie is present then it will also sell items from the exceptions list too (this can be toggled on/off, of course).

Haggler: http://www.wowinterface.com/downloads/info10658-Haggler.html

What is DataBroker?

DataBroker is part of a system that's similar to FuBar and its plugins, what you have here is a plugin but you'll also need something to display the output of the plugin. You have many options for this, and I've listed a number of them below for your perusal, just pick the one that interests you the most.

If you want further information, that nice feller tekkub has put together some information on his wiki. And it's good information too, information that you should probably read if you're just getting into DataBroker plugins. (Not to mention that poor old tek puts these pages together and not many people seem to read them, so I thought I'd do my part to help remedy that situation. )

http://github.com/tekkub/libdatabroker-1-1/wikis

2.4.3-1.5

- Certain mods/conditions may overload Junkie, I have a system in place to prevent this but I didn't have any kind of debug report in place informing the user. This has been remedied.

2.4.3-1.4

- This is almost exactly the same as the preview version below, with the simple change that the list of saved item IDs is now per character, as there are some items which may be considered as trash to one character, but not another (e.g.: Shiny Fish Scales).
- For a full explanation of how Junkie has changed, see the new screenshots and check out the new description.

2.4.3-1.4-PREVIEW

- Please note, this is a preview release. This is not meant for public consumption. If you're an everyday mod user, I'd recommend using the 2.4.3-1.3 version, which is the last official release. If you like testing out new mods and frequently pull new code from SVNs though, you should be fine. But be warned, you're goin' in there with no documentation!
- Junkie has been rewritten, a number of fundamental things have changed and it's a different beast compared to what it was in 2.4.3-1.3. There's now an exceptions list and a system for handling it, and its default mode only considers greys for destruction. This took me a long while to get right, because I wanted to play with a number of prototypes in order to find the one that behaved the best, and didn't veer from my philosophy of lightweight mods (I hope this one hasn't, anyway).
- Footnote: Though this is a rewrite, I spent hours upon hours testing this mod, bugfixing, testing again, until finally I was satisfied that even the most cosmetic of errors was fixed. I bought numerous items for the sole purpose of destruction, and I've kept at it until fatigue began to set in. I can find no issues, so I believe it's safe for public consumption. The reason as to why this is a preview release instead of a proper release can be found in the comments, but it has nothing to do with bugs.

2.4.3-1.3

- Removed the auto-sell part and sectioned it off into its own mod (Haggler). It really was something that should've been considered as beyond the scope of Junkie, and I've been thinking about doing this for a while. If you liked the auto-sell functionality, snag Haggler (linked in the description).

2.4.3-1.2

- Removed the green-colour from the plugin name in the toc, it causes alphabetical-listing issues. I'll do this for my other plugins too, but not tonight... too late, must sleep.
- Fixed the Junkie/Analyst bug zedbg was having due to differing GetSellValue() implementations, that bug shouldn't rear its head again (I hope!).

2.4.3-1.1

- Quick change to fortify the last update. Last update for the night though, it's time for me to do things that aren't work, and then get some sleep!

2.4.3-1.0

- I've added a check to make absolutely sure that Junkie doesn't try to sell grey items which can't actually be sold.

2.4.3-0.9(b)

- Upload error. My fault, sorry! I forgot to move the new zip-file to my folder of zip-files before uploading it. I've got a lot on my mind at the moment, so hopefully it's an understandable oversight. Still, my apologies.

2.4.3-0.9

- There's now an option to show only greys when Junkie is in its default "DESTROY ALL ITEMS!" mode. Get it? Greys? Destroy All Humans pun? ...never mind. Anyway! Via a combination of some clickiness and key-holding, you can tell Junkie to ignore all items which aren't actually, technically trash in its considerations.
- I've redone the keybindings a bit to work with this new feature.

2.4.3-0.8

- I've implemented that GetSellValue thing that everyone seems to be crazy about these days! Thanks goes to Phanx for the tip.
- I've corrected the toc-version, I am scared and confused by toc-versions.

2.4.3-0.7

- Junkie now scans when the mail frame, trade frame, and auction house frames are closed. Thanks to Skylinee for the heads up.

Vrul author of DockingStation was able to help me here, for DockingStation (and any other LDB display add-on that requires plug-in's to assign a type attribute) anyone who wants to fix this add-on until the mod author does, simply edit the Junkie.lua as follows:

Originally posted by Vrul Replace the following code (starts on line 5):

Relax, Esha...breathe Your addons are fine when it comes to CPU usage, trust me, I'm running tests on my own addons and I do not see them doing something excessive. That being said, the dilemma of accuracy vs performance is an old one and sometimes difficult to answer. As for the OnUpdates, I completely agree that events are preferable, sometimes that method is not that accurate, but there are other ways if you are so inclined to use a timer (for example AceTimer-3.0 is a fine alternative, it's a "cheap" 14kb embed with no other dependencies and I don't view it as the "kitchen-sink"). Don't take this the wrong way, these are suggestions out of genuine interest, ultimately it's your own addon and you are very much entitled to tell us to go to hell ;p I respect your work (hell I use most of your Broker plugins ) and admire the fact that you strive to keep your addons small and efficient, however it is my opinion that sometimes authors tend to get a bit obsessive about stuff that at the end of the day may not have that much of an impact on the user.

Originally posted by VagrantEsha
[b]@break19
-snip-You can do that if you like, but after the above it just sounds like you're being arrogant and that you have something to prove rather than actually trying to help. So I'll continue with doing things my own way. Had you actually had a friendly demeanour and verified your assumptions before you brought them to me, I would've been willing to listen.
-snip-

Wow.. just.. wow..

I stated that it didn't -appear- to work, because I had -never- seen it actually fire the event, (yes, I use bankstack, and therefore -should- fire the event according to what you posted earlier..) and I grabbed at straws to determine why, missed the local declaration at the top of the file. I was _NOT_ being arrogant at all. I have nothing at all to prove. I am a 3rd rate coder, who's barely managed to bang out 3 addons, 2 of which are stupidly simple fubar plugins that do nothing but hook into existing addons' functions to replicate their minimap button stuff.

The third one has to deal with multiple events, firing several times a second, yet only needs to run a function once, but -must- run it at the end of said event spam, or it doesn't work right.. So, I used a timer, in exactly the way I mentioned to you earlier, and I thought I'd toss the idea out to you, to see if you thought it had merit.

Which you obviously didn't. No worries, I didn't mean to step on your toes, was just trying to help.

I tried the updated version with very similar effects, and *no error messages*. I Bankstacked a messy inv then alt-clicked the grey in my ldb display. I got the message that the grey was deleted (but it wasn't - and luckily notheing else was - bags purposely nearly empty), and the grey was still listed in the ldb.

I found a work-around though - I shift click the Junkie ldb and reset the ignore list before alt-clicking - that seems to re-orient Junkie after a Bankstack nuke.

I don't want to use an OnUpdate in a DataBroker plugin, with my recent projects I've been doing my best to make sure that they'll run on any machine. The idea behind DataBroker is to be lightweight and not to include the kitchen-sink and overload a user's system, I don't want to be the one who breaks a fine philosophy.

Adding an OnUpdate would cause the CPU usage of the mod to balloon, as profiling via GetFrameCPUUsage() would prove. An OnUpdate should only be used if there is no other method available and the mod is dependent on the OnUpdate to function. If there is an event that could be used instead then it should be, in the case of Junkie there are such events and the use of an OnUpdate is very wasteful.

1) you can do away with your "inform()" stuff, that doesn't appear to work anyway

Doesn't appear to?

Is there any reason you think this? Did you actually run any tests to confirm your suspicions, or are you just running with a gut feeling? I can't imagine that you'd openly have a go at someone's work on just a gut feeling without having run tests for yourself, would you?

Still... I'm going to wait for Caliban's results, if that's all the same.

2) You can do away with attempting to set a global called "scanning" which again isn't appearing to work, thus why #1 isnt either.

You're wrong.

First line of Junkie: local ldb_tip, scanning

See why? The scanning variable is not global. Make sure you actually understand what you're criticising before you criticise it, assumptions just makes an ass out of you and me. (Me because I have to correct you.)

the slight CPU cost is worth the reliability of the addon.

This is a flawed philosophy.

This states that "It's okay to do A because B justifies the means."

Of course I want to make sure that Junkie is reliable, but I'll do that in my own way. I have faith that those who use my mods will trust me to do that, and if they don't then that's their choice.

You cite a "slight" over-usage of CPU, this is something I could almost accompany by a nervous cough. Suffice it to say, it's not slight enough for me, and it definitely doesn't fit my personal design philosophy.

(Edit.)

My design philosophy: I recognise that not everyone has top of the range computers or can afford to and in many cases, because Warcraft will run on lower-end spec computers it means that not everyone will have the computing equivalent of a hotrod.

This means that whilst CPU-abuse might not be so noticeable on a modern machine, it might be on a machine that's three or more years old. What I propose is that mods shouldn't forsake people on older hardware, we should try and create mods which are as optimised as possible so those running older hardware can run more mods. Just because newer hardware exists is no reason to be lazy.

But, this -is- your addon, and if you disagree, so be it, I'll just do it myself to my copy.

Feel free, there's a reason I haven't compiled my mods and that's because I have a pretty open mindset with them. You're a different coder than I am and you have different approaches, and our standards are clearly on different tiers. So you're free to do whatever you like with it, you can even put the kitchen sink in it if it so pleases you.

In fact, give me a few days, and I may be able to spare the time to do it before this weekend and paste a snippet here for you to peruse.

You can do that if you like, but after the above it just sounds like you're being arrogant and that you have something to prove rather than actually trying to help. So I'll continue with doing things my own way. Had you actually had a friendly demeanour and verified your assumptions before you brought them to me, I would've been willing to listen.

As it is, what you've achieved is humourous at best. Global indeed...

(Edit.)

Oh and if you continue to bash my work in such an arrogant manner without even bothering to verify your assumptions, I will bring Cairenn in on this. Those who use my mods don't need to see this kind of thing, and I can see you'll try and cover your above blunders and argue this until the end. If you want to do that, you can do it here politely or you can be more insulting via PMs. But if you're rude here, it will be reported.

Originally posted by VagrantEsha
-snip-I was actually a bit hesitant to include that because it seems to fire for every merchant update, which I was none too sure about (as I said, I'm trying to stay away from spammy events), but if it solves the problem...
-snip-[/b]

Why not use 2 functions, one creates a specificly-named timer that lasts 4 seconds, when it expires, then call the actual update function.

This has a few benefits:
1) you can do away with your "inform()" stuff, that doesn't appear to work anyway
2) You can do away with attempting to set a global called "scanning" which again isn't appearing to work, thus why #1 isnt either.
3) You can then hook more reliable-yet-spammy events to the timer, and no matter how many times the events call the timer-related function, the cpu overhead will be minimal, as all it'd be doing is resetting the timer.

Yes, there is slightly (VERY slightly, infact) more CPU usage in using the 2 functions like I said, however, imo the slight CPU cost is worth the reliability of the addon.

But, this -is- your addon, and if you disagree, so be it, I'll just do it myself to my copy.

In fact, give me a few days, and I may be able to spare the time to do it before this weekend and paste a snippet here for you to peruse.

The OnClick method is a good idea, I'll definitely look into adding that. All I'd want it to be though is a simple check, so if the item link doesn't match the one being displayed it'll refuse to destroy the item, output an error, and update itself. That'll be in the next version, but really it shouldn't need to be something that's used commonly, it should be rare. That's why I'd like to get this issue sorted out and include that click method, that way I can foster confidence in the mod.

i'm definitely thinking it's the anti-spamming system though, so I'll be very interested in hearing what you find out. The only reason I did that is because a lot of mods design their BAG_UPDATE handlers against floods, because as far as proper behaviour of the game is concerned, BAG_UPDATE hsould never flood. The fact that I didn't put an error report in there though is idiotic at best, but it was arrogance that did it because in my own tests I hadn't seen any problems and therefore I figured there wouldn't be.

Mod developing is a humbling experience, I can say that. But in my opinion, that's a good thing. I'm certainly learning from all this.

@Nyte

Re: Name for a grey-selling plugin. Grey Market

Ah, I already made the plugin a while ago. Sorry Nyte. :/ You can check it out if you like, it's called Haggler. That'll auto-sell greys, sell greys on click, and even use Junkie's exceptions list to sell non-greys if the two are combined and the right options are supplied.

Grey Market is a clever name though, I'd actually consider renaming it but I think that everyone'll be used to the name it has, now.

Re: Itemized Deductions. I still use it, but only for destroying greys when my bags are full. I am considering Junkie, but ID has programmed me to shift-click to destroy (at my age, old habits are hard to break). But then again, ID is probably on its last legs (the last fix for Item Data Cache was a fan update).

I'm hoping that I'll have Junkie in a usable state for everyone soon enough. For the clicks though, you can change them around if you like! It really is just a simple matter of find & replace. Use notepad to open Junkie.lua and use find to find every instance of Alt and Shift (case intended), then swap them around. Lua is a simple thing.

Vagrant, been reading this thread and, since you asked for opinions...

Re: Name for a grey-selling plugin. Grey Market

Re: A Data Broker Plugin in the tooltip. I have absolutely no problem with it; in fact, since I use Titan Panel as my display-er, I kinda like the reminder that it's not a Titan plugin and it won't have a right-click menu.

Re: Itemized Deductions. I still use it, but only for destroying greys when my bags are full. I am considering Junkie, but ID has programmed me to shift-click to destroy (at my age, old habits are hard to break). But then again, ID is probably on its last legs (the last fix for Item Data Cache was a fan update).

The only reason I like Bankstack is because it is blazingly fast (I'm an old MR. Plow user). Is Sort comparable in speed?

As an off note I was wondereing if in the OnClick event for destroying the item that an insanity check be made against the item ID held by Junkie and the actual item in the bag slot. If it doesn't match up - don't destroy and trigger a new scan for the old item - display a message to the fact if a new low has been found - if not proceed with the destroy at the new spot. I think in this way you don't have to monitor the BAG_UDATE spam of sorters.

I put some protection in Junkie to deal with BAG_UPDATE duplicates, basically if a scan is going on, another can't be initiated. This has always worked fine with Sort (http://files.wowace.com/Sort/), which I consider to be a well-behaved sorting mod, but with BankStack (that nuke-sorts the bags in ways I don't entirely like) the anti-spamming protection is hit upon numerous times, meaning an old item is shown.

I'll just remove the anti-spamming protection and put up a new version, but this is really one of the reasons I could never stand BankStack, the amount of BAG_UPDATE events it causes to fire and how often it causes them to fire is unbearable. I might see if I can think another way around this, but since one or two to almost every item can be moved in a sort, there's little I can do to actually offer any kind of buffer.

What I might do instead is put up one version first where--if the anti-spamming protection is hit against--a warning is offered in the chat-frame. That way you can see for yourself whether BankStack is causing that to happen, and whether Sort really is better or not. If it happens only with BankStack and not Sort (I can't test this for myself at the moment) then I'll leave the mod as it is, but if it happens with only BankStack then you're probably better off using Sort.

(Updated.)

Caliban, could you check out the new version?

Test it out with Sort and BankStack, if you would.

A number of things might happen...

1.) You might get no errors.
2.) You might get an error with BankStack but not with Sort.
3.) You might get an error with BankStack and Sort.

If the case is 1, then I'm going to have to start looking elsewhere for the issue. If the case is 2, then I'm likely going to leave my mod as it is because it's working as intended (it just needed that warning in there). If the case is 3 then I'll have to remove the protection, but doing so could really ramp up memoory usage. Personally, I'm hoping it won't be 3.

I really like the recent changes and direction this addon has taken, however i have a very serious problem with it. Twice now when trying to delete junk to make space in my bags it has destroyed quest items. Once it was one of the heads from the Arathi quest "To Steal from Thieves' - no big deal I went and killed the named mob again. But just now it deleted a stack of Indurium flakes from a quest in the Badlands and it is quite a grind for those so you can understand how concerned I am. Just glad I am testing this on a 40 alt and not with epics in my bags.

The problem I think stems from the interaction between Junkie and Bankstack. I believe Junkie scans and locates it's low cost grey target an puts it in the tooltip. Sometime later I trigger a bankstack and items in my bags swap places. Junkie destroys whatever is in the place it targeted.

Is there any verification prior to destruction that the item still matches the location in the bags?