• Latito

One of the other issues that doesn't seem to be addressed is that our OH weapon speed changes. Modeling based on a constant rate of attack (averaged based total haste, etc) would put someone at say an average OH attack speed of 0.85. This is however a far cry from being at 1.00 for 50% of the time and 0.70 for 50% of the time. Considering that in the real world, speed varies even more, things get tricky. The faster your OH goes, the more likely you are to be able to maintain a DP stack w/o points in Imp poisons, thus the more valuable Vile poisons becomes. However, the slower your OH is, the more likely you are to lose your DP stack, and thus Imp poisons becomes more valuable. Considering most rogues are likely going to spend some time on either side of this line where Imp and Vile poisons cross in terms of relative usefulness, modeling based on an average amount of haste is perhaps not the best model to use.

Ideally, one would need a simulator which properly models all haste buffs, not average haste. Or am I blowing this out of proportion, and averages aren't that bad for this?

 

• Aldriana

Averages are certainly going to have inaccuracies. How bad these inaccuracies are is hard to say; my guess would be that they're going to be fairly small, but it's hard to say for sure.

Personally, I fell pretty comfortable ignoring the problem, as we're already talking differences on the order of 1 or 2 DPS out of 2000, so I'm not *too* worried about our results being ever-so-slightly skewed by averaging. Of course, you could argue that we're already past the point where the inaccuracy in our model is relevant, which is probably a fair criticism; the difference is that that problem can theoretically be solved, whereas removing the various time-averaging basically can only be modeled through a simulator; thus the first problem is still relevant as a sort of theoretically-interesting math problem, while the second strikes me as... less so.

 

moktrizz

ABOUT HASTE RATING....

now, with all those new items giving so much haste rating, calculating base speed, haste %, haste proc ( ex: mongoose, trinkets), blade fury, slice and dices, haste potions, drum of battle and shammy s heroism.... i was capable of topping over 305% speed attack (using Anavar's Attack Speedometer addon), bringing my mainhand at 0.85 and my offhand 0.45...

now my question is: DOES MY WEAPONS REALLY GO AT THAT RATE ? OR IS IT A LIMITH TO HOW FAST ANY WEAPONS CAN BECOME ?

 

Left

Yes, it can go that fast. There are screenshots, in fact, of people with weapon speeds underneath 0.10. (That was, however, pre stacking-%-haste nerf.)

Also, please don't use all caps, and please check your spelling.

 

• Aldriana

So, I'd like to take a few minutes to discuss cycles. I've been thinking about this for the last few weeks, and while I haven't really come to any firm conclusions or solved all the problems there are to solve, I figure I'll just toss what I have out for discussion and see if anyone has any ideas on the outstanding issues.

The fundamental problem that I'm trying to address is that, fundamentally, we don't have a good theoretical understanding of cycles. To date, our technique for finding the best available cycle is... plug all the options we can think of into a spreadsheet, and see what happens. This is a fine approach, and I think we've probably got the right answer in most cases by so doing... but I have no confidence that we have all the edge cases correct. And I don't think we will, until we understand *why* cycles are good on a more theoretical level.

Now, some of you probably have no idea what I'm talking about and/or don't see the need for this. So, a couple examples of the stuff I'm talking about:

1) It's usually assumed that SnD is the best finisher, by a lot - heck, it's one of my rules of rogue DPS - "Don't let SnD drop". And, usually, it is... except when it's not. At least two rogues have posted on these forums in the past few months for whom this was not the case. Admittedly, it's usually because they have some wierd spec and a low gear level that allows Rupture to catch up... but the fact is, it happens. And I can see it happening in more normal spec situations (such as with TSH builds). So it would be good to understand when, and why, this happens.

2) The changeover from Xs5r cycles to 5s5r cycles at high gear levels. We know that it happens, based on the spreadsheets; and we have some vague idea of why it happens - it has to do with energy spent on SS versus energy spent on Rupture - but we don't really have the tools to describe it. As I've been asked on a number of occasions: how can it be that spending more energy on SS and less on Rupture can be a DPS upgrade, when Rupture is the more energy efficient move? And, of course, the answer isn't that hard once you think about it, but what we see here is that "Energy Efficiency" is an incomplete notion.

3) And if energy efficiency is a flawed notion, then we must reconsider some of our answers to other questions. For instance, it's generally cited that Eviserate is inferior to Rupture because it's energy efficiency is lower. But if energy efficiency doesn't tell the whole story (and it doesn't), might we need to reconsider this answer. In fact, as we'll see lower down - there *are* situations where Eviscerate catches up.

4) The rule of "always keep SnD" up experimentally seems to be a good one - but sometimes with cut cycles you end up refreshing it very early. So how much SnD uptime can you waste refreshing early before it's worth doing something else in the meantime and risk a short SnD gap?

