I need a bit of help here. I'm trying to set up a Main Tank group but it isn't working. I've set up a Raid group and that's working fine so I selected it and added a new group 'MainTanks'. It was an identical copy of 'Raid'. As a test I disabled 'Raid' and enabled 'MainTanks' nothing shows up. What am I missing? Is it not possible to have two groups of Unit Group raid? Seriously my 'Raid' and 'MainTanks' groups were identical, the first one I created shows up, the second one doesn't.
The difference in Raid group and MT group should only be the checkbox in filtering for maintanks.
Maybe you didn't see it because it was exactly the same, so also on the same position?
The difference in Raid group and MT group should only be the checkbox in filtering for maintanks.
Maybe you didn't see it because it was exactly the same, so also on the same position?
Yeah, I tried that. I just left it as Show All since nothing was showing up anyway. I tried By Class, I tried Main Tanks, I tried everything in that setting. I could not get a second raid group to show up at all. Not even when I disabled the first group.
EDIT -
Problem resolved itself, not sure what it was but I re-enabled the group that didn't work prior and now it works fine.
The raid frames seem to be killer on CPU, causing hiccups (freezing for 1 second every once every 5-15 seconds). I did a CPU profile while running raid frames to see how bad it could get:
I didn't really dig through the rest of the posts to see if it was a known problem, but I'm definitely going to leave raid frames disabled. It's a huge difference in performance from PB3, which I used a similar perfect raid style with.
Having a problem with the Totem indicator. It frequently floats up to the upper left corner of the screen rather than down in the center where I have the Player frame. If I open the config and disable then re-enable the Totem indicator, it jumps down to where I would expect to see it.
I am noticing one other behavior regarding this which may indicate a conflict with another addon. Sometimes when I disable / re-enable the totem indicators while totems are down, the place in the upper left still has totem timers where the totem indicators used to be. Not sure if those totem timers are PB4 or some other addon. I use Yata and Shaman's Friend but I have the totem timers turned off on both of those. I also use OmniCC and InlineAura. Maybe it is one of those?
What i would like is to show my health (and targets health) as Number | percent, instead of the default truncated number/truncated max | percent
Then on the ToT frame I just want %.
Every time I try to edit the text, it makes all text in the frame disappear.
Please help, and thanks in advance :)
Is it also possible to color the border based on class?
So Druid target would have orange border, warrior brown ect? (I didn't see the option for border colors, only textures) (I'm trying to do this in kgpanel, but can't get the target script to work :( )
In order to edit the LUA Code you have to select 'Custom'. What I do is copy from one of the other settings, then set to Custom, then paste and edit it to the way I want it. Then you need to hit the 'Accept' button. For instance, to just show current health | % you could use:
local s = Status(unit)
if s then
return s
end
local cur, max = HP(unit), MaxHP(unit)
if UnitIsFriend(unit,"player") then
local miss = max - cur
if miss ~= 0 then
return "|cffff7f7f%s|r || %s/%s || %s%%",Short(miss,true),Short(cur,true),Short(max,true),Percent(cur,max)
end
end
return "%s || %s%%",Short(cur,true),Percent(cur,max)
You could probably cut out some of it, it is really just the last line I edited.
Ok, I have been using PitBull4 for a while now. I've also been unhappy with my raid framerate for a while. I just learned that DogTag texts are a CPU hog thanks to gamemaster128's post above. I guess I should have taken the hint when that revision a while ago switched the default to LuaTexts, but oh well. Started the process of switching last night.
Now I just read a random post on a random forum that said there was a huge performance penalty associated with using any of the "-of-target" frames, such as target-of-target or target-of-pet. Is that still the case? Why (very curious about the technical reason, so lay it on me)? Will it be fixed?
Also if i don't want it short, is "long" an option?
You know, I just try all of the different default options until I find something that has what I want then cut and paste it into custom. Not sure what you want in 'Long' but I suspect if you hunt around in the defaults in the drop down you'll find what you're looking for.
Now I just read a random post on a random forum that said there was a huge performance penalty associated with using any of the "-of-target" frames, such as target-of-target or target-of-pet. Is that still the case? Why (very curious about the technical reason, so lay it on me)? Will it be fixed?
The units in question are the ones marked with a * at the end of their name in the unit selectboxes.
The semi-technical explanation is that blizzard doesn't send as many types of events for those unittypes. As such they have to be queried manually every so often for changes. I believe Shefki has already put some throttling mechanisms in place, but one need to be careful to not negatively influence the percieved reaction time to the user.
So in essence, there's still some room for performance fixes but you shouldn't hold your breath for it.
The units in question are the ones marked with a * at the end of their name in the unit selectboxes
This should be documented somehow on that screen, so people can learn it themselves.
Thanks for the explanation. I appreciate it. I guess all unit frame addons are affected? I can probably do without those frames -- I'll at least experiment to see whether there's a difference!
In that session I was. Even with LuaTexts, performance is too sluggish. I'm happy that I switched to another UF (shadowed).
I belive that this is actually LibDogTag-3.0 and LibDogTag-Unit-3.0 doing this. While you're using LuaTexts if you're using an embedded copy of PitBull4 (which is pretty much what most people use) then it's going to load LibDogTag anyway because we haven't shifted modules to be separate LoD addons yet.
You can confirm this by taking the following steps:
You can verify that LibDogTag is not loaded by trying to use the /dogtag command. If nothing happens except for the /help bit when you use an invalid command then it's not loaded. If you get a dialog box about DogTag then it is still loaded.
If the problem continues despite LibDogTag not being loaded then it's something within PB4. If not then it's a LibDogTag issue and should be reported to them. In the latter case you can leave those lines commented out to keep it from loading and you won't have the problem. If you update you'll have to do it again until we switch to Load on Demand modules.
(The above is a copy and paste job from my reply to another ticket, but I'm posting this here in reply to this poster because a lot of performance related stuff is turning up as actually just being LibDogTag still being loaded. I of course run disembeded and no longer even load LibDogTag unless I'm specifically needing the DogTagTexts module. It's my intention to fix this issue by getting DogTagTexts into a sepearate addon entirely and making it load on demand. Which of course would then pull in LibDogTag only if it loaded.)
Before I open a ticket, I wanted to ask if there is any obvious reason why with the new bar coloring options, "Color NPCs by hostility" does not appear to work with "Blank space" bars. (In addtion, the "Color by hostility" option has no effect on "Blank space" bars for units that are NPCs.)
Before I open a ticket, I wanted to ask if there is any obvious reason why with the new bar coloring options, "Color NPCs by hostility" does not appear to work with "Blank space" bars.
Was a typo.
(In addtion, the "Color by hostility" option has no effect on "Blank space" bars for units that are NPCs.)
That option only applies to player characters, we probably should update the description to make that clearer.
Okay, so I've had a go at Ticket 398 (hiding other bars while casting) and posted my results in the ticket here. Made some progress, and this was much easier than I thought. After seeing all the commits to improve bar handling, I figured now was as good a time as any to see what was involved.
As I state in the comment with the attachment, my own personal desire is to be able to hide other bars while the player is casting. More specifically, I'd like to hide the Power Bar whenever the Cast Bar is being displayed. Because the Cast Bar often stays displayed after a cast (in order to say "Interrupted" or whatever), my current hack sees the Power Bar come back too early. And there's some nuisance misbehaviour I'm noticing when I'm busy in-combat.
Having done zero unitframes programming before, I've made some mistakes and I'm not sure exactly what the finished code should look like. If anyone with more experience wants to take a look and show me what to do, that would be terrific. :)
As far as optimizing goes, with the Power Bar set to "Hide on cast", we now have Power Bars that listen for cast events, which is less optimal than the official code. However, while the bar is now hidden we (hopefully) aren't updating any LuaTexts on it and we aren't redrawing it constantly. If this was done properly, I'm not convinced such behaviour will have a net deficit on performance.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Thanks in advance, any ideas appreciated.
Maybe you didn't see it because it was exactly the same, so also on the same position?
Yeah, I tried that. I just left it as Show All since nothing was showing up anyway. I tried By Class, I tried Main Tanks, I tried everything in that setting. I could not get a second raid group to show up at all. Not even when I disabled the first group.
EDIT -
Problem resolved itself, not sure what it was but I re-enabled the group that didn't work prior and now it works fine.
The raid frames seem to be killer on CPU, causing hiccups (freezing for 1 second every once every 5-15 seconds). I did a CPU profile while running raid frames to see how bad it could get:
AV, actively PvPing away from the main raid group: http://i29.tinypic.com/k54qch.jpg
1200 secs worth of profiling done while doing Heroic UP: http://i27.tinypic.com/154j52w.jpg
I didn't really dig through the rest of the posts to see if it was a known problem, but I'm definitely going to leave raid frames disabled. It's a huge difference in performance from PB3, which I used a similar perfect raid style with.
Are you using DogTags? You might want to try LuaText. There is a huge difference in performance.
I am noticing one other behavior regarding this which may indicate a conflict with another addon. Sometimes when I disable / re-enable the totem indicators while totems are down, the place in the upper left still has totem timers where the totem indicators used to be. Not sure if those totem timers are PB4 or some other addon. I use Yata and Shaman's Friend but I have the totem timers turned off on both of those. I also use OmniCC and InlineAura. Maybe it is one of those?
What i would like is to show my health (and targets health) as Number | percent, instead of the default truncated number/truncated max | percent
Then on the ToT frame I just want %.
Every time I try to edit the text, it makes all text in the frame disappear.
Please help, and thanks in advance :)
Is it also possible to color the border based on class?
So Druid target would have orange border, warrior brown ect? (I didn't see the option for border colors, only textures) (I'm trying to do this in kgpanel, but can't get the target script to work :( )
You could probably cut out some of it, it is really just the last line I edited.
return "%s%%",Percent(cur,max)
for my ToT frame?
Also if i don't want it short, is "long" an option?
Now I just read a random post on a random forum that said there was a huge performance penalty associated with using any of the "-of-target" frames, such as target-of-target or target-of-pet. Is that still the case? Why (very curious about the technical reason, so lay it on me)? Will it be fixed?
You know, I just try all of the different default options until I find something that has what I want then cut and paste it into custom. Not sure what you want in 'Long' but I suspect if you hunt around in the defaults in the drop down you'll find what you're looking for.
The units in question are the ones marked with a * at the end of their name in the unit selectboxes.
The semi-technical explanation is that blizzard doesn't send as many types of events for those unittypes. As such they have to be queried manually every so often for changes. I believe Shefki has already put some throttling mechanisms in place, but one need to be careful to not negatively influence the percieved reaction time to the user.
So in essence, there's still some room for performance fixes but you shouldn't hold your breath for it.
This should be documented somehow on that screen, so people can learn it themselves.
Thanks for the explanation. I appreciate it. I guess all unit frame addons are affected? I can probably do without those frames -- I'll at least experiment to see whether there's a difference!
In that session I was. Even with LuaTexts, performance is too sluggish. I'm happy that I switched to another UF (shadowed).
I belive that this is actually LibDogTag-3.0 and LibDogTag-Unit-3.0 doing this. While you're using LuaTexts if you're using an embedded copy of PitBull4 (which is pretty much what most people use) then it's going to load LibDogTag anyway because we haven't shifted modules to be separate LoD addons yet.
You can confirm this by taking the following steps:
a) Make sure you're not using any other addons that need LibDogTag, you can find a list of the addons that use LibDogTag here: http://www.wowace.com/addons/libdogtag-3-0/reverse-relationships/ If you are using any of those other addons, turn them off for now.
b) Make sure that LibDogTag-3.0 and/or LibDogTag-Unit-3.0 do not show up as addons in your addon list, if so turn them off.
c) Log out of the game and edit the libs.xml file in your Interface/AddOns/PitBull4 directory. Find two lines that look like so:
And make them look like so:
You can verify that LibDogTag is not loaded by trying to use the /dogtag command. If nothing happens except for the /help bit when you use an invalid command then it's not loaded. If you get a dialog box about DogTag then it is still loaded.
If the problem continues despite LibDogTag not being loaded then it's something within PB4. If not then it's a LibDogTag issue and should be reported to them. In the latter case you can leave those lines commented out to keep it from loading and you won't have the problem. If you update you'll have to do it again until we switch to Load on Demand modules.
(The above is a copy and paste job from my reply to another ticket, but I'm posting this here in reply to this poster because a lot of performance related stuff is turning up as actually just being LibDogTag still being loaded. I of course run disembeded and no longer even load LibDogTag unless I'm specifically needing the DogTagTexts module. It's my intention to fix this issue by getting DogTagTexts into a sepearate addon entirely and making it load on demand. Which of course would then pull in LibDogTag only if it loaded.)
Was a typo.
That option only applies to player characters, we probably should update the description to make that clearer.
As I state in the comment with the attachment, my own personal desire is to be able to hide other bars while the player is casting. More specifically, I'd like to hide the Power Bar whenever the Cast Bar is being displayed. Because the Cast Bar often stays displayed after a cast (in order to say "Interrupted" or whatever), my current hack sees the Power Bar come back too early. And there's some nuisance misbehaviour I'm noticing when I'm busy in-combat.
Having done zero unitframes programming before, I've made some mistakes and I'm not sure exactly what the finished code should look like. If anyone with more experience wants to take a look and show me what to do, that would be terrific. :)
As far as optimizing goes, with the Power Bar set to "Hide on cast", we now have Power Bars that listen for cast events, which is less optimal than the official code. However, while the bar is now hidden we (hopefully) aren't updating any LuaTexts on it and we aren't redrawing it constantly. If this was done properly, I'm not convinced such behaviour will have a net deficit on performance.