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.
Legion's Shadow Priests have a new default power type called Insanity, so now we need an additional bar to show the player's mana (which all priests still have) while in shadow spec as a priest.
Updated with the new DK rune changes so there are no longer different types of runes, just the one type. Also hooked up support for any potential changes to the max number of runes (as is present in Blizzard's RuneFrame source), but have no idea how to correctly trigger the 7th rune (or if that's even in the current build). Tested with hackery via /script commands and verified it works, so *shrug*.
Adds support for the new 6/8 (without/with Anticipation) combo points instead of hardcoding to 5. This same treatment will need to be done to the other combo point-centric modules (SnD, ComboPointsBar).
Moved the old Anticipation extra-combo-point support to pre-Legion only. Anticipation doesn't work the same way now.
For some interactables, such as specific quest-related objects in WoD, we never receive a SpellCastSent event, only a SpellCastStart. If, prior to that event, we ever failed a spell cast, we would have an outdated "spell sent time" saved off for a previous cast. This value would then get used due to us receiving a Start with no Sent and would cause the lag bar to fill the entire cast bar incorrectly. For these cases, we now no longer show the lag bar at all because we don't receive enough information from the game to compute one.
This allows the user to override the fact that they've set a custom lag tolerance in the game's options and instead have the mod display the computed latency. (ticket #201)
There's no real reason to force this bar up into the TOOLTIP strata and have it draw on top of things. It can live in 'low' like every other part of the addon.
Apparently setting the castbar to 'reverse' mode has never set the lag indicator in the correct place. Now we instruct SetBarCoord to behave differently for lag indicators.