It's these sorts of questions that I would like to understand better, and while I'm not going to come up with solutions to all of them in this post, I do have some ideas for how to approach them, so I figure I'll toss my ideas out there and see what people come up with.

So, before I begin, a little terminology. Most of this is standard, and the rest should be, so I'm going to establish it now once and for all so we don't have to argue about it later. So, for cycle terminology, I'm going to use the following letters to abbreviate cycles:

Abbrev.	Ability
s	Slice and Dice
r	Rupture
e	Eviscerate
n	Envenom
a	Expose Armor
k	Kidney Shot
t	Deadly Throw
f	Generic Finisher

Note that k and t won't ever come up in DPS cycles. "f" is going to be used when discussing families of cycles - for instance, the usual family of cycles we're used to are of the form Xs5f - that is, we have the expectation that we'll be doing a SnD and then some other finisher, but what that other finisher is we're not sure. In reality, we know it's usually rupture... but this way we can think about the possibility of Eviscerate or Envenom cycles as well.

So, where do we start? Well, where we always do - with DPS. Our goal is to figure out what finishers or combination of finishers yields the highest DPS. Thus, the reasonable basis of comparison is, well, no finishers at all. If we're not using finishers, what are we doing? Well, we're mashing our combo point generating move (CPG, for short - SS, Shiv, BS, or Hemo), and we're autoattacking.. So the real question is: how much *more* damage will be do by using a given pattern of finishers than we would by just mashing our CPG alone? Well, the autoattack damage is going to happen regardless, so it basically becomes a question of how efficiently we can convert our energy into damage - the energy efficiency, if you will (yes, SnD messes with this. We'll get to that). But the key realization is that you can't just spam finishers - they always are accompanied by some number of CPGs. So when looking at efficiency, you have to look at the energy efficiency of the finisher + associated CPGs relative to the energy efficiency of the CPG alone.

Thus, if our CPG costs energy and does damage, and our finisher costs energy, does damage, and requires combo points to execute, the damage effiency of CPG spam alone is simply

,

while the energy efficiency of our cycle with a finisher is

.

Thus, the number we actually care about - the energy efficiency gain due to the finisher, which I will denote , is given by



Now, while this is the more useful formula to use for F, it's hard to see what's going on. We can rearrange it to see a little more clearly what we have:



So, roughly speaking, it's the energy efficiency of the finisher, minus the energy efficiency of your CPG, times the proportion of energy that you're spending on the finisher. So why is this form less useful? Well, because with Relentless Strikes, is 0 for Rupture (and, with Combat Potency, potentially negative for SnD), so this formula is not actually defined everywhere. So, we'll use the first formula to actually evaluate stuff.

Note that while this quantity is certainly related to our conventional notion of energy efficiency, it's decidedly not the same thing. In particular, a finisher that does more damage but is less energy-efficient (in the traditional sense) due to costing more can actually have a higher F-value than a lower-damage, lower-cost, higher-energy finisher (which describes the Eviscerate/Rupture scenario for at least some of us).

Now, at this point, the temptation exists to just pick the finisher with the highest F-value and just use it... this provably gives the highest damage output. And it would even work, if all finishers did instant damage. Regretably they do not, and if fact the two common winners of the F-value competition, SnD and Rupture, both have durations. Thus, if you "spammed" the SnD cycle, you would lose a great deal of the damage that SnD does (as you'd effectively only have about 13 seconds of uptime per SnD). To get the full damage, you need to wait 30.45 seconds to do it again, during which time you're doing the spam CPG-cycle. The hard part, then, is figuring out what the most efficient way of building an actual cycle out of this is.

In order to investigate this, we need to define a new measure of cycles, which I will denote F'. As opposed to F, which measures the energy of the cycle in ideal conditions (full duration on the activated ability), F' will measure the amount of damage one does if one's cycle consists entirely of the one finisher. That is: for a buff with a duration, you generate the combo points necessary to sustain the cycle, and then perform the null cycle - spamming your CPG - until you can refresh. Note that this isn't actually how you would manage your combo points in this situation; but it provides a minimum baseline for damage that can be reached only using the one finisher.

So, what does F' actually look like? Well, if your energy regen is given by R, and the finisher has length L, then the total amount of energy regenerated is LR, some of which is at the higher efficiency of the cycle, and the rest of which is at efficiency 0. Symbolically:



which we could, of course, rearrange into something more expository if we really wanted to, but I don't really feel the need - we have a pretty good idea what this means. Note that if the finisher has no duration, we instead define F'=F.

So, by looking at F', we can find what the most damage-efficient one-finisher cycle is. And *that* tells us that the optimal cycle - whatever it is - must contain some move with F-value higher than the maximal F' value.

Now, at this point, I'm not quite sure how to procede. I don't have a good feeling for how, based on this candidate list of abilities, one actually builds out a general cycle; the obvious approach is to simply find the most damaging finisher(s) you can do with the slack energy for each of the candidate high-F finishers; the problem being that while this can find cycles of the form XsYf, it's not going to find things like 5s5r3s, which could theoretically be optimal. So some additional thought needs to be put into how you build a general cycle from these pieces. I have some thoughts about dealing with special cases (such as the Combat Swords case, where the F-value of SnD is ridiculously larger than the F-value of anything else) which I will post once I have a chance to write them up, but I'd like to figure out a more general approach as well.

The astute observer will additionally note that some of the constants in these formulas themselves depend on what cycle is being done; for instance the exact finisher pattern can effect the uptime of Mongoose, which in turn effects the number of Combat Potency procs and thus the energy regen. However, it's not hard to show that this particular effect is relatively minor, so I'm not too worried about it.

It also might be noted that this approach doesn't really work for Mutilate, and has additional mess for Seal Fate. But as other people are working on those sorts of problems, I'm going to let them be beyond the scope of this discussion.

 

Left

Actually, for a basic case I think it shouldn't be too hard to incorporate seal fate. All you would really need to do is divide "k" by the average number of combo points gained per instant attack (ie, don't assume 1:1 CP:CPG). In the case of Mutilate, the chance of getting 2 CP is (1-crit)^2, while the chance of getting 3 CP is (1-(1-crit)^2). Thus, your average CP for Mutilate is:

