Tanking Spreadsheet - Page 10

Gruntle · 08/27/09, 4:53 AM

All ratings can be found in Whitehoof's post.
http://elitistjerks.com/f31/t29453-c...gs_level_80_a/

Armadeus, that's how far I got too

. We need testing to find these values. But unless there is some easy way of finding it through the interface pure testing is going to be a pain. Shield slam has a damage range of 50 so tests on the damage for a >2400 BV shield slam will have to be run for enough time to give a variance less than this.

edit to avoid double posting:
Hmm, I just realised that my assumptions on how the cap works are probably wrong. The 2400/2760 caps seems to apply to all of the block value that is added to SS damage. I thought I read somewhere that it was only the additional block value contribution that was capped (i.e. not the BV from strength), but after reading some more it seems most people think it is the full BV that is capped. The patch notes are not really clear, have anyone tested this properly?

Flukeworld · 08/28/09, 10:21 AM

Originally Posted by Triel

New release of the spreadsheet online :
- Correction on a few items
- New resilience rating
- On use AEP of trinkets updated
- Stamina + hit gems readded to the list

The black heart proc seems a bit overrated due to the fact that the sheet doesn't model the "elemental" blows such has Hodir Frozen blow, so armor is overrated.

I modeled the Fervor of the Frostborn as Armadeus did (the formula is a bit different but it's the same idea)
For Satrina's Impending Scarab, the HP are converted into stamina (minus vitality and BoK) for their AEP value.

Office 2007: http://theranthil.free.fr/wotlkwarr20090821.xlsm
Office 97-2003: http://theranthil.free.fr/wotlkwarr20090821.xls

A lots of things seem broken..

[Shivering Felspine] has wrong stats in the spreadsheet.
Unbufed dodge uses wrong values, missmatch from buffed/unbufed agility and dodge rating, at the end it calculates like +2% more dodge even with correct ratings.

The shield second gem formula is wrong and always shows blue gems (its has wrong check numbers).

Doormat · 08/28/09, 2:18 PM

Yeah even after fixing the numbers sheet I have too much dodge. I checked and all the base stats/ratings match my char sheet/armory so the calculation is wrong somewhere but I can't for the life of me figure out where.

Beyond this, I notice that parry gets a higher AEP than dodge even when below the 1.85 ratio. Is there some component of threat taken into account with parry?

Flukeworld · 08/28/09, 4:55 PM

Seems as someone inserted a line at Equip worksheet, so at stats the formulas uses wrong reference. Example dodge formula for unbuffed uses: Equip!$J$71 instead Equip!$J$70, which are the buffed stats (if you equip a dodge proc trinked buffed stats change)

I think i manage to fix the spreadsheet, but i will keep it at home as im not the creator of it..

Gruntle · 09/02/09, 7:23 AM

In Taliafear's sheet (and possibly also in Triel's updated version, although I cannot check) the value of the Blade warding enchant is severely underestimated. I have done some modeling that I think should be more appropriate to the enchant. I have searched the EJ forums to see if someone else have done something similar, but I couldn't really find anything so here goes.

EDIT: A work in progress, it seems I have made some errors, see posts below by Armadues and todemax.

Blade Warding approximate model.

The uptime of the 200*stacks parry rating is quite hard to determine since it will depend on multiple things (proc rate, player weapon speed, current player parry rating, boss speed). The damage from the procs are a bit easier to model, each proc will always result in ~700 damage (unless there is a stack limit, but it will be very very unlikely with >5 stack situations anyway), I might add this later. Modeling it accurately will of course demand that we know the actual proc rate and whether it is on ppm mechanic or not. This is an attempt to set up a framework for how to model it in spreadsheets and similar applications.

The first assumption I'm going to make is that we never go past 3 stacks for the calculation of parry rating. This will in principle mean that we underestimate the parry rating contribution by a very very tiny amount. It's perfectly possible to include more stacks, but things will not change by much. I also assume that every GCD is used for an attack that can proc Blade Warding. I will use the pseudocode/math function min(a,b) to designate that the minimum value of a and b should be used and trunc(a) for truncating to integer.

Variables:
r% - proc rate per hit/crit/glance?/block? of the enchant (could be ppm, in that case the formula becomes a bit different)
P - Player parry chance (with proc parry rating after DR added)
PR - parry rating before diminishing returns
dPR - added parry rating from proc (200/400/600)
dPR_dr - diminished parry rating addition
p_spd - player weapon speed
b_spd - boss speed
T, Tp - times over which the buff is active (more below)
N - number of attacks that can proc during the buff duration

Formulae:
We use the expression for a binomial distribution (with n the number of successes):

P_r% (n|N) = N!/n!/(N-n)! * r%^n * (1-r%)^(N-n)

The number of attacks during the duration is:

N = trunc(T*(1/p_spd+1/1.5))

the 1/1.5 term from the gcd abilities. This is truncated because the binomial distribution works with integers. It might be more appropriate to round this, but I'm uncertain.

