Junkie

I'll look into that, thanks. Currently I'm just using ItemPrice-1.1, but I'm not at all adverse to making other people's lives easier by including other methods.

It isn't?

...

Gods damn it.

I'll just revert it to 20400 then, I don't know if there's been a more recent toc version than that.

Thanks for letting me know, I appreciate that. I'll have a new wave of plugins coming out this morning anyway, so I'll correct the tocs. I think the correct number should be 20400 then, but I'll take a look at some of the mods in my Addons folder just to be sure.

Perfectly fair poinnt, but...

With my descriptions, to try and avoid confusion on the end-user end of things, I've only provided launchers for the type of plugin. For example, ButtonBin is great but it's designed more for handling launchers. Things that are more about being a button rather than having a text display.

I have both Fortress and ButtonBin, the text-display plugins I have Fortress handling, the clickable buttons and the plugins with no text displays I have ButtonBin handling. So ButtonBin I have listed in the descriptions of plugins like MadHatter and Opticon.

I'm interested in your opinion though, should I remove the distinction between the two and simply list all the mods that can handle DataBroker plugins for each plugin?

Edit: I finally got to test my implementation of GetSellValue in game, I've supplied it below so it can be previewed before I upload the latest Junkie (which I'll be doing soonish). I've been trying to minimise the use of variable-creation and heavy function calls, but whether what I've been doing there is good or bad... I cannot say. I'd appreciate an opinion.

The example below is in its own lua file (GetSellValue.lua) and I call the GetSellValue() function in my plugin now, as opposed to the GetPrice functionality of the ItemPrice library directly.

I've also got the original GetSellValue hook in a table, I'm not sure whether this is the right thing to do or not but I don't feel entirely safe unless I house hooks within a table. But perhaps I'm being old-fashioned about that? Iono.

Anyway, here's the preview code:

http://www.pastebin.ca/1186163

Okay, I'll change the descriptions of my DataBroker plugins to include all possible options. I might not have time to do so right away as my roomie and I are about to do a session of the actual game (Le Gasp!), but as soon as I have a moment, it'll happen. And I'll list Fortress and ButtonBin at the top, because I like ButtonBin too.

I had a long explanation for my reasons for not doing this over on the WoWAce thread for this mod, you can read that if you like.

The long and short of it was though that Junkie isn't just a cut-and-dry replacement for GarbageFu, it was a re-envisioning. I always felt that GarbageFu was way too heavy for just a display plugin, and I wanted something lightweight that really fit the ideology of a plugin.

If I had permanent lists in there, it would completely destroy the vision and the direction of Junkie, and make it just another rehash. So I don't want to go in that direction. Not to mention that I'd have to add a database to handle all the items you'd want to ignore/keep, that database would quickly get huge, it'd be annoying to manage, I'd have to include another library to allow me to have menus for managing the list, I'd have to almost doublet he size of the plugin to accomodate the management of the permanent list... so, as you can see, the result would be something that's very not-Junkie.

This however I can do!

I'll look into the best implementation of this once I'm done gaming today, but I can guarantee you that that'll get in there in some form or another.

Okay, I need opinions.

There have been commenters on my DataBroker plugins who've been invaluable when it comes to generally improving the plugins and simply making them better, their opinions have really counted towards that and I consider the input of these people important. Specifically; Phanx, Beoko, OttoDeFe, Nyte, and Fred. (My apologises if I've forgotten anyone.)

The thing is, as you've no doubt seen from the description pages and the latest updates of my plugins that there are areas where I'm willing to listen and agree to something, and others where I've put my foot down. One area where I did put my foot down is in regards to building customised auto-sell lists, that's never going to exist in Junkie because it already exists in other mods which are pretty damned good in and of themselves.

This got me to thinking though; about the element of Junkie where trash is sold to the vendor. I've been pondering its future within the mod and I'm not so sure of its worthiness as a part of Junkie. There are other mods that do it, but they don't do everything I want out of a junk-seller, or they do too much. If tekJunkSeller reported on the sale of each item (and its price), and the overall cash one got from selling junk, then I'd just rip out the functionality and tell everyone to use tekJunkSeller instead. It doesn't though, and that's why I added similar functionality to Junkie, but my own spin on it.