2*(1-crit)^2 + 3*(1-(1-crit)^2)

Divide "k" by that mess and you have a new constant for use with Mutilate.

The complicated bit, though, comes at the edges of the cycle. If you have 4 CP already, Mutilate can only give you one more, even though it has the average potential for granting 2.75 or whatever.

The other complicated bit is at the other end: Relentless Strikes. And the amount of CP you get from Relentless depends on what the previous move in your finisher cycle was, making it harder to evaluate the single finisher cases.

EDIT: Disregard the above; I wasn't thinking. Ruthlessness is the CP, and it isn't variable. You're right.

 

• Aldriana

It is, of course, the edge cases that make it hard. I suspect the full solution works as follows: for SF cycles, instead of computing the energy efficiency of a K point finisher, you compute the energy efficiency of a K+ point finisher; then, you simply work out all possible cases and weight them by the probabilities. That is: a 1+ point finisher can be any of the following things:

Ruthlessness proc, 1 pt finisher
4/5 T5 proc, 1 pt finisher
Ruthlessness and 4/5 T5 proc, 2 pt finisher
1 Mutilate (no crit), 2 pt finisher
1 Mutilate (crit), 3 pt finisher

It's straightforward to calculate the probability of each of those occurences, and thereby evaluate the expected damage and expected energy cost done by a 1+ point finisher. This will work fine for instant finishers, though it'll be a bit awkward in terms of finishers with durations, as these finishers have variable durations (and hence cooldowns) on them. It's not also entirely clear to me how Find Weakness and Ashtongue Talisman of Lethality fit into this discussion.

Now, admittedly, the resulting math is sort of messy, but that's not really too big a concern; there's a surprising amount of mess even in the above equations, carefully concealed by the fact that we're using very abstract, generic variables. If you actually try to evaluate any of the above, you'll find that most of the variables I used have extremely messy, nasty, formulas to go with them. These are decidedly the sorts of things one evaluates with a spreadsheet. And, ultimately, if we can figure out a general-case way of building optimal cycles out of their component pieces, that would want to get implemented in one or both of the existing spreadsheets.

I guess I'm not entirely clear what you're saying with the last line of your comment; Relentless Strikes doesn't add CP at all, only energy, which I would just subtract out of the cost of the finisher. Ruthlessness is the talent that adds CPs, but does not depend on the finisher used - it always gives the same number, hence is just a static reduction of k (as in, k=4.4 for a 5-point cycle). So neither of these talents seems particularly hard to model.

 

Left

Um, right... not sure what I was thinking above. I edited my post.

 

• Aldriana

I believe I have come up with a solution to another random problem that has been bugging me lately, and although it's one of those almost-totally-irrelevant details, I figure if it was bugging me, it might have been bugging other people, so it's probably worth posting my results - particularly since some additional data points would be useful in confirming whether this theory is correct.

So, the question is: how do Vitality and Blessing of Kings stack? I'd always sort of assumed they did so in some reasonably sensible way and thus didn't worry about the details, but I'd started to notice some oddities that weren't easily explained, so I figured I'd dig a little deeper and see if I could make sense of it.

So, first things first: it's been long established that Vitality applies to your base stats and gear agility separately, and rounds each down before adding them together. That is: in my usual gear, I have 163 agility from being a Night Elf, and 498 agility from gear. Hence, with vitality I have 163 * 1.02 = 166.26 (rounds down to 166) agility from my base stats and 498 * 1.02 = 507.96 (rounds down to 507) agility from gear, so my total agility on the character screen is 166 + 507 = 673, as opposed to the (163 + 498) * 1.02 = 661 * 1.02 = 674.22 = 674 agility you might expect.

