Actually I think the behavior is intended, and correct. The bug is that self:GetItem() doesn't return the crafted item, or both items. We bitched at the blues to fix that a few times, but I've kinda stopped caring. Double info on recipe tips doesn't really bother me.
*edit* and taint should *never* be an issue with tooltips... but still the script handler is better than direct hookerage.
It's not better if you need to workaround the recipe glitch. Like I said, depends on what you are trying to do.
You're right that it's not always the same fontstring, but it's not an empty line, it's a vertical offset. You could probably find a (very expensive) way to check this in a safe way.
The sole purpose of "OnTooltipSetItem" is to allow hooking, whatever the setting function is, whatever the parameters order and type that are called on all methods that creates tooltip, if it IS an item, then the "OnTooltipSetItem" callback is called. The fact that it's called twice is a implementation bug.
You can try to tweak around this bug and you should ask for the bug to be fixed. The issue with pre-hooking is that you need to know all functions that set a tooltip and hook them all. It needs to be maintained. You also have to care about not tainting.
I remember reporting this on the official forums way back when this feature was first introduced in a TBC patch, but they don't seem to care and its still broken on 3.2 PTR.
Also with the new GetItemStats(itemlink, table) API in 3.2, its also nearly useless in its current state. I wonder why it would only accept itemlink as input if it doesn't consider gems or enchants, it should just accept itemId which doesn't work in the current build, you have to feed it a proper itemlink.
You are mistaken. Mendeleev does post hooks of OnTooltipSetItem and OnTooltipCleared and it works perfectly when both the recipe and the item the recipe creates are in the local cache. I don't remember what happens when one isn't in the cache though, but if it does misbehave it will be correct the next time the tooltip is shown.
The top line in your screenshot is from the second call not the first.
What are you smoking? The hooks are still called on every tooltip even if you use the hook-all-methods method.
What are you smoking? The hooks are still called on every tooltip but without the extra lines of code to check if its the first call or second. And with out the OnTooltipCleared hook call. And with out the extra code if you want to check for recipes. ...
PS: I don't normally respond to rude posts. I know its kinda your style of talking, but please learn to not speak like you understand something when obviously you don't got a clue.
do
local tt_OnTooltipSetItemOrSpell = function (self)
local is_a_recipe = self:NumLines() > 4 and select(5, _G[self:GetName().."TextLeft4"]:GetPoint(1)) < -2
local count = (self[ArkInventory] or 0) + 1
self[ArkInventory] = count
if (not is_a_recipe and count == 1) or (is_a_recipe and count == 2) then
ArkInventory.TooltipShowCustom(self)
end
end
local tt_OnTooltipCleared = function (self)
self[ArkInventory] = nil
end
local function HookTooltip(tt)
tt:HookScript("OnTooltipSetItem", tt_OnTooltipSetItemOrSpell)
tt:HookScript("OnTooltipSetSpell", tt_OnTooltipSetItemOrSpell)
tt:HookScript("OnTooltipCleared", tt_OnTooltipCleared)
end
for _, tt in ipairs(tooltip_frames) do HookTooltip(tt) end
end
This is assuming TextLeft4 is always an empty line for recipes, which is not the case.
The question is why not avoid the overhead when you can?
In my OnTooltipSetItem script, I simply set a flag, such as tooltip.myaddon = true, and check if this flag is present so that the script doesn't add the line twice on recipes.
You then do an additional hook for OnTooltipCleared(I think that's the handler's name) to nil out tooltip.myaddon.
Unless I'm mistaken, if you add the line on the first call, it adds the line directly below the "item" made by the recipe, which ends up in the middle of the tooltip instead of the end, most likely not what you want.
As shown in this image, if you blocked the second call, only the first "ItemLevel: 85" line would be shown.
Secondly, using the OnTooltipSetItem method means extra checking on every item tooltip you show, not that you will show a lot of tooltips very often, but the overhead is there. While the hooking-all-methods method is a one time thing on load.
As for LinkWrangler, the author has provided a callback system which you can register with for LinkWrangler to inform your addon when it has created new tooltips (on demand) for you to apply your hooks or add your addon's lines.
Yes, thats just one addon, what about those that don't have one and you/your users would want support for it.
In the end LibTipHooker solves all of the above problems with a wide range of support for other addons.
1. OnTooltipSetItem gets called twice on recipes, if your addon needs to work well with recipes then this method may not always work for you. This is why LibTipHooker hooks all SetXItem methods instead.
2. Do you or your users need support for other addon tooltips? Do you only need it to work with the default UI? LibTipHooker maintains a list of most popular tooltip addons for you.
3. What about dynamically generated tooltips, for example LinkWrangler or Links gives you as many ItemRefTooltips as you need, do you want to support these? LibTipHooker does.
Of course, everything starts out small, with a small user base, maybe you don't need/want to support something you don't use yourself, so any of the hooking methods mentioned in previous posts will work well for you, RatingBuster started with small simple hooking too.
But when you break millions of downloads support is something you will get a lot of requests for, and thats when the whole thing became big enough for RatingBuster to spawn the LibTipHooker.
I just noticed once when mousing over that the % changed when mousing over, if you mouse over and them move the mouse off and over again sometimes the value changes, I'm not sure if having a buff constantly refreshing on my char like the new sniper training does could have any affect, though it happened when I changed to my 2nd spec which is marks on the PTR. I'm wondering if perhaps it might have something to do with diminishing returns or something since I have fairly high dodge on my hunter. Changing aspect seems to show the problem a lot.
I've attempt a fix for this in LibStatLogic r47, see if it works.
I'm still able to reproduce the dodge bug, including managing to get it to display like the following
I'm not sure what's causing the issue though.
Just by looking at the code, I have no idea what's causing this. It displays the correct % for my warlock. How do you "manage" to get it? or you just log in and its like that?
Not sure how this error is happening but on the PTR I get different results mousing over the same gem with apparently no reason why it's happening.
Here's a few screen shots showing the different amounts of dodge I should be gaining from the subtle scarlet ruby.
Note I'm not changing gear or gaining/losing any buffs other than my Sniper training buff on the PTR refreshing due to the changed mechanics, but Sniper training doesn't affect any ratings so shouldn't be causing a change.
Only dodge rating seems affected.
I'm unable to reproduce what you are seeing here on PTR
local function GetUnitIdFromName(name)
if name == UnitName("target") then
return "target"
end
for i = 1, GetNumRaidMembers() do
local raidTarget = format("%s%d%s", "raid", i, "target")
if name == UnitName(raidTarget) then
return raidTarget
end
end
end
It scans your and your raid member's targets for the mob name, and if found returns the unitid. You would have to check for nil returns before you use it.
0
It's not better if you need to workaround the recipe glitch. Like I said, depends on what you are trying to do.
0
I remember reporting this on the official forums way back when this feature was first introduced in a TBC patch, but they don't seem to care and its still broken on 3.2 PTR.
Also with the new GetItemStats(itemlink, table) API in 3.2, its also nearly useless in its current state. I wonder why it would only accept itemlink as input if it doesn't consider gems or enchants, it should just accept itemId which doesn't work in the current build, you have to feed it a proper itemlink.
0
No you are.
"Recipe source" from Mendeleev
What are you smoking? The hooks are still called on every tooltip but without the extra lines of code to check if its the first call or second. And with out the OnTooltipCleared hook call. And with out the extra code if you want to check for recipes. ...
PS: I don't normally respond to rude posts. I know its kinda your style of talking, but please learn to not speak like you understand something when obviously you don't got a clue.
0
This is assuming TextLeft4 is always an empty line for recipes, which is not the case.
The question is why not avoid the overhead when you can?
0
Unless I'm mistaken, if you add the line on the first call, it adds the line directly below the "item" made by the recipe, which ends up in the middle of the tooltip instead of the end, most likely not what you want.
As shown in this image, if you blocked the second call, only the first "ItemLevel: 85" line would be shown.
Secondly, using the OnTooltipSetItem method means extra checking on every item tooltip you show, not that you will show a lot of tooltips very often, but the overhead is there. While the hooking-all-methods method is a one time thing on load.
Yes, thats just one addon, what about those that don't have one and you/your users would want support for it.
0
1. OnTooltipSetItem gets called twice on recipes, if your addon needs to work well with recipes then this method may not always work for you. This is why LibTipHooker hooks all SetXItem methods instead.
2. Do you or your users need support for other addon tooltips? Do you only need it to work with the default UI? LibTipHooker maintains a list of most popular tooltip addons for you.
3. What about dynamically generated tooltips, for example LinkWrangler or Links gives you as many ItemRefTooltips as you need, do you want to support these? LibTipHooker does.
Of course, everything starts out small, with a small user base, maybe you don't need/want to support something you don't use yourself, so any of the hooking methods mentioned in previous posts will work well for you, RatingBuster started with small simple hooking too.
But when you break millions of downloads support is something you will get a lot of requests for, and thats when the whole thing became big enough for RatingBuster to spawn the LibTipHooker.
0
They work for me in enUS
0
The AP bug is fixed in RB r233.
The DR for dodge seems to be working fine but I have no idea how sniper training is affecting dodge, maybe its something else.
0
I've attempt a fix for this in LibStatLogic r47, see if it works.
0
Not yet, will be in the next commit.
Just by looking at the code, I have no idea what's causing this. It displays the correct % for my warlock. How do you "manage" to get it? or you just log in and its like that?
0
Thanks, this is fixed.
0
I'm unable to reproduce what you are seeing here on PTR
0
Heirloom scaling matches that of rare quality items.
0
Last time I had to detect instance changes, I used a delayed GetRealZoneText() check with PLAYER_ENTERING_WORLD
0
local function GetUnitIdFromName(name) if name == UnitName("target") then return "target" end for i = 1, GetNumRaidMembers() do local raidTarget = format("%s%d%s", "raid", i, "target") if name == UnitName(raidTarget) then return raidTarget end end endIt scans your and your raid member's targets for the mob name, and if found returns the unitid. You would have to check for nil returns before you use it.