Scan on Purchase?
  • Hello!

    I'm curious to know why when I click "Purchase" or "Buyout" in the General Searchers window, it sits for a good period of time at "1 scans remaining". Can someone shed some light on this area? It slows down interaction with the AH.

    Thank you!

  • I _think_ the theory is that because you've bought something the list is no longer accurate... Though I wonder if there's some way to just remove the item you bought from the scan data without rescanning? I don't know.
  • No, the issue is that the only way to buy something is to have the specific item listing be on the browse screen. When you're using the search tab, the browse tab can be showing anything (you can even be using both independently at the "same" time).

    So the first thing the search tab has to do is tell the browse tab to pull up the right item. If there are multiple pages of listings for that item, it will have to page through them until the right item is finally on the browse tab. Then we use an API to tell it to buy (which is when the confirmation dialog appears).

    I'm not sure why your scan is hanging, other than the current issues everyone is having with blizzard scans being awfully broken a lot of the time due to sharding and the like.

    just to be sure, you're running a scan first before using a searcher, right? can you run normal scans without any issue? after you tell a searcher to buy something, is the browse screen going to the right item listing?
  • Hi dinesh, the search to buy part is true, but it feels like it's adding more scans to the queue than that. basically every time you click "buy/bid" in the dialog the queue increases by 1, but if it was just the scan to buy the next item the queue would stay the same length instead of increasing. And if you watch what it's searching on the first page it repeatedly goes back to things you've already scanned.
  • Thanks for the replies. Yes - my typical usage is "login, click Fast Scan, then start looking for deals". Sometimes, I'll click the rescan little portal thing to refresh the current items.

    When I click "Purchase" or "Buyout" (I don't use Bid often), it'll add a "1 Scan Remaining" progress bar above my AH window, then sometimes it'll return with "That item no longer exists" after sometimes a minute or so.

    I haven't looked at the API that Blizzard offers, but I would have assumed that each AH listing would have a unique ID and you could invoke a "BuyAuctionWithID(AuctionId)" call, rather than having to keep track of pages of data and the index of the items, as I'm interpreting from your response. But you know what they say about assumptions - that you're sometimes wrong.
  • I use "Purchase All" and usually have hundreds of auctions pending, as you say many of them return "That item no longer exists", but by the time I've finished buying everything my queue of scans has increased to about 100 whereas when I've finished buying it should be 0. (1 at the most)
  • every time you click bid or buy your queue of scans should increase by 1, because each one adds a new buy event that potentially needs a new scan (if the item is not already on the current page). even if you're buying the same item multiple times, the sort on the search screen may be different than the order the items appear in the AH, so you may well have to start rescanning the same item from page 1 (or maybe it's the last page, I can't remember if we go forwards or backwards) to make sure you find a match if one exists.

    but as you suggest, by the time all the buying and/or "that item no longer exists" or "that item already has a higher bid" (or other error messages) is over, the count should be back at 0 and the indicator should disappear. if it's not, then we have a bug to track down.

    hughball - you'd think that, but no. There is no auctionID which is exposed to the client. We have to page through looking for an auction for the right item, with the right stack size, and the right bid and/or buy price.

    Here is the API for making a bid/BO:
  • The "search" page has a number down the bottom of scans it has to do, this goes down by 1, the queue increases, the scan is done for the item, you click on the dialog, at this point the queue should go back down by one.
    Now I just did some testing and _usually_ the queue hovers around the same number, going up by one then back down by one, and I was just testing it and whether the item still exists or not does not affect this, it _usually_ goes back down. Just now the only cases where I could see the number didn't go back down were successful bids (Though that may be a coincidence.)
  • Thanks for the heads up Dinesh. I'd gone over to the portal and looked at the API they offer, but that's for external clients. Not useful for ingame AH stuff.

    Well, good on you for having to deal with the way it's offered - and for doing it well.
  • The scan buildup is an oddity of the interaction between CoreBuy and CoreScan. Basically CoreBuy aggressively overrides some of CoreScan's behaviour, starting new scans before previous ones have finished - the idea being to get all the buying out of the way as quick as possible. After CoreBuy has finished, CoreScan is left to clean up the unfinished scans.
  • Well, my ambition didn't stop me from creating this post in the UI/Macro forum about modifying the AH API to include interaction with AuctionId:

    Probably won't go anywhere as it's likely been tried before, but a guy can ask.
  • Thanks brykrys
Start a New Discussion

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

norganna's addons network · tf2 warehouse · scrap warehouse · auctioneer addon · gatherer addon · addon forums · rdrct