A number of how many times the item was seen up for sale on the auction house is very helpful to understand which items are "hot". Thus, i think it deserves a place into the tool-tip, you could also make it off by default - to decrease database size for those who don't want the functionality.

#69

What do you mean by "hot", exactly? I've heard this suggestion before, but in the context of indicators for the reliability of the historical value.

There are two problems with this, though.

The first is that getting an exact auction count is impossible because there is no unique identifier for auctions. Let's say you scan for Felcloth and there's 10 of them on the AH. Well, so far, so simple, the count is 10. But, now, let's say 5 minutes later you scan again while the same auctions are still on the AH. Now, ideally, the count should still be 10, but there's no way of knowing if those auctions are actually the same. There are workarounds for making an approximation (like the one vanilla auctioneer uses) but they need tons of savedvariable space, slowing down the startup, and can be very inaccurate still.

The second problem is that the total count of auctions seen, even if accurate, isn't necessarily a great indicator of the reliability of the historical value. For example, the auctions may have been scanned a long time ago when prices were very different, or, depending on what kind of historical value if used their pricing data may be dominated by a few outliers, may never have been considered or may since been discarded. Also, certain items simply have prices which are consistently wrong, like shitty epics, which are almost always massively overpriced.

The suggestion is very interesting. It states "seen" just as a boolean flag.

But what if you introduce a parameter of "historical count" which is somewhat opposite to the historical price?

1. For every item on scan the total count of these items (not auctions) is summed.
2. For several scans a day the maximal count is saved for that day.
   I thought about minimal, it works rather stupid when you saw 0 items once a day and any positive count later at the same day.
3. As a historical value I propose a median for day of week (yes, seven values). I think this is more informative than a median across all days. It allows to draw something like graph of activity or week "pulse" of that item on AH over all time (of scans).

For a tooltip I propose 3 new optional segments:

1. Historical pulse: 7 numbers in a row for every day of week. It could be a simple graph, maybe
2. Last week pulse: 7 numbers of count for the last 7 days, finished with a today's value
3. Last seen. I suppose it would be better to have literal form: "not yet", "today", "yesterday", "this week", "X days ago", "X months ago", "more than year ago". But for simplicity this could just a date.

Days of week should be synchronized between pulses. E.g. if today is Thursday, than order will be: Fr, St, Su, Mo, Tu, Wd, Th - for both of them.

Zeros could be grayed out, if pulses will be a list of numbers.

What kind of problems do you see with that idea, @shirsig ?

aux has no notion of "scan" in the context of the history. Every auction encountered in some way is considered for the daily minimum price, could even be while sniping with the real time mode.

Afaik none of the major retail AH addons, even with the possibility of quick scans that don't exist in vanilla, do any graphing or keep enough information to sensibly graph in the first place. There's a single retail addon that I know of which does go further but this is an addon exclusively for scanning: https://mods.curse.com/addons/wow/market-watcher. Some of the reasons are explained on that curse page.

Basically, if you want to show really detailed information you have to scan for specific manually white-listed items or you end up with too much data (given the wow client restrictions), but this would be in conflict with the requirements of a general purpose AH addon for a historical value.

I think for a general purpose AH addon it's most important to have information that is concise, ideally a plain number which can be conveniently used for percentages, profit scans, easy comparison, derivative values (e.g., disenchant value) and more, that is available for as many items as possible and collected with as little effort as possible.

Actually, I think if you really need such detailed information the best solution would probably be to make an addon to export scan data to some format you can then import into excel or equivalents.

It seems that it seems way too complex.

Let's start from the very first single step: saving in the variables maximum daily count seen, as it is done for the minimum daily price seen.
No history, no graphs. Let's keep it as simple as possible for a while.

If you just don't really want this functionality in any way, just say it.
That's a good reason to stop the discussion.

AUX now has notion of whether search is completed or not. There's an evidence in the UI: it shows "Resume/Pause" button.

What's the problem with analyzing the data grabbed into the search table just before emptying it when a new search starts?

Yes this info could be partial and misleading, but it will serve as a sign that item was on the market at least. The next targeted search will fix it via the max function, if it happen.
This could be restricted only for simple exact searches, for example.
Yes, these that are often done by right-clicking an item.

All the queries for post page fit perfectly!
Auto-refreshing and manual refreshing - both are good to count items on market after this mini-scan is completed.

So again, about the very first single step: what prevents saving the maximum daily count seen?

I said it has no such notion in the context of history. The history module is written in a way that it gets passed some information about every auction encountered, like bid, buyout, stack size etc., but it doesn't learn anything about where the auction was encountered. The search tab module doesn't interact with the history module at all, that's handled at a lower level. You're basically asking for a parallel history system which works completely differently from the current one, which I'm saying is way too complicated for this seen count of questionable quality and usefulness.

Thank you, Simon, I've got it.

Then yes, to implement my suggestions you need to change the history module interface.
It should be supplied with a ScanResults reference, not a single Auction.
Ok, let this be postponed to a history module redesign.

What about only "last seen" date?
It can be presented literally, as mentioned in my first proposition.
And it can be deduced from a single auction, so you don't have to change the history module interface.

For most actively traded goods it will be useless showing "today" all the time.
However it's rather useful for items seen more rarely.
It'll help to decide on reliability of the historical value. If item was seen more than 1 month ago, maybe historical value shouldn't be trusted a lot.

It'll help to decide on reliability of the historical value.

Not so sure about that. Like I said in an earlier comment, even for a seen count this is questionable. The reliability can mostly be judged by two criteria: The completeness of your historical data (can only really be assessed when familiar with exactly how the historical value works) and whether the market is active. Usually, active market -> reliable, inactive market -> unreliable. For inactive markets the value is unreliable regardless of how long since the last auction was seen. You could argue that a seen count tells you whether a market is active (though you wouldn't actually need to know a number, just a boolean) but usually it's obvious from the rarity of items (e.g., blue/purple, specific suffix) and since vanilla doesn't have that many items you pretty soon know about all the exceptions.