So here's what it comes down to: I'm thinking of moving the grey trash-selling part of Junkie out of the plugin, into its own mod. From there I could build on it and add an idea into it I've been thinking about (I'll get to that later), and I could concentrate on it as its own project. I might even make this new mod a DataBroker plugin aswell, I probably will with some kind of bin icon that can be clicked to sell off junk.

As to the new features I could work in; I could possibly add a new hard-coded list of grey items to the new trash-seller which wouldn't be sold, things like the Darkmoon Faire hand-ins. I could then have a primary click system to sell all greys, or a secondary click system that would avoid selling certain types of valuable greys. If someone wanted to customise that then, they could edit the list (which I'd likely put in its own file).

So these are my thoughts, and I want opinions. I'd like to hear your opinions on whether I should section this out from Junkie or not at all, and if I do what I should do with it, should it be a DataBroker plugin, and should it have a hard-coded list of valuable greys? Moreover, if I did add such a list, could anyone point me to a list of such valuable greys?

I will take all thoughts into consideration, but after the way I put my foot down and said no to customised lists, I'm beginning to think that really the junk-selling bit should be beyond Junkie's scope too.

So... thoughts! If you would?

This is exactly what I was afraid of, it'd be knocking about in my head for a while now that I was falling prey to feature creep, and since most people will likely--as you do--have a mod for fobbing off junk to a vendor, it's really not something that Junkie should handle.

I'll give it some thought as to the best way to separate it, then I'll get it out of there. The hardest part will probably be coming up with a name for the new selling-of-greys mod.

Now this is valuable information, and frankly a real weight off my mind. I'd always thought that greys having any value was a myth, but the other day I was chatting with my roomie and he mentioned the Darkmoon Faire stuff, and after that I got to wondering and began to doubt whether there were valuable greys. I guess there aren't, so thankfully this is something I don't need to cover. I appreciate you letting me know about this, because otherwise I probably would've spent the next few days trying to devise an elegant solution to a problem that doesn't exist. I do that, I'm hopeless.

Okay, here's the problem as I see it (and please, bear with me and hear me out): DataBroker is a very graphical thing, it's designed to be practical, but it's also designed so that an idiot could use it. There's the button, and the tooltip which explains what the button does, and in some cases there's some text attached to the button.

DataBroker plugins are really something that a new user could pick up and use right away, without having to worry about anything fiddly. So I wouldn't really be able to use a slash-handler with a DataBroker plugin because it's asynchronous to the focus of the plugin. It'd be like giving with one hand and taking away with the other. "Okay, here's a really easy to use plugin thingy, but it has a difficult-for-newbies to understand slash-command part."

This leas to one solution; embedding libraries to make a graphical interface. Now I'm no stranger to doing this as plenty of my older mods have Ace3 config panels, but in Junkie it would really just take away from what I have here. I have an incredibly tiny plugin with the most minimal of libraries used, and that's helped me keep Junkie lightweight. When comparing Junkie with GarbageFu, the difference is really incredible and I like that.

Also, including a menu by default might confuse a new user who may not thouroughly understand the point of it, thus taking away from Junkie's user-friendliness, it'd give them a huge, fiddly database that they'd have to manage on a level-by-level, item-by-item database.

So, does all of this mean that I won't allow for some kind of permanent list? Well, actually... sort of no, no it doesn't. You see, I had an idea when I was writing this (this always bloody happens to me) and I have a counter-proposition for you, please give me your honest opinion on what you think of it. Because believe me, I do value your opinion, and you've been very helpful in the development of Junkie.

Okay, counter-proposition: Including a list in Junkie-proper is bad, in my opinion. But all I'd have to do is make sure that the ignore list can be accessed somehow from outside the Junkie plugin, I'd either have to throw in a set of functions to call/modify the ignore list, or simply make it global. Once I've done that, any mod can then tinker with Junkie's ignore list, and that's where things get initeresting.

