Actually, what's funny is that while I do apply the benefits of Haste Potions and Blade Flurry and such to the average-case cycle performance, I do not apply the penalty of Blade Flurry's cost. This is most definitely a cause of DPS inflation. I think both approaches can be considered valid in some ways, and obviously neither is fully correct, but I would say consistency would be the best practice.

Since many other areas of my spreadsheet use the approach of "model cycles as the average case ignoring one-off cases," it is most appropriate that both Blade Flurry's energy cost and its haste contribution not be considered in terms of cycle modeling. However, at the same time, I don't want the sheet's DPS modeling to ignore these factors entirely. As it stands in version 0.2.1, the energy cost is modeled as reducing your DPS by the DPE of your primary CP builder times 25 energy per 120 seconds. While effects like Blade Flurry don't make the average-case cycle shorter, they do contribute some extra energy by virtue of Combat Potency feedback. I would still like to model this, so I used the same approach to add a calculation of the average haste contribution of one-off haste effects (like Bloodlust and Blade Flurry) times the base EPS of Combat Potency times the DPE of your primary CP builder.

The net result, given my current gear and buff setup (which is the default in the sheet) is a DPS reduction of about 0.73%. More importantly, performing several quick checks using AToL, I find that the modeled value of that trinket did not significantly reduce.

Speaking of AToL, I'm intrigued by the curious behavior you found regarding AToL uptime in 0.2.1. However, coincidentally, I was just working earlier tonight on streamlining some of the cycle calculations (removing 4 rows from each cycle model and redoing the AToL calcs a bit, final result was the removal of some 7200 cells from the sheet) and in my updated sheet I cannot find the behavior you identified. I'll simply blame the previous method of calculating AToL uptime being a bit too convoluted and allowing some edge case to slip by me. Note that after making the changes I described, my calculated AToL uptime and DPS for 4s/5r and 5s/5r did not change at all.

(edit) I've been working on the cycle calcs a bit more and managed to find that issue you identified with AToL uptime. Let's look at a 1s/1s/5r cycle, assuming 60 energy pooled for all finishers, and assuming exactly 12 energy generated per second.

First 1s component:
Entry energy: 60 pooled - 25 spent (on 5r) + 25 refunded (RS) = 60
Builder cost: 40 * 0.4 (Ruthlessness) = 16
Exit energy required: 60
Energy gain needed during component: 60 exit - 60 entry + 16 builder = 16
Cycle component time: 16 / 12 = 1.333 seconds

Second 1s component:
Entry energy: 60 pooled - 25 spent (on 1s) + 5 refunded (RS) = 40
Builder cost: 40 * 0.4 (Ruthlessness) = 16
Exit energy required: 60
Energy gain needed during component: 60 exit - 40 entry + 16 builder = 36
Cycle component time: 36 / 12 = 3.000 seconds

5r component:
Entry energy: 60 pooled - 25 spent (on 1s) + 5 refunded (RS) = 40
Builder cost: 40 * 4.4 (Ruthlessness) = 176
Exit energy required: 60
Energy gain needed during component: 60 exit - 40 entry + 176 builder = 196
Cycle component time: 196 / 12 = 16.333 seconds

Total cycle time: (16 + 36 + 196) / 12 = 20.667 seconds
Total builder energy: 16 + 16 + 176 = 208 energy

Let's look at AToL proc possibilities:

First 1s component procs AToL:
Next component: Second 1s component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 40 entry = 160 energy
Builder cost: 16 (16 covered)
Cycle component time: 3.000 seconds
AToL time left: 7.000 seconds
Next component: 5r component
Base AToL energy: 7 seconds uptime * 12 energy per second = 84 energy
Total AToL energy: 84 base + 40 entry = 124 energy
Builder cost: 176 (124 covered)
Cycle component time: 16.333 seconds
AToL expires

Second 1s component procs AToL:
Next component: 5r component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 40 entry = 160 energy
Builder cost: 176 (160 covered)
Cycle component time: 16.333 seconds
AToL expires

5r component procs AToL:
Next component: First 1s component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 60 entry = 180 energy
Builder cost: 16 (16 covered)
Cycle component time: 1.333 seconds
AToL time left: 8.667 seconds
Next component: Second 1s component
Base AToL energy: 8.667 seconds uptime * 12 energy per second = 104 energy
Total AToL energy: 104 base + 40 entry = 144 energy
Builder cost: 16 (16 covered)
Cycle component time: 3.000 seconds
AToL time left: 5.667 seconds
Next component: 5r component
Base AToL energy: 5.667 seconds uptime * 12 energy per second = 68 energy
Total AToL energy: 68 base + 40 entry = 108 energy
Builder cost: 176 (108 covered)
Cycle component time: 16.333 seconds
AToL expires

