Since we have a tool that we can start testing rotation options with, it is worth discussing what to test (I did not realize that Mew had including a simulator - I missed that when I read the forum post about it).

Some random thoughts on rotations that I have been thinking about:

We should no longer Shred on OOC procs. The relative DPS value and energy cost of Shred is too low to justify this. Mangle refreshing is extremely important. There may be times when clipping Mangle by a few seconds is worth doing. With TF we have 6 seconds to refresh our DoTs and there may be times where we will Mangle first then TF.

We may want to put some new conditionals around TF that look at remaining time on Rip and Rake. While it may be a dps loss to randomly clip either of those with a TFed version, it may be a dps gain to wait 3-8 seconds before casting TF and then refreshing. Taking this further, since we have 6 seconds to refresh after TF, we should look at the respective cooldowns of both Rip and Rake and see if we can wait a few seconds and still be able to refresh both of them - perhaps toward the end of the 6 second window as needed. This would also include making sure we have sufficient combo points to refresh Rip during TF - since we cannot get 5 combo points, Rake and Rip in 6 seconds...

One thing worth thinking about is energy pooling. Since we may want to refresh TF in very fixed windows, energy pooling as implemented could cause a dps loss by suggesting that TF not be cast when it is optimum based on Rip/Rake dropping. We want to optimize both the timing for DoTs and also the energy gain. At the very least we could put in logic that eats up the energy pool as we approach the the TF window.

We need to test the relative value of casting SR with a higher priority than Rip - this will be very dependent on rotation. A 2 point SR will last 27 seconds - so we could sync this with a 27 second TF rotation and do it as a fixed time in the rotation immediately after refreshing Rip. It may make sense to manage SR far more than we are used to today where its priority is so high we need to always keep it up.

Outside of Blood in the Water range, the rules on when to fit in a FB should take into account synchronizing Rip with the next TF. It should not just look at how long before SR and Rip fall off. The 6-8 seconds of no Rip we often get on a FB in WOTLK could be a significant DPS impact if it occurs when TF is coming off of cooldown. This is rotation dependent though and we might build a FB into the rotation assuming some fixed Rip downtime. There is also the question of using the FB glyph - which is a major glyph (the only current major glyph that affects the cat rotation). Using this could make it more viable to use FBs in between Rips and SRs by minimizing the impact of energy loss.

Speaking of rotations. There are several we can test that also use different Glyphs. One possible rotation is to use the glyph of TF and only refresh Rip on TF while doing two Rakes per TF cycle. There is some question about the value of clipping Rake though. We are talking about clipping 1 tick out of 5 (20%) for the non-TF rake in order to keep it synced. But if we don't clip it, the number of Rakes that get TF could be significantly lower. The trade-off is actually one of energy - and when calculated across a fight we may be trading off shreds vs. TF Rakes. Definitely something to test in a simulator.

A rotation that would be interesting to test (although I suspect it will be inferior) is one with no glyph of shred and no glyph of TF where we can line up every other Rip and Rake with TF. The trade-off here is the relative value of other glyphs such as Berserk.

There is, of course the current rotation where we do not try to sync Rake and Rip with TF but just use TF as soon as it is up.

====================As a side note, my impression is that an optimized rotation in Cata will be more complex than it was in WOTLK. The added complexity of TF syncing with DoTs is the primary culprit.

Taking a first stab at a rotation based on using Rip only with TF is up and possibly clipping one tick of the Rake that does not have TF. If we always SR at a fixed time in the rotation - we can move more towards a rotation rather than the priority system prevalent today - it remains to be seen how this will affect overall dps.

Ignore Ravage at fight start - if we Ravage then it would start with Ravage, Mangle, Shred, TF instead of Mangle, Shred, TF (this assumes Ravage costs no energy).

<fight starts - and FF is handled outside of this>MangleShredTFRakeShred until 5 combo pointsRipShred until 3+ combo points (2 is possible but assumes no lag)SR

<loop start>Shred until it is time to Rake (FB when we hit 5 combo points before or after Rake)Continue to Shred until time to TFTF if combo points >= 2 otherwise ShredRakeShred until 5 combo pointsRipShred until 3+ combo pointsSR

