The Xs/Ye cycle only uses 1 evis before snd renewal, so if you use a 5 CP SnD for a slice time of 31 sec and a 5 CP evis you have a a CP builder time of ~17 sec and this time is set to the actual cycle time. So 14 seconds of snd uptime are wasted. So using imp. SnD makes no difference for the Xs/Ye cycle as the cycle time is still 17 sec.

Can someone explain me why I have a sudden increase of Expertise with my gear? I have entered exactly the same options and gear into the new sheet, but I see a difference of 1,25%, which is 5 expertise. I read back a few pages, but I can't find an explanation.

I find it hard to explain so I just uploaded the two sheets so someone can have a look at it:

Old Sheet
New Sheet

It appears that the expertise from Dwarf Racial wasn't added to the G9 cell (On Gear and Talents sheet) in roguecraft1.xls. The calculations are the same though, so apparently just a tooltip fix.

It is my thought that cycle-based spreadsheets use averages. So in your example would mean that you get 22.5 combos out of a complete cycle. This leads you to change your cycle in order to have a rotation that on average will not get SnD to drop. Cycle-based spreadsheets are deterministic in nature, there is no luck involved in the DPS calculations and you cannot say the odds of falling within a certain range of DPS values is X%. The DPS distribution is unknown.

On the other hand, stochastic modeling (simulations) do give you a better insight of your DPS distribution which permits you to calculate various values such as average, standard deviations and condition-tail-expectations which could prove useful in pointing out the setups that would not only provide the highest average but also a smaller standard deviations for consistent DPS.

The logic you have is somewhat sound but I think the error is in the way you are analyzing the variables. Instead of viewing it as an average of the total number of CPs generated per SS cast it needs to be dealt with individually and every SS compared to the % of crit likelihood at each occurrence. The goal of course would be to continue until the total 5 CPs is generated (assuming in this case at least that SND uptime is not a priority). Therefore the cycle time is estimated by the outcome of each cast individually instead of a variable based on the average outcome of the each SS in the entire cycle itself. Now if SND uptime is brought into the scenario then instead of a CP count of 5 being the trigger for the next event the the termination of the cycle would be tied to the time of the prior SND termination which of course would be tied to the results of the prior CP build up. By doing it this way the randomness of the simulation is built in from the very beginning instead of being tied to the end of the cycle.

To be certain, I am not talking about a simulation. I have created a simulation spreadsheet of rogue dps for these forums, so I know exactly how a simulation operates. My question is about average-cycle spreadsheet, such as the one currently being updated by Vef.

I am using the most recent version of Vef's Mutilate spreadsheet. It is telling me that using Instant Poison on both weapons will increase my dps by 800-900 points. It also says using Envenom for my finisher instead of Eviscerate yields an even larger increase. Which is interesting since you can't envenom without Deadly Poison.

Is this an error or is double IP really that much better?

So, I can't comment specifically on how Vulajin's sheet handled it, of if Vef has addressed it further since; however, as someone with a bit of experience with spreadsheet writing, I'd like to make a few comments on the issue. Honestly, this is a topic of active "research" (for lack of a better term) - improving the cycle model is a major point I've been working on lately. I won't go into all the details of how that works here, as it's probably more appropriate for a new thread, and I'm not quite ready to start one yet.

So, when dealing with spreadsheet cycle modeling, most of the calculation sheets here were originally devised during TBC, where the only sources of variance were Ruthless and Combat Potency procs; now, these are sufficient to cause several seconds variation in cycle length, but are small enough that they could be absorbed by energy pooling. That's a key point to note: Energy pooling can absorb some variance. In fact, given an arbitrarily large energy bar to pool within, one could absorb arbitrarily large amounts of cycle variance - with a 1000-point energy bar, we would likely have little trouble maintaining a rigid cycle even with Glyph of SS. Thus, the original assumption was that you could define a rigid cycle (i.e. 3s5r) and assume that people would pool to maintain this. Also note that some slack was often built into cycles to account for reaction time and some variance as well.