The chance of getting exactly 1 proc is then:

oneproc(T) = N!/(N-1)! * r% * (1-r%)^(N-1))=N * r% * (1-r%)^(N-1))

Two procs:

twoproc(T) = N!/(N-2)!/2 * r%^2 * (1-r%)^(N-2))

and three procs:

threeproc(T) = N!/(N-3)!/6 * r%^3 * (1-r%)^(N-3))

The mean time between each parry (i.e. the player parrying an attack from the boss) is:

Tp = b_spd/P

DR formula for parry (rounded to make it easier to read, should use higher precision in sheets):

P[%]= 1/(1/47+0.96/((def-400)*0.04+PR/45.25)) + 10

(assuming talented and 5% base)

The added parry rating can be transformed into diminished parry rating

dPR_dr = (1/(1/47+0.96/((def-400)*0.04+(PR+dPR)/45.25))-1/(1/47+0.96/((def-400)*0.04+(PR)/45.25)))/45.25

For proc-type buffs the average uptime will be equal to the sum of oneproc, twoproc and threeproc (and so on) chance if T is set to the buff duration. The problem with Blade Warding is that the buff is consumed when the player parries. We can get around this by setting T to Tp. We thus get the following expression for Blade Warding uptime (UT_n, one for each of the three proc expressions above):

UT_1 = trunc(Tp*(1/p_spd+1/1.5)) * r%^1 * (1-r%)^(trunc(min(10,Tp)*(1/p_spd+1/1.5))-1)

insert Tp from the above expression.

and the average parry rating contribution:

PR_bladewarding = 200*UT_1+400*UT_2+600*UT_3+... (fourth order and higher terms)

NB, 200/400/600 is not corrected for DR since the mean PR is subject to DR in the sheet calculations. In the sheets you should have a way of computing the AEP values for parry rating including DR. The actual value of the parry rating depends on your current def and parry (as all ratings with DR do). The model for Blade warding in the sheet has to include the extra diminishing returns you get due to the fact that the proc parry ratings are more sensitive that the mean value. Will have to do more work on that.

Examples
Defense: 540 assumed in all examples.

Low end tanking

r%=3%, p_spd=1.6, b_spd=1.5, PR=100
P(+0)=16.93, P(+200)=20.02, P(+400)=22.67, P(600)=24.96
dPR_dr(200)=140, dPR_dr(400)=259, dPR_dr(600)=363
Tp(200)=1.5/0.2002=7.49, N=9
Tp(400)=1.5/0.2267=6.61, N=8
Tp(600)=1.5/0.2496=6.01, N=7
UT_1=9*0.03*0.97^8=0.21161
UT_2=8*7/2*0.03^2*0.97^6=0.02099
UT_3=7*6*5/6*0.03^3*0.97^4=0.00084

-> Average uptime (i.e. amount of time spent with at least one stack)~ 0.23343
and PR_bladewarding (subject to DR) ~ 200*0.21161+400*0.02099+600*0.00084=51.2

High end tanking

r%=3%, p_spd=1.6, b_spd=1.5, PR=250
P(+0)=19.30, P(+200)=22.04, P(+400)=24.42, P(600)=26.49
dPR_dr(200)=124, dPR_dr(400)=232, dPR_dr(600)=325
Tp(200)=1.5/0.2204=6.81, N=8
Tp(400)=1.5/0.2442=6.14, N=7
Tp(600)=1.5/0.2649=5.66, N=7
UT_1=8*0.03*0.97^7=0.19391
UT_2=7*6/2*0.03^2*0.97^5=0.01623
UT_3=7*6*5*3/6*0.03^3*0.97^4=0.000837

-> Average uptime (i.e. amount of time spent with at least one stack)~ 0.2110
and PR_bladewarding (subject to DR) ~ 200*0.19391+400*0.01623+600*0.000837=45.8

r%=3%, p_spd=1.6, b_spd=2.5, PR=250
P(+0)=19.30, P(+200)=22.04, P(+400)=24.42, P(600)=26.49
dPR_dr(200)=124, dPR_dr(400)=232, dPR_dr(600)=325
Tp(200)=2.5/0.2204=11.31, but 10 is max, N=12 
Tp(400)=2.5/0.2442=10.24, but 10 is max, N=12
Tp(600)=2.5/0.2649=9.43, N=12
UT_1=12*0.03*0.97^11=0.25751
UT_2=12*11/2*0.03^2*0.97^10=0.04380
UT_3=12*11*10/6*0.03^3*0.97^9=0.00452

-> Average uptime (i.e. amount of time spent with at least one stack)~ 0.306
and PR_bladewarding (subject to DR) ~ 200*0.25751+400*0.04380+600*0.00452=71.7

