Authors CurseForge

Quote from Shefki

In particular for some reason there is a taint issue that makes changes happening to your raid frames break. Spending quite a bit of time digging into this I believe this to be a but in the actual SecureTemplates. I haven't tracked the exact source down yet but I have verified this bug still exists on the PTR. If I can track it down I can hopefully come up with a patch to contribute to Blizzard and see if I can't get it included in the next client update.

I've found the problem with this. It was actually something PitBull4 was doing that it shouldn't have been doing. I've recoded around it and these bugs should be gone with the latest Alpha push. If this proves effective I'll probably tag a beta to get this out to a wider audience.

Quote from rloli

In Pitbull4 however, debuffs don't recognize the presence of buffs (and viceversa) and just interpose each other as seen in this SS where exhaustion is covering half of Fort and another unseen buff.

See my reply on the ticket of yours that I closed:
http://www.wowace.com/projects/pitbull4/tickets/482-buffs-and-debuffs-interpose-each-other/

We've had a long standing taint bug that prevented us from properly creating new group frames while in combat. The SecureTemplates were supposed to allow us to do this but our bug prevented this. To avoid this we pre-created all the frames in PB4. Which worked in most cases but it still broke in the case that Allara recently brought up. I've fixed the root bug of all of these problems and did a bunch of work to bring PB4 back towards the creation of frames on the fly even in combat. The latest alpha pushes includes all of this work. I have not turned off the force creation of frames in advance yet. This is my intention however.

Quote from rloli

I'm aware of the width adjustment however the purpose of my post was to find a way of having all my buffs in 100% width unless the existence of a debuff as it was possible in Pitbull3.

I wasn't sure if it was my problem, the mod's or it was working as intended.

Thanks for the prompt response

Working as intended. There's no way to do that currently.

any ideas on the tags for player/etc that are generating the non-stop errors?

Quote from Allara

Noticed some odd behavior tonight in my raid. After a wipe, when everyone was re-entering the instance, all the raid pet and MT target frames would periodically flash on and then off briefly. This would happen several times randomly as people re-entered the instance, summoned their pets, etc. *All* the raid pet frames would flash on for like one frame, then go away. Not just the ones where pets existed.

Wanted to let you know that I've identified the cause of this. You can actually force it to happen by changing your title of all things. We're using the SecureGroupHeader in an unintended way. As a result we're butting up on a conflict between the design of the SecureTemplates and the SecureStateDriver. The group header for say raid pets is actually just another raid group header. It doesn't actually know that we're displaying pets. We then set a unitsuffix on it and ask the SecureStateDriver to hide/show the frames based on the existance of the unit. Whenever a GroupHeader update is triggered then it shows all the pet frames for the raid units that exist because it doesn't know they're pet frames. On the next OnUpdate cycle the SecureStateDriver hides them again.

The solution to this is to simply hide all our controls when the frames are hidden and then show them again when we go to update the frame. This issue didn't show up until recently or in PB3 because we were removing all the controls from the unit frames on hide and they didn't get repopulated until the frame was actually supposed to be shown.

I finally tracked this down because today in my raid someone was running a title rotating addon which trips a UNIT_NAME_UPDATE event and forces all the group headers to update. They were rotating their title once a second so the whole raid I had the pet frames flashing. After the raid I went to try and fix this and couldn't replicate it anymore. I remembered the discussion about the title rotating addon and connected the two.

Which leads me to my other commentary. I'd strongly suggest that you discourage your friends from using these title rotating addons. I'm sure they're very cool but they create load on the entire game and on other players systems from the UNIT_NAME_UPDATE events.

I posted about this here on the UI & Macros forums:
http://forums.worldofwarcraft.com/thread.html?topicId=18315579567&sid=1

Which resulted in a response from Xinhuan which very likely will result in the fix to the continued stuttering problems in AV. In the process of rewriting PitBull we lost the unregistering of the UNIT_NAME_UPDATE event on our group headers as we had done in PB3.

I need to test all of this tomorrow. Once I've tested it I'll push out another alpha with all of these changes. But for now I'm heading to bed.

Quote from Shefki

You'd need to use UpdateIn() or I'd need to specifically add some sort of support for modifier keys. There's no global event for key presses. There are OnKeyUp and OnKeyDown events but you only receive them when your frame has the keyboard focus, which means it's the only frame receiving them, which is pretty much not what you want. So either way it'd have to be checked on a timer. Me adding the support would probably be more effiicient. I'm just not sure if I want to do it because it would create some extra overhead that I don't know if it's worthwhile because I doubt many people use that. However, if I don't do it then you're eating extra overhead since you have to produce the entire string over again.

I'll think on this.

Any news on this? Couldn't find anything in the changelog, so do we still need UpdateIn()?

And a question to the default code of the percentage energy text. The code is

local max = MaxPower(unit)
if max > 0 then
  return "%s%%",Percent(Power(unit),MaxPower(unit))
end

Have I missed something or is the second call to MaxPower() not really needed?

edit: Oh, and another question:
In PitBull3 multiple colors could be configured for the castbar (casting, channelling, complete, fail). I can't find this option in Pitbull4 and I also can't find a ticket for it. Am I just blind or does really nobody miss that feature?

edit2: And I have a little problem:
My party frames are also shown if I convert the party to a raid. But in the group settings only the "show in party" option is checked. Any help would be nice :)
edit3: Oh, the party frames are only hidden if more than 5 members are in the raid. Can this be disabled somewhere?

Quote from bossmansmith

I updated to the newest version today and I can no longer find an option to hide the blizzard default buffs. Any help would be appreciated.

Modules, Hide Blizzard frames, Buffs/debuffs