[WOTLK 4.0] Cats - Page 31

a civilian · 11/19/10, 12:51 AM

Originally Posted by Leafkiller

If you model it in Mew it is always a dps loss to wait on Rake/Rip for TF - even if it comes off of cooldown .1 seconds later. I think this due to the possibility that TF will not always be immediately cast due to OOC or just having too much energy.

I would be extremely wary of trusting simulation results that run directly counter to rudimentary estimates and/or common sense. They could easily be artifacts of the simulation, whether the mechanics or the strategy. In particular, while I doubt it's worth waiting 3 seconds for TF (per the previous post), it's certainly worth waiting 0.1 seconds. We could say the resulting rip downtime is perhaps 0.3 seconds due to latency, but that's still a loss of only 1.25% of a rip in exchange for a gain of 15%. Energy can be planned in advance and clearcasting will be consumed by the rip at only a small loss.

Edit: Also, the glyph comparison depends strongly on fight length. For example, with my stats (at 80), Mew (simulation) says berserk > SR > TF in a 5 minute fight, TF > SR > berserk in a 3'2" fight, and TF > berserk > SR in a 2'3" fight.

Leafkiller · 11/19/10, 3:52 AM

Originally Posted by a civilian

Energy can be planned in advance and clearcasting will be consumed by the rip at only a small loss.

Bear in mind that the moment you wait for TF, it is unlikely you will be waiting for a fraction of a second - so even if you have been bringing your energy down in preparation for the TF, you could be gaining some back when you try to sync up - and will either waste energy if you TF with too much energy, or need to add an additional Shred in. This could add an additional GCD - so the wait can be longer than you think.

Edit:

Edit: Also, the glyph comparison depends strongly on fight length. For example, with my stats (at 80), Mew (simulation) says berserk > SR > TF in a 5 minute fight, TF > SR > berserk in a 3'2" fight, and TF > berserk > SR in a 2'3" fight.

With the level 85 t-11 premade toon I have been modeling with it is not close anymore. TF > SR and Berserk by a lot (200-300 dps) at all three of those fight lengths.

Astrylian · 11/19/10, 4:05 AM

Originally Posted by Leafkiller

Bear in mind that the moment you wait for TF, it is unlikely you will be waiting for a fraction of a second - so even if you have been bringing your energy down in preparation for the TF, you could be gaining some back when you try to sync up - and will either waste energy if you TF with too much energy, or need to add an additional Shred in. This could add an additional GCD - so the wait can be longer than you think.

Perhaps you missed it, but his point (and the obviously valid one) is that the simulation is suspect because waiting 0.1sec for TF to be obviously is a DPS gain, despite what the simulation says.

Leafkiller · 11/19/10, 4:37 AM

Originally Posted by Astrylian

Perhaps you missed it, but his point (and the obviously valid one) is that the simulation is suspect because waiting 0.1sec for TF to be obviously is a DPS gain, despite what the simulation says.

No - I did not miss this. Read my response more carefully and look at the hard data below. There was a point where the simulation was suspect because the dps difference was too large for waiting (it was inserting a GCD for TF) but that was fixed a few weeks ago. Rather than keep this discussion at the level of generalities, look at the data below which shows why this is happening.

Keep in mind you are waiting .1 seconds for TF to come off of cooldown. That does not mean it will always be cast as there are other constraints that affect it - energy level and OOC procs. The actual question to ask what is the average time between when TF comes off of cooldown and when it is actually cast. Also, if you are delaying a Rip or Rake for TF to come off of cooldown, there is some extra energy gain that can further delay the casting of TF. The alternative is losing energy by casting TF with too much. So the trade-off becomes either some downtime before casting Rip/Rake and/or lost energy. With human reflexes if anything I would expect this to be worse than the simulator, not better.

Here are some numbers comparing not waiting for TF, or setting a .1 second constraint on the t11 premade (5 minute fight):

Don't wait:
DPS: 22049.31306
Energy Regen (e/s): 18.06065
Number Rakes: 19.4846
Rake Uptime (%): 96.34993
Number Rips: 10.4305
Rip Uptime (%): 96.18875
Rake DPE: 1977.50545
Rip DPE: 4434.13373
Number Tiger's Furys: 11
Tiger's Fury Uptime (%): 22

Wait:
DPS: 22001.16462
Energy Regen (e/s): 18.04708
Number Rakes: 19.1555
Rake Uptime (%): 94.92141
Number Rips: 10.367
Rip Uptime (%): 95.55276
Rake DPE: 2011.80653
Rip DPE: 4448.69062
Number Tiger's Furys: 11
Tiger's Fury Uptime (%): 22