Blade ward is best used vs slow hitting bosses, it will lose a lot vs fast hitting ones. It is also better when you have low parry. I have not tried to compare this to Mongoose or Blood Ward, for that you will have to include the values of the extra threat from the proc damage (I hope to include this in an updated spreadsheet soon).

Please don't hesitate to tell me if you think I made any mistakes, I will edit my post accordingly (assuming that I agree with you).

edit:
- changed definition of r% to procs per hit rather than per swing
- included DR into the calculations, making the enchant considerably worse
- updated examples

todemax · 09/02/09, 9:00 AM

One mistake that I noticed, is that you don't as such account for diminishing returns. 50% uptime of 200 parry and 50% uptime of 400 parry, doesn't average 300.

I opened one of the newer versions of the sheet where the default parry % versus bosses were 16.11%. Adding 200 parry rating gave an extra 2.9%. Adding 200 more gave 2.51%. And 200 more 2.2%.

Using your 0.2575+0.0438+0.0045 uptimes in your first example, you express this as an average 71.7 parry rating. Plugging this into the sheet I am using adds 1,09% parry. Accounting for DR you get

0.2575*2.9%+0.0438*(2.9%+2.51%)+0.0045*(2.2%+2.51%+2.9%)=0.987%.

I'll take a closer look at how it can be implemented easily, but wanted to post this if you yourself had a bright idea on this

EDIT: Nonsense math. Corrected the calculation, but the point remains valid.

Gruntle · 09/02/09, 9:19 AM

50% uptime of 200 parry and 50% uptime of 400 parry, doesn't average 300.

Hmm, in rating it will. The actual parry chance you get out will not be as simple of course. But I get your point, the mean parry rating will not be an accurate measure since the mean will always be less affected by DR than the 200/400/600 rating you get during a buff. I'm not sure how to model this properly, if it was just about calculating the parry chance you get out from the enchant it would be easy enough.

The problem is that, in Taliafear's sheet, we need to be able to calculate the mean AEP value of using the enchant. The way I do this is by using the mean parry rating. There is no easy way of doing this if you want to use the actual mean parry chances instead since Parry in it self is not included as a stat with an AEP value. I guess one could rescale the 200/400/600 ratings to some value that would compensate for the DR (making them smaller), maybe that's what you meant.

I might also be using a bit low parry chances, you should probably think of them as base parry (before the addition of the actual proc parry). The values for P that should be used are thus different for each of UT_1, UT_2, and UT_3. Those values for P will of course have to be calculated with DR (but there are already formulae in the sheet that does this for you). All in all this will make the parry rating contribution go down a bit more. I will update the examples in my original post soon.

Armadeus · 09/02/09, 1:06 PM

The binomial distribution for the first proc is meaningless. You are calculating the probability of a proc before you parry naturally. This has no benefit for calculating uptime because if you parry and the proc is not up then it is not consumed. I am working on a model for this now.

todemax · 09/02/09, 1:26 PM

I made a simulation spreadsheet of the proc (just one milion lines of excel with 0.1s ticks. Around 27 hours ingame), because I'm rusty in statistics.
Didn't know if avoided attacks could proc Blade Ward, so just assumed it did (Easy fix if it's not). 1.5s GCD on instants, 1.6s player attack speed, 1.5s boss attacks speed. 16.11% parry with no Blade Ward procs. Both treating instants and autoattacks seperately and as the same yields similar results. I'm getting 6,3% uptime of the 1 stack, 3,5% of 2 stack and 0.1% of the 3 stack.

If anyone would be interested in having a look, please send me a pm.

EDIT: These numbers was from before I fixed a bug in the sheet. Please refer to my updated post, a few posts below.

Armadeus · 09/02/09, 3:33 PM

Okay I just built a model for this and using my gear (540 def and 226 parry rating) against hodir (2.4 swing timer) here is what I got.

A net increase of 5.30 parry rating (.117% parry) and 19.54 dps.

Here is how you need to model this:

First, calculate the probability of getting a proc. This is done by taking your attacks per second (1/player speed + 1/1.5) and multiplying it by your change to hit* (about 90% for me) and then multiplying by the probability of getting a proc (.03). Using a 1.6 speed weapon my chance of getting a proc was about .033.

You then calculate the chance of getting a proc during the 10 seconds it's active using a binomial distribution. You don't need to worry about the parry chance here, that is taken care of later. For me this value was about .25.

Now you need to calculate the dimishing returns from parry. Using my gear I got the following parry values for each stack.

1 124.2
2 231.5
3 325.1
4 407.6
5 480.7

Now we use these values to determine dodge percentage for each of the stacks. When you have a dodge percentage for each stack you do a binomial distribution for 0 successes with (10/boss swing timer) attempts. This gives you the probability that you have no parries in a 10 second period after the proc activates. 1- this value is the chance that you do parry.

You should have 5 binomial forumula results (one for the increasing parry associated with each stack).

To calculate parry you multiply (chance of a proc)*(parry gained after dr). The chance of a proc is calculated by (base chance)*(binomial solution for one proc over ten seconds)*(chance of ALL previous procs to not be consumed).

