Makes me wonder if the crit reduction is the same for casts as it is for melee crit. If so, I may have a complicated way of testing it. The problem with determining the crit reduction for casters (or for melee) is that one would normally need hundred's a thousands of repetitions under set conditions to be only reasonably sure that a said reduction isn't a fluke.

Now, if the crit reduction works the same for rogues and poison procs, one could conceivably get the answer by using rogues as the test device. Assuming we could figure out the base crit rate at 70 under the same conditions, we should be able to see the depression more easily since a rogues spell crit chance is so low to begin with. I believe there is a UI getspellcritchance function where one could characterize what happens at 70 with these buffs.

This method is very similar to what was done with weapon skill determinations. Maybe I'll try to get out to Felwood tomorrow and see if I can figure out a starting point.

And to reiterate what Aldriana is saying, we are just starting with the very basic case. Deadly Poison on offhand. Slice and Dice never drops (or isn't even used - same case). One is never parried, thus the frequency of attacks is completely uniform (i.e. hit like clockwork). So to get the average damage per second from the poison proc, we need to know the number of procs per second and at least the average number of stacks.

I don't know if this is any help or not, but the way that Aldriana has formulated her question (i.e., what is the average number of DP stacks on the target at any time), it would seem that queueing theory might be able to answer the question. There are a few snags, but this is what I've come up with so far.

First, to use the theory, we need to make the assumption that arrival rate of the event (in this case, DP proccing) follows a Poisson distribution. (You can use others; I however have not been trained in this yet.) In most cases, this is a good starting point. Next, the service rate. This is where the theory will break down if we are not careful. In the simplest sense, the service time here is 12s. However, the queueing theory that I am familiar with requires that the service rate (1/service time) is higher than the arrival rate, and that would be, well, ludicrous in this example. However, there is also the case that there are 5 separate channels (at least) for the DP to 'go into' for this. This certainly helps, but here comes the big snag.

Nothing I know in queueing theory allows for the replacement of someone in the system by someone arriving in the system (that I can recall offhand). Therefore, I am not sure how to handle the case when you have a full stack of 5 DPs on target, and another arrives. Similarly, I am not sure how to handle the fact that all the cases do not take into account that the 'service time' refreshes each time that a new arrival occurs.

Actually, if we can solve the second problem, the first problem can be alleviated by clearing the blocks. But that is another case altogether...

In any event, it should be easy enough to calculate the amount of time the system is idle. Let me look up the formulas, but these will be the givens:

1.5s OH
30% DP proc chance

12 ppm (arrival rate)

12s deterministic service time
5 spm (service time)

#channels: 5

Therefore,

M/D/5 queue, Lambda = 12/min (poisson distribution), Mu = 5/min (deterministic)

(Also note: The only formulae I can find are for Exponential Service times, which is not accurate. If someone can find me M/G/x or M/D/x formulae, it would be much appreciated.)

First, lambda/mu = 2.4. This is a very important measurement.

According to a handy chart I have (Introduction to Management Science, p.558), the chance that the system is idle is 0.0889. This is equivalent to stating that your DP has a 91.11% uptime.

I'm not sure how well queueing theory can handle the rest of the math until the underlying issues are resolved, but that should at least be able to help you 'do the math'.

Hrm. If done by a one-step Markov process, I think you'd almost have to do it on a per-swing basis. Which means that you would have to have a different transition matrix for each weapon swing you wanted to look at. Basically, I'm thinking that you would start at 0, and go as follows:

0
1 0s
1 (ss)
1 (2ss)
.
.
1 (highest multiple of ss <12)
2 0s
2 (ss)
.
.
.
.
etc.

This would be the rows and columns. This shouldn't have an absorbing state, the way that it is calculated. Then, once the steady-state matrix is achieved, the average number of DP stacks on target should be readily achieved. It's one hellaciously large (if not particularly hard) matrix to solve. Anyway, I'm going to review the code (what little I can understand of it) in the thread, then maybe suggesting another option.

Actually, one problem is the duration is not 12 seconds for determination of when DP drops. In fact the truth is, DP will drop when you fail to have a success in a given 9 second period, not 12 as any successful proc in the first 3 seconds does not reset the timer.

For a damage calculation, you could always simulate it, no? Something like (and I can't code to save my life, so view this as pseudocode at best):

variables

EncTime (continuous) (time of the fight in s, probably should be set to go until 600 or so)
SwingSpeed (speed of weapon, in s)
Swing# (which swing you're on; used for stopping timer)
ProcChance (chance to proc DP, including chance to miss/resist/whathaveyou)
NextSwing = SwingSpeed * Swing#

'Timer'
Run until EncTimer = MIN(NextSwing,PoisonDmgTime)

'Swing'
Swing#+
If RNG <= ProcChance, DPStack+,
If Poison Tick > 0, PoisonDmgTime = EncTimer + 3, PoisonTick = 0

PoisonDmg
Dmg = Dmg + 45*DPStack
PoisonTick+
If PoisonTick = 4, DPStack = 0 and PoisonDmgTime = (some very large number)
Else PoisonDmgTime = EncTimer + 3


Wouldn't something like this work? Then you can ask for dmg/enctime to get the dps in the fight from DP. I'm sorry for my ignorance, but what other uses (besides Envenom) could the average number of DP stacks you have on a target be used for?

I'll see if I can simplify the matrix issues at all. I have a neat little program that will solve the matrices rather quickly, as long as they're 10x10 or smaller.

Edit: Well, I don't know about 'simpler', but I do have a transition matrix for a 1.6-1.7 SS weapon for DP stacking. It's a 41x41 matrix, however. Since I can't post attachments, I can email it to anyone who wants it. (It's in Excel.)

Ah, this I did not know. How interesting. That makes it much harder to model from 0. Well, not harder so much as it moves certain states to other locations. I'll incorporate this information ASAP.

Edit: Okay, I've been playing around with different transition matrices. First, to give some 'fast-and-dirty' results. I'm using some software that came with my OR class, and it can do a maximum of a 10x10 matrix, and generally doesn't like having only one absorbing state. Therefore, I formulated the problem in a couple of different ways.

Formula #1: Take 1,2,3,4,5,0 stacks as the rows/columns in the matrix. An OH sword with 1.6/1.7 Swing Speed gets 7 attacks while DP is up. I decided to ignore (for now) the case where you get multiple procs inside that window; this means that the numbers generated will be lower than what you should see. At the very least, this should give a good baseline as to what to expect. With a 0.3 chance to proc each swing, the chance that you will get at least 1 proc in 7 tries is p ~= 0.918. Therefore, you use that for entering the next stack and 1-p or 0.082 for going to 0. Now, since we are sort of looking at a 12s window, we can use the same logic for the 0 state going to 1. Doing this, we get:

0 stacks: 0.082
1 stack: 0.075
2 stacks: 0.069
3 stacks: 0.063
4 stack: 0.058
5 stacks: 0.652

Expected value for this is 3.894 stacks. Given the number of assumptions used, this again should be considered the very lowest bound for DP stack #. Also, given the nature of the formulation, the uptime on the DP stack is 0.918.

Formula #2: Take 1(0-3s), 1(3-12s), etc. etc. This allows to model the new information above (well, new to me). Since there is generally one attack in the 0-3s window, you can use 0.7/0.3 for moving to 1(3-12) or 2(3-12). Then, since there are 6 attacks in 3-12, you use 0.882/0.118 for moving on. Coming back with more in just a bit.

Yes, simulation is definitely an option, and we've done some work on that in this thread in the hopes of validating any models available. In particular, take a look at this post and this post.

The results vary based on what type of modeling you are using. The "better" models employ a tick-based scenario, including tying the tick to either a global tick or to the first attack which procs DP. Some work still may need to be done, as I'm not sure all the assumptions made in the programs are valid. (For example, my simulator assumes that poisons tick at 3, 6, 9, and 12 sec, whereas others seem to be saying that poison ticks at 0, 3, 6, and 9.) Further testing will be needed, and probably adjustment of the models.

Hmm, good to know. I think this is the way I am currently simulating in my program; I'll have to double-check my logic to make sure.

On resists: I believe every proc is subject to the 17% resist rate, however, getting a proc resist doesn't reset your stack; it just prevents it from being refreshed by that proc. Proc resists and tick resists are different. I believe that once the stack is up, it is treated as a dot and therefore the ticks are subject only to partial resist mechanics. This will lower overall DPS somewhat, but not by much (and there isn't anything we can do about it anyway).