As you can see, the tradeoff is DPE vs. uptime - and while it is close, uptime is worth slightly more than the DPE gain. Also keep in mind, that the rotation is simplified by not trying to sync Rip/Rake with TF - so in this case the optimum rotation is also the simplest rotation - which means people are more likely to execute it properly. As I stated above, I would expect a human being to do worse than the simulator and have a larger disparity in the uptime - making the difference even greater.

Edit: On the subject of Mew being "suspect" on the handling of TF with Rip/Rake, we can certainly ask Yawning to make sure the code is doing what it should be (or dive into the code).

ineb · 11/19/10, 11:52 AM

Thank you for the posts guys, I am notoriously bad at anything beyond simple math and they were a big help

. I just figured it would be nice to address the subject in the thread. I personally got a bit higher DPS waiting, but that was a 6m test with no moving on a target dummy and there's a good chance that was just RNG since I only did it once.

To switch gears, does anyone have a link to some feral parses at 85? I'm curious as to how feral is doing at level cap, I enjoy being near the top of meters and am debating rerolling a pure dps class (lock or hunter) for Cataclysm.

Astrylian · 11/19/10, 1:51 PM

Originally Posted by Leafkiller

No - I did not miss this. Read my response more carefully and look at the hard data below. There was a point where the simulation was suspect because the dps difference was too large for waiting (it was inserting a GCD for TF) but that was fixed a few weeks ago. Rather than keep this discussion at the level of generalities, look at the data below which shows why this is happening.

OK, let me try this again, more bluntly. You're citing data from Mews to prove a point. We're telling you that you can't do that, because the point you're trying to prove is obviously wrong. Those results show that Mews is doing something wrong.

Leafkiller · 11/19/10, 3:31 PM

Originally Posted by Astrylian

OK, let me try this again, more bluntly. You're citing data from Mews to prove a point. We're telling you that you can't do that, because the point you're trying to prove is obviously wrong. Those results show that Mews is doing something wrong.

I sent a PM to Yawning asking him to check the Mew code for issues. The possible issues I could think of off the top of my head were GCD handling with TF (before and after) and Rip/Rake damage handling.

I also did some refinements on my script and I can now get a 12dps increase over having no TF conditionals with the code as follows (DPS: 22061.59603):

double tfRemaining = status.getTigersFuryCD();

if (cps >= 5 && timeToDie >= 6 && (!status.isRipUp() || ripRemaining < 2.0) && (!(!status.isBerserkUp() && tfRemaining < 0.0) || status.isOoCUp() || energy >= 60)) {

if (timeToDie >= status.getRakeBaseDuration() && (!status.isRakeUp() || rakeRemaining < 3.0) && (!(!status.isBerserkUp() && tfRemaining < 2.0) || status.isOoCUp() || energy >= 60)) {

My conditionals have room for additional refinement by comparing expiration times so I might be able to push that higher but it is still very small.

In any event, we can discuss the "whys" of the rotation after verifying the accuracy of Mew's code since, as you point out, there is no point in discussing the results if the tool itself is in question.

Yawning · 11/19/10, 7:03 PM

Just to throw my 2 Japanese Yen into the discussion.

There's a few possible explanations for why modeled behavior was different from intuition:
a) The Mew simulator has bugs in how it models TF/Rake/Rip

The code in question to look at would be:
EventRake.java - mew-wow-druid-model - Project Hosting on Google Code
EventRip.java - mew-wow-druid-model - Project Hosting on Google Code
EventTigersFury.java - mew-wow-druid-model - Project Hosting on Google Code
SimulationEngine.java - mew-wow-druid-model - Project Hosting on Google Code

I'm not seeing anything that immediately stands out as "This is blatantly wrong", but I am overfamiliar with it, and may be missing something obvious. (NB: Glyph of Shred is treated as +2 sec, since I haven't taken the time to exactly quantify bug behavior and add it to the "Blizzard Bugs" code. This is irrelevant when asking about holding Rake/Rip for TF.)

Edit: Leafkiller found a bug via code inspection. Rake wasn't getting the tf multiplier for the direct component. It changes net DPS by ~7 or so for a well geared level 80 druid. (Fixed in r349)

b) The Mew simulator behavior has quirks that produce artifacts.

To understand some of this, a brief overview of the Mew simulator design is in order. Mew at it's core is a Discrete Event Simulator (Discrete event simulation - Wikipedia, the free encyclopedia). There is a simulation clock, and a list of events that can occur. The event list is structured as a list of "things that will happen <T> seconds in the future", the clock is advanced by pulling things off the event queue.