DPS is calculated by 700*(number of stacks)*(proc chance)*(chance of ALL previous procs to not be consumed)*(chance that you WILL parry in the next 10 seconds).

This is probably not very clear and if people have questions I will write up a more detailed explanation but from all appearances this enchant is not that great. Calculating the AEP using some fairly default values I came up with an AEP of 60-70 for this enchant.

*I only included miss dodge and parry here

Gruntle · 09/03/09, 9:21 AM

The binomial distribution for the first proc is meaningless. You are calculating the probability of a proc before you parry naturally. This has no benefit for calculating uptime because if you parry and the proc is not up then it is not consumed. I am working on a model for this now.

I don't understand what you mean by this. The probability of getting a proc is not dependent on whether you have parried or not.

You're correct in that the proc percentage is per hit/crit/block/glance rather than per swing (will change that). I don't get why you want the procs per second though. Also, noone knows if there is stack limit, but the chances of getting more than 3 stacks are slim indeed, so I don't really see the point in going higher than that.

Now we use these values to determine dodge percentage for each of the stacks. When you have a dodge percentage for each stack you do a binomial distribution for 0 successes with (10/boss swing timer) attempts. This gives you the probability that you have no parries in a 10 second period after the proc activates. 1- this value is the chance that you do parry.

Guess you mean parry percentages? You have to make things clearer I think, I find it very hard to understand your reasoning.

What I'm calculating is the probability of getting 1, 2 or 3 procs over a set time period. Then I say that the gained parry rating will stay until you parry the next time. The average time to next parry can be estimated by dividing the boss attack speed by the parry chance (with stacks added and corrected for DR as pointed out by todemax). I might be wrong, but I cannot really find any fault with this. Could you perhaps point out where you think I go wrong? I have updated my first post to account for DR.

To calculate parry you multiply (chance of a proc)*(parry gained after dr). The chance of a proc is calculated by (base chance)*(binomial solution for one proc over ten seconds)*(chance of ALL previous procs to not be consumed).

I'll need the detailed calculations to make sense of this. By (chance of proc) I think you mean some kind of uptime measure? Otherwise you will not get average parry out.

todemax · 09/03/09, 1:41 PM

I found a bug in the sheet I made, and introduced a 90% chance for the player to land a hit. I also evaluated the DPS for the proc. The numbers with 90% hit, 1.5 boss attack speed, 1.6 player attack speed and 16.11% parry with no stacks up (DR included with stacks up), are:

Unmitigated DPS: 23.75
uptime(1): 0.132
uptime(2): 0.022
uptime(3): 0.004
uptime(4): negligible
uptime(5): negligible

Which results in an average of around 35 parry rating in this example.

Armadeus · 09/03/09, 8:10 PM

I have a big long post I am working on but I will put the first part out there so we can discuss it...

Okay I will try to cover the points one at a time.

The use of the binomial distribution

Using the binomial distribution the way you are, you are calculating the chance that you will get a given number of procs in 10 seconds, or when you parry the boss, whichever is first.

The reason this not applicable for the first proc is because you don't need to have the first proc happen in that given 10 seconds and if you parry naturally BEFORE the first proc, who cares. What you are saying is in a random 10 second (or however long it takes me to parry naturally) time period the chance of getting 1 proc is _____. The thing is, you don't care WHEN the first proc happens, you only care if the second, third...etc procs happen.

Because of this the chance of getting the first proc is (the total number of SUCCESSFUL attacks per second) * (proc chance).

Now for the higher level binomial chances. What you are calculating here is the chance that you will get 2, 3, etc procs either before you parry or in 10 seconds (which ever is smaller). There are two problems here: 1. With each proc your parry chance goes up so that must be taken into account. 2. When ever a proc happens it resets the 10 second timer so you don't HAVE to get all your procs in a single 10 second interval.

Gruntle · 09/04/09, 5:27 AM

I made a quick and dirty script in python to simulate blade warding that should be accurate enough (100k seconds with 0.1 sec timesteps). I get a lot lower uptimes and resulting parry contributions than what I calculate in my first post (more inline with what you have derived Armadeus), so I'm pretty convinced that I'm doing something wrong.

The reason this not applicable for the first proc is because you don't need to have the first proc happen in that given 10 seconds and if you parry naturally BEFORE the first proc, who cares. What you are saying is in a random 10 second (or however long it takes me to parry naturally) time period the chance of getting 1 proc is _____. The thing is, you don't care WHEN the first proc happens, you only care if the second, third...etc procs happen.

I think I might find it easier to understand if you could show me the formulae (perhaps in a pm). I'm sorry for being a bit slow.

Now for the higher level binomial chances. What you are calculating here is the chance that you will get 2, 3, etc procs either before you parry or in 10 seconds (which ever is smaller). There are two problems here: 1. With each proc your parry chance goes up so that must be taken into account. 2. When ever a proc happens it resets the 10 second timer so you don't HAVE to get all your procs in a single 10 second interval.

