Blizzard has glitched NamePlates!

[Wolryr]

Greetings,

First of all, excuse me if this is not posted in the proper sub-forum.

Around 3 months from now I've been experiencing this weird situation where the default Blizzard nameplates ('cause I don't use ANY nameplate AddOn) I'm not targeting will fly around when I turn around the camera. Like if they were trying to stick with my camera angle instead of the mob (only happens if the creature did cast something).

Here they're 2 quick simple sound-less videos to make things easier to understand: https://youtu.be/zceVmKO9F2A and https://youtu.be/zAeheTpqats

All of this happens when I turn off NPC Names in the Blizzard interface panel to make them appear for quest only. I really like it when just the creature I'm targeting will show its name instead of seeing every NPC name around me, it's a bit messy, so it makes things clean and simple to track for me, that's why I'm using the 'Quest Only' mode for NPC names. (As shown in the video). Sadly, this is what triggers the glitch, and when I tell Blizzard to show the names of all hostile NPCs, it stops.

Sorry to bother you all with this nonsense but it's kinda driving me insane 'cause I really like that feature, it's clean and simple, and be forced to see every NPC's name around me it's quite the opposite for the clean look I'm aiming for.

So far, I tried to call this function with a LUA code I found in an obsolete AddOn (credit to the author of course):

-- Author: Ketho (EU-Boulderfist)
-- License: Public Domain

-- show names on both friendly and enemy nameplates
for _, v1 in pairs({"Friendly", "Enemy"}) do
	for _, v2 in pairs({"displayNameWhenSelected", "displayNameByPlayerNameRules"}) do
		_G["DefaultCompactNamePlate"..v1.."FrameOptions"][v2] = false
	end
end

It will trigger some 'Interface action failed because of an AddOn' kind of stuff sometimes, but what I does for me it's: to make the nameplates show the NPC name IF I'm in combat with them, but then again, what I want it's the original Blizzard functionality as you can see in the video. The only reason to show the names in NPC nameplates will be if they're related to a quest/objective.