If I did that, I could create a plugin for Junkie (and list it in the optional files) which has its own permanent database, it would have Ace3 embedded for the purpose of a configuration screen and via that configuration it would allow for the creation and maintenance of a permanent list. I'll check out StealYourCarbon too to see if tek's libraries are more suited than Ace3 in this case too (as I do love the guy's work, I have most of his mods in my ersonal collection so I should).

Then all I'd have to do is--at load time--ensure that Junkie's temporary list is synched with that of the management mod, that'd simply be a matter of 'ignore = thisOtherDB'. Then any changes to the management database would be reflected in Junkie itself, as it would use the same database for its display. The only other thing I'd need to do is ensure that if the person has the database manager installed, the temporary ignore functions should be removed. Instead, I'd put a link there to open the management frame, and that'd be all I'd have to put into Junkie.

What this would achieve:

1) I could keep Junkie itself small and to my original vision (something which is important to me).

2) I could ensure that I don't force the database on people by default, but instead make it an optional element that people can choose to have or not.

3) Keep extra and unnecessary libraries out of the main part of Junkie.

Let me know what you think of this. I am really seriously considering this because you've always been respectful, and you've given me opinions which have been both honest and helpful. I might just say "Screw it anyway!" and put the DB handling in Junkie-proper, but I'm hoping you'll understand my reasons for not wanting to do that. The thing is, Junkie is still the mod I created for my own use at the end of the day, and at the end of the day I actually find managing a temporary list far simpler than the incredible irritation of having to manage a huge database.

So yes, let me know.

I'm going to work on getting the auto-sell element out of Junkie and into its own mod first, but if you think that this is a good idea then I'll work on that next. The great thing about this approach is that Junkie is split up without any unnecessary additional overhead (I'll see to that!) and everyone, myself, you, the next lady/fellow can all decide on the bits they want to take, instead of having one humongous package forced on them.

That was my problem with GarbageFu, that it offered a mansion of a mod when all I wanted was a hut, I don't want it to become my problem with Junkie. The solution above though is something I'm perfectly content with.

Will do!

I actually did it because I spotted that ZOMGbuffs did it, and I thought to myself "Hey, that's neat!", but it really does screw up alphabetising. So that'll be gone in my next round of updates. I don't want to make the life of anyone more difficult just to make my mod look more pretty, that's highly counter-intuitive to my own personal philosophy of mod design.

I know, I know... believe me, I know.

It's just a habit. I admit though that it's partly for organisation (I've recently started subtitling my mods, not sure why but it stuck) and partly for the humour value of it.

Teapot: It Makes Tea - I do realise it's basically like that.

I find it oddly endearing though, it's the special kind of idiocy (and I know, I said it) that I'm prone to. I think it looks really fun in the tooltip titles and I'd hate to see that go. Still... I suppose it is an annoyance to everyone but myself, so I will consider removing it.

It's just one of those weird eccentricities that makes my mods mine, as opposed to just another dull part of the UI.

(Edit.)

Maybe I should make it more pertinent to the mod at hand! Like Junkie: Junk Management, Bagsy: Bag Information, and Mad Hatter: Total Fashion Control! I feel like I'm going to be pelted with fish though for even suggesting that.

I checked this out and found the problem. It's basically down to a difference in how Junkie and Analyst handle GetSellValue(), but I can fix it on Junkie's end.

Okay, I've just uploaded a version of Junkie with a fix for zedbg's issue, and the toc name colour has gone too.

Plans for tomorrow:

1) Get the colour out of every other plugin's toc.

2) Separate the vendor-sell element out of Junkie and turn it into its own entity, which will also hopefully be a worthwhile DataBroker plugin.

3) I might start on the separate DB plugin thingy tomorrow too, especially if the idea is well received. It'll all be a matter of whether I have time though.