One additionally notes that Kings does not apply in this fashion. For instance, my racial base spirit is 58, and I usually have 14 from gear; with the 18 from GotW and 20 from food that I usually have in a raid environment, this works out to be 58 + 52 = 110 total spirit; and since Kings bumps me up to 121, it can't be performing the same split that Vitality does.

Thus, the question becomes: how do these interact? Well, I'll get to the details of that in a moment, but, before I do, we need to stop and talk about Imp GotW for a moment.

GotW by default gives 14 to all stats; the Improved GotW talent gives 35% more. 14 * 1.35 = 18.9, so it gives 18.9 all stats. In practice, it is usually assumed that this just gives 18, not 18.9, but in most cases the distinction doesn't actually matter - with no percentage benefits, and even with only kings, the difference between 18 and 18.9 will never be distinguishable. But, with Vitality, it is. With 163 base agility, 498 gear agility, Imp GotW, and Vitality, we should be able to just use the formula above (as there's no kings). So 163 becomes 166 as usual; and depending on whether GotW is 18 or 18.9, we have either 516 * 1.02 = 526.32 = 526 or 516.8 * 1.02 = 527.238 = 527 agility from gear and buffs; hence, total agility will be either 692 or 693. As it turns out, the character screen reports 692, so GotW only gives 18 agi, as expected.

Given that: back to Vitality/Kings stacking. The first thing to do, it would seem, is to determine whether things stack additively or multiplicatively. Fortunately, this is easy to figure out; with GotW and a Elixir of Major Agility on (53 buff agility) and neither Vitality nor Kings, I would have 163 + 498 + 53 = 714 agility; if BoK and Vitality then stacked additively, even if no intermediate rounding occurred at all, the most agility I could have on the character screen is 714 * 1.12 = 799.68, and in reality the character sheet reports 801. So things definitely stack multiplicatively.

But, lets take another quick look at that example; with no intermediate rounding and straight multiplication, we wind up with 714 * 1.02 * 1.1 = 801.108 total agility; hence, given that Blizzard always seems to round down on stats, we can only lose .108 total agility due to rounding.

Well, one might naturally ask, at this point, whether they simply perform all the multiplications and round at the end, given the way that example worked out. Well, first, this seems slightly unpalatable to me given that it means that Vitality is calculated differently depending on whether or not you have Kings. And secondly, it doesn't work anyway; with only Kings on (base agility 163 + 498 = 661), this would imply that I should have 661 * 1.02 * 1.1 = 741.642 = 741 agility; but the character sheet only reports 740. So in this case, the total rounding needs to cost us a full 1.642 agility.

So, we know there's an intermediate round occurring based on the second example; but we also know that it can't be costing us very much in all cases, based on the first example. In particular, if one assumes the usual vitality operation wherein you apply it separately to your base agility, *it cannot be rounded down*. 163 * 1.02 = 166.26, and if you drop that .26 you've *already* lost too much agility to make it to 801 with kings (as we only have .108 to lose).

Hence, based on this data, the only thing that seems to make any sense at all is this: Vitality applies separately to base racial agility and to agility from other sources; the gear + buff agility is rounded down to the nearest whole number, but the base racial agility is *not*. Then Kings applies as usual - to the whole value - and then the whole thing is rounded down at the end.

So, with no agility buffs, we have: (163 + 498) * 1.02 = 166.26 + 507.96; the 507.96 is rounded down to 507, and so the total agility is 507 + 166.26 = 673.26. If we don't have Kings, we just stop here and round down, getting 673 agility as usual; if we do have Kings, we then take 673.26 * 1.1 = 740.586, which then rounds down to 740, as observed. Meanwhile, with 53 bonus agility, we have (163 + 551) * 1.02 = 166.26 + 562.02; the 562.02 is rounded down to 562, so we have 166.26 + 562 = 728.26 * 1.1 = 801.086, which then rounds down to 801, which also matches observations.

This computation matches my observation for both stamina and agility for every data point I've taken so far; however, as that's only about half a dozen different agility values, I can't swear that there's not another explanation (though no other explanation I can think of matches all the observed data). So, if anyone comes up with a base agility + gear/buff agility + kings/vitality combination where this doesn't work, please let me know; otherwise, I feel pretty comfortable saying this is probably how it works.

 

• Aldriana

The recent discussion in the various other rogue threads about shivving to maintain a poison stack got me thinking, and I had an idea for how to approach the problem to get a possibly-more-useful estimate as to whether it's worthwhile or not.

For purposes of this discussion, I'm going to use the default stats and buffs in the 0.10.3 version of the Rogue Gear Sheet, which, conveniently, are *my* stats and gear. But there's nothing in this calculation that's specific to the exact gear setup; the analagous calculation can be performed for anyone.