Point 1 is accounted for by changing the time to next parry for the 2 and 3 stack calculations. Point 2 is valid, but including that would make the uptimes go up rather than down.

Armadeus · 09/04/09, 1:06 PM

No problem, let me try to explain it another way...

Basic statistics is the probability that something will happen over a very large number of trials... correct?

So the chance for a proc to happen is going to be the same on every single attack (.03).

The average number of seconds it takes for a proc to occur is found by multiplying (the number of attacks in a second) and (chance that an attack will cause a proc).

We want to know how often the first proc will occur, everything else is dependent on that, and the first proc is only a function of attacks and proc percentage.

By using a binomial for the first proc you are constraining yourself to say "What are the chances that this proc will happen in 10 seconds." BUT we don't have to worry about the buff falling off for the first proc, it doesn't HAVE to happen in 10 seconds.

Does that make more sense now?

illusive_2008 · 09/04/09, 8:04 PM

Generally speaking, what would one need to adjust to get solid view of choice of gear based on TPS tank set? I went through and adjusted the few of the calculated stats on Gear list tab. Overall it's already set to pretty high rating for Expertise, so I increased value of hit just a touch. Below is what I have for overall weights incase that will help you help me.

AC BAC Str Agi Sta Def Dod Par
1.0 0.9 1.7 7.0 9.6 7.4 7.2 6.1

1.0 0.9 1.7 7.0 9.6 7.4 7.2 6.1

Res Blk BV Hit Crit Exp AP Has ArP
0.0 4.7 2.0 3.7 0.8 9.2 0.3 0.4 0.8

0.0 4.7 2.0 3.7 0.8 9.2 0.3 0.4 0.8

Just curious if anyone has a solid stat weight across the board for TPS set, want to clarify that I don't mean trash set. I mean set geared around overall TPS, being it seems overall EH and avoidance are bi-product of top end gear.

Armadeus · 09/09/09, 10:43 AM

Unhide the "Bosses" sheet. Under your selected boss you can modify the weights given to Damage in (sustained damage), burst damage (spikey damage with no heals), and TPS. I would suggest you use one of the models a few pages back for Ulduar bosses and play with your stat weighting here.

The simple fact is we can't give you a "hard and fast" set of numbers because with diminishing returns different stats will be weighted differently. Once you get your spec nailed down (you can also use the sheet to play around with specs for maximum threat) then you will need to work with the weightings to see where your maximum threat vs. survivability is.

Armadeus · 09/09/09, 10:49 AM

Originally Posted by Gruntle

Point 1 is accounted for by changing the time to next parry for the 2 and 3 stack calculations. Point 2 is valid, but including that would make the uptimes go up rather than down.

You are undervaluing the uptime of the buff. However you are not factoring into your calculations if the buff is consumed. You are also vastly overvaluing the benefit of the buff (5 stacks after DR was only 489 parry with my gear compared with 1000 before DR).

todemax · 09/09/09, 11:04 AM

Am I understanding you correctly Armadeus, that a 1000 parry rating increase yields the same parry percentage for you, as 489 times the benefit of 1 parry rating?
If you are to evaluate the parry rating benefit of the proc, I think that it would be more appropriate to evaluate it compared to the parry percent increase of adding a larger amount of parry rating, rather than just adding one. E.g. the average rating given by the buff.

There is no reason at all to think about parry rating when evaluating the buff. We only really need the uptimes. The only reason why we would want an average parry rating at all, is to evaluate the enchant on the gear sheet. For calculations with the enchant on your equipped weapon, you can use the actual parry percentage.

Gruntle · 09/10/09, 6:29 AM

Originally Posted by Armadeus

You are undervaluing the uptime of the buff. However you are not factoring into your calculations if the buff is consumed. You are also vastly overvaluing the benefit of the buff (5 stacks after DR was only 489 parry with my gear compared with 1000 before DR).

Yeah, I'm doing something fishy with the normalization of 10 seconds. I think I've now figured out what you mean. Coming back to that in a sec.

The benefit of the buff is not overvalued by me, I explicitly write that the final formula needs to be corrected for DR, it's just that doing that is very dependent on how your spreadsheet works. If I can find some time one of these days I'll try to incorporate these things in the OpenOffice sheet. In principle the values at each stack size (200/400 and so on) needs to be corrected for DR at your current parry rate, but the problem is that doing that blindly will not be correct. The AEP for the enchant is calculated by multiplying the average parry rating by the weighting value for parry rating. This weighting value applies to parry rating before DR. Thus using the DR-corrected parry ratings for the enchant buffs would apply DR twice when calculating the AEP. On the other hand, if you just use the average value before DR, you're not doing the correct thing either since the average value will be severely less affected by DR than the actual buff values. It will need some careful consideration in the spreadsheet to get it right which was why I didn't include that in the calculations above.

