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).