ResetFrame too often

[mikfhan]

Nyduss04 & kljama mention 3.8-release showing wrong colors in a group for 10.1.5 retail, maybe ResetFrame is called too often?

Nyduss04: I am having a similar issue to kljama. I setup my name plates to be a more pass/fail system, where tanks have threat are green, tanks don't have threat are red, and tanks are low/losing threat are yellow. Currently, my name plates are almost always red even though the tanks have threat, and will occasionally flash green. This setup was working before the recent 10.1.5 patch. Here is an image of my current setup: https://i.imgur.com/4AtzFZS.png

kljama: Hello, after latest retail patch, this addon for me isn't working properly. The addon just, doesn't know how to say, but like it tries to color nameplates but can't, for first 2seconds it works fine but then it just colors it to default blizzard nameplates. In color border mode it just blinking colors from green to red to white (which is blizzard default) and it just can't work properly. I'm playing a tank and have this issue in raid, dungeons and outworld too. It doesn't pop any lua error so there's nothing more to share... For now im using some random threat coloring weakaura that works fine, so I guess it must be the addon issue. I'm not using any other nameplate addon, not even a UI that can overlap this addon settings, im just using default blizzard ui. Cheers! PS: this gif is the only thing that I can share to show the issue: https://s12.gifyu.com/images/SWIR4.gif hope it helps!

Maybe both could try moving retail\WTF\Account\username\SavedVariables\NamePlatesThreat.lua somewhere for safekeeping, then relaunch WoW Retail and hit the Defaults button inside AddOn options, so we have a common ground/colors for sharing our findings, and I run some random retail dungeons in a group to reproduce it on my end also.

[mikfhan]

Hmm think I already reproduced the issue - not 100% sure yet if resetFrame IS called too often or something else going on - I did some quick checks right before patching wednesday and saw no issues with color blinking, but that was entirely solo without a pet active.

Now after 10.1.5 released, as soon as I bring out the pet and enable Gradient colors, the healthbar will blink whenever threat situation changes. And if I disable Gradient colors the bar seems to get stuck in a wrong color instead of blinking so the effect is even worse.

I tried printing some debug text whenever resetFrame colors the bars or wipes the token info, but the colors also blink/stuck when I do not see this debug text so probably something else going on. Maybe I have to rollback to 3.7-release and recheck, but I just installed a new PC so notepad++ and SourceTree are not set up yet - maybe next week I have time.

[mikfhan]

Weid, it is only a problem for WoW Retail not Classic/Wrath - tried a Wrath hunter with pet, no blinking or wrong red/default color while pet is tanking, it just sticks to proper green color - almost tempted to believe Blizz snuck in some last minute changes for Retail right before patch day I missed in testing.

Blizzard apparently decided in latest WoW Retail patch that combat actions like attacking a mob should reset/redraw nameplate colors. Meaning, first my code sets the color by threat, then soon after my pet/myself attack that mob and Blizzard themselves reset the Retail nameplate color, completely unrelated to my own resetFrame logic.

Not sure I can do much about this, for now best option is to enable gradient colors so at least they only blink temporary instead of get stuck on wrong Blizzard red color - trying a workaround where I listen to combat log events now - whenever they happen I refresh nameplate threat colors 0.1 second after. Such an ugly hack, and it still blinks the color.

Anyone interested in testing the workaround can replace their NamePlatesThreat.lua with the one below, then chat command /reload and report their findings here in GitHub (especially how it behaves if you disable "color gradient" from addon options, it SHOULD only blink briefly before getting proper color again):

https://raw.githubusercontent.com/int3ro/Nameplates_Threat/mikfhan/NamePlatesThreat.lua

[kneekicker]

The 3.9-release workaround doesn't work. In fact it only makes blinking worse on my setup. I provide you with youtube link that shows the current behavior with 3.9-release .lua file.

https://www.youtube.com/watch?v=OPV-zrz6ebk

[mikfhan]

Yeah I figured as much - without the workaround the colors may get stuck in a wrong one for longer, but there is much less blinking - no idea how I can solve this if previous 3.7-release does not work either. Classic/Wrath still behave normal I believe.

https://github.com/tomrus88/BlizzardInterfaceCode/blob/24c0341aff3996fe55089e18b41e19bc40552c64/Interface/FrameXML/CompactUnitFrame.lua#L81

Yep, figured as much. Blizzard now try to only update Retail nameplate/healthbar once per frame rendered (instead of multiple times) when they are "dirty" (meaning the code health value is different from shown value, etc). In other words, whenever "UNIT_HEALTH" changes, on next frame rendered its nameplate will restore Blizzard color, working against the color NamePlatesThreat had just set.

I can't just set statusbar color on UNIT_HEALTH event itself because it's queued for next frame render instead - and if I do a C_Timer.NewTimer(0, callback) so it happens right on next frame it still blinks briefly the Blizzard default color - at least only for a slightly shorter time now (see latest 3.9-release lua candidate).

I could HookSecureFunc override their CompactUnitFrame_UpdateHealthColor but I've had bad Taint experiences with that before, maybe I need to make my own "dirty" flag for each nameplate in my own NPT array, then OnUpdate I redo updateThreatColor for those even if "color gradient" is set/not. It might even free up some CPU load but will take some time to implement and test, and no guarantees it won't still blink briefly so I have to do an easy pilot test first. Thanks Blizz.

[kneekicker]

Release 3.3 works - there's no blinking! The bug occurs from 3.4 onwards. I have no clue why, but for now the workaround is to download 3.3 version.

[mikfhan]

Great find! I have tried now to restore the two "hooksecurefunc" from that version in latest lua if you want to try it out. Please also try to chat /console taintlog 2 after /reload then we can test if the addon now will "taint" the other UI elements again. I think the way I do it now is better than 3.3-release so taint is avoided/minimized.

Your _retail_\Logs\Taint.log file after game exit will show if taint is happening (we want to avoid that if it puts the blame on NamePlatesThreat). If the taint lines only mention "TAINT FORCED" this is from default Blizzard chat frames when you exit the game, so those can be ignored (as can any from other addons - maybe best if you disable other addons while testing for taint).

[kneekicker]

I tried it yesterday, but the other add-ons were bloating the taint.log too much for it to be readable. Therefore, I redid it now with only NamePlatesThreat. Here's the log, looks empty to me. ACP is AddonControlPanel which I use to enable/disable addons with a preset. That's the only addon that's running besides NamePlatesThreat. taint.log

[kneekicker]

The blinking seems no existent on training dummies, I'll later play a mythic+ key to confirm.

[mikfhan]

Nice! You may have to disable even ACP also to be sure, sometimes taint from one addon puts blame on another one if both are active.

[kneekicker]

I didn't redo the taint log, but I was tanking mythic+ whole evening, and there was no blinking whatsoever on the latest .lua commit. Thanks for providing the fix. gn