• Latito

Roguecraft 101

specifically, near the bottom:
On Eviscerate: at nearly all reachable levels of gear, Rupture will be superior to Eviscerate on any target that isn't immune to bleeds. At 5 CP, Rupture deals 1000 damage plus 24% of your AP for 25 energy, or 40 damage plus 0.96% of your AP per energy. At 5 CP and with T5 2pc, Eviscerate deals 1245 damage plus 15% of your AP for 35 energy, or roughly 35.57 damage plus 0.43% of your AP per energy. Applying 3/3 Improved Eviscerate and 3/3 Aggression (121% modifier), 40% crit and RED (142.4% modifier), and 30% armor reduction (assuming a typical debuffed raid boss), Eviscerate comes to 42.90 damage plus 0.52% of your AP per energy. Thus, Eviscerate holds an advantage of 2.90 base damage per energy, but Rupture gains an additional 0.44% of your AP. At this rate, it takes only 656 AP for Rupture to overcome Eviscerate's base advantage. Simply, in any situation where you can Rupture, you should Rupture.

Note - that is the total damage done for a 5-pt rupture.. divide by 8 to get per-tick dmg. For smaller ruptures, consult WoWWiki.. I'm pretty sure it had the correct information last I checked.

 

Jakani

1pt = Attack Power * 0.04 + 324
2pt = Attack Power * 0.10 + 460
3pt = Attack Power * 0.18 + 618
4pt = Attack Power * 0.21 + 798
5pt = Attack Power * 0.24 + 1000

Information taken from Rupture - WoWWiki - Your guide to the World of Warcraft with about 30 seconds of effort.

 

• Rerox

Just noticed something strange: when I run the upgrade macro on my rings, i get several possible upgrades, ranging from 0.6 to 12+ dps. But even though the "Band of Devastation" is a significant dps-upgrade (more than 6.5 dps) it is never shown as possible upgrade in the comment.

I looked at the ring sheet but couldnt see any reason why this ring should cause problems.

 

Dontmindme

Well, 11.5 probably seemed right at the time as there was no way to pin down the subtraction or how the rounding actually worked, but, since Blizzard added the GetCritChance() command which returns a floating point, it can be determined.

To 6 digits,
209 Agility = 9.930000% (with 5% from Malice)
221 = 10.230000%
233 = 10.530000%
260 = 11.205000%
I'll let you do the math to verify that the answer is indeed (agility - 11.8)/40.

