I had a thought today, and wanted to get some opinions on it before deciding whether or not to put it in the sheet.
So, right now, the spreadsheet recommends "tight" cycles - that is, the size of the finishing moves are selected such that with average-case regen, you have exactly enough energy to start the next cycle the instant the last one runs out. The problem with this is that in practice, this can't be done - even ignoring the latency-induced issues of starting each SnD at the exact instant that the last one drops, there's the problem that strings of unlucky Combat Potency, Relentless Strikes, and/or Ruthlessness procs can cause SnD gaps to occur. Some of these can be managed via energy queuing... but some of them can't. Thus, in terms of discussing *real* cycles, there really should be some amount of slack added to each cycle to allow for the variance of procs. I've proposed some rules of thumb for dealing with this - "add half a point to the SnD size and round up" - which are fine as far as they go... but what occurred to me today is that there's no real fundamental reason I can't add that slack to the cycle computation in the first place - meaning that the sheet would then be modeling cycles you might actually be doing.
Now, the issue with this the question of "how much slack is 'enough'?" In an abstract sense, the necessary amount of slack can be computed in an analytic fashion... but in practice, this probability problem is messy enough that no one has ever solved it (to my knowledge). Thus, the question becomes "what is a reasonable approximation to use instead?" There's certainly easy approximations that can be made - for instance, requiring energy regen during the cycle to be 5% more than is needed to sustain the cycle, or plan for SnD to be refreshed with one second left, or some such thing... but it's not really clear to me what the "right thing" is. So if anyone has any ideas on how to define this, I'd like to hear them.
There's also the fact that different people will have different philosophies over how much slack is enough, depending on their latency and just personal opinion on the matter. If it's initially set to some reasonable default - 1 second extra SnD per cycle, or 5% extra energy, or whatever - that will still be too tight for some people and too loose for others. And it won't be as clear what to do with the cycle recommendation - there are people who, seeing a recommended cycle of 3.1s5r, will decide that they can squeeze it down to 3s5r, whereas some people wouldn't be comfortable doing 3s5r with a recommendation of 2.9s5r. Hence, there needs to be some sort of abstract "tightness" parameter that people could play with to figure out how tight their cycle has to be in order to do the stated cycle... and this would ideally be intuitive quantity, so people have an idea how tight a cycle they can manage.
So I guess my question is:
1) Is this a feature that people are interested in seeing, or are you content with the existing model, and
2) Do people have any ideas on the specific details of implementation, such as how the parameter should be defined so people can play with it in a meaningful way?
Maybe leave the current recommendation as-is, relabelling as "tightest possible cycle", and adding an option to show the other bound with a reasonably "looser" set of guidelines? This would give people a window that they could work within, and figure out how their playstyle works with it.
Well, I was thinking that there would be a "tightness" parameter on the advanced settings page that would allow it to be adjustable, with the tightest setting being equivalent to the current behavior. For instance, of the parameter were "number of extra seconds of SnD to allow as cushion" - if you set that to zero, you get the current recommendation - the tight cycle. If you set it to 1 or 2 seconds, you'd get some idea of what the cycle needs to be to give that amount of slack.
there are people who, seeing a recommended cycle of 3.1s5r, will decide that they can squeeze it down to 3s5r
I think this is the key point. Most of us realize that those individuals are doing themselves a disservice by attempting to use a cycle that is so tight they couldn't even use it theoretically. Ideally, whatever method we come up with, should make sure as to avoid suggesting partial cycles. Everyone knows we can't have 3.1 combo points, and the average rogue would probably think "3.1 is closest to 3, so I'll do that". If the spreadsheet can be forced to only suggest whole-number cycles, that would potentially avoid some issues.
This will likely lead to a debate on "weaving" 3s/5r/4s/5r type cycles. However, in practice those aren't terribly great either. Consider that if you could, on average, theoretically maintain a 3.3s/5r or something (some decimal between 3 and 4). Launching a 3s followed by a 5r will likely leave with with less time left on your SnD than would be feasible to get even another 3 combo points, never mind 4. Going the other way, if you launch a 4-point SnD you'll likely end up having too much time left. Yes, you can queue energy a bit to combat this problem.. but that only goes so far. Generally using a cycle which guarantees SnD uptime in near-worst-case scenarios and just cuts SnD time on average is the way to go.
I would definitely like to see some sort of "1 second slack" time put into a cycle due to just sheer latency as well as wanting to hit SnD not "as" it expires, but "just before". What the appropriate buffer on energy regen / free combo points is, I'm not sure.
Lastly, considering for most people the best cycle will either be 4s/5r or 5s/5r, perhaps you could just give the dps estimates for both of those cycles and let people choose for themselves, with the disclaimer that a longer cycle will be more sustainable and less susceptible to RNG luck. Could even put down a 3s/5r cycle with a disclaimer like "Warning, this cycle is quite fragile and not likely sustainable which will result in a dps loss".
I'd just say add both. The energy regen factor could be implemented such that, for example, 0.8 would indicate that the cycle should be calculated assuming you only gain 80% of the average rate of energy during the cycle.
However, if your goal is to make the spreadsheet more "friendly" to people who simply like to put their gear in and get the best cycle out, you may want to implement it directly on the main page as something more abstract like a pulldown box to select the "tightness level" between just a couple values (i.e. none, low, high), which would actually affect both the slack SND time and adjust for lower energy regen. It might help the advanced users to put it in the advanced settings sheet, but it won't help cut down on users who post saying "the spreadsheet told me to do this cycle, but I tried it and it doesn't work".
I'm neither a math nor a spreadsheet whiz, but maybe the following type of model would be possible:
1. For a given cycle, what is the chance that slice and dice will drop? (In my head this would look similar to the odds of DP stacks dropping, but maybe it's not).
2. From that, it would seem you could determine average lost damage to Slice and Dice dropping and account for that in the cycle DPS.
3. Once that is accounted for, perhaps longer Slice and Dice cycles show higher DPS than tighter cycles due to less dropping.
Example:
The current sheet recommends a 3.5s/5r cycle for me. This type of modeling would instead:
1. Figure the average DPS lost to SnD drops by running 3.5s/5r (weaving cycle).
2. Compare to 3s/5r and 4s/5r.
3. Choose the best cycle.
At some point, it would seem that a cycle could get too conservative, and you'd end up losing DPS by playing it too safe. Thus the sheet would recommend the cycle that is both the most maintainable and offers, on average, the most DPS. (i.e. though a riskier cycle may have higher potential, the safer cycle would be more consistant)
So, that's the ideal approach, to be sure, but in practice computing the probability of dropping is actually quite hard. And, in particular, an Excel spreadsheet would be a really annoying place to have to calculate it. It's the sort of feature I'd think about for the Python implementation of this sort of thing, but while we're still talking spreadsheets I think it'd be more trouble than it's worth. Figuring out the probability that any given cycle is short of energy is messy but doable; but with energy queuing and the like that can be absorbed, so one needs to look at the probability that you're short several cycles in a row until you get far enough in debt that it can't be covered... and that starts to look like serious math. Solvable, to be sure - it's easy enough to model it as a random walk and work from there. But it's decidedly painful to do, which is why I'm disinclined to try it just yet.
If I understand you correctly, you are proposing to calculate two different cycles separated by some sort of residual or error number that represents the difference between them (e.g. seconds of Slice and Dice time or Energy amount). The user manipulates this residual/error, according to their personal preferences and connection properties, to generate the new error-corrected cycle that should accurately reflect what they are seeing in the game. As long as users are still able to get back to the raw, theoretical cycle (i.e. error term set to zero as you mentioned earlier) I think that this is a grand idea that has very practical implications.
My vote for a "slackness estimator" would be seconds of Slice and Dice time as this metric has an easy-to-grasp meaning that can be applied without too much difficulty. I, for one, have a better recollection of how much Slice and Dice time is typically left (or not) on my cycles but I'd be hard-pressed to recite this in terms of energy. Furthermore, having this parameter in units of time is very useful when one tries to incorporate their typical latency into the picture.
Can you really get any "looser" than a 5s5r cycle?
I'm inclined to say that maybe the best approach would be to label the current recommended cycle that the spreadsheet produces as the "ideal cycle" with a warning that it is most difficult to maintain and could result in a loss of DPS due to the RNG on missed Ruthlessness and Relentless Strikes procs. Also, have the spreadsheet calculate two other cycles: a 5s5r "default cycle" to give an idea of the baseline DPS one can expect to deliver without concern for cycle efficiency, and one that is based on a user-defined variable (my vote is for the number of seconds allowed in overlapping SnD), maybe called the "practical cycle".
Actually, I'm really glad you had this idea and asked, Aldriana. I always worry when my actual DPS doesn't quite match what the spreadsheet kicks out for me, despite knowing that the spreadsheet is always going to exceed my actual DPS for this very reason. Having a way to loosen up the cycles in the spreadsheet will really help me to see if I'm actually playing up to the potential of my gear and spec. If, selecting a 2 second overlap in SnD yields X DPS on the spreadsheet and my actual DPS during an encounter matches or exceeds that, if nothing else I will feel more confident that I'm not doing something horribly wrong. Then maybe I select a 1 second overlap and see if I can tighten my cycles in game... if it works, awesome! If it doesn't, at least I'll have found what kind of practical approach I can take to dealing predictable, consistent damage, instead of striving towards unattainable DPS at the risk of unsustainable cycles.
1) Yes, you can get looser than 5s5r. You can do, say, 5s4r. Or 5s3r. Or, heck, just 5s. They cost you damage, to be sure - but you *can* get looser.
2) 5s5r is only the "safe" cycle for people of a certain build - namely, Sinister-Strike using rogues with Combat Potency, Relentless Strikes, and Ruthlessness. For dagger rogues, hemo rogues, etc. 5s5r isn't sustainable at all. So there's the question of figuring out the "safe" cycle in the general sense. The general way to do this is to, well, calculate a cycle with some reasonable amount of slack and recommend it.
3) Fundamentally, tracking and reporting 3 different cycles would be beyond a pain in the ass - thus, my plan would be to just report one cycle at a time- whatever is optimal for the specified amount of slack. You want to know the tight cycle? Set it to 0. You want a practical cycle with just a little slack? Set it to a second or two. You want a super safe cycle with lots of slack? Set it to 5 seconds. I'm open to suggestions, of course, but this is the immediate way that occurs to me.
1) Yes, you can get looser than 5s5r. You can do, say, 5s4r. Or 5s3r. Or, heck, just 5s. They cost you damage, to be sure - but you *can* get looser.
2) 5s5r is only the "safe" cycle for people of a certain build - namely, Sinister-Strike using rogues with Combat Potency, Relentless Strikes, and Ruthlessness. For dagger rogues, hemo rogues, etc. 5s5r isn't sustainable at all. So there's the question of figuring out the "safe" cycle in the general sense. The general way to do this is to, well, calculate a cycle with some reasonable amount of slack and recommend it.
3) Fundamentally, tracking and reporting 3 different cycles would be beyond a pain in the ass - thus, my plan would be to just report one cycle at a time- whatever is optimal for the specified amount of slack. You want to know the tight cycle? Set it to 0. You want a practical cycle with just a little slack? Set it to a second or two. You want a super safe cycle with lots of slack? Set it to 5 seconds. I'm open to suggestions, of course, but this is the immediate way that occurs to me.
Re: 1) & 2) -- Doh! My rhetoric, thwarted! This is me embarassed.
Re: 3) -- That makes sense. I know nothing about what goes into setting up a spreadsheet, so that was just my initial thought on the matter, without regard for the logistics of implementing it. I'd be perfectly content with the method you are describing, though. Honestly, I'd really appreciate whatever you do, because it's not like you have to do anything, and your work does greatly benefit us all!
Couldn't you put a box in the settings called SnD left when refreshed, and just substract that number from the 1-5s SnD durations. I have suggested to do the same in the Rogue DPS sheet. (Which is basicly what is already suggested, but differs slightly if you use two SnD's in your cycle)
Not being very good with Excel spreadsheets, I'm not sure if the following is included or in any way accounted for when considering optimal cycles:
Players current expertise rating.
Now we all know that you only need a hit rating of 142 for your special attacks to never miss.
And we all know that you need an expertise rating of 64 (44 if your Human using swords) as a combat spec to avoid all your attacks being dodged or parried.
Now, does the optimum attack cycle take into consideration the lack of EXP or HIT rating and factor in a percentage of lost combo points based on this? Or are we talking about too minimal a difference to make it worthwhile?
When reviewing my WWS reports, I see my Sinister Strikes being parried about 2-3% of the time at a rating of 54 and I do notice my SnD dropping off fairly frequently when using a 3s5r cycle, to the point where I may be having 3-4 seconds of no SnD. So most of the time I go through multiple cycles during a boss fight depending on what procs I get and how my CP's I currently have.
I've thought quite a bit about this and I don't think it's worth the effort. A real world ideal cycle would not be fixed, but changed on the fly depending on procs, bloodlust and such. I myself am not able to compute various cycles and their probabilty of short term sustainability within seconds during a raid, so I've come to accept that I play a ~3s5r cycle. And when I come into a very tight spot every couple of minutes or so, I pop a Thistle Tea.
So what's this rant supposed to tell us? Individual Playstyle, human error and the brain's incapability to do maths quickly make it close to impossible to accurately simulate human behaviour in an Excel spreadsheet.
With the current optimal cycle recommendation, we have something "hard" that is free of bad luck and human interference. Even before you start using the spreadsheet, you'll have a general idea of what your cycles are like, which you then compare to the sheets recommendation. From those two values, you can guess your new real world cycles, if the sheet's suggesting a new one.
And if the sheet's new feature were to recommend a more realistic cycle with a lot of slack, it still wouldn't be accurate for lots of players, so you still have to think for yourself. In the end, you'd go from having one step of mushiness to two steps of mushiness. First there's computed slack and then there's the individual adaption.
So all this effort of simulating a real cycle, which, while it might be closer to reality, still isn't identical to your actual cycle? And what's the DPS difference anyway? Rupture is ~3% of your total damage, so even if you increased that by a couple percent, there still wouldn't be a noticable difference. And if you account for the loss of Sinister Strike damage, it's all just so very close together.
The only place where these little differences might possibly matter, to be honest, is endgame raiding. With my current gear and raid buffs (which are pretty endgameish), the sheet jumps between 2,8s and 5s depending on a few buffs anyway. So it just has to be very close together anyway.
The only thing I'd find worth implementing, would be a DropDownBox to manually select cycles. But judging from the calc sheet names, that's not possible anyway.
Oh, and maybe rename the Approximate Cycle to something like "Chance free cycle".
Just my two cents (And sorry for any misplaced commas. We never learned how to place them in english at school, so when in doubt, I applied german rules.)
Not being very good with Excel spreadsheets, I'm not sure if the following is included or in any way accounted for when considering optimal cycles:
Players current expertise rating.
Now we all know that you only need a hit rating of 142 for your special attacks to never miss.
And we all know that you need an expertise rating of 64 (44 if your Human using swords) as a combat spec to avoid all your attacks being dodged or parried.
Now, does the optimum attack cycle take into consideration the lack of EXP or HIT rating and factor in a percentage of lost combo points based on this? Or are we talking about too minimal a difference to make it worthwhile?
When reviewing my WWS reports, I see my Sinister Strikes being parried about 2-3% of the time at a rating of 54 and I do notice my SnD dropping off fairly frequently when using a 3s5r cycle, to the point where I may be having 3-4 seconds of no SnD. So most of the time I go through multiple cycles during a boss fight depending on what procs I get and how my CP's I currently have.
Bosses cannot parry from behind, so either one of two things is happening:
1) You're attacking from the front (stop that).
2) The boss parried a SS you used right as he spun around to target a different raid member for an ability\debuff\etc. You really won't be able, and nor should you try, to reach a Parry cap. The Expertise cap as it relates to Rogues is entirely about boss dodges.
Yes, the spreadsheet does account for expertise. However, as has just been discussed thoroughly in the last page or so of posts, the spreadsheet will typically recommend the tightest theoretically possible cycle under ideal circumstances. Since a raid environment is never ideal, you should adjust accordingly.
If your SND is dropping, then you need to adjust your cycle, no matter what the spreadsheet recommends. Most likely you will do fine with a 4s/5r cycle, or since there is very little difference, a 5s/5r cycle.
This is actually a really interesting idea ... as a 2pc T4 user, I've been trying hard to stick to 1S5R to maximize dps. However, I drop SND alot more than I'd like (granted, for less than a second in general) due to just not having enough energy. This is particularly an issue when I want to use a long cd - BF or Drums generally, since if I just used a GCD for AR, I'm not going to be having energy problems. It would be interesting to know how much "leeway" I have on 1S5R.
Sorry for the double post, but I've been wrestling with this for awhile and decided to go ahead and ask -
are most of you able to achieve the "raw dps" number the spreadsheet reports? Is this a highly idealized value that just won't happen in the real (game) world, assuming you have the listed buffs?
In my case, the only buffs I can really count on day to day are Imp. GotW and 5x Sunder. We sometimes have an enh shaman ... almost never more than 1 paladin (salv) and we used to have a raiding fury warrior but no more. I run with self-buffed flask and spicy hot talbuk or agility food depending on the target (working on vashj for the most part now). And all of this is reflected in my buff sheet setup. Raw dps claims ~1050-1100 dps ... I can't achieve that in general.
Here's a WWS of clearing SSC except vashj (turned on log after hydross) - I'm the top rogue in the report which appears as Jitte to me.
This overall raid dps is fairly tupical for me. On boss fights that are fairly stable I can generally get between 900 and 1k ... but being consistently above 1k is a bit beyond me at this point.
Amory link here, but I logged off in partial pvp gear so if you want to make any meaningful conclusions based on that you'll have to check back later.
While changing the spreadsheet to reflect my gear I noticed that Fang of Vashj and Heartrazor is listed only under MH and not under OH. I was also wondering if the feature to import from wow armory, that is in the rogue dps spreadsheet, will be added at some point? It made it quick and easy to change from the original gear listed to your own gear when you first download it.
Thank you for the time and work that has been done to put these spreadsheets together.
It's known to be slightly less reliable in terms of accuracy, as the modeling there makes more assumptions than Aldriana's modeling. However, it will still give a reasonable estimate, and it supports Mutilate (which the Gear sheet does not).
Also, look for updates to the cycle modeling coming soon which should improve Mutilate modeling.
Both of these problems are because this sheet does not model Mutilate (or indeed any assassination/seal fate) builds. Both of the daggers you mentioned are terrible combat daggers offhands and are thus not listed in the dropdown.
04/15/08, 7:46 PM
in 
(And sorry for any misplaced commas. We never learned how to place them in english at school, so when in doubt, I applied german rules.)
Similar Threads
