Note: Most of the following is just technical stuff explaining what changes are currently planned and why relative to the way the addon currently functions, so if you don't care and just want to provide answers/feedback, scroll down to the big, bolded part below.
Given the expansion is coming up and we'll have a decent break before we get back into "official" raiding, I've decided to use part of this time to re-write the kAuction addon to the next major version and make a few core changes. A few things planned for this re-write are:
Reduce memory footprint
First, I'd like to modularize all the aspects of the current kAuction into separate, load-on-demand dependencies to the main addon, such that the individual user can select the modules he or she will use during login. For example, the current kAuction can be broken down into the following basic chunks of functionality:
- Core Client -- The basic functionality that most users use, allowing client auction receipt and bids.
- Core Server -- The functions and data processing used by the server user (raid leader).
- User Interface -- All settings that alter fonts, sizes, textures, layout, positioning, auction events, etc.
- Wishlist Core -- The basic Wishlist functionality, such as creating and modifying wishlists, and auto-bidding/bid-type flags for wishlist items.
- Wishlist Search -- The advanced Wishlist functionality, including database storage/downloads from Wowhead, and the Search functionality in the Wishlist interface.
- Weight -- The current Weight system & functionality.
- Custom Modules -- Custom fight-specific modules used in the past, almost exclusively by me only (ToC Scarab achievement, HLK Horror module, Algalon module, etc).
All told, at present, all the above stuff is included in this giant chunk that is kAuction, and while I suspect a lot of it isn't used by many users, it still exists and is taking up memory, CPU time, and event triggers. The current kAuction client with normal Wishlist usage and such seems to use about 4 megs of memory standing still, which out of 2+ gigs for most people is still a drop in the bucket, but it would be nice to slim that down wherever possible. Even before re-coding, simply cutting out some of the larger modules above I've already found huge memory savings. For example, simply taking out the stored Wishlist Search Item Database frees up about 1 meg of memory, or virtually 25% of the entire Addon!
Re-write Backend Communication
As many of you know, one of the biggest performance issues with kAuction in the past has been the annoying "lost my vote" or "lost my bid" issue, where kAuction appears to not have properly tracked your item bid or auction vote. This typically happens during prime time hours with high-popularity items, where many people are bidding on one or many items simultaneously. The combination of the server communication being slightly delayed (think very slight, 200-400 milliseconds) plus so many messages simultaneously cause kAuction to send out many "updates" too frequently, causing overlaps.
This issue is due to the way I coded kAuction - I wanted to verify each incoming message from a client against the server to prevent fraud or data corruption of any kind, before sending out a reply message (similar to HTTP). During an auction, every time any client takes an action on that auction in someway, a message is sent to the server, verified, changed on the server data, and that change is relayed back out to all clients. So if we have a boss that drops 3 items, and each item auctioned has 3 bidders, and each bidder changes 2 flags on the item (such as best in slot, spec-type, set-bonus, currently equipped item, etc), and each auction gets 3 votes, we get the following number of incoming messages sent to the server:
3 Auctions * 3 Bidders * 2 Flags * 3 Votes = 54 Client-to-Server Messages
That is actually not too bad, and the server can receive and handle all that very quickly in a second or two. The "lost vote/bid" issue happens because the server is programmed to send out response messages to ALL clients for each update, to keep the data integrity for both server and client, such that each change a client makes is quickly relayed to all other clients.
Thus, for each of those 54 messages, the server sends out a response message to all clients, which updates the client on what changed for a given auction. However, due to a (even slight) delay within the addon channel, when communication is frantic and happening often, an update message sent out by the server containing any given alteration will be transferring to all clients at the same instant that an additional message from a client is being sent out to the server. This causes the actual user (a client), to click his or her action, such as a bid on an auction, see it update in real time, only to suddenly "disappear" and revert back to the previous copy when that "mid-flight" message from the server comes in. Meanwhile, the server has received that "bid" update from the client, but the user thinks it wasn't processed and might try again, and the process repeats.
Since I didn't account for this transaction delay when first coding this part of kAuction, now I have the chance to re-do that aspect of things so that those "lost" bids or actions don't occur anymore. The primary means to doing this are larger data chunks per message, communication throttling, and client-based data locks.
Allow vertical resizing
Due to technical difficulties in implementing it and the fairly low priority of it, I never bothered allowing users to change the vertical size/height of the main kAuction window. However, this is a good time to get that functionality in so users can alter the overall space used by kAuction as well as how many auctions are visible at once.
Cut unused functionality
This is up the air, and is the main reason I'm asking for user feedback, but one thing I'd like to consider in this re-write is cutting out unused features. The biggest culprit, I suspect, is the Weight system, which is a huge chunk of code and, given how little attention it gets, is probably not used by most people (myself included). To be honest, sometimes I add things like the Weight module just for a project to work on, and not necessarily because it is a key feature.
Hopefully feedback will given an idea of what areas people use least/most often.
TO PROVIDE HELPFUL FEEDBACK, PLEASE REPLY AND ANSWER ANY OR ALL OF THE FOLLOWING QUESTIONS
Please feel free to provide additional information or elaborate for any question; the more feedback, the better.
1. Using these descriptor options (Never, Rarely, Sometimes, Often), how frequently do you use each of the following kAuction features:
1a. Wishlist Core - Creating Wishlists, adding items to wishlists, using auto-bid/flags for wishlist items for your in-raid auctions, etc.
1b. Wishlist Search by Name - Using the Wishlist Search interface to search for items from your local item cache by name.
1c. Wishlist Search by Filter - Using the Wishlist Search interface to search for items from your local cache by zone/difficulty/slot type.
1d. Weight Core - Using the Weight system to create stat-based weighting for items and to compare new drops to existing items.
2. To navigate large lists, do you prefer to:
A) Use a scroll bar to look through the whole list, OR
B) Use page forward/backward buttons to view chunks of the list at a glance?
3. For countdown indicators, such as duration of an auction, in which format do you prefer this data to be relayed:
A) A horizontal bar, draining over time, OR
B) A numerical countdown?
4. Fill in the blank: "On average, when bidding for an offspec/rot item or when I am not wearing my normal main spec gear, I remember to/bother to manually change my Currently Equipped Item when bidding on an auction _______ times per week."
5. Optional: What feature(s) would you like to see added to kAuction, or if already existing, modified in some way, if any? Please explain.
6. Optional: In terms of "ease of use", do you find kAuction lacking in any areas, and if so, please explain; the more detail, the better.



Reply With Quote