I presonally can't recall a time that a deadly tick got flat-out resisted by a mob, although that could theoretically happen even using the partial resist system. Procs yes, but not ticks. It might, however, be that I'm just not remembering correctly, so it wouldn't hurt to look at combat logs for that mechanic too.

I guess to clarify my question. It's an overall average 17% resist rate on procs? I.E. With maybe a 1-2% chance to get all out full resisted, x% chance for 3/4; 1/2 etc, it should all average out to the same 17% number we are used to dealing with on the initial resist? Not playing a caster, I think that is how this works out, but am hoping for clarification for "on average", given I will be going through the DPS sheet DP mechanics more closely soon and want to make sure all the i's are dotted and the t's crossed so to speak.

I think you're confusing level-based resists and resistance-score-based resists.

Casters have a 17% chance to be resisted against any raid boss, and they can negate 16% of that to cap out at 99% chance to hit. This will result in 99 spells hitting, and 1 being fully resisted.

The partial resists you're talking about only occur due to mob resistances, and only certain spells are affected by it. Frostbolt, for example, either hits or is resisted - it can't be partially resisted. Fireball, however, CAN be partially resisted. As such, spell penetration comes into play more for a Fire spec than it would for Frost.

I'm not entirely sure if any of the poisons are affected by this binary/non-binary system. The information on this page seems to imply that something like Wound Poison would be a binary spell (has an additional non-damage effect):