The third of the above might have to wait until the day after, because the second is going to take me quite a while in and of itself, and that'd allow time for some opinions to be posted here.

But now? Now I'm off to bed, it's 2AM and if I don't get sleep I won't be codin anything tomorrow!

Can't say I didn't have that coming, but I'm still not sure what to do with those tooltip titles. I did try removing the subtitle and it made it all look so very barren. What would work is if I could align the tooltip title to the center, then I'd remove the subtitle because the title wouldn't look so horrid if it wasn't left aligned. Any advice there?

You know, that's bloody brilliant! I'm honestly amazed I hadn't come up with this, and I hope this is what you meant because it solves all my problems of not wanting to deal with libraries. In fact, I really do think I can use that but I'm not sure if it's what you actually intended.

I'm not sure how best to explain what I'm thinking here, but bear with me...

First of all, we do away with the default mode. The grey-item mode becomes the only mode. By default, Junkie will only present grey items to the user for consideration and no others.

Now instead of switching between the old default (all items) and grey mode, that keybinding switches between three modes.

1.) The default "destroy greys" mode.

2) The "exceptions management" mode.

The idea is that exceptions management will work similar to the old mode, you'll be able to scroll through all the items in your bag and either tag or untag them as exceptions with different key + click combinations. For example, "Small Furry Paw" might be added with shift + click, and removed with alt + click. As always, using control + click would reset the cycled list back to the first item.

This means that the interface remains entirely with the button, the clicks, and the tooltip (thus keeping the cohesion of the plugin), and it remains easier to deal with than fiddling with a huge menu since the only time an item would be considered is when the player actually has an item.

So if a player found later that they didn't want such-and-such a white item to be considered for destruction, they could simply switch back to the other mode, cycle through to the item and then untag it again.

One of the main problems I had with the GarbageFu system is that it simply dumps a view of all the items a player ever ignored on them, and that's simply not very user-friendly. But this method you've come up with (or that I've misinterpreted) actually allows one to completely avoid these huge list. The motto of Junkie remains that you deal with the items you have, and only the items you have.

And actually working from a greys-only position and adding exceptions from there is a bloody brilliant concept anyway, because that allows the list to be so much smaller. It means adding only a few items here and there that would actually be destroyed, as opposed to adding every damn item under the sun to the ignore list.

Yes, this could work because it solves all the problems!

As I said, that's bloody brilliant.

I'm not sure if this is what you meant though, so I'll leave this here for you to mull over and consider. But it could add all the bits that everyone's always wanted, and at the same time it allows me to be stubborn and stick to the initial vision of Junkie, of a mod which is easy to understand, never overwhelms the user, and doesn't have huge menus or lots of extra files bundled in with it.

Bah, you and your "I can be succinct when I reply to something!"-ness, how I envy that!

Anyway, as far as Junkie goes, I'll get to work on that after I'm done playing the game today. It might not arrive until late tomorrow because looking over Junkie, it'll be a rewrite of a few fundamental things, and I want to make sure I take the time to do that right. Rest assured though, it will happen soon enough, and I've already put my thinking cap on in regards to it.

Thanks, Phanx!

Okay, there's now a preview version up for everyone to test.

I would make this an official release considering that I've tested it until the bovines return, but that'd mean I'd have to rewrite the front-page (since the way it works has changed drastically), and I'd have to upload new screenshot(s)... these are things I don't feel up to doing tonight. In fact, I'm going back to bed! Well, soon enough anyway, I'll be updating the description and screenshot tomorrow but I didn't want to make everyone wait.

I think I've done a good job with this, I'm satisfied and maybe even a litle pleased with myself. I worked hard on finding the most lightweight solutions to the features I wanted to put in there, and I even found a rather unique way of handling the database of exceptions that Junkie will now have. There might be things I could improve on though, so I'm open to thoughts and opinions here. What do you think of the new Junkie, as far as both the code and functionality are concerned?

I'll be back to read the comments and do the appropriate spring cleaning tomorrow.