<repeat at <loop start> substituting a Mangle for Shred if it is off of cool-down>

Berserk can be built either before or after the SR or just before the middle Rake (if using glyph of Berserk then Berserk should be closer to when SR is used).

=========================

Edit - I will express this as a script later today or tomorrow - it is easily expressible using the priority/coding system in Mew, including the start of the fight. It will be interesting to compare this to the current default script.

- I would argue that Shredding on OOC is still a DPS increase at 80. We're not hurting for CP's to keep Mangle/bleeds up, we just hit like a...kitten...yeah. 85 is arguable, though. - There's basically two delay scenarios we're looking at- delaying TF when Rip/Rake expiration is >6 sec and delaying Rip/Rake if TF CD is <X sec. We'll have to model and sim each of those individually, and yeah, it'll be a pain making everything else hang together with that.- I see where you're going, but I'd caution about putting too much effort into designing a DPS rotation until we have an idea what bosses will be like. If we're moving as much as I think we will be, then anything fixed is going out the window.- FB glyph will be a lifesaver at 85, I'm predicting. Right now, it's a small DPS loss, though only if you play perfectly.

Rather than saying fixed then, how about phased. Note - this is an alternate rotation I am going to model and test to see how it performs. Until we do a lot of measurement - and we have final coefficients on the damage of each of the attacks, we won't really know what is optimum - but we can explore different options in the meantime.

In add fights, our rotations have always been outside the realm of the move predictors as the adds die too fast. So the optimization is around single target. In highly mobile fights, there is a question of resetting what phase we are in assuming that we have implemented the phases in a priority order in the same way the current algorithm is.

As for OOC - I would be surprised if hitting an OOC Shred was more valuable than refreshing a 5 combo point Rip with 1 second left on TF. At the very least, we could add to the OOC Shred conditional to not apply during TF. Another example is where it would be better to FB than Shred on an OOC if there was just enough time to get the FB in and still have time to get enough CPs up for the next TF/DoT refreshing. Shredding at that point might remove the possibility of getting the FB cast in time for the TF and result in CP waste - vs. the 5 energy difference in casting costs between Shed and FB and the increased damage that a 5 point FB does compared to Shred. Both of these cases are when we are on the border of time sensitive actions - but that is part and parcel of our rotation.

As a side note - TF is looking like our most important cooldown now as long as we can use it for DoTs - and we will be working in Berserk in such a way to not impact TF.

I'm not arguing that there's optimizations that can be made (like attaching a conditional to an OOC Shred, as you've recommended) but I'm unsure if the optimizations will make a significant change at this point. I (personally) don't want to get into the rotational fine-tuning until we see if the nerf to our DPS is intended or not. (Of course, if you write a script that shows a significant DPS gain, I'll get on your bandwagon and pretend this post never happened.)

Wouldn't feral dots be treated the same as all other dots? If so then there is no longer a need to fear clipping. I know for warlocks and shadow priests the new mantra is to actually try to clip that last tick as this way you have 100% uptime. The new speel is just added to the last tick.

One thing I was not expecting. Clipping the final tick of Rip and Rake in order to get higher uptimes is a 200 dps gain.

I implemented the most current version of the "default script" that I have been using and I am finding many of the same things you found and implemented in your script:

Any time spent waiting for TF before doing Rip/Rake is a DPS loss.

DPS is higher if you clip the last tick of Rip/Rake by about 200.

One thing that is an interesting difference between our two scripts is the handling of OOC procs. In your script casting SHRED on OOC takes DPs from 17286 to 17319 while in my most current script, casting SHRED on OOC lowers DPS from 17322 to 17278.

I will continue to compare the two scripts to better understand the differences and to look for more optimizations. With the current changes I have made, the DPS is about 300 higher from the version that matches the most recent Ovale script I posted. Most of this was due to adding in the Rake/Rip clipping and other small optimizations that focused on Rip/Rake uptime.

One small comment about your script. In several places you used "|" to express an "or" operation. While it is working, technically speaking, "|" is a bitwise or, and you should be using "||" which is a logical or.

