FB preprocessing

Since detecting FB-refreshes is impossible, unless you wait for Rip to be refreshed a 4th time by mangle/shred, or go for a more reliable approach of checking if it ends when it shoud, I've decided to use a different way and do a preprocess phase of the combat log, where I only look for FB/Rip durations.  This allows me to pre-flag the FB events as "refreshes" and makes the analysis code less messy.
Alternatively, I could go for some on-the-fly log editing, adding AURA_REFRESH events for Rips where they should be.  I'll try both approaches.  Whatever the result, having a preprocess phase will make life easier for several other things (I could consider moving the OOC use detection there, for example).

4.3

Melee auras: it seems like Improved Icy Talons is there.  I need to check out more in detail, but this is good. No idea about the others, but there's hope!

FB/Rip refresh: nope.  Argh :(

I think I'll just disable any error checking on FB and just report the time left on SR/Rip, leaving the user to decide if it's an error or not.

4.3 incoming, will the fixes be there?

I'm still waiting to post a new release to see if 4.3 finally fixes all the crap which was not fixed or clearly added by 4.2.  I mean:
- melee haste auras not present in the combat log
- Rip refreshing by Ferocious Bite reported in the log (which was working, but "disappeared" in 4.2).

Together they make annoying things to do during the analysis, since they are not easily guessed.  It's of course possible to code workarounds, but it should not be necessary, and I'm not too hot on playing guess-the-FB-refresh in multitarget scenario, only to see it fixed in 4.3.

BTW a gem from the last logs I'm playing with, it's about melee haste auras:

Hunting party?
> grep Hunting 111102\ 203427.txt
no output.

Maybe Windfury Totem?
> grep Windfury 111102\ 203427.txt | grep AURA
no output.

Ok, so it'll be Improved Icy Talons:
> grep 'Icy Talons' 111102\ 203427.txt
11/2 22:07:44.055  SPELL_AURA_APPLIED,0x01800000037824B0,"Unknown",0x518,0x0,0x01800000037824B0,"Unknown",0x518,0x0,55610,"Improved Icy Talons",0x10,BUFF
Wonderful: in an entire raid evening with multiple wipes, we have a single application, from an Unknown unit to an Unknown unit....

Insert obligatory "WoW coding going downhill, end of WoW, film at 11".

Parallel cat-o-rama?

I'm having some "fun" with OpenCL.  If you have never heard about it, it's a computing language to perform general-purpose programming on GPUs.  Since the current-generation GPUs pack a ton of processing power, it can lead to some impressive speed-ups, if you recode the time-critical part of your program and make them run on the GPU.  Only caveat: the GPU is massively parallel, so if your problem is not suitable for parallelization, you have a problem (and you lose performance).
Of course things are not as easy as the tutorials online make it: coding is trivial, but getting good performance is a nightmare of memory-access optimizations.  This is because even if the GPU has massive computing power, the memory latency is enormous, and unless you arrange the execution of your code so that memory accesses (intrinsically slow) can be "coalesced" (= many programs access contiguous memory at the same time, leading to a single operation), performance gains can be minimal.  Still, when things work it's fun: right now I'm trying different approaches for a 7x7 image box filter.  I'm at x100 execution speed-up (note, filtering calculation only, I'm forgetting about the computer<->GPU memory transfers, which add some more time, bringing the speedup to some x40-50 "only"), but I'm trying to see if it's possible to do more....

What's the relation to WoW?  None.  Except that making a cat simulator which can run on the GPU would be nice and allow for some serious kick-ass speedup of the simulations (simulating multiple combats is very parallelizable and very little memory-bound if all you care about is the final DPS).
Genetic cat optimization algorithms, anyone? :)

Energy reconstruction

Even if I'm silent, the energy reconstruction code keeps improving.  I've actually managed to have the "used" and "regen" totals match exactly.  Ok, it was a test fight using only mangle and avoiding any weird scenarios, but it means that the changes which I did to the way energy tracking is performed are getting better and better.  I still have some trouble with FB, and I need to test the +10% melee auras, because things look weird when I test on some real raid-25 fight.
For the moment the melee haste auras are hardwired to "true", I'm still thinking about the best method to detect them.

After too many Tol'Vir runs....

Ok, completely useless (except for the mass-rez, which is nice), but still good to have.  Ah you also get access to a mount, which I don't know if to define "ugly" or "more ugly".... in any case definitely not "beautiful".

I'm planning a new RWF release shortly, but the detection of errors for the use of FB is still wrong, and I need to hack in a way to detect the melee haste auras, which ARE STILL NOT REPORTED in the combat log.....

Primal Madness

In the energy reconstruction I've hit another problematic detail: Primal Madness, which increases the energy cap to 120.  This is not complicated in itself (my code can handle a changed energy cap just fine), the problem is as in FB: WHEN does the energy cap change happen?  Is it client-side or server-side?

