Since the patch, tooltips' opacity isn't working anymore. Before that, my tooltips were fully opaque. Now, they're ~20% transparent like the Blizzard's ones. I didn't saw any option to switch that, is this just Blizzard overriding opacity now ?
If you have some fix for this, it'd be very nice :D Thank you ! :)
I've found a workaround to at least make it look normal again. I really have no idea why it's not updating correctly, nor do I have the time to look into it properly, so this will have to do for now:
Add to the bottom of the following functions (directly before the final "end" statement) a manual override of whatever faulty backdrop is being applied:
This is what I added:
Some background info (if someone wants to look into this further):
For some reason the settings (particularly the backdrop color/opacity) are not being applied properly. I noticed that, when changing settings via the /tiptac options menu, e.g. by clicking on a checkbox, it would always call this function and apply the opacity correctly - at least until the mouse is moved to another unit/object. However, when updating normally this was not the case - perhaps the backdrop "fixes" I found in the code have stopped working? So I've added this manual update to override whatever is happening beforehand, and it appears to be working.
It seems to work fine, except on item tooltips (both in Character Pane & bags for instance). Is there another function to change to match those tooltips too ?
(Thank you anyway for the partial fix ! <3)
is there a fix for the tooltip of the items? they still have no background?
The tooltip clearing function now clears the backdrop. Putting self:SetBackdrop(tipBackdrop) where there are self:SetBackdropColor(unpack(cfg.tipColor)) calls seems to restore functionality, at least as far as I've tested.
Also added ANCHOR_NONE to the GTTHook_OnUpdate(), "if (gttAnchor == "ANCHOR_CURSOR") or..." line (to account for items)
Is it not enough to add it to GTTHook_OnTooltipCleared and TipHook_OnHide?
not working after update....
After the most recent update, most tooltips still aren't working properly (though some are).
The self:SetBackdrop(tipBackdrop) change does seem to help, though.
Made some changes in today's release, but more may be needed to fully fix this. As I cannot test it out myself, specific feedback is appreciated.
I added a function tt:ApplyBackdrop(tip), which will apply the backdrop to the given tip, including color and border color.
It's being called from a few places already, but perhaps it needs to be added elsewhere too. It would obviously be preferable to call it as few times as absolutely necessary.
The problem still persists unfortunately. I don't know why Blizzard feels the need to re-invent the wheel every expansion and cause problems like this for addon developers.
Some icons apply the correct tip but only after a short delay - for a brief moment, you see the blizzard tooltip border and a different backdrop to the one specified in your settings. Then it changes correctly. Other icons don't change at all, and remain with the incorrect settings. Items and doodads continue to remain unskinned.
Anchors and everything else works fine. It's only the backdrop and border that is playing up now.
Sadly this will probably take a bit of self-testing to fix. I wish I could help more but I don't understand .lua.
Is this only an issue for world tips? World tips are those that appear when the mouse is not over a UI frame, such as a mailbox or another player in the world.
If everything else fails, adding a call to tt:ApplyBackdrop(tip) from the GTTHook_OnUpdate function should fix it all, but that seems like a final solution as calling too much stuff during OnUpdate() is a terrible idea.
If it's only world tips that's an issue, replacing the two lines of backdrop stuff on line 1021 + 1022 with tt:ApplyBackdrop(tip) should do that trick. If this is a problem with tips even on UI frames, then the call to tt:ApplyBackdrop(tip) would have to be an unconditional call in GTTHook_OnUpdate.
In fact, let me just try and post a few solutions, and if anyone wants to test them out, it would be a great help.
Contains 4 files, to test it out, overwrite the core.lua file with one of them, reload the UI and check if anything got fixed.
The 3rd one should definitely work, as that continuously sets the backdrop of the tooltip on each frame. I find it to be a horrible solution, but if nothing else works :S
I was aiming to test these out, but overwriting the core.lua with any one of those files causes the addon not to load properly. Options cannot be loaded (the /tip command doesn't even work).
Now that I think about it, WoW caches the files when you start the client, so if you add/replaces any files, a UI reload might not work, and you're forced to do a full restart. Didn't think this would be an issue as long as the files were named the same though.
Restart the game, you mean? I was completely exiting and restarting the game each time, not just doing a reload.
My mistake, there was an error in my code, meaning the file failed to load.
Re-uploaded a new file.
Confirmed that core3.lua works!!!
EDIT: I spoke too soon. It looks like the only issue with core3.lua is that it is still not skinning tooltips that appear when hovering over items in the chat window. Otherwise, it is skinning everything else just fine.
The 3rd one is unfortunately the one which applies the backdrop on every single frame update. Which I would hate to settle with as the solution.
The chat window tooltip in your screenshot seems to be mouse anchored. If so, core1.lua will probably fix that, but not the other tips.
As each file applies a fix in a different place, I just need to figure out the combination of these fixes for the final solution. Lets say fix 1 fixes that chat window item tooltip, and fix 3 fixes that other stuff, then I just need to combined those two.
If you don't mind, can you test out a few more permutations. If none of these work, I'll make an update which applies the fix everywhere.
Re-uploaded this archive with new files (5, 6, 7 and 8)
Looking through the code I noticed that all of these backdrop issues that came about in WoD, which only seems to have gotten worse in BfA, might have broken the reaction colored backdrop options.
Could you take a look and see if any of the two checkboxes under the "BG Color" option category does anything?
Current findings with the new core.lua files:
core3.lua was still the least buggy, sans the chat window skinning issue.
The BG options work fine, fortunately. But I'm still using the latest official release if that helps. - 18.07.22
Is the backdrop being applied on every frame update specifically bad, as in CPU intensive or slow the game down?
Since the last update, none of the Backdrop options work. Im getting the default blizzard border and the default blizzard background. Background color works but not always.
Generally you want to do as little as possible during the OnUpdate event, as this event fires every single frame. With tons of addons installed, it can easily bog down the whole game if every single addon does heavy taxing stuff here.
However, setting the backdrop of a frame is something that happens in the WoW C code, not in Lua, so it's not possible to see how taxing that is, and I never did any benchmarks, as the whole backdrop issue was never an issue when I played WoW. It may be nothing more than changing a pointer (which is not taxing), or it may actually create a completely new backdrop instance internally, who knows.
Thanks for all the great feedback, it has been really helpful. I should be able to figure out what to do from this.
New update probably wont be out until tomorrow though, as I've got some work in the way first.
The thing about _OnUpdate() is that for certain types Blizzard seems to reset the backdrop as well as the backdrop color, so if you style a tooltip only in _OnShow() it'll revert, so you pretty much have to reset it on _OnUpdate().
I'd have to assume that if Blizzy is resetting the backdrop that frequently that it's not that taxing.
I've got a couple hacks in and the backdrops are showing correctly everywhere (except items in blizzard frames, like the Mail Frame), and it's resetting each tooltip _OnUpdate(). I don't see a larger impact with it than without it but that might be due to my setup.
Things are ... weird in Mail, Auction, etc. They don't style even via _OnUpdate() or hooking the events directly (e.g., InboxFrameItem_OnEnter) but will if you copy the event and style within the replaced copy. I'm thinking it's a context issue of some sort even though it's GameTooltip that's explicitly called in those routines.
Aezay, I think Blizzard's out to get you :)
The more aspirin I down on this, the more I'm wondering if it wouldn't be better to just co-opt GameTooltip_UpdateStyle() and GameTooltip_SetBackdropStyle() instead of fighting with it.
Thanks for all the feedback.
I looked through the Blizzard UI code some more, and they have exposed a lot of interesting things with 8.0 which may be helpful in fixing these issues.
Replacing line 182 with the following might just fix most of the backdrop issues. Just need to recreate the .backdropBorderColor and .backdropColor.
local tipBackdrop = GAME_TOOLTIP_BACKDROP_STYLE_DEFAULT;
Seems like I really need to get some hands on time with the WoW environment to really fix this addon. Just don't feel like I have the time to get into it.
Here is the updated TipTac with some of the ideas. No idea if this will fix anything.
@Aezay for me it fixes everything, the backdrop is good everywhere (addon tooltips, skills, items, ...)
However the alpha channel is ignored (it's just the plain color I chose), but it's definitely way better. Thanks!
That sounds really good.
The Blizzard code I reuse sadly doesn't use the alpha channel. I guess I could hook it and run my own code that does apply the backdrop color with alpha.
@Aezay I wish I'd gotten your message earlier... I worked out the exact same thing not long after I posted, just hadn't had a chance to test it. It seems to be rock solid so far, even the point of pulling out some of cyclic update code in tiptac.
Edit: Since GAME_TOOLTIP_BACKDROP_STYLE_DEFAULT is being modified, the call to reset the backdrop ( ApplyBackdrop() ) in GTTHook_OnTooltipCleared() and in TipHook_OnHide() is unnecessary.
Blizzard already resets the backdrop using GAME_TOOLTIP_BACKDROP_STYLE_DEFAULT when the tooltip is closed, so TipHook_OnHide seems to be redundant.
GameTooltip_UpdateStyle is also called in OnTooltipCleared (see GameTooltipTemplate.xml).
I downloaded the new core.lua linked earlier today and it's been perfect for me. Even the BG colours work (though I don't use them)
Let's try what Vincent suggested, and if everything is still peachy then this looks like a solid release candidate.
Hopefully this update should fix things.
OnTooltipCleared is actually being called for the ShoppingTooltipTemplate, not GameTooltip. Had to update the backdrop in TipTac's OnTooltipCleared hook.
Okay latest version changed a few things. The version I downloaded before (from the URL http://aezay.dk/addons/core.lua) respected borders. The latest official release doesn't respect borders. Luckily for me, I am happy not having a border - and 99% of my tooltip are still working fine. Items, spells, doodads etc.
With one exception. Pet battle abilities still have the classic blizzard tooltip border. Mousing over pet battle buttons in the bottom panel makes it anchor to the bottom right corner.
*edit* mousing over friends in the friend list also doesn't reskin.
But you know, it's really not a big deal. I am happy :)
New version seems to work fine, but mouseover on items (on character sheet,in bag, in bags and even in Game journal) is causing unpleasant fps spikes. (Tested with solo TipTac with no other addons)
Also Azerite Gear tooltip is showing as Blizz default when i mouseover it in Journal.
@Alderon99857 the Azerite gear has a different default tooltip configuration table (GAME_TOOLTIP_BACKDROP_STYLE_AZERITE_ITEM) and we're trying to sort out the GAME_TOOLTIP_BACKDROP_STYLE_DEFAULT handling atm so Azerite item tooltips are behaving as expected.
Makes me wonder, since TipTac is piggybacking off the GAME_TOOLTIP_BACKDROP_STYLE_ logic if the configuration shouldn't be expanded to deal with those independently... (don't beat me, Aezay)
@Aezay GameTooltip_OnTooltipSetItem() calls GameTooltip_UpdateStyle() so the comparison tooltips will be reset when an item is loaded to the shipping tip (since it had to decide between default or azerite backdrops), so the OnTooltipCleared() feels excessive and I didn't notice any problems not having that there; however, I won't quibble over a few lost milliseconds. I'm thrilled to have Tiptac working again.
To post a comment, please
or register a new account.