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++.
UNIT_SPELLCAST_SENT is now firing at the same time as UNIT_SPELLCAST_START which is when the client receives confirmation that a spell s/he wanted to cast has begun casting (as opposed to pre-7.0 when _SENT would fire when the client pressed the button before receiving confirmation). As per http://www.wowinterface.com/forums/showpost.php?p=314818&postcount=31, I'm now hooking CURRENT_SPELL_CAST_CHANGED to give us a slight chance of acquiring lag info. Unfortunately that event fires for just about every casting-related thing that happens (with no context/useful args at all), so we get a proper lag indicator for the initial cast, but nothing once we start chaining casts together. I guess this is something to keep an eye on as 7.0 nears release.
Theoretically we could reuse this module for Roll the Bones as well, but the nature of its effects makes the duration bar portion difficult and not terribly informative to the user since each of the 6 possible buffs can be activated with different durations depending on when RtB was used.
When loading into the game as an Outlaw, the mod was creating 5 slots for combo points. Switching to Assassination increases the max to 6, but the module was failing to compensate for this and causing an error instead.
Right now most ClassPowerCounter child classes are doing this work themselves, but they don't need to be. Some cleanup could be done there if anyone ever felt like doing it. (I did a tiny bit with Shards and Chi, but there's more to be done)
There are too many classes that need to care about mana as a background resource in addition to whatever their primary resource is to keep creating class-specific bars, so let's just make one bar that does it all. I've done a one-time inherit of DruidMana's settings since it's the only bar that's been in a Release version that serves this purpose and should migrate its settings forward.
