Not signed in (Sign In)

Auctioneer::Technical: Discrepancy in hooked QueryAuctionItems/private.IsInQuery/Appraiser in invType matching

Bottom of Page

1 to 8 of 8

  1.  
    • CommentAuthorlunghusk
    • CommentTimeSep 22nd 2008 edited
     
    Hey all,

    I noticed something weird while I was looking for gear for my low level character. Looking for usable headgear, it kept matching [Armor][Miscellaneous][Head] a lone [Blood Elf Bandit Mask] as new no matter how many times I refreshed it. Each time I refreshed it showed this ridiculously priced auction as new.

    Tracing through the code to see what was causing this, I saw

    [code]function private.IsInQuery(curQuery, data)
    ...
    and (not curQuery.invType or (data[Const.IEQUIP] == Const.InvTypes[curQuery.invType]))[/code]

    which converts a number (curQuery.invType) to nil, because Const.InvTypes has only string indices. So all queries specifying an invType show all matches as new when refreshed, which distorts prices by seeing the same auctions repeatedly as fresh.

    I fixed this (removing the indexing into Const.InvTypes) but then APPRAISER refreshes started seeing everything as new and stacking up visible auctions, because it QueryAuctionItems by equipLoc ("INVTYPE_HEAD" etc.) while the scanner matches by invType.

    So I'm confused. What is the scandata database supposed to contain and match on, invType indices or "INVTYPE_..." or both, and should Appraiser be querying by invType or equipLoc or both? I fixed it locally by the above plus converting equipLoc to invType in the QueryAuctionItems hook.
    • CommentAuthorRockSlice
    • CommentTimeSep 22nd 2008
     
    Thank you for spotting this. The fix has been put in place for the next build.
    CoreScan.lua should not be using the Const list, while AprFrame.lua should have been.
    • CommentAuthorlunghusk
    • CommentTimeSep 22nd 2008
     
    Thanks, that should do the trick! Only thing I'm wondering is if the QueryAuctionItems hook should support "INVTYPE_..." inputs to match the base function. (It can apparently handle them or the "bad" Appraiser queries wouldn't have returned any items). My fix to the hook was along the lines of

    if (type(invType) == "string" and strfind(invType, "INVTYPE_")) then
    invType = Const.InvTypes[invType]
    end
    • CommentAuthorRockSlice
    • CommentTimeSep 22nd 2008
     
    Except the INVTYPE_HEAD isn't the string. It's the global variable that Blizz uses for localization purposes, so on US servers, INVTYPE_HEAD == "head", while on German servers, INVTYPE_HEAD == "kopf"
    • CommentAuthorlunghusk
    • CommentTimeSep 22nd 2008
     
    They're used for localization yeah. Problem is that IsInQuery remains vulnerable to other addons which send these "bad" queries. Rather than converting, QueryAuctionItems could simply drop them invType = tonumber(invType) or 0 Most of the other parameters are cleaned up like that.
    • CommentAuthorRockSlice
    • CommentTimeSep 22nd 2008
     
    hmm. good idea. Please add a jira for it
    • CommentAuthorlunghusk
    • CommentTimeSep 23rd 2008
     
    Added as ADV-313. Also noticed that Const.InvTypes has some incorrect entries - included some code in that issue to generate the correct table.
    • CommentAuthorlunghusk
    • CommentTimeOct 2nd 2008 edited
     
    Hmm I noticed a related problem with recipes. I am busy training up my cooking so I did a search for usable cooking recipes, and see 2x[Recipe: Savory Deviate Delight] and 3x[Recipe: Lynx Steak]. Each time I refresh the scan it shows

    2 unchanged items
    3 new items

    so the Lynx recipe is apparently being matched incorrectly when "Usable Items" is checked. The only big difference is in the quality (Savory is green while Lynx is white), could that be affecting it?

1 to 8 of 8

  1.  
World of Warcraft™ and Blizzard Entertainment™ are trademarks or registered trademarks of Blizzard Entertainment, Inc. in the U.S. and/or other countries.