5.2 combat log changes

I've done some more (mostly random) work on the code, and I've decided that I should completely decouple some parts (like DoTs) to write them as "general code" calling some DoT-specific logic at times.
Then 5.2 arrived and messed up the parsing.....
Blizzard seems to have added 6 fields (one GUID + 5 integers) at random in combat log events.  I say 'at random' because even if the placement is constant, the presence is not.  Monk HoT ticks have this additional information, Druid HoT ticks don't.  Looking at the data it *could* be that the data is about the spell/event target and the 5-digit numbers make me guess current HP/mana, but I have no idea what the additional 3 values may be, and even less I can guess why only some events have it.... (maybe it's a "work in progress" and they have not yet updated all spells to support it?).
I have fixed the parser to be able to deal with the new logs, but I'm waiting to see if I can get some solid information on those numbers to see if there's anything exploitable for health (or energy) tracking.

UPDATE: ok, my random guess is as good as anyone's after playing with SPELL_CAST_SUCCESS:

Caster GUID, Caster HP, Caster Mana, unknown, Power Type, Power Amount *after the cast*

If it's true then health/energy tracking has become a whole lot easier!

UPDATE 2: thanks to the guys at WoL, the values are:

1: GUID
2: Health
3: Attack power
4: Spell power
5: Resource type
6: Resource amount

DoT code rewritten, but....

....it doesn't work (yet :).  Apart from de-duplicating the code, I have prepared a simpler (better?) framework to put in the checks for "errors".   I'm also thinking about indicating the absolute/relative tick damage change on a DoT refresh, in line with the current trend of "refresh if damage is boosted".
The absolute priority is making sure that the code does not segfault every time a dot is applied, as it is doing now :), and with the Christmas holidays coming up I should have enough time for a new better, shinier, release!

Rewriting in progress...

Apart from minor fixes, like adding support for Shred! (which is not the same spell Id as Shred), so that Glyph of shred can be taken into account, I've started rewriting the way damage and DoTs are processed.  For the moment I've improved the statistics, but I still need to un-triplicate the DoT code and I'm also thinking on how to correctly deal with block/absorb, so that damage is correctly taken into account.
Sooner or later I should also add support for crit normalization (= "normalizing" your damage/DPS to the value it would have if you didn't have luck/unluck with crits or OOC), but that's still far away.  The main objective is to get the visualization to correctly deal with everything.
Side note: Garalon down, and the log has an interesting "problem".  The legs are "recycled", in the sense that they don't behave like adds which die and repop: there's no UNIT_DIED event or anything similar, and they always have the same id.  This is good, because you only have four "adds" in the display, but at the same time it's impossible to know from which moment to which moment they existed, so any attempt at calculating an aura uptime in % is impossible.....

Version 0.3.1 out

I've just uploaded version 0.3.1, source only for the moment, I'll rebuild the windows executable during the morning.
Notable changes are that I fixed one crash, and started adding support for Soul Swap.  Problem is, it's a bit of a mess, and I never wrote "correctly" the code for DoT management, as a result I have the DoT code in triplicate (Rake, Rip, Thrash) so I need to do a lot of cut-n-paste when I add stuff to the DoTs.  This cannot go on, so I'll rewrite the entire thing as soon as I can to centralize the DoT code.  For the moment Soul Swapping rake works, the other DoTs are still swapped, but the swap is not recognized as a Soul Swap, so the code complains about a lot of stuff (Rip applied at less than 5 CP mostly).
I've also added some more statistics on the attacks: in particular the calculation of the "real" DPE (damage-per-energy) associated to the attacks.  This allows you to see how incredibly good Thrash is as soon as you can hit more than one target :)

Autodetection of talents

Well, I just realized that asking the player for talents is useless, since all the relevant ones are easily spotted in the combat log (source = you, spellid = the one of the talent), so I've modified the preprocessor to detect the talents.
I've added skull bash to the energy tracking, and I've fixed an error which was reporting swipe twice in the OOC allocation pie chart.
FB refreshes of rip now correctly propagate TF/DoC boosts, and the warning for too few shred extends is turned off as soon as you start to refresh rip with FB.
Activity tracking is still a complete mess, reporting hours-long casts of Healing Touch, I'll have to look into that, but I'm starting to wonder if that display is of any use whatsoever.
In the week-end I'll try to fix some more stuff and then I'll put out a new release.

Dream of Cenarius has no doses

Ok, so I finally got a log with Dream of Cenarius.  The good: my code to mark DoTs as "DoC boosted" worked on the 1st try.  The bad: since DoC has two charges I was expecting it to be handled as a 2-stack-maximum self-buff.  Well, it isn't.   DoC, the damage part, spell id = 108381 does not have AURA_APPLIED_DOSE or AURA_REMOVED_DOSE, it's just APPLIED or REMOVED.  I'm also thinking about a way to indicate which of your attacks are DoC-boosted beyond DoTs... I guess I'll add one more element to my display class to provide an additional "flag" to events.
Apart this I have some weird stuff happening (all heals are marked as crits, go figure why), I had to fix once and for all the friendly fire problem (which was segfaulting the program), the "Cowardice" debuff/DoT on Spirit Kings was killing the health tracking since it has no source, I was getting some nice error report on Berserk cast, of the kind "Error: energy below 80" and at the same time "Error: energy above 79", which makes for a narrow margin of error :P
As soon as I get that stuff cleaned up I'll go for a "prerelease"!  Stay tuned (but don't hold your breath).

Health tracking

Activity tracking is still MIA :), but health tracking turned out to be a lot simpler than I remembered from my tanking days.  I think there are two reasons for this: first is that I don't care for precision, I just want to "give an idea", which makes life very much easier.  When you're not dealing with exact numbers, you can safely ignore the total HP pool, effect of raid buffs on Stamina and temporary health enhancements (Might of Ursoc and friends).  Of course the result will be approximate, but if you're sitting in bad stuff it'll show up clearly, and that was the original idea.
The second reason is associated to the changes brought by Cataclysm: much larger health pools and "smaller" heals.  In Wrath, tank HP were oscillating like mad, here I'm testing tracking on a DPS (much smaller damage intake) and huge health pools which are not meant to be healed in a single spell.  As a result, the inconsistencies coming from the timing issues (sequence errors resulting in heals arriving before the damage is inflicted) are a lot less visible.
I had to do some internal changes, so that on the health display zooming in provides better resolution for picking and displaying events (there are tons of small heals going on...), and I did some other minor quality of life improvements.  As soon as I can get a windows compiler running, I'll create the "MoP release" and put it up for download.  If you're curious: health tracking in the final Elegon phase looks like this:

(in case you wonder: the final red line is Elegon one-shotting me with his final attack)