So, question the first: how much damage from Deadly Poison am I currently getting? Well, cracking open the sheet (Xs5r.B375 for those of you following along at home), I'm doing a base of 74.92 poison DPS before Misery. Question the second: how much poison damage would I do if the stack never dropped? Well, a 5 stack is base 75 DPS, times 1.16 for poison talents, of which about 6% is lost to resists; so the theoretical maximum is 75 * 1.16 * .94 = 81.78 DPS; computing the difference and passing it through Misery, we find that I'd gain a grand total of 7.21 DPS by keeping my DP stack up all the time.

Observation the first: shivving to save the stack is going to gain me at most 7 DPS. So if this is going to be worth it at all, it's not going to be by very much.

Regardless: we then compute the energy efficiency of Shiv as opposed to SS; for me, we find that Shiv has an efficiency of 26.55 damage per energy, whereas SS has an efficiency of 38.65 damage per energy. Thus, in order to be able to spend 31 energy (expected) on a Shiv, we need to gain 31*(38.65-26.55)=374.98 damage from poison in order for this to have been a worthwhile tradeoff, meaning that it can be worthwhile only if we have to Shiv at most once every 374.98/7.21 = 52.03 seconds. Note that in reality if we are exactly at this crossover point, Shiv will have a slight advantage due to the slightly faster combo point generation; for purposes of this estimate, we will neglect this fact.

Thus, the question becomes: how often do we actually need to shiv to keep things up? Well, a little estimation indicates that on average our stack will be dropping something like once every 136.4 seconds. As this is larger than the spacing required for Shiv to break even, this means that if that we shiv absolutely perfectly - that is, we shiv every time the stack would have fallen off, and never if it wasn't going to - we can theoretically gain some small amount of DPS increase (up to a maximum of 7 DPS, with the expected value being more like 4).

Note, however, that in practice perfect shivving is impossible, and unless I quite miss my guess you'd end up shivving significantly more than that - say once every 75 seconds instead of once every 135 seconds. As such, your advantage would drop to about 2.5 DPS, or about 900 damage over the course of a Brutallus fight. Which is about the same amount of damage you lose by letting SnD drop for 2 seconds or letting your energy cap out for a tick. Hence, unless you can do perfect stack-saving without messing anything else up - ever - it's not worth trying. And if you can do perfect stack-saving without messing anything else up... well, you're a better rogue than I.

That said: it might be worth running the analagous calculation at some other gear levels to see if it might be worth it at lower gear levels. Though I suspect the answer will be the same.

 

Safiyania

There's something that has been nagging me about this formulation for energy efficiency that I couldn't quite put my finger on for some time until it came to me. 3/3 Ruthlessness factors into the larger picture of a cycle as it gives a 60% chance to "refund" you 1 CP after using the finisher meaning that your next finisher really only required k-1 CPGs to reach the desired number of CPs. In other words there is a fixed percentage chance that each finisher will feed energy forward into the next iteration of the cycle.

So in fact, on each finisher used there is an additional future energy usage reduction term of a magnitude expressed by: 0.6*(D_c/E_c)
More generally this would be 0.2*i*(D_c/E_c), where i is the number of talent points spent on Ruthlessness although why on earth anyone would spec 1 or 2 of 3 instead of 3/3 is somewhat beyond me.

Now, this is in essence a constant for any given cycle given a particular CPG and thus in any sort of comparative sense should likely have no impact on any direct comparison of finishers in a combat build for most T6 rogues but in a seal fate build this effectively means that a finisher may in fact require only a single CPG to generate k combo points (if 3<=k<=4) or in the case of a 2-pc T4 Combat rogue who may require 0 CPGs to get that SnD refreshed in a 1s5r cycle.

 

• Aldriana

Yes, I slightly misdefined k in the above derivation. Really k should the number of CPGs required to generate sufficient combo points for the finisher in question; without Ruthlessness, for most CPGs, this definition is equivalent; but with Ruthlessness, it basically means k will be up to .6 less than the size of the finisher being done - that is, a 5 point finisher with 3/3 Ruthlessness should be scored with k=4.4. With Mutilate cycles on needs compute based on crit rate the expected number of Mutilates required to get the desired number of combo points - for a 5 point finisher, k is probably under 2 for a Mutilate rogue. That's actually how I intended to define it in the first place, but I guess I erred when I was writing stuff up.

The only caveat is whether it's safe to push the average through in this fashion - that is, it doesn't actually take 4.4 CPG, it takes 4 60% of the time and 5 the rest - is it safe to model this as just needing 4.4? My intuition is that the answer is yes, it is - but I'd have to think about it for a while to prove it.

 

Left

It strikes me that this is more true the closer together your CPG's occur. IE, if you are a well geared CSwords rogue, your Sinister Strikes are hitting around every 3.1 seconds or so. At 40 energy and 3.1 seconds, it is fairly easy to pool enough energy during your cycles to easily average out the 4 and 5 CPG cycles so that SnD never drops. Thus, for CSwords, it probably is a good approximation.