What I did was take CombatStatsFu, found the line with self.critChance = format("%.2f",GetCritChance()) and changed the 2f to 6f to give me 6 places after the decimal. It also became clear that Agility to crit rounds normally (up on 5's).

Now, there is some unusual "noise" past 6 digits, so it actually shows to 16 digits 9.9300003051757813. the extra fraction seems to be 5^4/2^11/10^6 for whatever that's worth. If I had to guess, this might have something to do what random number seeding.

 

Dontmindme

Yeah, I tried that just now, looked at the macro quickly. Something weird going on. I'll have to look at that again when I'm more awake. Everything looks fine but clearly isn't.

 

• Rerox

DMM: another thing I wanted to ask: how were the haste calculations changed in 2.3.2.6 and how "reliable" are the results?
Just wondering, because I noticed the dps-gain from several haste-items increased significantly since earlier versions of the sheet (e.g. Akil'zon's Talonblade or Band of Devastation).

/edit: seems also to be the case for armor penetration - Choker of Serrated Blades or even Dory's Embrace, going up in dps significantly.

 

todemax

@glowacks

i agree that an average of AR energy is a wrong model, and that it should be modelled something like (energy for a 5e cycle)*(5e cycle damage)/(150 energy) minus a correction due to you breaking your normal cycles (unless you have 5 seal fate, where the energy matches).

DP modelling: I remember it beeing implemented back in the days, and the one who did it claimed that it wasn't very accurate, so i guess it could use som love. It shouldn't be that hard to use some statistics to model it more accurately.

The effect of cooldown stacking is minimal in my opinion, as the cooldowns should be used not long after the cooldown is up. However the number of times an on use effect can be used in a bossfight will be important if a "length of fight" button is added at some time.

Some day the cycles will need to be of the form e.g 3.3s/4.2r or so. Although the way that the mutilate cycles is given would be a nice way to present the normal cycles as well.

 

Valen

In my opinion Spreadsheet shouldn't include BF/AR/Heroism/Haste potions etc. in the average values at all. The DPS of those should get calculated seperately and added as a flat value. It will not be very accurate for those, but I believe it will give more accurate results for gear choices and also optimal cycles that way. Passive haste for example is a stat that becomes stronger as you turn Heroism, BF and Haste potions off.


PS: I also would love to see more tests with DST. Averaging DST's haste out might overrate its' worth. In my opinion DST because of the short uptime per proc (10 sec) is a bit overrated compared to something like WSC with 15 sec uptime, because you can stack other things when you get a 15 sec uptime. Also, the value of activable AP trinkets, for example Zul'jin one, are probably underrated. You can be sure that they are *always* used with combination of haste potion and BF, and also once in every fight AR.

 

Left

One way to do this might be to separate static haste from activated/procced haste, and use the resulting values for different calculations. Sum of the static/passive haste and put it in a cell called "static haste", then compute the averaging effects of the activated/procced hastes and put them under a cell called "effective haste" (or whatever names could be chosen). The idea would be to use "static haste" to calculate uptime for things such as DP procs but use "effective haste" to calculate actual average white DPS.

In practice, haste effects tend to get stacked as much as possible (popping BF during a Dragonspine proc, for example), so the "static" value is actually in effect the majority of the time. Thus, while it will be a slight underestimate of poison uptime, it should be accurate most of the time. The increased poison uptime during a procced/activated haste will only be good until that haste effect ends, so it might not be worth the additional work required to do separate poison modeling during procced/activated haste effects.

Note that I would include "Heroism" and "Slice and Dice" in the "static haste" category, since when you turn them on you pretty much just assume them to be active 100% of the time.

I'd love to look at this myself, but I'm still getting the hang of how the whole sheet works and trying to understand all the connections. If I do any fiddling I'll try to post the results here.

 

todemax

I'm a big fan of using statistics instead of using averages, and I believe that on use effects shouldn't be modelled as effect*duration/cooldown but instead modelled such that the dps will be ((dps with effect)*duration/cooldown)-(dps without effect)*(1-duration/cooldown)) and if you're fancy about it, a statistical factor should be added to factor in the increased/decreased effect of overlapping effects if you assume that cooldowns are used instantly. (This way of doing it should have pretty much the same effect as you suggest Left.)

As of effects like bf, I think that it's ok to add an average energy/second from combat potency procs due to this and the energycost of bf itself, as the energy gained/used is a lot less than AR, and thus doesn't mess with your cycles as such.

Overall a lot of the ways the sheet is modelling things needs some minor adjustments, which as he himself stated is on dmm's to do list, as well as many others, so keep them comming

 

todemax

I have some questions about DP that i hope some of you can answer.

If you at T=0 sec proc DP such that the stacksize is 1, and at T=2 sec proc another, and at T=4 sec proc the third one, will you get one tick of a 2-stack in this 4 second window, or is the three second tick global, such that the tick may happen anywhere in this window?

 

Zurgat

I believe it is global, but i'll try to verify this for you when i get home.
Meanwhile you should be able to test this with shiv to ensure your target gets poisoned at the time you want it to.
If you go to blasted lands, and turn away from the mob at a 70-80 degree angle, you won't be able to hit it with autoattacks anymore, but you should be able to attack it with special attacks such as Shiv.

-= Random Ravings - RSS Feed =- Rogue and Hunter stuff here. As well as guides to get you trough your spare time.

 

Left