Now, for the first couple versions of my spreadsheet, at least, this was largely the assumption despite the fact that it's patently not true, because honestly it's not a bad assumption anyway. Modeling was done off a 4s5r5e cycle (or whatever) under the assumption that you could pool so as not to overlap ruptures, not to drop SnD, and still get those attacks off with the correct timing. And while this is clearly not possible in practice, it's not actually a terrible estimate of the reality of the situation - the important thing while modeling is not the exact cycle, but the relative attack counts of each move type. So the handwave is that while the 4s5r5e cycle might not be 100% accurate, the relative numbers of slice and dices, ruptures, and eviscerates is about right, such the that the modeling is decent even if the cycle is a bit unrealistic.

However, this is also the reason why of late I've been spending a lot of time thinking about cycles, and why the 1.3 beta of my sheet has a vastly expanded calculations page to try to address this issue. The newest version of the Combat sheet has dispensed with the notion of cycles in favor of attack priorities and working out the number of each move that result. The Mutilate sheet has done this for a while as well. And this is clearly the correct approach, it's just not always easy to do, which is why it's taken some time.

As for the details of how one actually does this - well, that's new-thread territory. And I do intend to raise the issue at some point, there's just some remaining work I want to do first.

Thanks Aldriana.
I understand your points regarding energy pooling even though I can't judge about how realistic it is to assume energy pooling can consume all combat-spec rng. Especially going into mutilate, the variance of random processes there is even higher due to Seal Fate, so it's hard to imagine energy pooling can completely consume it. Besides energy pooling has problems of its own with mutilate. For instance, timing envenoms with DP ticks and trying to pool energy to even 60 often leads to energy capping or disruption of envenom-timing, both of which hurt one's dps. So I would not advise to pool energy while doing envenom-based mutilate and rather focus on timing envenoms to DP ticks.

I am curious about your approach with attack priorities instead of cycles. The artificiality of cycles was one of the big reasons why I took on the simulation approach to estimating dps. Analytical modeling of dps based on attack priorities, if I understand it right, brings it much closer to simulation approach in terms of realism of dps modeling. Yet you don't run into problems with variance of your DPS estimates. So when you do venture into that new-thread territory, I am definitely going to take a look.

Pardon me if I misunderstand the ongoing discussion, since I've only been loosely following this thread of late. It seems that the question at hand is, how does the Roguecraft sheet handle the variance in CP generation and timing introduced by Glyph of Sinister Strike.

The answer goes back to Left's work on the Mutilate modeling in the original Rogue DPS Spreadsheet back in BC. He devised a calculation table which took, as inputs, your desired number of CP (X) and your various CP-generating procs/talents/whatever. Then, based on whether you were using Mutilate or SS/BS, it would calculate your likelihood of reaching X CP, or of overshooting it and hitting X+1 or X+2. It would also calculate the average number of combo moves performed to reach each amount. In his implementation, the averaging was done at this point to figure out how many combo moves you'd perform per cycle as well as how many CP you'd generate.

I deferred the average calculation a little longer. First I calculated the results of running a cycle consisting of each combination of possible outcomes, i.e. if you're running (X+)s/(Y+)r, then we'd want to simulate Xs/Yr, (X+1)s/Yr, (X+2)s/Yr, Xs/(Y+1)r, etc. The damage output, cycle length, and all the other quantities of these cycles are each computed separately, and then averaged together based on the likelihood of their occurrence. Unless Vef has greatly changed the sheet, you can see all this stuff at work on the Cycles calculation sheet.

Did you consider Lightning Reflexes?

I don't recall if Vulajin's sheet had the option or not, but if so: did you choose the correct race?

The trinket doesn't have flat AP, you gain the (stacking) AP bonus on use and with a 2 minute cd. So without being able to download and check the spreadsheet at the moment I still think he implemented it correctly and you are somehow mistaken as to how the trinket works.