About the uptimes.
If I understand you correctly you're saying that the basic chance of the buff (>0 stacks) being up at any given time is procs/sec (0.033). The fact that the buff can be stacked complicates things a bit, the chance of having exactly one buff stack up becomes:
procs/sec*chance of no additional proc during 10 seconds
The fact that boss parry consumes the buff adds another layer:
procs/sec*chance of no additional proc during 10 seconds*chance of no boss parry with 200 PR(+DR) added

The chance of having exactly 2 stacks is then:
procs/sec*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added

The chance of having exactly 3 stacks is then:
procs/sec*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added
and so on.

So the one stack uptime at base parry rating 150 (corresponding to P=20.72% with 200 rating added after DR) with boss speed=2.5 becomes:
0.033*(1-0.033)^(10*(1/1.5+1/1.6))*(1-0.2072)^(10/2.5)=0.028

But this is way smaller than what I get from simulations, where I find a one-stack uptime of around 10%. So I'm not sure what you're doing is correct either. Using (chance of getting exactly one proc in 10 seconds) instead of procs/sec above give higher uptimes, maybe that is what you meant? The uptimes are still smaller than expected from simulations though.

Just for reference, this is the python code I've used to simulate the proc, there might of course be errors in that too. Parry haste is not included in the code. Damage might be overvalued a bit, since I use a crit chance of 0.3 (which I guess is too high).Should be possible to copy+paste and run in the python shell (but you need to have numpy installed), note that 1M sec takes a while to run (~3 minutes).

from numpy import *
from numpy.random import *
# input params
time=1000000.
dtime=0.1
pr_pd=150.
bspd=2.5

# initializing
count_wh=0.
count_y=0.
count_b=1.0
count_dur=0.
damage=0.
t=array(arange(0,time,dtime))
np=0.
dtp=0.
pp=0
buff=zeros(t.size)
r_numbers = random_sample((t.size,3))

# setting up diminished parry for all stack sizes
pr0=0.1+0.01/(1./47.+0.96/(140.*0.04+pr_pd/45.25))-0.0004*15
pr1=0.1+0.01/(1./47.+0.96/(140.*0.04+(pr_pd+200.)/45.25))-0.0004*15
pr2=0.1+0.01/(1./47.+0.96/(140.*0.04+(pr_pd+400.)/45.25))-0.0004*15
pr3=0.1+0.01/(1./47.+0.96/(140.*0.04+(pr_pd+600.)/45.25))-0.0004*15
pr4=0.1+0.01/(1./47.+0.96/(140.*0.04+(pr_pd+800.)/45.25))-0.0004*15
pr5=0.1+0.01/(1./47.+0.96/(140.*0.04+(pr_pd+1000.)/45.25))-0.0004*15
Parry=array([pr0,pr1,pr2,pr3,pr4,pr5])

# start simulation
for tstep in array(arange(0,(t.size-1))):
     if (t[tstep]==count_wh):
             if (r_numbers[tstep,0]<=0.03):
                     buff[tstep]+=1
                     count_dur=0.
             count_wh+=1.6
     if (t[tstep]==count_y):
             if (r_numbers[tstep,1]<=0.03):
                     buff[tstep]+=1
                     count_dur=0.
             count_y+=1.5
     if (buff[tstep]>5):
             print "Buff stack greater than 5 at time ", t[tstep]
             buff[t[tstep]]=5
     if (t[tstep]==count_b):
             PP=Parry[buff[tstep]]
             if (r_numbers[tstep,2]<=PP):
                     damage+=700*(0.7+0.3*2.)*buff[tstep]
                     np+=1.
                     pp=1
                     if np>1.:
                             dtp+=t[tstep]-tpprev
                     buff[tstep]=0
             count_b+=bspd
     if pp>0:
             tpprev=t[tstep]
             pp=0
     if (buff[tstep]>0):
             count_dur+=0.1
     if count_dur>10.:
             buff[tstep+1]=0
     else:
             buff[tstep+1]=buff[tstep]

# output
allstack=buff[buff>0]
onestack=buff[buff==1.]
twostack=buff[buff==2.]
threestack=buff[buff==3.]
fourstack=buff[buff==4.]
fivestack=buff[buff==5.]
print "uptime (1 stack): ",float(onestack.size)/float(tstep)
print "uptime (2 stacks): ",float(twostack.size)/float(tstep)
print "uptime (3 stacks): ",float(threestack.size)/float(tstep)
print "uptime (4 stacks): ",float(fourstack.size)/float(tstep)
print "uptime (5 stacks): ",float(fivestack.size)/float(tstep)
print "dps: ",damage/time
print "average time between parries: ", dtp/(np-1)
print "parry: ", np/(time/bspd)
print "parry (no procs)", pr0

