Only try to redraw if the maximum count exceeds the numbers of frames we have to display the count. If the maximum drops below the number of frames we have to display it, that's fine because the excess frames will just be hidden.
There's a case where custom counters seemingly get stuck with an outdated maximum number of charges (perhaps only when augmented by a talent such as with Throw Glaive). This may catch and fix it (I couldn't reproduce the problem with a starter DH since you need level 108 or something to get the second charge for Throw Glaive).
Changing this default has confused too many people, so let's put it back. Now this information is technically duplicated, but avoiding confusion is more important.
The player health bar will now show a (by default) faded white bar above the health for the amount of absorption the player currently has. The incoming heal bar starts above both the player health and the absorb, if any is present.
Also disabled the PlayerAbsorb bar by default since it's redundant. It can still be enabled separately if desired.
With runes being homogenized in 7.0, it makes a little less sense to adhere to the structure of specific runes being available/used. This adds an option to display the runes more like combo points where simple textures are shown to indicate how many runes are available. No cooldown or "soon-to-be-ready" type indicators are setup just yet since that problem is more difficult and my personal usage doesn't really need them right now.
Also added an option to show the Runes module any time the player has some runes that are recharging.
We were creating font factories every time the runes module was asked to redraw. Oops...
Also fixed the numeric frame's parent while I was in there so that it (in a future commit) will show and hide with the module properly.
Sometimes combo points can get stuck in a state where only 5 will draw on the screen even if the player has 6 max available. It's been really tough to reproduce, but I think the problem is that the frames are getting created but never having a texture set to them. This should fix that.
Looks like at some point I modified how "darkened" inactive powers worked and ended up drawing two copies of the darkened power counter for each inactive power. "runebg" is superfluous since we're just setting the color of the actual counter to black and partially transparent instead. For some power counters, such as Paladins, the runebg texture was actually wrong and drawing the entire atlas rather than just the texture we wanted.
Looks like some things changed in spellcast events on 7.0 which necessitate using the spellcast GUID to identify when a specific cast starts or stops. Now we use those GUIDs which restores the castbar to its appropriate behavior. (ticket #215)
I guess something in the 7.0 client must have changed how animations work for inherited frames because it would appear that the RotateFrame call for the child flashFrame is now causing issues somehow. Removing the call allows the flash/low threshold frame to travel alongside the parent frame when rotating.
When the player had one profile with a bar rotated 90 degrees and another profile with the same bar not rotated, the non-rotated profile would fail to put the bar back in its original location. Thanks for the detailed report, spacegato!
I keep seeing things online saying the one-argument version of UnitPower has been deprecated, so I figured I'd go ahead and update my few uses of it in case it actually gets removed at some point. I haven't had any trouble with it, though.
Destruction Warlocks have a PowerMax of 1000 and apparently trying to create that many graphical frames blows something up really quick. In 7.0, everyone's runes are discrete objects, so I was trying to ensure that the graphical representations of a given power were ready at all times, but didn't consider the pre-7.0 case where this calculation would lead to an absurd number of "runes".
This change also fixes an errant CreateFrame() in UpdateRunePower() that was supposed to be self:CreateFrame(). CreateFrame() was just creating a nameless, parentless frame for no reason at all. Good job, me. This isn't C++.