The first source of timing artifacts is TF specific. For performance reasons, Mew currently does not query the strategy at all while the player is in a GCD. This forces Tiger's Fury usage to be GCD aligned, but it correctly treats TF as not causing a GCD, so it will still do things like "TF + Rake at exactly the same moment. The obvious concern here would be losing TF uptime due to slightly pushing back TF casts, however recent revisions of the script report near perfect TF uptime (given that there is a few seconds of downtime at the beginning of the fight). This does not affect bleeds at all since casting TF does not push back bleed application, and from the testing that was done when the decision was made to add this optimization, there was no statistically significant difference between GCD aligned TF and non GCD aligned TF.

The second source of timing artifacts is generic. By default, Mew will only query the strategy for an action when not in a GCD whenever it processes an event. An event is something like "the player exiting the GCD", "a DoT ticking", "energy gain", "buff gain/fade", or "a white swing". If the modeled player exits the GCD, and the script responds that there is nothing to do, there's a small but non-negligible interval till the next time the script is queried, though it will be always < 100 ms in sim clock time due to energy gains. This has a impact specifically for "holding our global pooling so we can refresh bleeds at exactly the right moment". The "High Resolution Timer" option which Leafkiller is using when doing script tuning solves this problem by scheduling a dummy event every 1 msec when the player is not in a GCD, thus this is a non-issue. For all intents and purposes, his simulated druid can take actions at a 1 msec precision. (As a side note, I'm open to suggestions regarding making this behavior the default or not. I've gotten one good case for making it the default, but the run time penalty for it is rather extreme for a < 10 - 20 dps gain. It should be used for micro-optimizing script behavior though.)

c) The Mew simulator implementation is correct, no one has been able to find a script that produces gains from the situations under discussion.

Mew's simulator output is only as good as the script's. It is quite easy to write a script that will produce non-optimal DPS, and for reasons that should be painfully obvious, writing a script that will produce optimal behavior is extremely difficult. Since Leafkiller is now showing a small gain by micro managing TF, I personally think that this is the most likely case. (As a side note, holding Rip waiting for the TF cooldown being a minor gain has come up in some of Toskk's testing, the optimal behavior for it hasn't been quantified perfectly so the change hasn't made it's way back into the script in SVN yet.)

Script design is an iterative process, and there hasn't been much time to iterate on it (I'm extremely appreciative of the feedback that I've received from Alaron/Leafkiller/Toskk and countless others thus far).

At this point, I'm in agreement with Leafkiller:

Keep in mind you are waiting .1 seconds for TF to come off of cooldown. That does not mean it will always be cast as there are other constraints that affect it - energy level and OOC procs. The actual question to ask what is the average time between when TF comes off of cooldown and when it is actually cast. Also, if you are delaying a Rip or Rake for TF to come off of cooldown, there is some extra energy gain that can further delay the casting of TF. The alternative is losing energy by casting TF with too much. So the trade-off becomes either some downtime before casting Rip/Rake and/or lost energy.