With 150 parry rating and a boss attack speed of 2.5 I get:
uptime (1 stack): 0.106669821334
uptime (2 stacks): 0.0107181021436
uptime (3 stacks): 0.00105830021166
uptime (4 stacks): 0.00010290002058
uptime (5 stacks): 1.360000272e-05
dps: 11.98288
average time between parries: 13.780214707
parry: 0.1814125
parry (no procs) 0.177542657091

This means that the enchant added 17.6 parry rating (after DR) and ~12 dps.

At 250 parry rating with a fast hitting boss (1.5 sec):
uptime (1 stack): 0.0892060178412
uptime (2 stacks): 0.00644790128958
uptime (3 stacks): 0.0004275000855
uptime (4 stacks): 1.10000022e-05
uptime (5 stacks): 2.0000004e-06
dps: 15.4154
average time between parries: 7.62796729115
parry: 0.1966455
parry (no procs) 0.192962893111

Added 16.3 rating (after DR) and ~15 dps. The dps figure is higher here because with lower boss attack speed, more of the stacks will actually get used before expiring. NB, parry rates still vary by 0.5% when you use a 1M sec simulation -> the added parry rates can vary by as much as 50%. In fact, the 16.3 rating here is probably on the high side.

edit: changed parry in the code to the correct values vs lvl 83 mobs

todemax · 09/10/09, 8:43 AM

A quick note. You seem to have used parry values vs. level 80, not a boss mob. And you assume 100% hit chance. Additionally mongoose and berserking seems to be 1 ppm. So I would imagine that the proc rate should be 1.6/60 rather than 0.03.

With 95% hit, 1.6 player attack speed, 1 ppm proc chance, and using boss reduction in parry, I get the following:

150 parry rating, 2.5 boss attack speed:

uptime (1 stack): 0.18574101
uptime (2 stacks): 0.042807917
uptime (3 stacks): 0.01037416
uptime (4 stacks): 0.00168621
uptime (5 stacks): 0.000347161
dps (base): 21.1004406
parry: 0.179874154
parry (no procs) 0.1716

That's 57 parry after DR.

250 parry rating, 1.5 boss attack speed:

uptime (1 stack): 0.13887627
uptime (2 stacks): 0.0217779
uptime (3 stacks): 0.003353574
uptime (4 stacks): 0.000542563
uptime (5 stacks): 0.000109108
dps (base): 26.32868402
parry: 0.190801299
parry (no procs) 0.1859

That's 35 parry rating after DR.

I seem to be getting quite different results than you with my own sheet, and the few comments I had on your simulation doesn't seem to explain this. But anyways thought that a second set of uptimes could be beneficial.

Gruntle · 09/10/09, 9:45 AM

Doh, thanks for that correction, forgot about the lvl 83 effect on parry. Changed it in the code now. I neglected the hit bit since I didn't think it would make much of a difference, but maybe it will. As far as I can see the parry change results in slightly higher uptimes, but nowhere near what you seem to get.

Whether the proc is 1 ppm or not is not known as far as I know, but it's easy enough to change in the code. Maybe all procs are 1 ppm nowadays?

How long simulations are you doing with the sheet?

todemax · 09/10/09, 10:25 AM

100.000 seconds (1 million lines with 0.1s spacing). Treating specials and auto attacks separately. Using 1 ppm should result in a lower overall uptime, so I don't really know what's going on. As I'm using a spreadsheet, I have a rather informative interface, as I can see exactly what's going on, and I haven't found any clear errors. However it is a bit slow so I don't know how it would fare with increased precision. The uptimes doesn't change much between simulations though.

About the 1 ppm. Mongoose, berserking and executioner is treated as 1 ppm by rogues. Mongoose was tested to the extent that it's very likely to be ppm as far as I recall, but whether it's 1 ppm or 1.1 is hard to test. Mongoose was treated as 1.1 ppm for a while, but is now treated as 1 ppm.
So I would say that when a weapon enchant procs somewhere near what it should be as 1 ppm, it's a better guess to assume that it is indeed a 1 ppm effect, rather than 3% proc chance. If someone could auto attack a heroic target dummy for a few hours, with a fast weapon and a slow with Bladeward on, it should be relatively easy to conclude from the combatlog.

Armadeus · 09/10/09, 12:21 PM

Originally Posted by Gruntle

About the uptimes.
If I understand you correctly you're saying that the basic chance of the buff (>0 stacks) being up at any given time is procs/sec (0.033). The fact that the buff can be stacked complicates things a bit, the chance of having exactly one buff stack up becomes:
procs/sec*chance of no additional proc during 10 seconds
The fact that boss parry consumes the buff adds another layer:
procs/sec*chance of no additional proc during 10 seconds*chance of no boss parry with 200 PR(+DR) added

Close... but you are missing yet another layer of complexity here (I did too at first).

The explanation below is not fully correct but it should be sufficient to help you understand. If you want a complete model read the EXTRA STUFF section at the end. There is another level of recursion that makes the formulas harder to understand and you can still get a good estimate without it.