Looking at the log, it seems like the Primal Madness aura is applied client-side, i.e. immediately after the cast of TF.  This would mean that the +20 energy bonus is applied immediately.  But during my tests I found a strange behaviour in one log: immediately after TF (which includes the AURA_APPLIED for Primal Madness), I have one cast which fails with "not enough energy", even the energy amount + the 20 provided by PM should make the cast possible.  Seeing that the cast has failed, the code lowers the current energy value, which already includes the +20, and I fear that this is messing up with the rest of the reconstruction (ok, the effect will be small).

I'll do some more tests, spamming mangle (or shred) while activating TF at different times/energy levels, so as to see if the +20 is applied at aura application time (= immediately), or it's postponed until the SPELL_ENERGIZE event provided by TF (which, BTW stays at +60 even for a PM talented cat).

FB and extra energy consumption

Looking at my energy bar during fights seems to indicate that the same problem of client/server time "separation" occurs for Ferocious Bite.  In a mix of the two scenarios of my last post, it looks like FB drains the base cost (the one which can be eliminated by OOC) client-side, i.e. immediately at the CAST_SUCCESS event, while the extra energy is drained at application time, i.e. SPELL_DAMAGE event.  While this is not particularly complex in itself, it raises some questions on how the extra energy is calculated.

Possibility 1: client-side.  When you execute a FB, the client sends the server both the order to do FB together with the current energy level, while at the same time draining the base cost (which is guaranteed to happen).  Upon actual execution, the server uses the energy value you sent (checking it for consistency) to determine the extra energy and sends back a message with the damage and with the energy amount actually used, so that the client can update.

Possibility 2: server-side.  The client just sends the order to FB while draining the base cost, the server looks at the current energy and determines the extra amount, returning it to the client together with the SPELL_DAMAGE event.

The difference is small, and can be quantified to be the amount of energy regen occurring during the network transit (which can be non-negligible, especially if you're testing in SW...).  Since I don't really know how to reliably test it without things being complicated, I'm assuming that the extra energy is determined at cast time, i.e. when you press the key the extra energy is EnergyNow - BaseFBCost (capped by the max extra energy), which is possibility 1.  Whatever the case it won't play a major role.

Apart from these minor details, energy reconstruction looks more reliable now, but I still have an error (more regen than used).  What surprised me is that on the test log I'm using (shred only), it's almost exactly 40 energy, which is definitely suspect.... almost like one normal shred ended up being counted as OOC-powered.....  I'll do more test runs and keep improving things.

Energy.... again

Ok, I've decided to face reality and now I'm implementing energy tracking "right".  Which means using the right events to perform energy updates.  After some testing with VERY weird results, it turns out that using SPELL_DAMAGE events doesn't cut it, and energy tracking must be done right, i.e. using SPELL_CAST_SUCCESS to substract energy and SPELL_MISSED for energy refunds.  SPELL_ENERGIZE to account for energy boosts was already done right.  It's interesting to see the weirdness of energy checking/usage which is done partly client-side (SPELL_CAST_SUCCESS is client-side timing) and partly server side (SPELL_ENERGIZE provides energy at spell execution on the server).  The result is for example that if you Mangle, the Mangle energy cost is subtracted immediately, while the energy return of Tiger's Fury is delayed by your lag.  I'm also adding in handling of Primal Madness and the related /cancelaura to correcly manage the 20 extra energy provided by the talent.

Overall, the new version will have a more reliable energy tracking (assuming the right values for haste are used), and also more reliable error indications.

...and completely unrelated:

In addition to WoW I'm also playing LotRO, with an elven hunter (which I later discovered being the absolute noob-indicator in this MMO) and an elven warden (which is sub-optimal, human is better, but I don't give a damn).

Overall, I find LotRO to be a 2-3 years old version of WoW, with slower combat and annoying grinding (in particular traits and reputations), something which WoW has finally evolved out of.... almost (*cough* Tol Barad *cough*).

As much as the huntard...hunter I mean...is absolutely bland when it comes to gameplay (press button -> do damage, press another button -> do more damage), the warden has an interesting feel, even if I've been too scared to actually go and tank an instance.  The lack of an automated LFG tool is part of the problem, spamming LFF is not for me.  I'll definitely try it sooner or later, the idea of a tank without taunt, holding aggro via AoE dotting and threat transfer is definitely a change.

Back in business

After a pause, I'm restarting developement.  I feel that my DPS is not up to par at the moment, and I need to know why.

So I'm back coding RWF, fixing some long-standing problems (for example crashes when it incorrectly detects a enemy unit as a friend).  I'm still thinking about a way to add combat-dependent stat weights, but for the moment I cannot think of anything except using the damage % from the various abilities and using the way they scale off the stats to determine the coefficients.  One thing is sure: while this approach was definitely "sucky" in the past, due to combo point management, the current "never FB just spam shred" approach makes it a lot more precise, since combo point management has became almost meaningless.

Stay tuned :)  (but don't hold your breath).

Happy new year!

Happy new year to all cats and bears (ok, and other forms too :).

I've not been advancing much.... I'll try to restart the developement now that the leveling is out of the way and we're returning to a normal raid schedule.