So, to summarize:

- The first 1s component gets AToL uptime as follows:
--- If the 5r component procs AToL (100%), all 1.333 seconds and all 16 builder energy are covered.
- The second 1s component gets AToL uptime as follows:
--- If the first 1s component procs AtoL (20%), all 3.000 seconds and all 16 builder energy are covered.
--- If the 5r component procs AToL (100%), all 3.000 seconds and all 16 builder energy are covered.
- The 5r component gets AToL uptime as follows:
--- If the previous 5r component procs AToL (100%), 5.667 seconds and 108 builder energy are covered.
--- If the first 1s component procs AToL (20%), 7.000 seconds and 124 builder energy are covered.
--- If the second 1s component procs AToL (20%), 10.000 seconds and 160 builder energy are covered.

Trivially, the two 1s components will always have AToL up. For the 5r component, if any of the three finishers procced AToL, we get 5.667 seconds and 108 builder energy: 1-(1-100%)*(1-20%)*(1-20%) = 100% chance. If either of the two 1s components procced AToL, we get an additional 1.333 seconds and 16 builder energy: 1-(1-20%)*(1-20%) = 36% chance. If the second 1s component procced AToL, we get an additional 3.000 seconds and 36 builder energy: 20% chance. All in all, we get an average of 6.747 seconds and 120.96 builder energy on this component.

Thus, our average total AToL uptime is 1.333 + 3.000 + 6.747 = 11.08 seconds. Given a total cycle length of 20.667 seconds, our AToL uptime is 53.61%. Our average total AToL builder energy is 16 + 16 + 120.96 = 152.96 energy. Given a total builder energy expenditure over the cycle of 208, our average AToL uptime on builders is 73.54%.

For this same cycle, given 12 energy per second, my sheet is telling me 46% AToL uptime and 40% AToL uptime on builders. However, doing this whole analysis allowed me to realize that the reason this bug is occurring has to do with the fact that AToL procs are only modeled across two cycle components following the time they were procced, instead of three. This only causes problems with cycles short enough where an AToL proc can genuinely carry across three cycle components, such as the one given above, or your example of 1s/3r.

(edit 2) After correcting the formulas to account for the extra carryover, the spreadsheet gives values of 53.61% for AToL uptime and 73.54% for AToL uptime on builders for the example 1s/1s/5r cycle with 60 energy pooled per finisher and 12 energy per second, corresponding exactly with the predictions above. Seems correct and should rectify any problems with short cycles. This fix will be deployed in 0.2.2.