I believe it is timed from the application of the first stack, but I could be wrong. I wouldn't trust it without testing. It should be easy to test by using Shiv to apply DP, then immediately stopping your attack and checking for how long until the poison damage ticks.

EDIT: Eh, looks like the previous poster got in before me... incidentally he thinks it is global. Yeah, someone better test it. This macro might help:

---------

Also, I spent some time this morning looking into DP models (very slow day at work) between the two spreadsheets. I can't say I fully understand the modeling of either sheet, but I certainly don't know what is going on in the RogueDPS spreadsheet. It looks pretty complicated, but it seems to be computing an "average stacks" up at any point sort of thing (check cells O17 and Y41 on the Wep_Enchants sheet; I'm hypothesizing that Y41 is the "average stacks"). Having only an average of 3.8 stacks up seems pretty low to me, but since I'm not following the math to get there I can't call it one way or the other.

On the other hand, Aldriana's sheet calculates DP damage differently. As far as I can tell, Aldriana calculates the average number of DP procs per second, and then uses that to calculate the chance of DP dropping off (see cells B361 and B362 on the Xs5r sheet). Then, the sheet assumes a 3/5 damage loss for the %time that DP drops off (see cell B362). Again, this seems to me an odd way to calculate the damage loss... I think it is underestimating the damage lost when DP drops off by not accounting for build-up time.

In summary, I would venture that the RogueDPS spreadsheet underestimates DP damage while the Rogue_Gear spreadsheet overestimates it, although I can't verify the first assumption because I can't follow the math involved.

A better way?
A better way to calculate DP damage, in my opinion, would be to account for both (a) the chance of the stack falling off, and (b) the build-up time when it does fall off. For simplicity, it's possible to assume linear DPS instead of ticks. (Yes, that makes the calculation a bit less accurate, but should more or less average out.) The general calculation then looks like this:

DP_DPS = [DP_Dmg*5/12 - ((2.5*DP_Dmg/12)*(AvgRampUpTime/AvgTimeUntilDPFallsOff)] * Multipliers (ie, Vile Poisons, Murder)

AvgRampUpTime (average time to go from a 0 stack to a 5 stack of DP) is a direct function of the average number of DP procs per second:

AvgRampUpTime = 5 procs / (DP_Procs/sec)

(This, of course, assumes that you can build back to 5 procs without it falling off again. It's also assuming a pretty much linear ramp-up; hence the 2.5 in the above equation. I think this should be a reasonable assumption unless your hit is really low or you are using a super-slow offhand.) The average value during the linear ramp-up time is just the max value/2, or 5/2 = 2.5

AvgTimeUntilDPFallsOff (geez, what an ugly variable name) is a function of the probability in any given 12 second time period that we'll get a dry streak and the DP stack will fall off. This probability is roughly:

(1 - (DP_Procs/sec))^12

Now I'm stuck. I don't know how to transform that probability into an average time until DP falls off. Anyone know how to do that? If we start at T=0 and for any Tdiff = 12 there is a (1 - (DP Procs/sec))^12 chance that DP falls off, how do I get the average time until it falls off? Anyone know? (Note that T=0 to T=12 is one interval, but so is T=1 to T=13... the intervals overlap. That's what is getting me.)

 

todemax

i was thinking of a more complicated, but more precise treatment, but I don't really have time to look more closely at it for a few weeks. Considering global ticks, which makes the calculations a lot easier, since you can ignore the ticks in the calculations.

(1-(1-probability for application of DP per hit)^(attacks with dp over 12 seconds))

This should be the probability for the stack to fall off, and the uptime for 1,2,3,4 and 5 stacks should be easy enough to figure out since the uptime for 0,1,2,3 and 4 stacks should follow the same trend. (Haven't quite figured the finer details yet )

 

Eyegore

I can't say as I have the mathematical wherewithal to contribute to, or even really follow, much of what is going on here, but this deadly poison modeling discussion here seems to be approaching the ability to answer a question that has been nagging at me. Is it ever, and if so at what gear levels, worth it to shiv to save a deadly stack? I have seen it asked a few times on these boards, but have not seen a comprehensive answer that I recall.

The general consensus I have heard is that when you compare dps loss from not landing a SS instead vs poison dps loss it comes out to be pretty much a wash and thus not worth the time and attention to worry about. However, this is coming from the usual contributer here who is in much better gear than my rogue alt in kara gear. I assume at my rogues gear level the dps contribution from poisons becomes relatively more important, but I have not come up with any way to answer the question for myself as to whether this is a significant enough difference for it to be worth it for me to try to save a 5 stack instead of just hitting SS again.

If I am just being an idiot in some manner I am not seeing please tell me so and move on, but if this is indeed a question worth consideration I would be grateful for any insight you all may have.

 

Garren

I tested DP a month or so ago, and it ticks based on the time of the application of the first stack.

I did this because I was making a deadly poison simulator - results posted earlier in this thread and also more recently in Roguecraft 101.

However, out of that, I also set up an equation that was empirically fit to the data and is in reasonable agreement (within 1 DPS) for realistic values. If someone maintaining the spreadsheet would like, I could PM them the empirical calculator.

The equation itself is based on average time building up to a full stack and average time at a full stack. A correction factor is applied to the time building up to calculate the average tick damage during the time building up.

 

todemax

regarding the shiving to keep dp up. Based on my current spec of 30/0/31, with improved poisons disabled (for worst/best case scenario), the chance of dp falling off is about 6.6% which corresponds to a shiv every 45 ish seconds (sloppy calcs) to keep the 5 stack up. Comparing the shiv damage per hit and the ss damage per hit this corresponds to about 20 dps loss. Enabling 5/5 improved poisons, 2/2 master poisoner and putting DP on both hands (reducing the chance for dp to fall of to near 0) yields a 32 dps increase, so in this scenario it will be worth to shiv. However depending on gear and spec, you might lose some dps by putting dp in offhand instead of mh. My calculations was pretty fast, but i would say that it isn't worth shiving if you have a few points in improved poisons and have 100 SnD uptime.

 

Deadlyhit

I have been using this great tool for some days and looking into it more thoroughly, but a thing i miss and been trying to fix by myself but without luck is in the Gear_Upgrades tab.
It is some collums where you can compare the +hit, unbuffed crit and buffed crit from the gear you have copied and your "saved dps" so you allso can compare gear on hit and crit because on some fights a high crit procentage can be better than a higher average DPS

 

Zene

I think what you also have to consider is that DST is only on a 20 second "hidden" cooldown. At least from what I've read on the forums.

Here's one post I could find backing that up, but I'm sure you could find more.

 

Meedo

huge thanks to all who onctribute great and small to this project.

I DL'd 2.3.2.7, plugged my data in manually, and that all seems fine. But I'm getting errors/failures when I try to run any of the upgrade buttons:

Microsoft Visual Basic
Compile Error: Can't find Project or Library.

Anyone know whats up?

 

saedo

Try installing http://rogue.raidcal.com/msxml6.msi

That's what fixed it for me.

 

Meedo

Bah! I saw that item for install, but I thought that was for the Armory import only. TYVM, issue resolved in record time.

 

Dontmindme

Well, assuming the calculations leading into and out of the haste calculations are correct, it should be spot on more accurate. Haste (beyond SnD and BF) were significantly undervalued do to a calculation error. The cell in question was Q39 on the (Un)buffed DPS sheets. This influences the MH and OH procs per second. The equation just wasn't correct. It only seemed to affect Haste rating effects (as SnD is calculated in the cycles). Someone pointed this error out a few pages back, I looked at it and determined that the suggested change was correct. Originally you could just multiply SnD with your permanent haste and see that the avg Haste was lower than that (not even working BF into the equation)

Looking at the AEP numbers, Haste seems closer to where it belongs. I don't know what to say about armor pen except to check CoR and other buffs for changes. It's possible one sheet has this defaulted on and another defaulted off.

While I'm on the topic...I would appreciated it if people more knowledgeable than I would offer up suggestions for a default list of buffs for the sheet. Basically, what should be (un)checked as a default. I don't believe my guild (former guild now) was typical in its use of buffs and talent builds which is all fine and good (cough...Boomkin...cough), no complaints, but I'd like a set of buffs defaulted on the sheet that would be majority use. Basically what is used by a majority of guilds and what usually isn't. This may be tricky with some like CoR which I've heard is used by some, not by others.

As to the issue of modeling averages vs. more specific. I'd like to more accurately address some of the formulas (and will try to implement that in the future). Especially with regard to Armor Penetration where averages just aren't nearly as accurate as averaging haste effects for example. The big problem with getting perfectly accurate is when you have multiple overlapping proccing effects. These almost have to be handled seperately and the more items and combinations you have, the more impossible the task becomes to model all the combinations. This becomes much more complex as it affects one's cycles. Not to mention how one would maintain that as new items get introduced.

Modeling energy averages vs. not modeling them is a two-edged sword. You model them as an average and your average cycle bleeds a little only to gain energy as the proc happens. Don't model them, and you are running a slow cycle that every time you proc, you really want a shorter cycle. I think the average model gives a more accurate reflection of your average cycle DPS. By not including procced energy, you are consistantly undervaluing your cycle DPS as every time you proc, you can use a shortened cycle and this change wouldn't be reflected in your finisher DPS. When using averages, yes, the cycle might be short of energy at times waiting for the proc or running a higher cycle to get back on track (and overvaluing your cycle DPS), but this is countered by the times you get the proc (which undervalues your cycle) as you can use a shorter cycle that time. So, in many ways, using average energy is self-correcting itself while if you left that energy consistantly out of the cycles, you are skewing your results in an undervalued direction.

Now, AR is a big exception to this. Pop AR and well, you can possibly pull off something like a 1s/4r/4r cycle in the middle. I don't see the same problem with most of the other averages. You still usually have to adjust your cycles anyway for lucky/unlucky procs and other effects, moving, so having those averaged into your cycles still usually works.

You pop one of those and you build your combo points quicker and can regen some energy waiting for your SnD to drop, thus allowing you to really use that slightly lower cycle. So you slightly bleed a little energy every cycle til you proc and gain it back so averages do actually kinda work most of the time.

But overall, I do want to spend more time on the formula side of things. Thus far, I've mostly done updates, correcting or implementing issues pointed out on the boards, some user interface things (like Armory Import and making the talent sheet easier to use). It's a good sheet. People have attested to its approximate accuracy, still, as with any project this large and complex there are many things which can be done better.

If people write pieces of code and have specific suggestions that make the sheet more accurate, I'll definitely use them subject to finding the time and having the solutions be more accurate than what is modeled. Beyond that, some of these things will get done when I find the time between all the other maintainance, updates and bug fixes.

 

Wethryn

"the security level is set to high and the macros have not been digitally signed or verified as safe." How can I fix this problem? I've tried to find the signature without any luck. I've tried setting my security level to low, but that still is apparently too high. What am I doing wrong?

 

Sweetmeat

First let me say how much I appreciate all the effort that has gone into making this wonderful tool for us. Everyone that has worked on it really deserves a big Thank You from all us rogues!!

I've come to really count on this tool as my most valuable resource when making gear decisions. Now my guild is moving pretty far into BT its more important than ever. However, with the new version not working for the many Mac users its extremely frustrating for us. If there is anyway you can put the Mac fix as a "need it yesterday" priority it would be a huge deal for a lot of your spreadsheet users. Having to wait for you next version with other fixes is really waiting far too long in my opinion. If you know how to fix it and can find the time to release a quick bug fix asap, it would be huge for many loyal users... just my .02 and frustration speaking.