Ovale Spell Priority

277 - Stat snapshotting

What version of Ovale are you using?

What class and specialization were you playing when the problem occurred?
Feral Druid

Which script were you using when the problem occurred? If possible, please provide the smallest script that demonstrates the problem.
Modified Leafkiller's script

What steps will reproduce the problem?
Refreshing a dot towards the end of a buff has a chance of not counting that buff's stats

Please provide any additional information below.
I'm not sure I like how the addon currently updates the stats for debuffs. Currently the way I have my ovale script setup it prevents me from trying to do a bleed for 300ms before any trinket/self buff is about to expire. Sometimes even that far out, I'll put up a rake at like 300 ms remaining on Rune and then ovale will "update" the stats to say that the bleed doesn't have the rune buff but when i check the damage it very clearly does. This is far more devastating than the problem of not catching it at the start of the buff (or the very rare occasion that it will not catch a buff falling off) because now it will suggest that I overwrite a superior bleed with a weaker one where as at least the other way I was putting up an equivalent bleed or better 95%+ of the time (and it occurs far less frequently on buff gain vs buff fade with the exception of Tiger's Fury because it gives energy and is off the gcd).

A couple ways you might tackle this:
An option as to whether or not to use the snapshot updating code. Some classes might get better use out of one method over the other (I've found it to be far worse than just using whatever the character sheet says at the moment since that was at least consistent).
Only try to pick up updated stats on aura gain and not aura fade.
Some combination of those two.
Something else I haven't thought of.

Given the limits of what we're given, I don't think we will ever have perfect stat snapshots. We just need to figure out what works best.

This is essentially a continuation of Ticket 259 which began as a discussion in Ticket 258

User When Change
jlam May 08, 2014 at 21:01 UTC Changed status from Accepted to Fixed
jlam Jul 22, 2013 at 20:53 UTC Changed status from New to Accepted
jlam Jul 22, 2013 at 20:53 UTC Changed assigned to from Sidoine to jlam
ShmooDude Jul 22, 2013 at 15:38 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of jlam jlam May 08, 2014 at 21:01 UTC - 0 likes

    I think we've done about as well as we can do with regards to snapshotting. The aura lag problem isn't going to go away and the best that you can do for DoT refreshes is to simply give yourself enough safety margin so that the ~400ms aura lag doesn't mess up your DPS.

  • Avatar of ShmooDude ShmooDude Aug 03, 2013 at 14:29 UTC - 0 likes

    Appreciate all the effort :)

  • Avatar of jlam jlam Aug 02, 2013 at 20:19 UTC - 0 likes

    Just as an update, I am still working on this. I've spent some time experimenting with different approaches, but the problem of dealing with random ordering of events is difficult to handle in the general case. I've added more debugging code to Ovale to allow for tracing the casts of various spells and when auras are applied or removed.

  • Avatar of ShmooDude ShmooDude Jul 23, 2013 at 01:18 UTC - 0 likes

    Oh, also, if 300 ms is too short (though honestly I've never seen it have problems at that setting except ovale puling an incorrect snapshot post buff fade) what do you think is the safest number?

    Last edited Jul 23, 2013 by ShmooDude
  • Avatar of ShmooDude ShmooDude Jul 23, 2013 at 00:31 UTC - 0 likes

    @jlam: Go

    I'm pretty sure you're right in that its not a fixable thing as far as random buffs go. Not unless Blizzard starts sending server related timestamps with everything which I doubt they're gonna do.

    However, I'm reasonably certain that the macro problem can be mostly fixed at least for spells and on-use trinkets.

    It looks like WoW uses a rolling 8-bit number to tell the server the order in which spells were used. This is either the 4th item in any of the UNIT_SPELLCAST events or the 8th in the UnitCastingInfo("player") function. If you can figure out a way to hook into these to determine the order that events happened, you can hopefully determine whether to update snapshots more accurately for macro'd abilities (by determining which the player said to use first).

    For spells: The Spell ID on the UNIT_SPELLCAST will match the Spell ID on the GetAura(spellid) function
    For Trinkets: The Spell Name on the UNIT_SPELLCAST will match the Spell Name on the GetItemStats(itemID).

    You could probably use names for the spells too but given that names are non-unique I'd only use em on trinkets where there's no other way to match them up.

    Of course, its easy for me to say its doable since I'm not the one programming it. And also while it might be technically feasible, it might be too performance costly or some other thing I haven't considered. Hopefully this'll give you a good starting point for hammering down the macro problem.

  • Avatar of jlam jlam Jul 22, 2013 at 20:43 UTC - 0 likes

    What I see as the crux of the problem is that Blizzard only cares what its servers thinks is happening, and they pass information to the client to let you know what they think is happening. However, that gap in time between them knowing the actual state of the game versus when the client receives all the information -- that gap causes problems.

    Here's an analogy that may highlight the problem better: Suppose Blizzard has a detailed photograph of a scene and we put a plastic sheet over the photo and reproduce the photograph using a paintbrush. In the main parts, our reproduction and Blizzard's photo will match, but wherever there are sharp lines in the photo, those lines get softened and fudged in the painted reproduction -- it won't match exactly there.

    That photograph is the actual server game state, and the reproduction is what we on the client side of things can manage to make using the game events that Blizzard sends us. Mostly, what we think is the game state matches the true game state, but at the edges when buffs are about to fall off or appear (in my observations in the 300ms range), there's a bit of fudge where we could be wrong about the actual game state.

    What I'm trying to do is to use additional information to repair the client's idea of the game state to more closely match the server's true game state, but to do it without resorting to knowing specific details about buffs and debuffs. However, I think we're always going to be screwed if, just as Rune of Reorigination mastery buff is falling off, you pop a TF+Rip macro. You won't really know what buffs are active on your Rip until you inspect the damage and back-calculate whether RoR and/or TF were actually up.

    Perhaps I'm wrong and there's a way to figure it out. At the very least, as I said before, I'll see if we can err on the conservative side of things so we don't overwrite strong DoTs with weak DoTs.

  • Avatar of ShmooDude ShmooDude Jul 22, 2013 at 17:55 UTC - 0 likes

    Yeah the Bliz UI is no different than stats (you can actually see the delay on the character sheet).

    Sorry if this is repeating what you already know, just want to make sure my understanding is the same as yours.

    Character Stats lag behind UNIT_AURA events.
    Everything lags behind when you say to use an ability (GCD starts when the client says to use an ability, not when that ability is actually used by the server)

    After playing around with it some more, I can actually tell the game to use an ability before TF wears off and it might not have the TF buff applied to it.

    I'm not sure specifically how you're doing it but at least on the tail end of buffs it feels like ovale is too aggressive with trying to re-snapshot. But I suppose that could just be me. I'd rather err on the side of caution and watch to see if the damage is down rather than ovale suggesting I overwrite a potentially higher bleed with a lesser one.

    But back to the macro thing for a second, I had an idea about that while I was messing around. I noticed that (at least for druids) the spell ID for the ability matches the spell id of the aura (ie TF is 5217 for both the ability and the aura). Since the server seems to accurately reproduce the order the macro is in, could ovale do the same via something like UNIT_SPELLCAST events? These events have a LineID which I'm assuming is the order of events (ie if I put TF before Rake, TF will have a lower LineID number than Rake)? You'd probably know better than I but if it does what I think it does it has the potential to make ovale work perfectly for macros (though I don't know how hard the actual programming would be).

  • Avatar of jlam jlam Jul 22, 2013 at 16:03 UTC - 0 likes

    I think you'll have problems when you try to get your script timings down towards the 300ms area. My investigations into the combat log show that in that range, the combat log is very inconsistent in the ordering of events. We can certainly update stats in the direction of safety in the case where the snapshot is incorrect. However, I'd prefer to try to nail down something that can catch the very common case where an on-use ability is macro'ed to a spell.

    As an aside, I'm not sure if you're aware, but the Blizzard UI is no different from any addon -- it is drawn and updated using the same API and same events that every addon uses. In the case of Ovale's paper doll module, it and the Blizzard in-game character sheet actually use very similar code.



Last updated
May 08, 2014
Jul 22, 2013
Fixed - Developer made requested changes. QA should verify.
Defect - A shortcoming, fault, or imperfection
Medium - Normal priority.

Reported by

Possible assignees