I also noticed that problem lately. That usually happens only when some player is d/c out of range or something like that. For some reason tags with 'UNIT_HEALTH' and 'UNIT_NAME_UPDATE' events do not properly update.
It's pretty easy to fix though, just force frequent update on the text region with that tag, e.g.: n.frequentUpdates = 0.5 (0.5 should be enough and not too much to affect unit frames' performance) I guess it's not the best way (sort of hackish) to do this performance wise, but so far it's the only one I managed to figure out to get rid of that weird behavior. EDIT: or wait actually never mind ^^ just noticed another topic about this issue: http://www.wowinterface.com/forums/s...ad.php?t=36869 so I guess updating TagEvents to 'UNIT_NAME_UPDATE UNIT_CONNECTION' should help :) |
seems to be working to early to tell anyways ty!
|
or not... tho its seems to maybe be tag related, gonna check them over tomorrow.
|
Solved it I think
It was the "Tag" if you call it that on the raid. Code:
"oUF_Raid", nil, 'custom [group:party,nogroup:raid40] show;hide', Code:
'oUF_Raid', nil, 'solo,party,raid,raid10,raid25,raid40' |
Going to try it, but i have the same problem with party also :)
|
Ooh this is helpful. Noticed the same thing, will try.
|
Hmm but doing solo will give you group in raid groups where you are solo in that group. Which is really bad if you have different party and raid layout and only want to have one of them at a time appear.
I think this is a bug. You get this in party aswell when at the end of a dungeon. People leave the instance. You had 5 people in the group. 3 leave. The one that stays does not get changed properly. Unitframes state him as Paladin ABC but he is Hunter XYZ. Normally you would catch that by adding "PARTY_MEMBERS_CHANGED" and "RAID_ROSTER_CHANGED" event to tags. But they provide no "unit" as an argument afaik. So not sure if you can add those to the tags. Bad. http://wowprogramming.com/docs/event...EMBERS_CHANGED http://wowprogramming.com/docs/event..._ROSTER_UPDATE If there is any possibility of adding those to the tag event list I think we can fix that. I for myself only have "party" in the visibility argument for my party header spawn and "raid" for my raid header spawn. I think the unitID and updates correctly. Because once you have hover the unit and the tooltip is correct. I think it's just the tag not getting activated. What I think is the bug is that UNIT_NAME_UPDATE doesn't get fired. If that one would be activated the unitname would update correctly. http://wowprogramming.com/docs/events/UNIT_NAME_UPDATE Workaround that could work is registering the roster_update and the party_members_changed to the header unit self objects and once they get fired call the specific tag with self.unit. That may work. |
Quote:
|
Well not for me, I have the problem and I use no fancy custom filters on the visibility argument.
Party header Code:
local party = oUF:SpawnHeader( Code:
local raid = oUF:SpawnHeader( Once I'm the only person in my group both headers will get spawned. As soon as more that one is in my group the party header disappears. |
I only use the raidframes btw, removed all partyframes and use the raid for party aswell.
The code if it helps Code:
if cfg.RaidandParty then |
This can't be the way to go, anyway. Visibility is there to be used, not to be abused to workaround something else. :p
I'll see if this happens for me, too. |
Anyhow added to old
Code:
"oUF_Raid", nil, 'custom [group:party,nogroup:raid40] show;hide' |
What kind of tag is that? The "veryshortname" tag from Nivea?
|
Quote:
Code:
oUF.Tags["veryshortname"] = function(unit) |
I just removed that tag yesterday as "left-over-code" in oUF_Slim. That 3 letter name, looked familiar. ;)
Anyway, anyone tried using a tag that does update on more events than just "UNIT_NAME_UPDATE"? That might fix it, too. |
Most of my names tags goes with a "UNIT_HEALTH UNIT_MAXHEALTH" update, never had any problem with that. Didn't try it recently though.
|
Maybe it's just at the end of an instance when all have 100% hp, someone leaves and the units are already creates. So no unit_health gets fires. But the name should update but doesn't.
|
It is not just at the end of an instance. I have seen this at start of Battlegrounds as well. During the start period everyone is at max health, and when 1 person leaves and another joins the names can get a little mixed up.
|
tested it today again and well
It does seem to be 'UNIT_NAME_UPDATE' event bug. And as I mentioned in my previous post there are 2 ways of fixing it: 1) by adding .frequentUpdates = 0.5 to the name field (although I thought that should not work as tag is not updated when we fire update on the name field... but it does oO) 2) by adding additional events to the .TagEvents like 'UNIT_HEALTH UNIT_MAXHEALTH' now I wonder which way is more efficient? |
All times are GMT -6. The time now is 10:48 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI