The new ClassIcons element
Haste merged combo points, shadow orbs, holy power, chi orbs and soul shards (covers only affliction warlocks for now) on the master oUF branch on GitHub.
I have some questions about it: Can we display combo points on the target frame and class power on the player frame and not mix them? An "issue" I have with this is switching from cat to moonkin as I then have both the eclipse bar and the combo points shown on the same frame and have to account for the extra space. How do I proceed if I need to change the width of the class power "icons" in response to changes of max power? If I get it right, I can do this either on Pre or PostUpdate. PreUpdate is not a good go for this I believe as I would resize widgets before oUF updates their visibility. In PostUpdate I either do it every time or add another field to the ClassIcons array just as ClassIcons.__max and use it to find out if a resize is needed. Wouldn't it be better is oUF tells PostUpdate whether maxPower changed? What is the idea behind element[i]:SetDesaturated(desaturated)? I also find the name somewhat misleading. Why not call it ClassPower or something more descriptive that it is about class resources? |
You have to seperate them.
ComboPoints are for target. ClassBars are for player. Vehicles can have comboPoints aswell. I do it this way: http://imgur.com/a/1znsW *edit* Holy cow what has he done? He changed it all into one widget? ALL??? Man I nearly finished creating the new elements on my layout. ... But actually it is not that bad as I thought. Since I had to override the elements for my textue display anyway I just made the old classIcon elements local modules of my layout. @Raidrider Now I understand your problem. You are correct on the seperating. |
I believe the change was because all the elements behaved the same: all of them were just textures being shown or hidden depending on the same events (with the sole exception of combo points, which does not toggle on UNIT_POWER*). Some layouts used a "class bar factory" because of that, having the same code create this type of class resources.
Some other things I noticed about the new element: CPointsDisable and ClassPowerDisable do not hide the element. This holds true for every oUF element actually. There is a commit for this on Adirelle's oUF fork, don't know why he didn't make a pull request for it. The soul shards part of the element does not unregister SPELLS_CHANGED if Soulburn in known (that's at lvl 19 currently - GetSpellLevelLearned(WARLOCK_SOULBURN)), so the element would update visibility for nothing every time the player changes glyphs or learns new spells. But I suppose this will change as burning embers and demonic fury have to be status bars and would require a new element to handle them. The holy power part registers UNIT_POWER and not UNIT_POWER_FREQUENT as the other elements and the standard ui do. Don't know if that is much of a difference in that case, but it helps to get the Ascension talent for monks without registering PLAYER_TALENT_UPDATE and we have a similar situation with paladins when they level to 85 and learn Boundless Conviction . Also HOLY_POWER_FULL always equals 3, even if Boundless Conviction is known (that's actually irrelevant :)) On a side note: does anybody know a vehicle quest with combo points where I can test the behavior of the new element (apart from Aces High! because it requires rep I don't have) |
And another question (sorry about that):
Can SetSize and SetPoint be called in combat? What happens if my 3 chi monk enters a vehicle in combat and I try to re-size and re-anchor the "class icons" from 3 chi to 5 combo points in PostUpdate? |
Quote:
|
I combined combo points with the rest of the player elements because I've always viewed it as one. It also replaces the player element when you enter a vehicle. Anyway, I'll split it out again later today. I understand the annoyances people find with not being able to put it exactly where they want. :)
The intention with the element was to merge everything that's pretty much the same, but with slightly different input variables and colors. I'm all ears for improvements, things aren't really set in stone at all atm. Quote:
Quote:
Quote:
Quote:
We could still change the name to something else, or use ClassPower and ClassBars or something. I'm planning on having ClassBars handle Runes, Destruction and Affliction warlocks, druid/monk mana. One could probably throw EclipseBar into the mix as well, but it has fairly strict anchoring requirements. Do note that these elements are still very different, they would just be renamed. Quote:
Quote:
Quote:
Quote:
|
Quote:
|
I'll add it to my list :P
|
I pushed some changes just now. They're pretty much all from Monday. I was planning on reviewing them before I pushed, but ended up having to travel through half of Norway due to work on Tuesday...
If you have any gripe with it still, let me know. |
No, Combo Points are back in CPoints. classbars.lua was just a stray file in my branch :(.
|
Yeah I just found out about about that...
|
I probably wouldn't have noticed if you hadn't said anything. :P
|
Decided that making a new topic for my request is quite silly, so posting it here, ‘cause it’s related to class powers.
While making custom rune bar for my interface, I found out that it would be quite useful to have the same PostUpdate hook for runes as we’ve got for health/power bars, even two of them, because there’re UpdateType and UpdateRune. For example, if we had those two hooks we could recolor runes, when they are on CD. I think other addon authors will like this idea, but.. who knows :D That’s not too much to modify in runebar.lua code, just 3 extra lines of code for each function. Lua Code:
Lua Code:
|
Just out of curiosity, why do you want to change the colors? They are statusbars, so if a rune is on cd then you have the filling bar as an indicator for this. Changing colors probably makes it more difficult for the user to distinguish which rune is recharging. Apart from that you probably need the returns of GetRuneCooldown(rid) or you'll have to call it yourself again in PostUpdate.
|
Quote:
As for difficulty, it depends on how you change the color. If you're using a darker blue for recharging frost runes, and a brighter blue for ready frost runes, that probably makes it easier for users to see which ones are ready, especially if you're using a small statusbar where it's hard to distinguish between 90% full and 100% full. |
But to be fair. You can always make your own module if the default one doesn't fit your needs.
|
That's true; I'd probably just use an Override if I wanted to change the default update process instead of adding to it.
|
Well, we've got PostUpdate/Override callbacks for almost everything :) there are 6 of them (5 PostUpdate + 1 Override) for eclipse bar!!
Quote:
Quote:
And as for overriding runebar update process, to be honest, I’d try to avoid it because of enabling/disabling OnUpdate scripts inside the default update function. That's why I asked for adding 2 PostUpdate callbacks. |
Quote:
|
Quote:
P.S. btw i'm colorblind (don't see any green) :D |
All times are GMT -6. The time now is 09:16 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI