Gotcha. Yay for Blizzard expanding their API! Now if only they'd done this stuff four years ago...
We'd asked for it and were told the client didn't have the info. My guess would be the 2.4 combat log revamp changed that situation and they finally got around to give it to us.
You'd need to use UpdateIn() or I'd need to specifically add some sort of support for modifier keys. (...)
I'll think on this.
So will I. I was wanting to use them to hide raid frame names in a sensible fashion, but I'm not seeing it implementing like I want it. I did get UpdateIn working though.
This might not be the thread to ask, but it is related to PB. I'm trying to make my raid Text 100% alpha regardless of range. [Alpha(1)] doesn't seem to work because all text is link to frame strata. I had the same problem with trying to Parent Panels to the raid frames. Any suggestions?
This might not be the thread to ask, but it is related to PB. I'm trying to make my raid Text 100% alpha regardless of range. [Alpha(1)] doesn't seem to work because all text is link to frame strata. I had the same problem with trying to Parent Panels to the raid frames. Any suggestions?
Can't be done. It has nothing to do with strata. Any child frames inherit the Alpha of the parent frames. The only way around this would be to reparent all the frames, which would be a pain in the butt.
As of the push tonight I believe the major performance issues are taken care of and generally serious bugs are fixed. There are of course a few here and there and some feature enhancements I'd really like to do. But the point here is that I consider us pretty much to be pretty much to a beta state.
While I consider us to be at that point I won't be immediately tagging the project as a beta. I'm gonna let PB4 simmer for a little bit to see if some things come up. I figure it'll get tagged probably sometime this weekend.
All that being said I wanted to talk about performance. Particularly as to how it is going to impact this timeline. I'm very interested in performance problems. PitBull in the past has had adequate performance, but it still has been somewhat lacking. I think we can provide the configuration options that our picky users want while still maintaining top notch performance.
As of the changes tonight during a typical AV run PB3+DogTags will use about 3.6 seconds of CPU time per minute of battleground time. PB4 using LuaTexts is using about 2.5 seconds of CPU time per minute of battleground time. PB4+DogTags is using about 6.4 seconds of CPU time per minute of battleground time.
The above is with roughly identical configurations between the 3 different setups. The DogTag performance numbers is including the time the LibDogTags-3.0 and LibDogTags-Unit-3.0 libraries took (PitBull was the only addon using them).
I strongly recommend that people still using DogTags and having performance problems migrate to LuaTexts. When reporting performance problems please do say if you're using DogTagTexts or LuaTexts, as you can see there is a drastic performance difference.
I have a pretty good idea as to what is causing the performance problems with DogTagTexts. Unfortunately, I don't have a very good solution for the problem. DogTags was largely written with PitBull3 and CowTip in mind. PitBull3 puts a lot of work on the individual modules to know when to update frames, particularly frames that we do not receive events for. PB4 includes this work in the core. Unfortunately, DogTags takes on this work and it gets doubled up. This explains the performance numbers seen above as the PB4 number is slightly less than double the PB3 DogTag number.
As a result of this it's almost guaranteed that I'll be switching the default text provider to LuaTexts.
I want to be clear that I'm not giving up on fixing DogTagsTexts. However, it was always the intention of making a lighter weight text provider be the default. I'm going to encourage people to shift to LuaTexts pretty strongly. I hope this post helps people make the decision to switch.
I also hope it demonstrates that PB4 is at this point outperforming PB3 with the exception of DogTags. I look forward to your feedback.
As of the push tonight I believe the major performance issues are taken care of and generally serious bugs are fixed. There are of course a few here and there and some feature enhancements I'd really like to do. But the point here is that I consider us pretty much to be pretty much to a beta state.
While I consider us to be at that point I won't be immediately tagging the project as a beta. I'm gonna let PB4 simmer for a little bit to see if some things come up. I figure it'll get tagged probably sometime this weekend.
All that being said I wanted to talk about performance. Particularly as to how it is going to impact this timeline. I'm very interested in performance problems. PitBull in the past has had adequate performance, but it still has been somewhat lacking. I think we can provide the configuration options that our picky users want while still maintaining top notch performance.
As of the changes tonight during a typical AV run PB3+DogTags will use about 3.6 seconds of CPU time per minute of battleground time. PB4 using LuaTexts is using about 2.5 seconds of CPU time per minute of battleground time. PB4+DogTags is using about 6.4 seconds of CPU time per minute of battleground time.
The above is with roughly identical configurations between the 3 different setups. The DogTag performance numbers is including the time the LibDogTags-3.0 and LibDogTags-Unit-3.0 libraries took (PitBull was the only addon using them).
I strongly recommend that people still using DogTags and having performance problems migrate to LuaTexts. When reporting performance problems please do say if you're using DogTagTexts or LuaTexts, as you can see there is a drastic performance difference.
I have a pretty good idea as to what is causing the performance problems with DogTagTexts. Unfortunately, I don't have a very good solution for the problem. DogTags was largely written with PitBull3 and CowTip in mind. PitBull3 puts a lot of work on the individual modules to know when to update frames, particularly frames that we do not receive events for. PB4 includes this work in the core. Unfortunately, DogTags takes on this work and it gets doubled up. This explains the performance numbers seen above as the PB4 number is slightly less than double the PB3 DogTag number.
As a result of this it's almost guaranteed that I'll be switching the default text provider to LuaTexts.
I want to be clear that I'm not giving up on fixing DogTagsTexts. However, it was always the intention of making a lighter weight text provider be the default. I'm going to encourage people to shift to LuaTexts pretty strongly. I hope this post helps people make the decision to switch.
I also hope it demonstrates that PB4 is at this point outperforming PB3 with the exception of DogTags. I look forward to your feedback.
Would love to make the swap to lua text, but unfortunately im to much of a lua noob to even begin to understand how to translate my DogTags to lua texts :(
Is there any plans to add layout inheritance at all. One feature that I find slightly frustrating if once I have my layouts set, and I want to alter something, I have to go though each individual layout to do so. This could end up been quite a few layouts.
A prime example of this is for example my Player and Target frames are almost identical, the only difference been I have Aura's configured on my Target frame. This ofc incurs two layouts, (I copied my Player Layout once I 'thought' I'd finished with it) so if I change one I then have to change the other.
If the Target frame could inherit its layout from the Player frame, I could simply alter the layout of the Player frame, effecting the Target frame aswell. Any settings on the Target frame which differ from the Player frame would be considered overridden (in this case Aura's).
Is this something which has (or is been considered) and if not, is there a reason why this approach wasn't taken.
As a result of this it's almost guaranteed that I'll be switching the default text provider to LuaTexts.
The only danger here is that LuaTexts just isn't as user friendly as DogTags. While I'm fine with writing Lua for my texts a lot of people aren't. Is the long term plan for LuaTexts to make the syntax more like DogTags (and by that I don't mean DogTag syntax specifically but just that it is a lot more abstracted from the code), or would that just lead to the same problems that we have with DogTags now?
Is the long term plan for LuaTexts to make the syntax more like DogTags (and by that I don't mean DogTag syntax specifically but just that it is a lot more abstracted from the code), or would that just lead to the same problems that we have with DogTags now?
I would say that for the most part, that's what we already have. I see 52 helper functions already in the script environment, which almost all emulate DogTags to some degree. I'm sure more can be added if they are necessary.
The only danger here is that LuaTexts just isn't as user friendly as DogTags. While I'm fine with writing Lua for my texts a lot of people aren't. Is the long term plan for LuaTexts to make the syntax more like DogTags (and by that I don't mean DogTag syntax specifically but just that it is a lot more abstracted from the code), or would that just lead to the same problems that we have with DogTags now?
I'm fully aware that it's not as friendly. My experience in talking with users is that while quite a few people do modify their texts extensively. Most people just use the ones in the drops downs and that's it. Of the people that modify them. A number of them go to a forum and find code already written for them.
Making LuaTexts the default really only impacts people who start out with new profiles. If they want to use DogTags all they'll have to do is turn off LuaTexts and turn on DogTags. It's really that simple.
For the most part I consider LuaTexts to be done. There are a couple of things that people want to do that are a real pain right now. I'm debating on if they're worth adding. However, I think at this point 99% of DogTags being used with PitBull can be converted relatively easily.
Performance wise probably the biggest difference is our behavior towards events and avoiding repeated API calls. DogTags listens to all the events that it possibly can. When it receives an event it dispatches it to all the relevent texts that needs it. If there are no texts then it wastes CPU time figuring out if there is an text that would need that event or not. DogTags also encourages repeated API calls. A simple tag like:
[HP] / [MaxHP] || [PercentHP]
Ends up calling UnitHP and UnitHPMax twice. This may not seem like much but it adds up when you're in large groups where the health is changing repeatedly.
LuaTexts helper functions were written in many cases to discourage this. There is no PercentHP function there's just a Percent function. Lua affords us the option to have variables to save the returns of the functions and then reuse them.
The more you disconnect the user from what they're actually telling the machine to do the more difficult it is to be efficient. It's entirely possible for something like DogTags to be made very efficient. However, it's very difficult to do that in an interpreted environment where you can't necessarily spend the time that a compiler of a higher level language might spend optimizing the code.
Is there any plans to add layout inheritance at all. One feature that I find slightly frustrating if once I have my layouts set, and I want to alter something, I have to go though each individual layout to do so. This could end up been quite a few layouts.
A prime example of this is for example my Player and Target frames are almost identical, the only difference been I have Aura's configured on my Target frame. This ofc incurs two layouts, (I copied my Player Layout once I 'thought' I'd finished with it) so if I change one I then have to change the other.
If the Target frame could inherit its layout from the Player frame, I could simply alter the layout of the Player frame, effecting the Target frame aswell. Any settings on the Target frame which differ from the Player frame would be considered overridden (in this case Aura's).
Is this something which has (or is been considered) and if not, is there a reason why this approach wasn't taken.
It's been talked about but providing a configuration UI for this is very difficult. Right now we're using AceConfigDialog which wasn't designed with this in mind at all. We'd have to provide a way to show what was being inherited and what was not. In order to do that we'd have to litter the UI with checkboxes.
I'll admit it would be convenient for users like yourself. But I don't see it happening anytime soon. PB4 really wasn't designed with this in mind and bolting it on at this point would be pretty difficult.
Shefki you know that some units' portraits in the game show up as full body even if you've dechecked that option? And if you check that option when you have that mob selected he turns into portrait view, i.e. it's inversed. Well I've added a custom code to the portait module that will handle such issues correctly, wonder if you could implement this.
The function to be changed is ofc modelOnUpdate(arg1, arg2).
local function model_OnUpdate(self, elapsed)
[COLOR=Red]local inverseFullBodyNPCs = {[/COLOR]
[COLOR=Red]["woolyrhino"] = true,[/COLOR] [COLOR=Green]-- Rhinos in Northrend[/COLOR]
[COLOR=Red]["felorcmale"] = true,[/COLOR] [COLOR=Green]-- Fel Orcs in Outland[/COLOR]
[COLOR=Red]["fleshtitan"] = true,[/COLOR] [COLOR=Green]-- Thrym and Thaddius[/COLOR]
[COLOR=Red]["facelessone"] = true,[/COLOR] [COLOR=Green]-- Faceless Ones in Ahn'Kahet and Ulduar[/COLOR]
[COLOR=Red]}[/COLOR]
[COLOR=Red]local Unit_File = self:GetModel();
if (type(Unit_File) == "string") then
while(strfind(Unit_File,"\\")) do
Unit_File = strsub(Unit_File,strfind(Unit_File,"\\")+1);
end
Unit_File = gsub(Unit_File,".m2","");
Unit_File = gsub(Unit_File,".mdx","");
end [/COLOR]
self:SetScript("OnUpdate", nil)
local frame = self:GetParent()
local layout_db = PitBull4_Portrait:GetLayoutDB(frame)
if not layout_db.full_body [COLOR=Red]and not inverseFullBodyNPCs[Unit_File][/COLOR] then
self:SetCamera(0)
[COLOR=Red]else
self:SetCamera(1)[/COLOR]
end
if type(self:GetModel()) ~= "string" then
-- the portrait wasn't set properly, let's try again
PitBull4_Portrait:Clear(frame)
PitBull4_Portrait:Update(frame)
end
end
That's not really the right way to fix that problem. But I was looking at the Portrait issues last night. That said I'm not inclined to start making and maintaining a list of models that are messed up.
Seriously, there has got to be a better way to fix this problem. If anything I'd rather submit this as a bug to Blizzard and have them fix the reversed cameras on the models than start doing this. It's gonna be an endless maintenance task.
Edit: To be clear. Some things we have to work around because it's just the way they are. But working around every bug or glitch in WoW is in impossible task. Some things are just best fixed where they are broken. On top of that I'm not even 100% sure that those models are broken at this point. We have an issues where we're not properly setting the camera. Target yourself after a fresh reload. Your portrait is just the head. Now clear your target and target yourself again. Ohh look full size now. Target someone else without clearing your target. Head again. Now target yourself again without clearing the target, still just the head. Clear the target and target yourself, now we're back to full size.
Basically there are deeper problems in the Portrait module. I'm not gonna start throwing hacks on top of it for this sort of thing until I work these issues out.
As far as the portrait on mobs issue. See this ticket. I reworked your changes and made a patch. But I have not applied it to main. I'm still undecided if I want to include this in main.
Seriously, there has got to be a better way to fix this problem. If anything I'd rather submit this as a bug to Blizzard and have them fix the reversed cameras on the models than start doing this. It's gonna be an endless maintenance task.
Edit: To be clear. Some things we have to work around because it's just the way they are. But working around every bug or glitch in WoW is in impossible task. Some things are just best fixed where they are broken. On top of that I'm not even 100% sure that those models are broken at this point. We have an issues where we're not properly setting the camera. Target yourself after a fresh reload. Your portrait is just the head. Now clear your target and target yourself again. Ohh look full size now. Target someone else without clearing your target. Head again. Now target yourself again without clearing the target, still just the head. Clear the target and target yourself, now we're back to full size.
Basically there are deeper problems in the Portrait module. I'm not gonna start throwing hacks on top of it for this sort of thing until I work these issues out.
That was code for Pitbull 3! And by the way that was before I discovered that you could capture the unit by its model name instead of GUID. See the difference? I don't have to list every single mob, only its model (felorcmale).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe'd asked for it and were told the client didn't have the info. My guess would be the 2.4 combat log revamp changed that situation and they finally got around to give it to us.
So will I. I was wanting to use them to hide raid frame names in a sensible fashion, but I'm not seeing it implementing like I want it. I did get UpdateIn working though.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCan't be done. It has nothing to do with strata. Any child frames inherit the Alpha of the parent frames. The only way around this would be to reparent all the frames, which would be a pain in the butt.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs of the push tonight I believe the major performance issues are taken care of and generally serious bugs are fixed. There are of course a few here and there and some feature enhancements I'd really like to do. But the point here is that I consider us pretty much to be pretty much to a beta state.
While I consider us to be at that point I won't be immediately tagging the project as a beta. I'm gonna let PB4 simmer for a little bit to see if some things come up. I figure it'll get tagged probably sometime this weekend.
All that being said I wanted to talk about performance. Particularly as to how it is going to impact this timeline. I'm very interested in performance problems. PitBull in the past has had adequate performance, but it still has been somewhat lacking. I think we can provide the configuration options that our picky users want while still maintaining top notch performance.
As of the changes tonight during a typical AV run PB3+DogTags will use about 3.6 seconds of CPU time per minute of battleground time. PB4 using LuaTexts is using about 2.5 seconds of CPU time per minute of battleground time. PB4+DogTags is using about 6.4 seconds of CPU time per minute of battleground time.
The above is with roughly identical configurations between the 3 different setups. The DogTag performance numbers is including the time the LibDogTags-3.0 and LibDogTags-Unit-3.0 libraries took (PitBull was the only addon using them).
I strongly recommend that people still using DogTags and having performance problems migrate to LuaTexts. When reporting performance problems please do say if you're using DogTagTexts or LuaTexts, as you can see there is a drastic performance difference.
I have a pretty good idea as to what is causing the performance problems with DogTagTexts. Unfortunately, I don't have a very good solution for the problem. DogTags was largely written with PitBull3 and CowTip in mind. PitBull3 puts a lot of work on the individual modules to know when to update frames, particularly frames that we do not receive events for. PB4 includes this work in the core. Unfortunately, DogTags takes on this work and it gets doubled up. This explains the performance numbers seen above as the PB4 number is slightly less than double the PB3 DogTag number.
As a result of this it's almost guaranteed that I'll be switching the default text provider to LuaTexts.
I want to be clear that I'm not giving up on fixing DogTagsTexts. However, it was always the intention of making a lighter weight text provider be the default. I'm going to encourage people to shift to LuaTexts pretty strongly. I hope this post helps people make the decision to switch.
I also hope it demonstrates that PB4 is at this point outperforming PB3 with the exception of DogTags. I look forward to your feedback.
Would love to make the swap to lua text, but unfortunately im to much of a lua noob to even begin to understand how to translate my DogTags to lua texts :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTry holding down shift when moving them. I'm pretty sure that's the snap to feature.
A prime example of this is for example my Player and Target frames are almost identical, the only difference been I have Aura's configured on my Target frame. This ofc incurs two layouts, (I copied my Player Layout once I 'thought' I'd finished with it) so if I change one I then have to change the other.
If the Target frame could inherit its layout from the Player frame, I could simply alter the layout of the Player frame, effecting the Target frame aswell. Any settings on the Target frame which differ from the Player frame would be considered overridden (in this case Aura's).
Is this something which has (or is been considered) and if not, is there a reason why this approach wasn't taken.
Cheers
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would say that for the most part, that's what we already have. I see 52 helper functions already in the script environment, which almost all emulate DogTags to some degree. I'm sure more can be added if they are necessary.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm fully aware that it's not as friendly. My experience in talking with users is that while quite a few people do modify their texts extensively. Most people just use the ones in the drops downs and that's it. Of the people that modify them. A number of them go to a forum and find code already written for them.
Making LuaTexts the default really only impacts people who start out with new profiles. If they want to use DogTags all they'll have to do is turn off LuaTexts and turn on DogTags. It's really that simple.
For the most part I consider LuaTexts to be done. There are a couple of things that people want to do that are a real pain right now. I'm debating on if they're worth adding. However, I think at this point 99% of DogTags being used with PitBull can be converted relatively easily.
Performance wise probably the biggest difference is our behavior towards events and avoiding repeated API calls. DogTags listens to all the events that it possibly can. When it receives an event it dispatches it to all the relevent texts that needs it. If there are no texts then it wastes CPU time figuring out if there is an text that would need that event or not. DogTags also encourages repeated API calls. A simple tag like:
Ends up calling UnitHP and UnitHPMax twice. This may not seem like much but it adds up when you're in large groups where the health is changing repeatedly.
LuaTexts helper functions were written in many cases to discourage this. There is no PercentHP function there's just a Percent function. Lua affords us the option to have variables to save the returns of the functions and then reuse them.
The more you disconnect the user from what they're actually telling the machine to do the more difficult it is to be efficient. It's entirely possible for something like DogTags to be made very efficient. However, it's very difficult to do that in an interpreted environment where you can't necessarily spend the time that a compiler of a higher level language might spend optimizing the code.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's been talked about but providing a configuration UI for this is very difficult. Right now we're using AceConfigDialog which wasn't designed with this in mind at all. We'd have to provide a way to show what was being inherited and what was not. In order to do that we'd have to litter the UI with checkboxes.
I'll admit it would be convenient for users like yourself. But I don't see it happening anytime soon. PB4 really wasn't designed with this in mind and bolting it on at this point would be pretty difficult.
The function to be changed is ofc modelOnUpdate(arg1, arg2).
local function model_OnUpdate(self, elapsed) [COLOR=Red]local inverseFullBodyNPCs = {[/COLOR] [COLOR=Red]["woolyrhino"] = true,[/COLOR] [COLOR=Green]-- Rhinos in Northrend[/COLOR] [COLOR=Red]["felorcmale"] = true,[/COLOR] [COLOR=Green]-- Fel Orcs in Outland[/COLOR] [COLOR=Red]["fleshtitan"] = true,[/COLOR] [COLOR=Green]-- Thrym and Thaddius[/COLOR] [COLOR=Red]["facelessone"] = true,[/COLOR] [COLOR=Green]-- Faceless Ones in Ahn'Kahet and Ulduar[/COLOR] [COLOR=Red]}[/COLOR] [COLOR=Red]local Unit_File = self:GetModel(); if (type(Unit_File) == "string") then while(strfind(Unit_File,"\\")) do Unit_File = strsub(Unit_File,strfind(Unit_File,"\\")+1); end Unit_File = gsub(Unit_File,".m2",""); Unit_File = gsub(Unit_File,".mdx",""); end [/COLOR] self:SetScript("OnUpdate", nil) local frame = self:GetParent() local layout_db = PitBull4_Portrait:GetLayoutDB(frame) if not layout_db.full_body [COLOR=Red]and not inverseFullBodyNPCs[Unit_File][/COLOR] then self:SetCamera(0) [COLOR=Red]else self:SetCamera(1)[/COLOR] end if type(self:GetModel()) ~= "string" then -- the portrait wasn't set properly, let's try again PitBull4_Portrait:Clear(frame) PitBull4_Portrait:Update(frame) end endResult:-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://forums.wowace.com/showpost.php?p=262056&postcount=69
Seriously, there has got to be a better way to fix this problem. If anything I'd rather submit this as a bug to Blizzard and have them fix the reversed cameras on the models than start doing this. It's gonna be an endless maintenance task.
Edit: To be clear. Some things we have to work around because it's just the way they are. But working around every bug or glitch in WoW is in impossible task. Some things are just best fixed where they are broken. On top of that I'm not even 100% sure that those models are broken at this point. We have an issues where we're not properly setting the camera. Target yourself after a fresh reload. Your portrait is just the head. Now clear your target and target yourself again. Ohh look full size now. Target someone else without clearing your target. Head again. Now target yourself again without clearing the target, still just the head. Clear the target and target yourself, now we're back to full size.
Basically there are deeper problems in the Portrait module. I'm not gonna start throwing hacks on top of it for this sort of thing until I work these issues out.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://www.wowace.com/projects/pitbull4/tickets/391-bonechewer-mobs/
That was code for Pitbull 3! And by the way that was before I discovered that you could capture the unit by its model name instead of GUID. See the difference? I don't have to list every single mob, only its model (felorcmale).