This is significantly different, however, from a Mutilate rogue's 6.0 seconds between Mutilates. 60 energy is significantly more energy to pool, making it harder to cover for bad cycles. Fortunately, right now Mutilate rogues are swimming in SnD uptime due to a SnD/Rupture cycle being the best general cycle to run. I, for example, usually cut my SnD by 5 or 6 seconds each cycle. Nevertheless, there is a significant shortcoming in averaging Mutilate cycles because in the worst-case cycles there just isn't enough energy pooling to cover for the bad apples when they come up.

Consider, at 35% base raid crit, a Mutilate rogue has a 50% crit chance on Mutilate. Let's say this rogue is trying to get to 5 CP (as in, for example, a 3-5s/5-5r cycle). The chances of getting to 5 CP with 1 Mutilate are zero (not counting 4pT4 set bonus). The chances of getting there with 3 are very low: (0.4)*(0.5)*(0.5)*(0.5)*(0.5) = 0.025 = 2.5%. Thus, the chances of getting there in 2 Mutilates are 97.5%. So, what we would normally do (and what I did in the DPS Spreadsheet) is to them say that the expected number of Mutilates is 0.975*2 + 0.025*3 = 2.025. All this results in is our average cycle lengthening very slightly, so the only real difference in the estimate is a bit lower Rupture uptime and a closer SnD cut. Even FW is still estimated as 100% uptime, since the total cycle length still comes in under 20 seconds and there are 2 finishers involved.

But what really happens when we have to go to 3 Mutilates? Well, two important things:
1] We spend an extra 60 energy. If we are operating from a 3-5s/5-5r cycle, that means we go from using ~190 energy to using ~250 energy. Since a 3 pt. SnD will cover only 21.75 seconds, there is a very real chance that SnD is going to drop before we get through the entire cycle (if a 3 pt. SnD was used).
2] The 3rd Mutilate will not benefit from Find Weakness at all, which isn't covered under our model. (Or Ashtongue Talisman either, if we're using that.)

This is compounded by the fact that SnD times for a Mutilate build are variable, based on the CP probability that you have after you perform X number of Mutilates. A low SnD time coupled with bad luck on crits is bad news. Thus, for Mutilate, the loss from a bad cycle is disproportionate to the percentage chance that that cycle will occur. Right now, it's not huge, because we can mostly just eat up the absurd amounts of SnD slack time we have. With WotLK, there is an excellent possibility that we will go to a 3 finisher cycle or spend a lot of energy on Hunger for Blood (or both), and those SnD slack times will get a lot closer.

My problem is that I can describe the situation that will occur, but I can't figure out a good way to fix the estimate. The best thing I can think of is to describe Mutilate in terms of how many are used (1Ms/2Mr, for example) instead of the combo points reached, but even that isn't really ideal. (Although, it is what we do in practice, since we know that a third Mutilate to reach 5 CP is bad news.)

Maybe this helps make the case for why an approach is needed that can separately address different probability paths. It's the biggest shortcoming in the current Mutilate spreadsheet work that I can think of.

 

• Aldriana

It is my intention in RogueCalc to do some level of tracking of the independent probability paths - I'm not sure whether I'm going to go down to the level of plotting out every single little case, but I'm certainly planning to go into more detail than either spreadsheet has. The challenge is that to do the damage calculation correctly, one must either derive from scratch what the optimal cycle is (which is to some extent what we're trying to do here), or be able to compute the DPS of an arbitrary cycle, whereupon you can just try a bunch of different things and/or apply a genetic algorithm in order to figure out what the actual best cycle is.

I'm of the opinion that the first of these, at least for now, remains impractical; hence, what I'm trying to do in the RogueCalc thread is to pin down the rules used to define and perform Mutilate cycles, such that we can take the second approach of simply trying a bunch of different cycles to get a top DPS estimate.

From your description here, it sounds the like what we really want to do is specify Mutilate finisher size using not one number but two - that is, instead of saying we're going to use a 4+ CP finisher, or a 2-Mutilate finisher, we want to use a <5,2>-finisher - that is, launch the finisher once we've achieved either 5 combo points or 2 Mutilates; usually this will be equivalent to a 2-point finisher, but as it is possible to achieve 5 CP in 1 Mutilate with 4/5 T4, you may sometimes only do 1.

So let's look at the usual finisher size options we have under this notation. It seems to me that the usual building blocks of cycles will be finishers of the following sizes:

<5,2>
<4,2> (which is equivalent to the usual 4+ pt finisher)
<3,2> (which is equivalent to the usual 3+ pt finisher)
<3,1> (which is equivalent to a 1-Mutilate finisher)
<2,1> (which is equivalent to the usual 2+ pt finisher)
<1,1> (which is equivalent to the usual 1+ pt finisher)