Binary spell - WoWWiki - Your guide to the World of Warcraft

This does have me curious though - is a running DP stack succeptible to that resistance-based resist as well? The way I understand it, DoTs are checked against the mob's resistances for each tick. You can see this pretty easily just using Drain Life or Mind Flay on a mob with high Shadow Resistance. You'll get a lot of ticks for 3/4, 1/2, and 1/4 damage.

Well, Deadly poison can be resisted initially on application and then each damage proc also has a chance to be resisted partially or fully. That much I do know. So my question is, without any spell penetration effects, is this partial resist rate also 17% vs. Bosses (at least in terms of average damage resisted) for the damage procs?

Sorry, not to split hairs, but by 'damage proc' to you mean the tick that DP does every 3 seconds that has nothing to do with it 'proc'ing from the weapon?

Resistance - WoWWiki - Your guide to the World of Warcraft has a good explanation on how resistances work. The important things I found were:

and the fact that

To save us all the math, there's a nifty table about halfway down the page that gives resist rates:

Resistance - WoWWiki - Your guide to the World of Warcraft

I think I found a more authoritative source for that information. It says the resist rate is 6%. And I'm such an idiot for not thinking to look in this place first...

Working Theories of Theorycrafting as of 2.3

That's a pretty big disparity between what WoWWiki and the EJ thread suggest. If I'm reading WoWWiki right, the 15% reduction due to level row should be the correct source, and we would have

0% DR: 54%
25% DR: 33%
50% DR: 11%
75% DR: 2%

versus a generic statement of 2% per level and no mention of how the 25/50/75% factor is determined.

I hate to call EJ into question, but do we have a source for that? If not, I'd definitely be up for providing some stats from a boss fight to help test.

I actually found this from a link on the wow forums of all places (linking me back here). There appeared to be significant testing done in the 2.1 topic to pin down whether it was % based or seemed to correspond to a set resistance number. This % based resistance also appears not to be subject to spell penetration, so it looks to be something a little different.

Looked at a couple WWS's, not a big sample size but...
Tidewalker 224 dots - average 6.2% mitigation
Lurker 176 dots - average 5.0% mitigation

Certainly higher than 3%.