I'm already clipping the last tick by allowing it to refresh with 2sec duration remaining (3s for Rake). Did you mean something else, or were you just saying you got a 200 dps gain off the default script by implementing that? (If you have a Mew script, I'd love to see it and compare.)

I got the 200dps increase by copying the clipping from your script. I started by taking the v1 script and changing it as needed to replicate the Ovale script I have been working on. That was about 300 dps behind yours. I then compared the two to see what made a difference. You will see a lot of things taken from your script in the current one I have - and a couple of differences. Logically the main difference (that I am aware of right now) is that I still have 6 second windows up on SR to protect Rip refreshing - that and I deal with OOC procs differently - but so far changing the OOC handling in either of our scripts to match the other one is a dps loss. This may be an interaction with the windows I have on SR. I have not yet played with the windows themselves (other than trying to remove them entirely) so there may be some optimization there. Here is the most recent script I have that currently generates 17328 DPS using Yawning.mew as the gear setup. I just came back from dinner and plan to go spend sometime on a treadmill - so if you happen to make any optimizations over the next hour, let me know. And yes, I know you are not a programmer (although you pretend well on these scripts). I just pointed that out in the off chance that it might be an issue in your code later - if you change all those to "||" your code performs the same right now.

//// Sample Simulator Script//// Yawning <yawninglol at gmail.com>// (Alaron v1, 8 Oct 2010)// (Leaf v1, 15 Oct 2010)//// WARNING: This routine is invoked every time the Simulator thinks it's a good idea// to query the user for input. While the temptation may be there to pop open a window// and render fractals, doing so is strongly advised against.//

// Heroism // // Note: This doesn't handle "encounters that would result in non-integer uses of heroism" // at all. Defining default behavior for that case is more a matter of personal taste. if (status.getHeroismCD() == 0.0) { // If the mob will die as heroism is falling off if we use it now, use it. if (timeToDie <= 40) return Action.HEROISM;

// If we will get a full heroism in at the end of the fight if we use it now, use it. if (timeToDie >= 600 + 40) return Action.HEROISM; }

// Unholy Frenzy // // Just simulate the DK using this on cooldown for now. More sophisticated things // like stacking it with Berserk or Heroism could be done. if (status.getUnholyFrenzyCD() == 0.0) return Action.UNHOLYFRENZY;

// Ravage if Stampede will drop during the next global. if (status.isStampedeUp() && status.getStampedeRemaining() <= 1.0) return Action.RAVAGE;

// actions+=/berserk_cat,if=energy>=80&energy<=90&!buff.tigers_fury.up // Since Berserk does not clip Tiger's Fury anymore, stacking is ideal but makes this encounter sensitive. // For now Berserk whenever we are at the correct energy level, and when it won't push back the next TF. // The difference between the two appears to be < 10 DPS. if (energy >= 80 && energy <= (status.getEnergyCap() - energyPerSec) && canBerserk && status.getTigersFuryCD() > 15) return Action.BERSERK;

Yeah, I see what you're trying to do. I'm sure we can squeeze out some more DPS by using some kind of stepwise function on some of the if statements, but that would take forever to figure out and I'm not sure how much benefit it would be. (My dream is a genetic algorithm that could automatically solve for the best rotation...I talked to a few people about doing that with Simcraft a while ago and they said I was crazy. I'm not crazy, dammit!)

And I do appreciate the correction. I keep meaning to sit down and learn a programming language, whenever the Army will let me.

I saw that. Should we be using a different Glyph, and does that have something to do with not being able to overwrite a Rip? I verified that with no shreds - mangle to 5 cps, TF, Rip, mangle to 5 CPs, Rip and get the error message. It is a pretty small dps loss though - it looks like the biggest chunk of the dps gain comes from clipping Rake, not Rip.

I posted a new script based on the Mew results. I also broke up some of combined sections into separate conditions to match how the logic is expressed in the Mew scripts. I just did a 10 minute run with 11515 dps (I took the script off the website to make sure what I posted was not bugged).