I don't see that there's a lot of meaning in anything else - for instance, a <2,2> finisher is exactly the same thing as a <2,1> finisher, as you can never need more than 1 Mutilate to get to 2 CP; a <4,1> finisher is exactly the same thing as a <3,1> finisher, as both are incapable of meeting the CP requirement without also meeting the Mutilates requirement.

Since most of these are equivalent to finishers with a more elegant notation; in fact, I would argue that the <5,2> finisher can reasonably just be called a 2-Mutilate finisher, with the understanding be that you can abort after 1 in the rare case that that already has you at 5 CP. Hence, rather than needing to carry around all these extra numbers in cycle representations, one simply needs to introduce notation for a n-CPG finisher in addition to the usual k-CP finisher. I suggest using n# for this purpose; hence, the currently preferred cycle would be denoted something like 2s2#r - that is, a 2+ CP SnD followed by 2 Mutilates and a Rupture. The notation for n-CPG finishers does seem a bit clunky, but I don't have any better ideas for how to denote it.

 

Left

Seems reasonable. The only catch would be if we somehow identify a crazy non-Mutilate Seal Fate build that somehow did decent DPS. Right now, we know of no such builds, but in the future maybe one will come up. In such a case, we need a way to handle <N,M> cycles (where N is combo points and M is CPG's) for a 1-CP CPG, like Hemo or Sinister Strike. Then it might get more complex. Because then you might have to identify refresh cases where you either reach 5 CP (or something less), or you run out of slice time (and are therefore limited to a certain number of CPG's by enegy generation).

 

Dorvan

Actually, a Seal Fate/Combat Fists build doesn't seem too far-fetched given the currently lack luster state of deep combat, so your concern may be valid after all.

 

• Aldriana

Combat is lackluster, but I don't think it's quite lackluster enough to justify SF/Fists. The actual damage contribution of SF is not as large as one might like, though the situation may improve somewhat with the increased damage done by finishers that has been observed to date.

That said, general answers to this sort of question is of course the point of the discussion, so it seems to me that we probably do want a way of handling them. That said, I suspect that combo point generation in nonMutilate builds will be sufficiently granular that the usual k+ CP finisher model will suffice to at least get us in the right ballpark.

Actually, it seems like the more general approach would be to just define cycles normally, and then include an option for whether to abort to keep SnD up - that is, have a cycle consisting of "SnD, followed by as much of this other stuff as you can squeeze in before the SnD drops". So you could define your base cycle to be, say, 4s4r4e, and if you run out of energy before getting to the evis, you just skip it and do the SnD. Or 2s5r, with the rupture being cut back to 4 if you don't have time for it. And so on.

Point being, what's necessary to make the RogueCalc model of this stuff fly is a general description of the rules that define SF cycles, such that we can try a bunch of different option and figure out what's going to be best. One better would be the ability to outright derive the optimal cycles, but as that seems impractical, I'd be content with a method - no matter how messy or computationally intensive - for defining and evaluating SF cycles. If anyone has any ideas, let me know.

 

◊ Shaker

One thing to keep in mind is that, in my opinion, you're still operating with the assumption that keeping SnD up is the primary goal during all of these cycles. With other finishers getting more powerful and SnD not changing in power, we need to stay aware of the line where SnD downtime becomes acceptable. Of course, I think we can say with confidence that any cycle of the form XsYf, where f is a non-SnD finisher, that the cycle goes to Xs5f. Also, in a weird world where non-SnD finishers were highly buffed, it's possible that X goes to 0. (If eviscerate were strongly buffed, 5e could be the optimal cycle - this is unlikely, I design-wise we will still almost always be talking about XsYf finishers with X>0).

Consistency. It's only a virtue if you're not a screwup.

 

Dorvan

SnD is getting more powerful though. With new and better gear our white damage will be going up in absolute terms, and as such the DPS contribution of SnD will continue to scale. Exactly where it will fall is an open question, but I think it's a reasonably safe assumption for the time being that is will remain the highest DPS finisher, due to it's drawbacks (generally unimportant for PvE) that it provides no burst and relies on continual melee contact with the target.

 

• Aldriana

Well, that's why I phrased the "do stuff until SnD drops" idea as an option, not the only way of doing things. It certainly seems like a useful family of cycles given the current balance, but is it the only family we should be considering? No - it's just an option. My plan was to (perhaps) model this family, as well as all the more conventional cycle families, and thus figure out on a case by case basis which works out to be best.

Again: the challenge is coming up a list of all reasonable options that can be considered, and representing them in an elegant fashion. Once that's done, evaluating all of them to figure out what's best should be straightforward.

 

Yavn

Hello, I've been recently working on a DPS simulator which is primarily aimed at nailing best attack cycles for Combat Mutilate. Right now I'm finishing code concerning white hits, procs/buffs and poisons, then I'll move to things that actually let you spend some energy I've taken an approach that tries to simulate the game and produces combat log and data similar to that you can get with Recount in WoW, as opposed to statistical approach used in spreadsheets.

