I explicitly added what I believe to be the spell id for the new Grotto Netherwing Drake so it *should* work regardless, but then also discovered that the flying mount's UnitPowerMax is 0 unless you're on a Dragonriding mount, so that should be the longer-term fix for whenever old-world mounts add Dragonriding capability (10.1.5?).
This displays the Vigor charges for the player whenever they're on a Dragonriding mount (which is detected via explicit buff ID scanning from a hardcoded list...I'd like to make that more robust so I don't have to keep up with new mounts being added, but I'm not sure how to do it another way just yet). The Alternate Power bar is hidden if the Vigor module is enabled so that we don't end up with duplicate Vigor trackers (although right now it flashes on the screen before the mount buff is detected, so I'd also like to fix that...).
I've effectively had to implement my own Vigor module from scratch by poking into the internals of the Vigor widget by its ID in order to determine the recharge amount on the final Vigor charge because there's currently no API to get this information otherwise. Hopefully this gets added; if it does, I'll happily rip out this widget inspection junk. Aside from the partial charge stuff, this is just a skinned version of an Alternate Power indicator that only shows when the user is on a dragonriding mount. ClassPowerCounter doesn't sound like a particularly appropriate base class for this, but since Vigor is implemented as Alternate Power, it worked out nicely.
This adds more robust visuals on the power counters where we can (finally) display artwork similar to the default UI where the charges are sometimes framed by something and sometimes have a textured background behind empty charges. This doesn't yet add support for animations. Child classes can take advantage of this simply by implementing GetFrameAtlas() and/or GetBackgroundAtlas().
Note: as part of this, I moved the rune texture's layer to "BORDER" which doesn't feel quite appropriate, but does allow the layering to work as I want. I don't think this is going to be an issue since texture layers should only apply internal to a frame's strata (meaning this shouldn't suddenly cause an existing power counter to display above/below something else), but I wanted to document it in case something weird does come up later.
I also hardcoded a + 10 on the width/height for the frame since that's what works for Vigor. If those values don't work for any future users of this, it's easily adjusted.
This adds support for a class power counter that has a visible recharge on the final "rune." Most power counters are either fully ready or full un-ready (where the recharge is hidden away), but Dragonriding's Vigor resource does show the recharge of the final point, which this now supports.
Child classes can support this by setting self.partialReady to the index of the rune that's partially ready, and self.partialReadyPercent to the percentage that that final rune is ready (0.0-1.0). If the partially-charged point uses a different texture, the child can also implement GetPartialRuneAtlas() and it will be used only for the partially-ready rune.
If we ever need to be able to show multiple partially-ready runes, this will need a small refactor.
This isn't used anywhere else, so there's no reason for it to pollute the global namespace. And being local now, it also doesn't need the IceHUD prefix on its name.
This enables a simpler method of making sure the appropriate texture is set and using the appropriate color (for after a rune was modified to darkened/hidden).
I need this for an upcoming feature, and it turns out that the "new rune just became ready" feature didn't cooperate with width-growing runes anyway, so this is also a bugfix for that (I don't know that we have any width-growing power types in the game today, but still).
This offset is an additional offset meant to apply only when a class power counter is in a non-Numeric mode with the "also show numeric" checkbox checked. This offset is hidden when in Numeric mode, but was still being applied, therefore making it an option you could not change without going through multiple other steps first.
I can't reproduce a problem here, but based on some user feedback, this could potentially be an issue. Most other modules are calling the super's Update() first thing, but these modules call them later, so healthPercentage may not be defined at this point.
This addresses a user-reported issue where Low Threshold was not usable with Color By Health/Mana % disabled, due to some internal technical reasons. This was exacerbated by the recent fix that allowed Low Threshold and Color By Health % to work together.
This also fixes the low threshold flash to apply immediately when changing the option, and fixes the Low Threshold % slider to be usable without the Low Flash option set.
Finally, it hides the Low Flash option for bars that don't support it (right now that's just PlayerMana, I think because it only sets the low threshold to the Min Mana Color even if the class uses a different power type...something for future me...).
Fixes wowace ticket #334
If Low Threshold was checked, then scaling by health/mana % was getting overridden and forced to the Max Health/Mana Color after being set to the scaled value.
This shows the player's current Energy amount when they're in a form that doesn't use Energy. For example, this could show the user how much energy they currently have while they're in Bear form so that they can shift away and wait on their energy to refill.
Note: requires a new version of LibDogTag-Unit for the bar text tags to function if DogTags are enabled.
