I don't have beta access so I can't test this yet, but this should catch everything in the Deprecated_11_0_0 file in wow's official ui source as well as some stuff not mentioned but reported by users.
This has been tested on Classic with a Rogue up to level 5 using various modules and casually checked against a few level 1 classes. I'm sure there's a lot more to do here. I also made sure to test on Live.
Where possible I tried to check for API availability rather than specific client versions or program IDs. There are many cases where that's impractical, however, so version/program ID checks were used.
This was tested with:
* Ace3 @r1225
* AceGUI-3.0-SharedMediaWidgets @r61
* LibDBIcon-1.0 @v8.2.0
* LibDogTag-3.0 @v80200.1
* LibDogTag-Unit-3.0 @v80200.1-2-g93a898d-alpha
* LibRangeCheck-2.0 @v4.2.3 (with a couple of local changes)
* LibSharedMedia-3.0 @r113-alpha
It's still, at it's core, a guess because Blizzard doesn't offer the necessary events to make a reliable decision, so it tends to be wrong semi-frequently in a chain-casting scenario. But it's better than it was.
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)
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.
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)
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.
- colorized the FAQ and Module Settings description text to be more readable
- removed custom coloring from certain options that didn't match the rest
- hid a few debug-only settings
- consolidated all the 'create custom module' buttons into a drop-down + create button
- clarified description of some options so that their intent/purpose is more clear
- moved around/cleaned up headers for consistency
- doubled the width of long options so that they don't get cut off and ...'d
- the ace3 conversion also broke the dependence on Waterfall and gave a much better configuration screen through AceConfigDialog; plus Waterfall is very broken in Cataclysm and it's unclear whether anyone will bother to fix it or not
- fixed a bug with the custom CD bar when changing profiles where it would generate endless errors until a reloadui
- removed DewDrop library as it was no longer in use
- temporarily removed FuBar plugin as it doesn't work as a mixin with AceAddon-3. i will eventually be bringing this back in some form (before the next full release version)
- removed an unused 'about' button on the config page and some empty headers...not sure why they were ever there
