Since Auctioneer Advanced's SearchUI is now functional, we've come to realize that in order to get all the functionality we want into the SearchUI module we would need to duplicate the existing evaluators that BottomScanner uses, and not only duplicate, but modify them to work with how the SearchUI feeds its searcher modules data. This is simply unacceptable since it will mean that we would have to maintain two files that do the exact same thing, but are written for incompatible APIs. So how do we solve this issue you ask? Well, we considered a few options, including writing a wrapper for the BTM evaluators so that the SearchUI could use them, but each of those options we considered sub-standard and hackish. So we opted to create a new AddOn, tentatively called "Evaluator", that would house the evaluators (and filters) that would be used by both Auctioneer's SearchUI and by BottomScanner.

You might have noticed that I said the evaluator/searcher APIs for both BottomScanner and the SearchUI are currently incompatible, and you might have asked yourself that if these two systems are incompatible how can we write an evaluator system that would serve both systems? The answer to that one is rather simple. Even though the systems are currently incompatible, the underlying mechanics are the same. In fact, I've explained the SearchUI as BottomScanner on the snapshot, that is, BottomScanner that acts not on "live" data, but on data that was stored by Auctioneer Advanced scanning subsystem. So basically, both APIs have the same requirements, just different ways of asking for those requirements. Having said that, I will also mention that both systems will have to be re-factored to accept the new unified evaluators system that we're proposing.

By this point you might be asking exactly how will the new system work? Well, the new system is rather simple, as previously stated there will be a new AddOn tentatively called "Evaluator" that will be a required dependency of both the SearchUI and BottomScanner. This new AddOn will provide a way for other evaluators and filters to add themselves to the list of avalilable evaluators and filters. Evaluators would do the job of assigning an item a worth, based on internal calculations. Filters would, as the name implies, filter out unwanted auctions based on internal characteristics. The Evaluator AddOn would also provide a set of utility functions for Evaluators to use.

Evaluators would have to provide a single function tentatively called EvaluateItem() who's prototype would be as follows: function EvaluateItem(itemLink [,stackSize [, infoTable [, minBid, curBud, buyout]]]) return buyOrNot, value, delta [,stddev [,reason]] end. Explanations of the individual parameters follow:
itemLink = The full item's link
stackSize = An optional stack size being evaluated, if nil it means that the evaluator should not do any computations involving stacksize and just return price evaluation
infoTable = An optional table that will get filled with extra info (like that currently displayed by BTM's evaluators in the Tooltip). Exact format TBD.
minBid, curBud, buyout = These optional parameters are the same ones returned by the GetAuctionItemInfo() function.
Explanations of the individual returns follow:
bidBuyOrNot = "bid", "buy" or false, self explanatory :)
value = Price valuation
delta = Delta is the difference from the value taking into account re-listings, ah fees and the like.
stddev = A confidence value from 0-1, usually stddev, but can be gathered from wherever, basically stating how certain an evaluator is of the given value+delta's accuracy.
reason = A string outlining the reason why an item should be bought or not. Please only fill this out if its an important consideration, since it might be placed in the Tooltip. Even if you do not return this, the caller will still know your module's name. So don't return "buy it for resale!" (if you're a resale eval) or "valuation > price" or anything obvious.

Filters would have to provide a single function tentatively called FilterItem() who's prototype would be as follows: function FilterItem(GetAuctionItemLink(), GetAuctionItemInfo()) return filterBid, filterBuyout, reason end. The parameters for this function would match those returned from GetAuctionItemLink() & GetAuctionItemInfo() for the specific auction being questioned for filtering. The returns are true if the auction is to be filtered or false if its should not be filtered, the reason is as above.

Additionally, the Evaluator AddOn would provide mechanisms for calling each module individually in addition to functions to call all the modules in turn for a specific item/auction.

This forum post was created in a public forum so that you the users (and possibly creators) of these evaluator and filter modules could comment on, and ask questions about the proposed implementation.

--
MentalPower
Lead Developer of the Auctioneer AddOns Project

My I recommend that in the future, discussions like this take place before someone takes on a major coding task that everyone has been saying for months has been needed, but nobody's tackled?

Given Nine's gentle sidetracking above, I'm providing a link to my thoughts on pricing: http://forums.norganna.org/discussion/5084/treatise-on-pricing/

Some parts are perhaps a little dated, but I still agree with most everything I said there. Note that there is also a section on evaluators (the buy price section), though it is significantly less detailed than MP's proposal above.

Posted By: dineshGiven Nine's gentle sidetracking above, I'm providing a link to my thoughts on pricing:http://forums.norganna.org/discussion/5084/treatise-on-pricing/

Indeed, did sidetrack there a bit, sorry. I condensed my rambling into one reply. It just seems kinda odd to me to have two or more APIs that do basically the same thing: take an item and perhaps some other details and return a monetary value.

Also consider e.g. the "snatch" evaluator which SHOULD be configurable to only buy a specific amount of things (except that last bit was never fully implemented). This necessitates the evaluator knowing about counts of items.

We did start out by thinking "evaluators should be simple", i.e. only accepting an itemlink and returning a value. And that is indeed enough for the really simple evaluators.

But then we started playing "what-if" scenarios:

• Counts got added because of snatch.


• Bid/buy got added because evaluators can currently be configured to bid or buy separately. This COULD be configured in the using app, but keep in mind that we'll have several apps using the evaluators, and duplicating these settings (on a per-evaluator basis) in all apps is just unnecessary work for the user.


• We split the value into two: 1. the projected sell price and 2. the max to buy for:
  - The projected sell price is interesting to the user
  - The max buy ("valuation") depends on several things internal to the evaluator, e.g. what is the relisting cost? What markdown% should we use? These are all configurable on a per-evaluator basis today.


• Stddevs got added mostly because we know that some evaluators can predict very accurately what the chance is of making X amount of cash off an item (DE mats is a shining example). This could be presented to the user, or filtered on by the using app.

As you may have noticed, many parameters and returns are optional, meaning that in its simplest mode you could indeed feed pretty much only an itemlink to the evaluator and have it spit out a projected price + valuation. I do not know which addon would use this, but the option is available.


I was going to add a "my $.02" here but I realize I've typed way too much - it'd just look out of place :-P

Posted By: MikkAlso consider e.g. the "snatch" evaluator which SHOULD be configurable to only buy a specific amount of things (except that last bit was never fully implemented).

Just for some historical perspective, snatch counts were fully implemented (back in Auc4? or was it BottomFeeder?). Somehow or another that functionality did not get ported over to the new framework.

Stddevs got added mostly because we know that some evaluators can predict very accurately what the chance is of making X amount of cash off an item (DE mats is a shining example). This could be presented to the user, or filtered on by the using app.

As an aside, I would much prefer we call this confidence (or some such) rather than StdDev, since for many (or possibly even most) evaluators, the value we return here will not be an actual statistical standard deviation.