You'll lose 5-6% of magic damage to partial resists due to mob level. This cannot be overcome by anything.
Think of it as "magic glancing". No, CoE/CoS and -resistance gear won't help you there.

Also, bear in mind that the combat log doesn't properly log crits/multipliers on partial resists.
Example:
Your poison would hit for 200. Misery (+5% magic damage) makes that 210 damage. Now you get a partial resist, the displayed "partial resist number doesn't factor in the multiplier on the mob.
"Your poison hits mob for 105 nature damage (100 resisted)."
If that partial resist is a crit, it looks like this:
"Your poison crits mob for 158 nature damage (100 resisted)."

That makes the actual damage lost a little bit higher than what WWS/logs display. It's pretty much negligible for rogues (1 debuff, no innate crits), still worth mentioning.

5%-6% (usually assuming 6%) damage lost to unremovable partial resists against bosses/73 mobs is commonly accepted.
There should be no resists against level 70 mobs or lower, ~2% vs. level 71 and ~4% vs. level 72.
The only mobs that seem to have actual nature resistance are nether drakes.


I've got a totally different question:
Has anyone figured out the proc mechanics on [Flowing Flamewrath Cape]s yet?
Dontmindme's spreadsheep lists them as a 0.5 DPS increase.
I tried them 3 times with wanding (1.5s shoot time), and got 6-8 proc each time (over the one minute duration), which is a lot more than the listed.
With dual-wield, instant attacks and haste, it should be much more.

Has anyone done some conclusive tests with those yet?


[Edit]:
Did two quick tests with a blue/Kara geared enhancement shaman on Servants in Blasted Lands.
Got 810 and 680 damage in those during that one minute.
Average it at 700, add raid debuffs, and it's ~930 damage. Spread over it's 3 minutes cooldown, it's 5 DPS.
Better than what the sheet suggests.

Most likely still not worth losing your emergency health stone, but better than nothing at all.

I'd like to see more testing and combat logs before remodeling [Flowing Flamewrath Cape]. Best would be enough testing to determine if its a percentage based proc or a PPM effect. Flame Cap was modeled prior to my involvement in the spreadsheet, but I'd want a little more than 3 isolated (and undocumented) 1 minute tests before I change what is already in the spreadsheet.

Does that apply to non-binary effects?
I agree that the initial effect (or chance to hit) will have a minimum 1% failure chance, but this discussion is about the follow-up poison procs and potential/partial resists. I've never heard one way or another whether there is a minimum failure rate after you've passed the "chance to hit" test.

Ah, good question. I might have de-contextualized his statement a bit too far.

So you're asking if a (non-binary) DoT basically has to roll 1-100 each time it ticks, and if it can just have a tick resisted fully without the DoT dropping?

I have a hunch that the warlocks in our community may know better than us.

Only the first application of the DoT is subject to the 1% miss rule. Once it starts ticking the worst thing that could happen is a partial resist.

So for rogues, the applications of DP can get resisted, the dot ticks can only be partially resisted.

Great, thanks for the info Vyed!

Sorry, but the way I understand and look at it is at a very simplistic point of view.Thus I would think it would be easier than that to genrate a general formula. With deadly poisons having a 30% Chance to apply its effect(Assuming no Improved poisons talents is in place) , One must then consider Expertise and hit . This affects whether the OH Weapon with DP on it would miss/get dodged in which case there is 0% of applying the poison? then with that, and the weapon speed, You would know how many times it actually hits per 12 seconds(Taking Hit and expertise into consideration). Then 30% of that is the number of times DP would be expected to be applied ,per 12 second.

Im pretty new here to the theorycrafting world but basically that is how it seems to me, maybe I'm just simple-minded, pardon me for that and feel free to collapse what i have said, after all, I do realise that rogueTC is not napkin maths ^^ .

-Moonblitz

Well, right, you can use that approach to figure out the average number of applications in 12 seconds... but what good does that do you? Knowing the average rate of application is certainly useful (and more or less assumed by the earlier posts), but it's not the number we're trying to solve for. The rate of application is the easy part. Figuring out the uptime based on that number is the part we've been having trouble with.