I have some questions concerning the following mechanics:

Haste. What happens if haste effect applies during swing timer? Let's say we have a weapon attacking at 2.6 speed currently and 1 second has passed, so next swing should occur in 1.6 seconds. Now SnD kicks in, and hasted weapon speed is 2.6/1.3 = 2.0. When the attack will hit now? In 1.6 s (unaffected by haste) or in 1 s?

DoTs. What happens if DoT is refreshed between ticks? Let's say we have one stack of DP on target and 2s has passed since last tick. Next tick should occur in 1 second. Now the poison is applied and we get 2 stacks and poison time is 12 seconds again. When next tick will happen? After 1 second or after 3 (application resets tick timer). Second thing, is stack number affecting this (e.g. below 5 stacks ticks get resetted, but at 5 stacks they aren't?)

Mongoose. I've heard that Mongoose should approximately proc once a minute regardless of weapon speed and has no cooldown of any sort (i.e. it can chainproc on two consecutive white hits if lucky). Therefore I'm assuming that proc chance should be weapon_base_speed / 60 for auto attack. Specials or haste effects will increase number of procs.

As you see, these things might have a quite significant impact on final DPS. Getting Deadly Poison right is particularly important for me, as the difference between resetting tick timer or not is major, especially if proc chance is high due to haste, hit and poison talents.

I see that testing poisons shouldn't be that difficult as we have Shiv at our disposal, but I'm asking in case someone have already verified this. Thanks in advance


EDIT: Thanks for reply, Vulajin. I'll take a look at that log and try to find an answer. How you have obtained such combat log, btw? Is that some sort of add-on that can dump this to a file?

 

• Vulajin

It's funny that you should raise this question, because I have a combat log that I took some weeks ago when posed the same question by a friend. I haven't been able to do a solid analysis of it, but an initial scan seemed to imply that a haste effect gained or lost could affect the speed of an ongoing swing. For example:

Based on the timestamps, you can see that the two swings during which the Slice buff was gained and lost took 1.100 and 1.266 seconds respectively, while the fully Slice-hasted swing took only 0.934 seconds, and the fully unhasted swing took 1.267 seconds. Obviously some sort of mid-swing hasting effect occurs; I simply haven't been able to nail down precisely what to date.

I've attached the log here, the only delay in actually analyzing it is that I need to write some sort of tool to convert the log into a form that can be used in Excel to do some graphic. If someone happens to have such a thing or feel like analyzing it by hand, feel free.

Attached Files

MidswingHasting.txt (398.4 KB, 36 views)

 

Yavn

Hmm this is nice combat log indeed. Format was confusing for me at first, but now it all falls into place.

As far as importing this into Excel goes - it's a fairly simple task! Grab some text editor (I've used Programmer's Notepad) and Find&Replace whitespaces with commas. Then you just import this to Excel as CSV file, breaking into cells where commas are. Then you only need to tweak some date/time formatting and you're set. Hope that helps!

 

• Vulajin

Importing into Excel isn't the issue. The issue is going from the raw combat log input to some sort of data format that actually can be meaningfully analyzed. Given the raw combat log as input, I can't exactly make Excel graph the relationship of time left on a given swing before gaining Slice and Dice versus time to complete that swing after gaining Slice and Dice.

 

Yavn

I have filtered the log a bit and calculated time between swings. Unfortunately I can't seem to find option to attach the file, so I'll have to paste it here. It contains tabs so it should look ok when pasted back to Excel.

Looking at these times I noticed that values fluctuate quite a bit, which I guess is attributable to lag. In column "SnD" I've put number to indicate if SnD was active (1) or not (0). It's difficult to notice a pattern that wouldn't lie inside the error margin caused by lag. The swings that interest us happen when SnD changes from 1 to 0 or 0 to 1. These are moments when haste was applied or removed during the swing timer.

Averaged weapon speed during SnD is 1.026 and 1.271 without it, so I assume you were using some 1.3 speed weapon. However, one can get interesting averages in following cases of white hits:

1. Last hit before SnD - 1.298
2. First hit with SnD - 1.103
3. First hit without SnD - 1.191

This looks bit less clear to me... The differences might be too small compared to measurement error, but assuming this is right, we get: 1. isn't affected because swing started and ended before SnD (ok); 2. got hasted by 17.9% and 3. by only 9.2%. So you're right that this is a bit difficult to interpret. It's either latency or the swing is somehow affected by the moment in which haste effect was applied. Unfortunately the differences in values are a bit too small to already jump to conclusions.

I guess the only way to clarify this is to get a much larger combat log, so the lag will have smaller impact on data (the part I've analysed so far was fairly short).

EDIT: I'd also love to hear some feedback on DoTs and how ticks work. So if anyone knows something, don't hesitate to tell me.