Version 0.2.2 is available via the download link at the bottom of the first post (it's back to being an EJ forum attachment instead of requiring a Savefile download). Changes:

- Removed feedback from cooldown-based haste effects into cycle model.
- Added separate calculation of energy feedback from cooldown-based haste effects via Combat Potency.
- AToL procs lasting more than two finishers are now accounted for.
- Greatly streamlined all AToL and FW calculations.

Along with making the AToL and FW calculations a lot more accurate, particularly for short cycles, I was also able to remove about 5100 extraneous cells from the cycle modeling sheets. I also made all the calculations a bit more concise, hopefully improving their readability by others. More importantly, all of these changes reduced the file size by a significant amount, allowing me to switch back from Savefile hosting to the EJ attachment system, which should be more convenient for everyone.

Going from 3 to 4 Drums of Battle on the buffs sheet doesnt increase dps but should, because you are going from 75% to 100% uptime on Drums.

edit: Figured it out *dooh* default values for drummers are 30 60 90 90 and not 120 for the last expected.

I've included some coloring to sheet. Was a bit too cluttered in my opinion and I think it's easier to find the important cells this way (from a user's point of view).
http://sp00n.pytalhost.com/misc/Roguecraft.BC.0.2.2.rar

Now that I have finished that I can actually begin to use it.

Briefly scanned your changes and I like them. I'll commit them all to 0.2.3 and on, unless you have any objection. (Also, you didn't change anything of actual substance in the sheet, right? I assume it's purely coloring/bordering changes and some cell merging and labeling.)

Of course you can use them, that's why I made them in the first place.

As for the changes, I think I didn't break anything. Seems to be working fine for me.
I did copy over the right part of the DPS header from the second to the other sheets, but I think there was nothing important hidden in the empty cells there.
Otherwise it is just colors/borders/merge/alignment.
Oh, I changed race to Night Elf and Faction to Aldor, but these were the only 2 changes before I started adding the coloring.


Picking up koaschten's posting, I'd suggest changing the values for the drums to 0/30/60/90 instead of 30/60/90/120 if you have 4 drummers. Else you'd not be starting the drums until 30 seconds have passed.

For the sheet itself, I think adding select boxes for TRUE/FALSE would be better. It doesn't 'feel' right to type it manually (even more because Excel doesn't accept TRUE/FALSE in the German version, only its equivalence WAHR/FALSCH).
Also, the Saved DPS variable seems a bit lost where it is now, at the very bottom of the sheet. A button to save the value just like in the DPS would be nice, but I don't know if that'd break OO compatibility. For the time being, moving it to the top of the sheet and making it a bit more prominent would be just as good.

I didn't mean that far to the top, i.e. to the header, but rather to the top of the DPS sheet itself, below the header.

As I was tinkering with Windfury Temp Enchant and Windfury Totem on the "Buffs" tab, it would seem that WF is being included twice in the DPS? What am I missing here?

Also, again as mentioned, it would be nice add a stat totals for gear at the bottom or top of the gear page. Not that this can't be accomplished on your own if it is a necessity, but for simplicity sake it would be nice. "Stat Totals from Gear" or something of that nature. I also know that stat totals are on the DPS tab, but some people may want to see gear contribution and changes. Just a thought.

I'll play with it some more tonight. Thanks for your work

Could you be more clear on what you were doing and what leads you to believe Windfury is being counted twice?

You have WF in 2 places.

On the "gear" tab you can add it as a "Temp Enchant".

On the "buffs" tab you have the TRUE/FALSE option of Windfury Totem.

So, is it counting WF twice (it doesn't appear to be from the numbers), or does the WF Totem have to be activated for the Temp Enchant to work.

If I set WF Totem to FALSE and put IP on the MH and then set WF to TRUE, the DPS increases.

So, is WF Totem over-riding the IP?

I see the problem. You shouldn't touch the WF Totem cell on the buffs sheet, it automatically sets itself to TRUE if you specify Windfury for your main hand and FALSE otherwise. If you change it, you break that formula.

I'll make this more obvious in 0.2.3.

Ahh...gotcha.

May want to just leave that out as an option or hidden perhaps to avoid confusion. Maybe also give an option for "none" under temp enchants for people that like to see baselines with zero buffs?

Version 0.2.3 is available via the link in the first post. Changes:

- Redesigned extra attack calculations to allow arbitrary numbers of extra attack types.
- Implemented Blinkstrike.
- Extensive cell formatting and coloring changes graciously provided by sp00n. Cheers!
- Added total hit rating and expertise, with flags if the respective caps are exceeded, to the header on data entry sheets.

As far as the sheet UI goes, I'll continue adding things here and there, but I'm not really going to make huge strides in that direction until I have nothing better to do (i.e. there are ZERO pressing mechanics issues). However, huge props to sp00n for taking it upon himself to do some of that stuff for lazy me. I altered a very small number of the changes he'd made (setting non-DPS talents to gray backgrounds, undoing a couple column width changes to personal taste), but otherwise kept everything, because he did a fantastic job. The sheet looks almost usable now.

For what it's worth, I'm getting to a point of reasonable confidence in the sheet's accuracy. I'll probably remove the beta disclaimer when we get to 0.3.0.

(edit) By the way, Blinkstrike is not especially better than its tier, predictably.

(edit 2 - 11:31 EDT) Did a quick emergency update because the hit/expertise cap labels were horribly broken. Added some conditional formatting while I was at it.

Version 0.3.0 is available via the link in the first post. Changes:

- Fixed a minor error in off hand DPS calculations when syncing AP and haste cooldowns.
- Fixed an error in Hemo debuff DPS calculations.
- Shiv's damage contribution from AP is now properly reduced by the off hand penalty.
- Fixed various minor bugs relating to Shiv/Mutilate and proc calculations.
- Replaced hardcoded rating conversion calculations with a more flexible implementation.
- Reduced Sinister Calling to 1% Backstab/Hemorrhage boost per point, per patch 2.4.3 notes.
- Modified Buffs sheet coloring to be slightly more primary.
- Added an entry for target type (e.g. humanoid, beast).
- Implemented The Night Blade.
- Implemented T5 4pc (Coup de Grace).

I've removed the beta disclaimer. The main feature of 0.3.0 is that I pored over all the calculation sheets to ensure the removal of any significant errors. Although there may be minor bugs remaining, I don't feel that the sheet's general accuracy is in question any longer. I wholeheartedly encourage anybody who uses and enjoys the sheet to recommend it to others for use.

This version will likely become the basis from which I make the Wrath spreadsheet, unless any glaring bugs pop up.

Thanks to everyone who has been entering and re-entering their gear and buffs in the sheet up until this point. I'm pretty confident you can actually stick with this one.

WotLK beta patch notes are available and there's no NDA for the beta, so I can say that I'll have a Wrath version of the sheet available before too long. I'm thinking a couple days, max.

Version 0.1.0 LK is now available! Changes in this version:

- Initial WotLK release.
- Implemented hit rating > spell hit and crit rating > spell crit conversions.
- Vile Poisons (Assassination) changed to 3 points maximum.
- Windfury Totem changed from MH weapon buff to a 16% haste raid buff, increased by up to 4% through talents.
- Grace of Air Totem and Strength of Earth Totem effects rolled together.
- Implemented all new WotLK talents except Cut to the Chase, Murder Spree, and Honor Among Thieves.
- Drums limited to only one use of either type, with Battle preferred if both are activated.
- Implemented all new WotLK raid/group buffs, talents, and changes related to same.

This doesn't quite cover all of the new stuff, but I should be able to finish up Cut to the Chase pretty soon. Honor Among Thieves probably won't ever get implemented unless it becomes so unbalancingly good that I have to do something about it.

I've assumed, in the default settings, that the rogue is in a group like this: BM hunter/SV hunter/rogue/rogue/feral. With raid-wide Battle Shout, Unleashed Rage, and Windfury Totem, there's no particular reason for rogues to be with warriors or shamans. Ferocious Inspiration and Leader of the Pack are both still party-specific, as is Hunting Party, the new survival talent that provides 10 energy on the survival hunter's crits, with an 8 second cooldown. This is estimated for now as one proc per 10 seconds. It may not be optimal for the survival hunter to take this talent; instead, he might spec 7/31/33, which would provide Trueshot Aura and Expose Weakness, but not Hunting Party, and substantially increased personal DPS for the hunter. I've accidentally left Trueshot Aura on at the same time as Hunting Party, which is technically impossible; feel free to correct this error on your own, it's not worth re-uploading.

If you're a little bit lost with the new talents, feel free to take a look at the Wowhead talent calculator for rogues here: LINK. If you'd like some in-depth analysis of the new talents, I've made a lengthy post covering numerous topics, including the new talents, located here: LINK.

Please be extra careful when using this beta spreadsheet. I do not warrant that any conclusions made regarding beta talents and abilities will represent the actual state of rogues at level 80. The purpose of releasing the spreadsheet at this time is to allow those with an interest in game balance to evaluate the talents and buffs in consideration of all external factors.

As far as I know, any %-based haste effect stacks multiplicatively, external or not. Has there been any conclusive proof that external %-based haste effects do not stack at all?

Well, I'm pretty sure the unholy frenzy stacking trick doesn't work any more since the 6k DPS parses on early Hyjal bosses have stopped coming in. So that's what data point indicating that they don't stack anymore, though just because Unholy Frenzy doesn't stack with itself anymore doesn't mean other things can't.

I tested WF Totem/Bloodlust with a shaman friend in the beta and they do currently stack.

I think it makes a certain amount of sense that these abilities, coming from separate sources would stack, as it seems that Blizzard is continuing the trend of adding synergies to raids, especially from the Hybrid classes. Doesn't mean I expect them to suddenly do an about-face and make EA and Sunder stack though... then again, that would probably just be a license for them to drive base armor on bosses into the stratosphere.

When putting in my current gear, I currently see increasing gains in increasing my cycle from 3s/5r to 4s/5r 5s/5r. This is odd since all 3 list 100% SnD uptime, meaning 3s/5r would be the most rupture uptime and should be the highest DPS.
(I currently run 3-3.5s/5r for the most part depending on whether I'm hasted from bloodlust etc. And 3.5s/5r is ~what both other sheets list.)

So my only guess is that the sheet somehow expects me to keep 100% rupture uptime through a 5s/5r cycle, which is near impossible unless ridiculously lucky.

No, that's very possibly correct - this is an effect that has been discussed a couple of different times, but as I can't find a link to the discussion off the top of my head I'll give the short version here:

Compressed cycles of the form Xs5r work by trading Sinister Strike damage for rupture damage. Each cycle is a little shorter, so you gain rupture uptime; however, each cycle also spends some energy on the SnD due to Relentless Strikes not proccing all the time. When you work this tradeoff out, it proves to be advantageous for almost all rogues.

Note the word "almost". It turns out that at very high gear levels (like, mid-to-late Sunwell), with raid buffs, one can reach the point where the extra SS damage is more than the gains of Rupture uptime, hence 5s5r can and does take over at the best cycle above a certain gear/buff level. Usually not by much... but it does happen. Also note that the longer cycles give you more time for energy queuing and the like, which will increase the value of AToL in this sheet and further increase your damage. Hence, if you are seeing at high itemization levels 5s5r overtake the compressed cycles by a small margin... then it's probably correct.