In addition to this, there are several factors that I assume would favor the "do not hold" scenario (which reduces the observed gains).
a) Misses/Dodges. May be a small factor with the absurd meta gem requirements in Cata (Never going to gem Expertise though), but some of the time, you will miss enough to where you end up with bleed downtime by holding and or energy capping.
b)CP generation effects. By holding Rake, you are pushing back CP acquisition (doesn't matter too much since CPs are relatively fluid as a resource). By holding Rip, depending on energy level/clear casts and your priority list, you may be forced to use Shreds to burn energy down to the point where you can TF (The alternative is wasting energy).

For something like the Simulator, once definitive timings are established, holding is closer towards the inhuman perfection required, so the default script will do so. For Ovale or what real people should do as "good practice", I think the "hold bleeds for TF" requires entirely too much precision to consistently execute at a DPS gain (since the potential for loss is quite high with human reaction time, latency, error), especially for a 0.05% potential gain under ideal conditions (assuming the model is correct).

I would naturally be overjoyed if someone finds bugs in the code or further improves script behavior since it will improve the quality of the results.

Astrylian · 11/19/10, 9:55 PM

Is your simulator not taking advantage of DoT queueing? You mentioning misses/dodges implies that you don't.

Talented, Rake ticks 5 times.

t=0: Rake applied
t=3: Rake ticks
t=6: Rake ticks
t=9: Rake ticks
t=12: Rake ticks
t=15: Rake ticks

You can reapply dots at any point between the last two ticks, and not lose any ticks:

t=0: Rake applied
t=3: Rake ticks
t=6: Rake ticks
t=9: Rake ticks
t=12: Rake ticks
t=13: Rake re-applied
t=15: Rake ticks
t=18: Rake ticks
t=21: Rake ticks
t=24: Rake ticks
t=27: Rake ticks
t=30: Rake ticks

Additionally, the damage of the dot is updated at the point that it's re-applied. So if the re-application is with TF, you actually can get 6 TF'd ticks out of it. However, it goes both ways; if you have TF'd-Rake up, and apply Normal-Rake between the last 2 ticks, the next tick will not be TF'd. So it may be optimal to use the queueing on every other Rake application, sync'd with TF.

Whenever you use the DoT queuing, avoidance is nearly moot; if you miss once, no lost uptime. If you miss twice, no lost uptime with Rake, only latency lost uptime with Rip. If you miss thrice, only latency lost uptime with Rake, 1 GCD lost with Rip. You have to miss *4* times with Rake, or *3* times with Rip, to lose any uptime beyond latency.

Yawning · 11/19/10, 10:25 PM

Originally Posted by Astrylian

Is your simulator not taking advantage of DoT queueing? You mentioning misses/dodges implies that you don't.

It takes care of that, however consistently queueing Rip is difficult with the live implementation. (Yep, Rake/Rip behavior is inconsistent. It implements what I understand to be correct for both.)

Additionally, the damage of the dot is updated at the point that it's re-applied. So if the re-application is with TF, you actually can get 6 TF'd ticks out of it. However, it goes both ways; if you have TF'd-Rake up, and apply Normal-Rake between the last 2 ticks, the next tick will not be TF'd. So it may be optimal to use the queueing on every other Rake application, sync'd with TF.

Whenever you use the DoT queuing, avoidance is nearly moot; if you miss once, no lost uptime. If you miss twice, no lost uptime with Rake, only latency lost uptime with Rip. If you miss thrice, only latency lost uptime with Rake, 1 GCD lost with Rip. You have to miss *4* times with Rake, or *3* times with Rip, to lose any uptime beyond latency.

You're quite correct in saying that misses/dodges don't matter normally. (The default simulator script behavior has been tuned to take advantage of this for a while, and queuing has been present in one form or another since I first wrote it.)

Except in the context of this discussion, we were discussing holding off Rake/Rip refresh based on TF coming off CD right? Or am I missing something. Leafkiller/Toskk say that pushing back Rip refresh by up to 2 seconds is ok to get the next Rip TFed. Assuming we do so, the amount of time you're pushing back Rip so you can TF it is directly cutting into the window you have to refresh. The point I was trying to make was that in the context of holding DoT refreshes in anticipation of TF coming off CD, misses/dodges do matter.

Astrylian · 11/19/10, 10:33 PM

You can hold off Ripping by up to 2 sec, and Raking by up to 3 sec, from when you first can do it, with no uptime loss, though.

Leafkiller · 11/19/10, 11:28 PM

Originally Posted by Astrylian

You can hold off Ripping by up to 2 sec, and Raking by up to 3 sec, from when you first can do it, with no uptime loss, though.

The sim scripts include that - it is set to clip rake if rake left is less than 3.0 seconds and clip rip if rip left is less than 2.0 seconds. The results I posted include that logic. I will continue to investigate ways to optimize the dps through TF syncing and see if I can make it meaningful enough to include in the rotation. The earlier versions of my script did that but I removed it when it was showing as a dps loss in my simulations (although a very small one). With the more sophisticated checks I have now - it looks like it is a small dps gain.

I have some more ideas of ways to refine my logic that I will test out - and if I find anything interesting I will post it and test it in Ovale to see how the rotation feels. I want to make sure it is both meaningful and also something that can be executed in game.

edit: One thing we kind of glossed over in this discussion. There are only 10 or 11 TFs in a 5 minute fight. We are dealing with a case where Rip/Rake is coming off of cooldown within 2/3 seconds of TF coming off of cooldown (or more to the point within 1 second), where there is no OOC proc and where energy is low enough that you won't need to Shred first. This is a small case that does not happen often.

Leafkiller · 11/20/10, 5:54 PM

I did some additional testing on waiting for TF before Rip/Rake. What I found is that as long as TF will be up before the end of the clip window, then in Mew it is a dps up to wait for TF. Specifically, I had the best simulated results with the following two conditionals:

if (cps >= 5 && timeToDie >= 6 && (!status.isRipUp() || ripRemaining < 2.0) && (status.isBerserkUp() || ripRemaining <= tfRemaining))

if (timeToDie >= status.getRakeBaseDuration() && (!status.isRakeUp() || rakeRemaining < 3.0) && (status.isBerserkUp() || rakeRemaining - 0.8 <= tfRemaining || energy >= 71))

Testing with two different level 80 toons and two premade t-11 toons, the dps up for waiting varies from around 10dps for the level 80 toons to up to 40dps for the t-11 premades.

Rip in particular is extremely sensitive to being cast late - even setting the code to allow only a .5 second late window on Rip becomes a dps loss over not waiting at all for TF. Given the human factors in an actual fight, I would recommend against waiting on TF before casting Rip. The chances of missing the clip window due to TF being delayed are too high.

On the other hand, Rake is not as sensitive to missing the clip window. For the level 80 toons, syncing is pretty much a wash with or without waiting for TF, and for the level 85 premades, even allowing for Rake to be cast up to 1 second after the clip window, putting the code in to wait for TF is a 20-25 dps gain (around .1%).

From a rotational perspective, if you are using a move suggester such as Ovale, then putting in the sync code does not make the rotation any more difficult. Clearly for someone not using a move suggester, it is more complex to try to synchronize the Rake and TF timers and fit both into the clip window.

I am going to leave this out of my rotation at this point unless something changes to make this more beneficial.

Astrylian · 11/26/10, 6:25 PM

I've got Rawr.Bear mostly ready for Cata, and am focusing now on Rawr.Cat. Here's my musings on how to closed-form model Cat DPS right now. An important note here is that, as before, Rawr.Cat will be based on a player which plays optimally (but that's not to be confused with a player which players better than optimally, is especially lucky, or can predict the future, or has 0 reaction time. Most people will not reach their optimal DPS, but they could).

Ability Usage
Melee: Constantly used for full fight duration.
Rake: Constantly ticking after 1sec (Ravage) or 2sec (Ravage+Mangle if applying Mangle). 1-2 misses in a row do not reduce uptime, 3 misses in a row reduces uptime by [latency]. 4+ misses in a row reduces uptime by [misses-3+latency].
Rip: Constantly ticking after 5cp are generated. 1 miss does not reduce uptime. 2 misses in a row reduces uptime by [latency]. 3+ misses in a row reduces uptime by [misses-2+latency].
Mangle: Used 1/min, if not covered by someone else. (EDIT: Or used thrice at the start and then once every 30sec with T11)
Shred: Used to generate needed combo points for Rip+SR uptime, and then extra energy used on it (minus energy needed to FB enough).
Ferocious Bite: Used to use up extra CP. Will have to evaluate both 35 and 0 extra energy bites.
Ravage: Will model ravage as an attack that takes 2 GCDs, can be used every 30sec, costs 10 energy, and you lose [1-s/2]sec of melee damage (s=melee attack speed). Will make it optional, and evaluate with and without it.
Savage Roar: Constant after 5+5cp.
Tiger's Fury: Used every 30sec, after 3sec (to use up initial energy). Need more thought on what attacks get the +15% boost. At least the 30%->0% Rip will be boosted, beyond that perhaps just evaluate whether they'll line up right with each Rip/Rake application.
Berserk: Used every 3min, after 3sec (to use up initial energy).

Will probably evaluate the rotation once for 100%->25%, and then a second time for 25%->0%, with Rip applications (but not damage) ignored.

EDIT 2: Here's the damage numbers I've got; if anyone has anything more up to date, please let me know:

Melee: 1 + WeaponDPS + AP/14
Fury Swipes: (Melee+0)*3.1
Mangle: (Melee+316)*3.6
Ravage: (Melee+330)*8.5
Shred: (Melee+330)*3.5
Rake Init: 304 + AP*.023
Rake Tick: 620 + AP*.14
Rip Tick: 868 + AP*.115
Ferocious Bite: 2822 + AP*.545

Melee, Fury Swipes, Mangle, Ravage, Shred, and Ferocious Bite are affected by armor. (TODO: Check if Rake Init is; it wasn't last I checked, but that's inconsistent with Lacerate/Thrash, so they may have fixed/changed that)
Savage Roar buffs plain Melee by 50%, or 55% when glyphed (but not any of the others that are based on Melee).
Bleed multipliers buff Shred, Rake Init, Rake Tick, and Rip Tick by 30%.
4T10 and 2T11 buff Rake Init and Rake Tick by 10%.
Glyph of Mangle buffs Mangle by 10%.
Glyph of Rip buffs Rip Tick by 15%.
Feral Aggression buffs Ferocious Bite by 10%.
Rend and Tear buffs Shred by 20% on bleeding targets.
Tiger's Fury buffs abilities applied while it's up by 15%.

Any other damage-affecting things I'm forgetting?

teranosouras · 11/26/10, 9:58 PM

Mangle: Used 1/min, if not covered by someone else

T11 set bonus would need to be allowed somewhere too, not letting those stacks fall off etc.