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)

The endless cast

Since I'm abroad I don't have access to any "new" logs to play with.  In particular, I cannot test DoC/NV since I don't have here any logs where I used them..... I've put the code in, but I'll be postponing the tests until I can create some appropriate logs.
So I have decided to add activity tracking: the idea is to see if you are a key-spammer (tons of cast failed due to GCD / low energy) or a classy-clicker (just press the key once exactly at the right time.  Of course, it turns out that it's not so easy.  Apart from the negative-time casts (which I can try to detect as instant cast since I have the spell effect just before the cast_success), I've found a new gem: SPELL_CAST_SUCCESS is used for instant casts, but it doesn't appear in the log for channeled casts.  What I mean is this:

10/17 00:10:27.143  SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8
10/17 00:10:28.189  SPELL_CAST_FAILED,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8,"Another action is in progress"
10/17 00:10:28.959  SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5176,"Wrath",0x8
10/17 00:10:31.163  SPELL_DAMAGE,0x0180000001B138CB,"Helistar",0x511,0x0,0xF130EBFA00004EBC,"Elegon",0x10a48,0x0,5176,"Wrath",0x8,308679,-1,8,0,0,0,nil,nil,nil

The SPELL_DAMAGE event corresponds to the *first* Wrath cast (remember, Wrath has a fairly long "flight time").  This means that I have no way to detect that the actual casting of Wrath has ended, except guessing it from the fact that I had another CAST_START.  This also means that I have no easy way of knowing if the player is idle or not.  I'll need to do some tests, but I fear I'll be forced to go dig in the CAST_FAILED error message to see *why* it failed, in order to understand if it's just a key-spam while already casting (= you're not idle), or if the cast really failed because you moved (or the target died, ...), in which cast the CAST_FAILED indicates a transition back to the idle state.
And it's actually worse: if you cast a single Wrath, I have no way of knowing that the casting has ended.... since the spell effect (SPELL_DAMAGE) will appear a lot later.

I don't know why, but I'm starting to think that this whole "activity display" thing is a bad idea.....

Cast, instant cast, *negative-time* cast!

More combat log weirdness.
Even more weird since it cannot be due to multiple clients having different latencies and the lag-compensation code messing the timestamps: here I am healing *myself*:

10/17 00:17:00.970  SPELL_HEAL,0x0180000001B138CB,"Helistar",0x511,0x0,0x0180000001B138CB,"Helistar",0x511,0x0,5185,"Healing Touch",0x8,92919,0,0,nil
10/17 00:17:00.991  SPELL_CAST_START,0x0180000001B138CB,"Helistar",0x511,0x0,0x0000000000000000,nil,0x80000000,0x80000000,5185,"Healing Touch",0x8

The healing touch healed me 21ms *before* I even cast it.....
In the best of worlds we would have SPELL_CAST_START followed by SPELL_CAST_SUCCESS and then SPELL_...whatever effect it does...
Or maybe, for an instant spell we could just have the effect, or if we really want to keep track of client/server latency, SPELL_CAST_START followed by the spell effect.
Clearly, we are not in the best of worlds.
Before you ask: yes, this makes for nightmarish scenarios where some poor piece of code sees a cast_start and hopefully waits (forever...) for the spell effect to take place (solution: ignore the cast_start).  It's bit like the horrible consistency errors you get on bosses like Ultraxion or Gara'jal where the logs of players from one "dimension" are missing all the information about those in the other dimension, leading to all possible aura-uptime consistency failures....

Updates, updates

The list of stuff to add is growing, but the code is not :)  this is not good.
I need to add the heals/DoC detection/Wrathspam and I just found out that I messed up Soul of the Forest, which, unbelievably, actually appears as SPELL_ENERGIZE in the log.
I have checked the damn Rip uptime log thing and it's trouble:
- applied at (seconds) 12.831 (expected to end +16s later, so at 28.831)
- refreshed 3 times by shred (so expected to end in total at +22s or 34.831)
- gets refreshed by another Rip at 38.166
Now, I know that one extra tick is possible, which would place the expiration at 36.831.  I also know that the aura is "sometimes" longer (even if it appears correctly to end at the last tick in EventHorizon).  But this is almost 1.5 AFTER the exceptional tick.  It's not a +6s shred refresh, it's almost +10s refresh (9.33 to be exact).  I don't know exactly how to deal with this.  I will alter the BitW code to be a lot more tolerant (+3.3s/shred instead of +2s), but I'm wondering if something is going wrong...... the rip refresh mechanism has always been "weird", but it's the first time I see it being *so* weird.
Whatever... I'll see if I can cook up a release in a couple of weeks.

Elegon down, and Rip woes....

Ok, so Elegon is down.  Ugly down, we (barely) won.  So I feed the log to the analyzer and I find that I suck (hardly a surprise), but also that there is a phase where Elegon is DoT-immune (I had not really cared much to check, it seems to be during the p2-p1 transitions, from a cursory look).
But there's stuff going wrong: I have a BitW range which starts in phase 1, which is definitely wrong.  Looking at the visualization it seems like there's a Rip which is lasting too long.  I know that 1 extra tick is possible, but here it's more than that.  Usually, even when one extra tick is added, the aura fades immediately afterwards, but here it seems like there's a refresh after half a tick, and this with 4 extra ticks.  Since visualization is independent of the preprocessing, it means that there really is some spell_periodic_damage going on.  I'll have to go through the log in detail to see what happens.  Blizzard does weird stuff with the logs at times (and not just logs...) :).

RWF for MoP

I've started updating RWF for Pandaria.

There is a ton of changes, mostly in the amount of stuff to track.  Some mechanics have changed as well, so my energy check for TF are failing systematically, I'll have to look into detail to see what's going on.
I also have no idea on how to provide a "quick" display on the buffed status of DoTs, which can now be buffed by TF, DoC and (rarely) agi potion.  I think it would be nice to be able to quickly see if a DoT was buffed and by what without being forced to hover on it, but there are a lot of combinations, so using colors would be an utter mess.  I'll probably stick to "red = error, yellow = unbuffed, green = buffed by at least one thing" and let the user hover on the DoT to see the details.
There were also some random changes in the combat log, such as the type of environmental damage being written lowercase instead of uppercase (which crashed the parser.....), I guess that with time I'll be able to clean them up.
Well, at least the preprocessor to locate the execute (BitW) range works.

RWF for 4.3 up and running

I've finished the FB preprocessing thing and found that the lack of AURA_REFRESH events for Rip was also messing up other things.  I've put in a horrible workaround, but it works, so who cares? :)
Contrary to my initial impression, melee haste auras continue to be a problem, Hunting Party is nowhere to be seen.... Also, several skills changed their IDs, so some detection is messed up, I'll think about this later on.  Correct haste management is still on the TO-DO list: Heroism/BL/TW are correctly handled, but trinkets require a lot more work (= add them one by one), so they are out for the moment.
After a hardware upgrade, my windows environment was completely reinstalled, so I'll have to reinstall Qt as well before I can compile the windows executable.  I'll try to do it before the week-end.