What you are calculating is the chance of getting a stack when you don't parry but there are other cases you are missing.

You need to calculate the chance you will parry each of the bosses swings over the 10 seconds the buff is active. Interestingly enough when you add the chance to parry all of the swings to the chance to not parry the result should be 1.

The case you have:
Case 1
A proc that lasts for 10 seconds with no parry.

Now for the cases you don't have:
Case 2
A proc with a parry on the first boss swing.
Case 3
A proc with a parry on the second boss swing.
Case 4
A proc with a parry on the third boss swing.
Case 5
A proc with a parry on the fourth boss swing.
...

Case 10/b_spd
A proc with a parry on the (10/b_spd) boss swing.

When modeling these swings I use .5, 1.5, 2.5, etc for my boss swings because the the time between a proc and the first boss swing should normalize to half a swing. (there is an equal chance that the proc will happen right after a boss has hit you as well as right before a boss hits you)

Each of these probabilities will add to the up-time of the buff.

Originally Posted by Gruntle

The chance of having exactly 2 stacks is then:
procs/sec*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added

Once again you are only taking into account the chance that you will get a second proc when you do not parry.

The other thing you need to take into account here is that since proc two is dependent on proc 1 you have to involve the probability of proc 1 occurring.

So using the other cases as an example:

Case 1: 1st proc that lasts for 10 seconds with no parry.
In this case the chance of getting a second proc is:

A. No parry of the boss on second proc:
Chance of Case 1*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added

B. Parry of the Boss on first boss attack second proc:
Chance of Case 1*chance one additional proc during 10 seconds*chance of boss parry with on first attack 400 PR(+DR) added

C. Parry of the Boss on second boss attack second proc:
Chance of Case 1*chance one additional proc during 10 seconds*chance of boss parry with on second attack 400 PR(+DR) added

etc... keep going until you reach 10/b_spd boss attacks.

Case 2: 1st proc is consumed on first boss attack.
In this case the chance of getting a second proc is:

A. No parry of the boss on second proc:
Chance of Case 2*chance one additional proc during .5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added

B. Parry of the Boss on first boss attack second proc:
Chance of Case 2*chance one additional proc during .5*b_spd seconds*chance of boss parry with on second attack 400 PR(+DR) added

C. Parry of the Boss on second boss attack second proc:
Chance of Case 2*chance one additional proc during .5*b_spd seconds*chance of boss parry with on second attack 400 PR(+DR) added

etc... keep going until you reach 10/b_spd boss attacks.

Keep going with cases until you have accounted for all of the possible parrys during the first proc.

Rinse and repeat for 3,4,5 etc procs.

As you can see this is a recursive relationship and deriving a formula for it is really nasty. Right now I am setting everything up in an excel spreadsheet one step at a time so I can compare my result with the formula I am trying to derive to make sure I didn't miss anything.

EXTRA STUFF
If you understood what was up above just hang on to that. Once you understand it thoroughly then read this part. There is yet another level of complexity that needs to be taken into account to fully model this scenario properly.

I will take a simple case to demonstrate the idea and extrapolate out from there.

In the case where a second proc is triggered and not consumed during the 10 second up-time should be

Chance of case 1*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added

However, this proc overvalues the uptime because this model assumes there is no possibility for a third proc to occur. If the third proc occurs then you are giving uptime for both the second proc and the third proc. To accurately model this we need to take into account the chance that the next proc WILL NOT occur.

Our formula then becomes:
Chance of Case 1*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

Note that the "Chance of NO proc during 10 seconds" is the same as (1-Chance of a proc during 10 seconds)

So for total chance to have a second proc last the entire 10 seconds we would calculate:

Chance of Case 1*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

plus

Chance of Case 2*chance one additional proc during .5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

plus

Chance of Case 3*chance one additional proc during 1.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

plus

Chance of Case 4*chance one additional proc during 2.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

.....

plus

Chance of Case n*chance one additional proc during 10-.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during 10 seconds.

For a further example the calculation of a second proc that is consumed on the first boss attack the calculation is:

Chance of Case 1*chance one additional proc during 10 seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during .5*b_spd seconds.

plus

Chance of Case 2*chance one additional proc during .5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during .5*b_spd seconds.

plus

Chance of Case 3*chance one additional proc during 1.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during .5*b_spd seconds.

plus

Chance of Case 4*chance one additional proc during 2.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during .5*b_spd seconds.

.....

plus

Chance of Case n*chance one additional proc during 10-.5*b_spd seconds*chance of no boss parry with 400 PR(+DR) added*chance of NO proc during .5*b_spd seconds.

Like I said, it's a recursive formula and it is nasty.

todemax · 09/10/09, 1:29 PM

This post, and the thread in general, could be relevant for the ones of you working hard with uptime models.

http://elitistjerks.com/f31/t20747-a...on/#post621369

A varying parry rate changes things a bit, but I thought that you might find it useful.