[Bug Fix] LibExtraTip does not work with recipes on AH
  • Hi,

    I've noticed that the latest (revision 408) LibExtraTip does not handle recipes on AH. For example, I was hovering over
    http://www.wowhead.com/item=6390/pattern-stylish-blue-shirt
    in the AH window but no info was added to the tooltip (other items worked fine).

    Debugging showed that the workaround for Blizzard's bug in GameTooltip:GetItem() is not working in this case. The item link returned for this item looked like "|cffffffff|Hitem:::::::::100:254::::::|h[]|h|r".

    I propose fixing it by replacing the following line in the OnTooltipSetItem() function in LibExtraTip.lua:

    if not checkItemID or checkItemID == "0" then -- it's usually "0"

    by

    if not checkItemID or checkItemID == "0" or checkItemID == "100" then -- it's usually "0"

    This fixes the problem for me.

    Best,
    Brizag
  • Ok, I'll have to debug that one to see what is going on.
    Your suggested fix probably won't work reliably.
    And I suspect this might be a symptom of another bug that Blizzard needs to work on.
  • Bet the extra info is appearance related. Good to confirm it's related to what had to be worked around before.
  • Blizzard replaced all "0" fields with "", so we need to check for checkItemID == "" now.
  • I suspect there is more to it, but I'm still adding code to catch the offending data..
  • ok, this is fixed in SVN.
    And it appears to be just the old Blizzard bug, plus the fact that zeros are not printed in itemstrings anymore.
  • Neither checking "" or "100" fix recipe links in the appraiser tab, or anywhere else for me.
  • The 100 in this case was your character level, the only part of the itemlink that's valid is the character info level and specID.

    http://wowwiki.wikia.com/wiki/ItemLink
    http://wowwiki.wikia.com/wiki/ItemString

    My level 1 rogue for example gets 1:259, so basically the itemlink being returned by tooltip:GetItem() is just NULL.

    The fallback / backup of reg.item or reg.additional.link are also both NIL.

    The failure is actually that item is non-zero but still essentially NIL. This breaks all the other logic in the function. GetItemInfo(item) isn't going to return anything.

    I really don't see how to get the correct info when blizzard simply isn't providing any. Possibly the tooltip info needs to be extracted with a method other than GetItem()?


    local checkItemID = strmatch(item, ":(%d+):") -- this match string should find the itemID in any link

    Since there is no itemID in the link, this will always return the players level as it's the 1st non-empty value in the itemstring.


  • get the fix from svn, then try it
  • Alright, so the proper fix.... extract the actual itemID entry (1st one) from the itemLink. If it's "", set item = 0 so the rest of the logic in the function works properly. The 2nd time the fuction gets called, the information is valid and will get set to the reg info. What was happening, is it thought the info was valid since the itemlink (item) was non-zero, but since it was empty the empty info would get cached in reg and reg.hasItem set to TRUE preventing the valid info from ever getting there.

    Extra fields from strsplit could probably be removed just tossed them in for testing.



    local testname, item = tooltip:GetItem()

    local itemtext, itemId, enchantId, gemId1, gemId2, gemId3, gemId4, suffixId, uniqueId,linkLevel, specID, upgradeId, difficultyId, numBonusIds, bonusId1, bonusId2, upgradeValue = strsplit(":", item)

    if (itemId == "") then
    item = 0
    end
  • "get the fix from svn, then try it"

    Right that will work, since reg.item and reg.additional.link are NIL at that point it sets item to NIL in a roundabout way and fixes the rest of the logic.
  • actually, the reg.item is usually a valid link for the recipe.
    But fixing the search string makes sure it's actually testing the item number and not just the first number in the item string.
  • Guys, a question, I see that you maintain/develop this great addon, but it has no separate project on Curse. Can I create one for the sake of all these who prefer their libraries installed separately?
  • Hi vvv444 we do have a curse page: https://mods.curse.com/addons/wow/auctioneer
    We generally debug things here and make sure they are stable before releasing them there. We are getting ready to do that soon. Thanks for your patience.
  • That's not exactly what I meant. I meant creating separate page just for the LibExtraTip project. So that other projects that use it (e.g. BetterBattlePetTooltip) could reference it separately (for these users who like their libraries installed separately)
  • Ah, I understand. I'll leave that to dinesh to talk about.
  • i'd like to see this as a separate project too, having the library updatable as a separate project on Curse will allow users to better use LibStub to always only load the newest version of a library... as it is now it's a gamble of hit and miss with LibStub and various versions of LibExtraTip delivered with other addons because of THIS:


    local LIBNAME = "LibExtraTip"
    local VERSION_MAJOR = 1
    local VERSION_MINOR = 335
    -- Minor Version cannot be a SVN Revison in case this library is used in multiple repositories
    -- Should be updated manually with each (non-trivial) change


    according to FishEye the last time VERSION_MINOR was changed was on 21 Jul (24 days ago) (today's fix did not increment the version numbers)

    this means that LibStub cannot decide which version of LibExtraTip is the newest and it's possible to load and run a buggy version from almost a month ago because it's pulled in by an addon that's slighly old.

    as it is now, i had to manually search&replace about 7...9 copies of LibExtraTip.lua around my computer's addons folders, just to make sure they all use the latest version that i downloaded from SVN


    one note though... the project should be configured on curse to always automatically mirror the changes in SVN as development releases. If this is possible then the set it to check once a day for changes in SVN and if it's changed then publish them automatically on Curse as a beta/alpha.
  • Why not just automatically substitute the svn revision to VERSION_MINOR?
  • Of course, and I'm willing to create pkgmeta that will pull it as external.
    So, no objections I create it? In the worst case, I always can pass someone else the manager access.
  • about version...*headscratch* don't know... probably brykrys or ccox can answer that.
    for project, wait for all of them to see what they have to say.
  • 1. Unfortunately, it is not possible to configure it to pull for changes once a day... at least not on Curse... But maybe I can setup an automatic script local on my comp to do that...
    2. On the note of "I had to manually search&replace about 7...9 copies of..." - I'm a big supporter of using "nolib" approach for everything, it both simplifies debugging and improves UI load time. But unfortunately, many addon developers don't like this approach.
  • 3. According to the following comment (by brykrys) about the VERSION_MINOR:

    -- Minor Version cannot be a SVN Revison in case this library is used in multiple repositories
    -- Should be updated manually with each (non-trivial) change

    I would still suggest using the SVN revision.
    As long as the main repository for this library is svn.norganna.org the revision will always be correct. When one uses Curse packager to checkout the library as external, the revision still would be filled with the revision from the main Norganna repository. If the 3rd party developer uses a different approach and copies the library into his codebase, it would most probably be copied with the revision already filled from the main repository. So I don't see how the revision of any other repository can enter the code here...

    Besides, if it does not work, we can add code to verify the repository URL using $HeadURL$ an addition to $Revision$.
  • Auctioneer is released under an open source license, and can be used in any way that is consistent with that license.

    If LibExtraTip would be valuable to be maintained as a separate addon at CG, my preference would be for you to give me a bit of time to talk it over with the rest of the project team first and give us a chance to do it.

    Hope that helps!
  • Sure. I just wanted to point out that it is ALREADY defacto used as such by other projects and I could just save you the work. But as you prefer.
  • "actually, the reg.item is usually a valid link for the recipe.
    But fixing the search string makes sure it's actually testing the item number and not just the first number in the item string."

    Actually if you print out the calls and values, the 1st time through everything is NIL, then 2nd time it has values. Key is identifying the empty/invalid itemlink so it doesn't get cached and block the valid data.
  • The first time through getItemInfo returns nil because the item isn't in the cache yet. Yeah, that is going to fail no matter what we do.
    Now we are using the valid data, even if the link is a bit wonky.
  • please bump the minor version, it's still at 335 (from 21 July), even in the beta released on Curse, 7.0.5664
    => LibStub gets confused which one is newer and may keep loaded the same version but from other addons, and those can still have buggy tips.
  • Not sure if tooltips were working for recipes as mail attachments, but they're not currently.
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

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