My apologies again, I know all of this might've sounded silly or extensive, but I've tried virtually everything at this point (all of that tested with NO AddOns whatsoever:

• Formating my PC
• Upgrading and downgrading GPU drivers
• Playing with the on-board video
• Resetting user CVars from the login screen, and with /console cvar_default
• Turning almost every interface and video options on and off (including the cursor ones) and trying different combinations
• Playing with Dx9 and Dx11
• Playing with a different mouse
• Posting a ticket (nothing, they said they'll look into it).
  
  ... the list can go on.

PD. I'm using W7 x64 (but also tried with W10), and a Nvidia GTX770.Ç

Thank you all for your help and thoughts.

[Ammako]

I've noticed this over a year ago and figured it was my fault. If it's really just a Blizzard bug then that's interesting.
I have never been able to reproduce it on demand, so testing for this is a bit difficult. It doesn't help that it doean't happen so frequently, but erratically.

This happens even without any addon touching the nameplates whatsoever? Or what about without any addons at all, actually?

[Wolryr]

Originally Posted by Ammako I've noticed this over a year ago and figured it was my fault. If it's really just a Blizzard bug then that's interesting. I have never been able to reproduce it on demand, so testing for this is a bit difficult. It doesn't help that it doean't happen so frequently, but erratically. This happens even without any addon touching the nameplates whatsoever? Or what about without any addons at all, actually?

Thank you for your answer.

Yes, this happens without ANY AddOns at all or CVars messing with my nameplates. Like, I tested in a fresh WoW client within a recently formatted PC: nameplates still bugging. Seems, in fact, it's a Blizzard bug.

Glad I'm not the only one. Let's hope they address this Soon™

That code it's from, NameplateNames, that AddOn, although outdated and obsolete, will still force the game to show the names of the NPCs I'm in combat with (on top of it's nameplates) without forcing me to use the in-game option to see every single name of every hostile around me, just those I'm hitting. And showing the name of the NPCs will stop the glitch. (Since nameplates alone, w/o names on top, it's what seems to trigger it).

It's a workaround at least. Not sure if there's a way to do it better. I don't really know much of LUA or coding.

[Ammako]

I probably wouldn't do it this way because touching the frame option tables introduces taint, still.

That code makes names show on all nameplates, still. If you wanted to have the names show only on units that are in combat with you, you would want something more like this:

hooksecurefunc("CompactUnitFrame_UpdateHealthBorder", function(frame)
    if frame.optionTable.colorNameBySelection then
        if UnitGUID(frame.unit) ~= UnitGUID("player") and UnitThreatSituation("player", frame.unit) then
            frame.name:SetText(GetUnitName(frame.unit, true))
 
            if CompactUnitFrame_IsTapDenied(frame) then
                frame.name:SetVertexColor(0.5, 0.5, 0.5);
            elseif frame.optionTable.colorNameBySelection then
                if frame.optionTable.considerSelectionInCombatAsHostile and CompactUnitFrame_IsOnThreatListWithPlayer(frame.displayedUnit) then
                    frame.name:SetVertexColor(1.0, 0.0, 0.0);
                else
                    frame.name:SetVertexColor(UnitSelectionColor(frame.unit, frame.optionTable.colorNameWithExtendedColors))
                end
            end
 
            frame.name:Show()
        else
            frame.name:Hide()
        end
    end
end)

This taints the friendly nameplates so you will get errors if you have them enabled within instances, but shouldn't cause issues anywhere else.

Having it show only for quest-related NPCs would be very complicated, because they don't directly give us access to knowing whether or not an unit is quest-related or not. It would require scanning their tooltips to know, which I don't know how to do.

Still, this would only be useful if you turned off NPC names entirely, and that breaks it anyway. If you kept NPC names set to show all names, then you wouldn't have really needed Ketho's code to begin with, I guess.

[Wolryr]

Thanks, Ammako.

Yes, what you intend with that code is pretty much what I'd like to do.

Originally Posted by Ammako If you kept NPC names set to show all names, then you wouldn't have really needed Ketho's code to begin with, I guess.

No, I don't have it set to show all names, that's what looks kind of messy. This is how I have it set up: NPC Names > Quest Only.



Also, I don't use friendly nameplates at all.

EDIT: I just tested your LUA code and it seems it removes the name of the NPC entirely UNLESS I'm in combat so I can't even see the name of the creature in it's nameplate even if I'm targeting it. Like so:



Sorry, I just deleted everything inside Ketho's LUA file and pasted your code; I don't know if that's how it's supposed to be done.

Ketho's one worked, it just mess with the friendly nameplates as well which I don't use, so thats the only thing I think that should be wiped out.

My apologies, again, if I'm addressing this in a wrong way. I appreciate your help very much.

[Ammako]

So I'm confused, either way. You want the original Blizzard functionality where names only show up if the unit is quest-related. Wouldn't that already be default behavior if you kept NPC Names on "Quest NPCs", without needing to use any addons?

That would still have the nameplate bug, though, which I imagine you're trying to find a solution where it stops happening, while still having names showing only on Quest NPCs.

Originally Posted by Wolryr Also, I don't use friendly nameplates at all, ever, so thank you for cleaning that out of the code.

I didn't clean it out of the code as much as I simply omitted making the distinction between friendly and hostile but even if I did, it's a lot more complicated than having a check for friendly vs enemy, because nameplates are shared and reused between all units. When one has been modified on an enemy unit, that nameplate may eventually end up being reused by a friendly unit, but the modification done while the nameplate was assigned to an enemy unit will have tainted it and it would cause errors when within instances.
I haven't cared enough to look into how to make modifications cleanly without breaking friendly plates in instances.

(Either that, or I already had the right idea when I was trying to add friendly nameplates checks in instances, but got the checks completely wrong and they have never been working.)

[Wolryr]

Originally Posted by Ammako That would still have the nameplate bug, though, which I imagine you're trying to find a solution where it stops happening, while still having names showing only on Quest NPCs.

Yeah, that + showing names of the units I'm in combat with .. AND if targeted (even if not in combat).

Having Hostile and Quest NPC names shown will look like this:




And that'll be too messy in crowed situations. That's where Ketho's code will come handy, 'cause it'd make it so with the NPC Names selected as Quest NPC only in the Interface menu, it'd cause only the combat units + the Quest Related + the one I target show it's name, not the entire world as you can see in that picture. The downside of the code, as you said, is that it'll taint friendly nameplates (which I don't use nor care about), because it was clearly designed to to something else, but it happened to help me here as well.

I mean, I can totally play with Ketho's code as it is, it just gives me this taint action blocked 'cause of an AddOn- messages now and then. I assume playing like that it's not optimal, but I doesn't seem to be that critical either, I guess... until the whole nameplate situation get's fixed by Blizzard, if it really ends up being a bug (which is more likely the case here). At least knowing that another person experienced the same it's comforting.

Hope I made myself clear.

Thanks again for your answers.

[Ammako]

Well, you've been saying that you wanted NPC names to show on nameplates if you are in combat with them, so that's what I did.

If you want them to appear in multiple different circumstances, then you should list those clearly, but it sounds like you just want names to appear on nameplates at all while not having them show up above everything's heads on the overworld.

hooksecurefunc("CompactUnitFrame_UpdateName", function(frame)
    if frame.optionTable.colorNameBySelection then
        if UnitGUID(frame.unit) ~= UnitGUID("player") then
            frame.name:SetText(GetUnitName(frame.unit, true))
 
            if CompactUnitFrame_IsTapDenied(frame) then
                frame.name:SetVertexColor(0.5, 0.5, 0.5);
            elseif frame.optionTable.colorNameBySelection then
                if frame.optionTable.considerSelectionInCombatAsHostile and CompactUnitFrame_IsOnThreatListWithPlayer(frame.displayedUnit) then
                    frame.name:SetVertexColor(1.0, 0.0, 0.0);
                else
                    frame.name:SetVertexColor(UnitSelectionColor(frame.unit, frame.optionTable.colorNameWithExtendedColors))
                end
            end
 
            frame.name:Show()
        else
            frame.name:Hide()
        end
 
        frame.BuffFrame:SetPoint("BOTTOM", frame.BuffFrame:GetParent(), "TOP")
    end
end)

This should just make all names show up on nameplates at all times, while the names above NPCs' models will follow your NPC Names setting.
(btw: at line 4, you can change true to false if you want names of cross-realm players show (*) instead of their full realm name, if you ever want to have friendly nameplates enabled.)

I mean, if Ketho's code does the job and it doesn't seem to be majorly breaking anything, nothing inherently wrong with using it I guess, but it does sound like it's doing something that the game doesn't like if it gives that error (even if nothing really seems to break from it.)
Also, it doesn't specifically taint friendly nameplates, but all nameplates, though I'm not sure what bugs could occur in practice due to it. You can make it affect only enemy nameplates' option table, but the game doesn't like it regardless.
The way I do it taints friendly nameplates in that it makes them no longer secure, which throws errors while in instances if friendly nameplates are enabled, but shouldn't cause issues anywhere else.

[Wolryr]

Thank you, Ammako. That one did the job perfectly.

I appreciate the amazing help. I'm sorry I was not being clear enough, it might be a little be tricky to explain without the visual references, but that code works fine: exactly what I wanted. Appreciate the effort and time to write it.

[Ammako]

Already had it all written, the only effort required was to remove other unrelated code from it if anything. ;p

[Wolryr]

Already had it all written, the only effort required was to remove other unrelated code from it if anything. ;p

But an effort, nonetheless. :P

I'm sorry to bother you again, but I notice this happens to the nameplate's debuffs using your code. It's a 30 sec vid (Ignore the audio, please). Notice how I'm targeting myself, and Skovald's debuffs on it's nameplate will get jumpy and weird. That happens only to the enemies' nameplates I'm not targeting. Is there a way to keep those from moving up and down randomly?

Sorry again, if that's too much, I'll understand.

(I tested that with no AddOns, well, just yours, of course... the one I did pasting that code into a LUA along side a .TOC)

EDIT: Just found this code to move debuffs closer to the nameplate, maybe this might help so we tell the game to adjust the offset of debuffs in a fixed location?

/run local function fn(...) for _,v in pairs(C_NamePlate.GetNamePlates())do local bf=v.UnitFrame.BuffFrame bf.baseYOffset=0 bf:UpdateAnchor()end end NamePlateDriverFrame:HookScript("OnEvent",fn)

[Ammako]

That's what I use to keep the buff frame lower like that. Didn't think buff frame position would reset like that so often without CompactUnitFrame_UpdateName() being able to catch it and re-position it back right away.

Changing the buff frame anchor point is necessary because, for nameplates with names that only appear when targeted, the game will change the buff frame's current anchor point as the name appears and disappears. When we force the names on like this, the rest of the code still thinks that the names aren't visible.

https://www.townlong-yak.com/framexm...Plates.lua#468

The code you found should work, but otherwise this is also something that can be done, I think.

hooksecurefunc(NameplateBuffContainerMixin, "UpdateAnchor", function(self)
    self:SetPoint("BOTTOM", self:GetParent(), "TOP")
end)
 
hooksecurefunc("CompactUnitFrame_UpdateName", function(frame)
    if frame.optionTable.colorNameBySelection then
        if UnitGUID(frame.unit) ~= UnitGUID("player") then
            frame.name:SetText(GetUnitName(frame.unit, true))
 
            if CompactUnitFrame_IsTapDenied(frame) then
                frame.name:SetVertexColor(0.5, 0.5, 0.5);
            elseif frame.optionTable.colorNameBySelection then
                if frame.optionTable.considerSelectionInCombatAsHostile and CompactUnitFrame_IsOnThreatListWithPlayer(frame.displayedUnit) then
                    frame.name:SetVertexColor(1.0, 0.0, 0.0);
                else
                    frame.name:SetVertexColor(UnitSelectionColor(frame.unit, frame.optionTable.colorNameWithExtendedColors))
                end
            end
 
            frame.name:Show()
        else
            frame.name:Hide()
        end
    end
end)

Can't really do more than just quickly testing for 5 minutes since I can't care to actually go out there and kill stuff, but that seemed fine to me.

[Wolryr]

Yeah, that's more like it. Seems to work pretty good so far. Friendly nameplates looking good too (tested in a dungeon).

Can't thank you enough for your help, really appreciated.