Take a look at it when you have a chance. Other than the names being a little on the long side (as those are based on the Ovale default script) it is a good starting place. I did have to slightly alter some of the conditionals due to what is available in Ovale but it is close. I really like the feel of the rotation now - it is very tight and easy to maintain.

I put in Stampede code but it was causing errors - so you can see it there - just commented out. I have not yet added in Berserk code. With the new rotation (TF) and the possibility of switching to the Berserk glyph, saving Berserk for specific times in the fight will be much more difficult - so it makes a lot more sense now to use the Ovale to optimize when to use it (as in the 5 seconds after a TF has been cast).

Yep. Theoretically, the best time to use Berserk is immediately following a TF, as then you're sitting on 70+ energy and can basically spam abilities for 5s that are 15% buffed. Of course, this means you basically need to have 0 energy (probably by using a FB) before you start.Primal Madness could also come into play here, but it still seems to work very oddly. It's be good to test how Berserk + TF interact with PM.

Alaron, here is the most recent version of my Mew script. It is extremely close to the Ovale script I posted earlier tonight. I don't have any plans to take this any further right now. It is 7dps less than your most recent script - but if I add in Rip clipping at 2 seconds, it ends up being 28dps higher (using Yawning.mew). In other words, the dps difference between the two scripts is "in the noise." I do think this is a little easier to execute in game do to not doing anything special for OOC procs.

//// Sample Simulator Script//// Yawning <yawninglol at gmail.com>// (Alaron v1, 8 Oct 2010)// (Leaf v1, 17 Oct 2010)// Note - this script incorporates a lot Alaron's most recent modifications to Yawning's model - which is now the default model.// Most of the testing was done using Yawning.mew.// This was developed in conjunction with an Ovale script and they are very close to one another in functionality.// The Ovale script can be found at: http://fluiddruid.net/forum/viewtopic.php?p=427#p427// Since it is not always possible to clip Rip in game, // this script has no Rip clipping in it. The default script clips Rip with 2 seconds left.// Some differences: SR handling is different - it is prioritized below Rip. There is no special OOC handling -// OOC procs are just used in the normal rotation. This makes the rotation easier to use in game as it does// not swap to Shred on a proc. The code to desync Rip and SR is different as it incorporates the prioritization of Rip over SR.// DPS is 7 below the default script, although it is 28 above if 2 second Rip clipping is added to this script.// In other words, the two scripts are very close in total DPS.// If the simulator is not taking into account "A more powerful spell is already active,"// then the results for the default script are not accurate. I am guessing this is not being modeled right now.//// WARNING: This routine is invoked every time the Simulator thinks it's a good idea// to query the user for input. While the temptation may be there to pop open a window// and render fractals, doing so is strongly advised against.//

// Heroism // // Note: This doesn't handle "encounters that would result in non-integer uses of heroism" // at all. Defining default behavior for that case is more a matter of personal taste. if (status.getHeroismCD() == 0.0) { // If the mob will die as heroism is falling off if we use it now, use it. if (timeToDie <= 40) return Action.HEROISM;

// If we will get a full heroism in at the end of the fight if we use it now, use it. if (timeToDie >= 600 + 40) return Action.HEROISM; }

// Unholy Frenzy // // Just simulate the DK using this on cooldown for now. More sophisticated things // like stacking it with Berserk or Heroism could be done. if (status.getUnholyFrenzyCD() == 0.0) return Action.UNHOLYFRENZY;

// Ravage if Stampede will drop during the next global. if (status.isStampedeUp() && status.getStampedeRemaining() <= 2.0) return Action.RAVAGE;

// actions+=/berserk_cat,if=energy>=80&energy<=90&!buff.tigers_fury.up // Since Berserk does not clip Tiger's Fury anymore, stacking is ideal but makes this encounter sensitive. // For now Berserk whenever we are at the correct energy level, and when it won't push back the next TF. // The difference between the two appears to be < 10 DPS. if (energy >= 80 && energy <= (status.getEnergyCap() - energyPerSec) && canBerserk && status.getTigersFuryCD() > 15) return Action.BERSERK;