Calculating the avoidance value of expertise

[Serv]

Hopefully i won't stress this massive nerdery any further. So this whole bunch of numbers is your model for expertise evaluation against a single mob.
But what if the really really really worst case comes into play and 2 or 3 targets including a boss are parrying a HotR?

[tlitp]

irrelevant; PHs are computed on a per-target basis

[theckhd]

there are three groups of double-parry opportunities : AA+HV, HotR+HV, Reck+HV (your simplifying hypothesis sounds about right, though); however, neither one can lead to a double-parry event - a trigger that isn't successful will effectively nullify any contribution of HV; there is only one case where double-parry events are possible, a Reck proc ((AA OR HV) AND (Reck OR HV))

basically, the math was fine, while the model itself was a bit flawed :p

Well crap. I got so caught up in the probability that I forgot to think. So we can scratch out DPE's outside of Reckoning.

Reckoning should obey similar statistics though. There are four situations, as you noted:
AA parried, Reck parried
AA parried, Reck connects, HV parried
AA connects, HV parried; Reck Parried
AA connects, HV parried; Reck connects, HV parried.

So there's a p^2 chance for the first, a qp^2 chance of the second and third, and p^2*q^2 of the fourth. Or p^2 * (1+q+q^2) total for one of these 4 possibilities, every time we get a regular auto-attack. That happens 0.1*Na/2 times, for a net probability of
(N-2)/20 * p^2 * (1+q+q^2).

For N=6, p=0.075, that's 3/20*0.01564, or 0.0023. Much smaller than the 0.0169 we got for (mythical) DPE's. Using p=0.06741 gives us 0.0019, for a diff of 0.0004.

DTPS reduction then works out to be 0.144 * ( (26.3k * 0.0194) + (29.4k * 0.0004) + (27.4k * 0.0018) ) = 82.3, or 3.5x as good as dodge.

Worst-case scenario works out to 124.7 DTPS, 5.35x as good as dodge.

So a slight reduction of the numbers, but still solidly ahead. Now I have to figure out how to go back and work this all into that monstrosity.

[theckhd]

Hopefully i won't stress this massive nerdery any further. So this whole bunch of numbers is your model for expertise evaluation against a single mob.
But what if the really really really worst case comes into play and 2 or 3 targets including a boss are parrying a HotR?

If you're tab-targeting, and we assume you spend equal time meleeing each mob, then it's irrelevant.

If you're just attacking one target, and the only thing the other targets will parry is HotR, expertise will become less effective, because N is smaller for those extra two mobs (they're receiving fewer parryable attacks per second). My rough estimate is that it would be reduced in effectiveness against the secondary targets to about 62% of it's single-target value.
(2 attacks every 6 seconds = 0.3333, as compared to 0.5342 for auto-attack and HotR together, 0.3333/0.5342=0.6239=62.39%)
Oops. Try 16%, see below.

[Meloree]

If you're just attacking one target, and the only thing the other targets will parry is HotR, expertise will become less effective, because N is smaller for those extra two mobs (they're receiving fewer parryable attacks per second). My rough estimate is that it would be reduced in effectiveness against the secondary targets to about 62% of it's single-target value.
(2 attacks every 6 seconds = 0.3333, as compared to 0.5342 for auto-attack and HotR together, 0.3333/0.5342=0.6239=62.39%)

Unless I totally misunderstand the methodology, 0.5342 is not "attacks per second" but "seconds per attack", so 2 attacks every 6 seconds is surely 3.0? This would make expertise approximately 16% as effective against secondary targets at reducing damage intake.

--
Meloree, <Edge>, Garona

[theckhd]

Unless I totally misunderstand the methodology, 0.5342 is not "attacks per second" but "seconds per attack", so 2 attacks every 6 seconds is surely 3.0? This would make expertise approximately 16% as effective against secondary targets at reducing damage intake.

Er, yes... today is clearly not my day for simple math.

0.5342 seconds between attacks, vs 3 seconds for the secondary targets, so 16%.

[majiben]

Actually, what is the value of turning off auto attack and only using HotR to keep the SoV DoT up with a 2.6 speed weapon and it's threat loss?

Also is there any modeling planned with 1-2 other tanks also attacking from the front?

[snoweagle]

Actually, what is the value of turning off auto attack and only using HotR to keep the SoV DoT up with a 2.6 speed weapon and it's threat loss?

(edit for clarity)

would the baked in autoattack for HotR/Judgement be avoidable via macro?

Code: Select all

/cast judge/hotr
/'baked in' start autoattack
/stopautoattack

Does an autoattack sneak its way in before the last line of combat processing?

[theckhd]

Actually, what is the value of turning off auto attack and only using HotR to keep the SoV DoT up with a 2.6 speed weapon and it's threat loss?

Also is there any modeling planned with 1-2 other tanks also attacking from the front?

Well, if you're turning off auto-attack, the weapon speed is irrelevant to the parry-haste calculations. So it would drop to 16%, just like it would for any other mob that isn't being auto-attacked.

The threat gain of using a 2.6 speed weapon wouldn't offset the massive threat loss of turning off auto-attacks though. You gain about 200 TPS by switching to a slower weapon of equal ilvl, but our auto-attacks are a significant portion of our threat, upwards of 1000 TPS. I doubt that it's worth the trade-off, especially given that we have so much expertise on our current gear to help reduce parry-haste damage intake already.

I hadn't planned on adding more tanks, but it's something I could probably do pretty easily. Extra tanks would just add a constant number of parryable attacks per second into the boss parryhaste equation, but since they aren't parrying the boss's attacks themselves they wouldn't see the recursive hasting that the person currently tanking sees.

[Candiru]

If only blizzard hadn't prevent hunters from attacking while using deterrence.

We could have had two people with 100% parry attacking each other incredibly quickly.l Would be a very good way to gather data on precisely how parry-haste works.

[Panzerdin]

We already know exactly how parry haste works. See http://www.wowwiki.com/Formulas:Parry

[Candiru]

Right, but that might not be as correct as we think it is!

Does parrying have a strange relationship with swing time then, where parrying an attack early in the swing such that the 40% of Weapon_Speed reduction takes it to exactly 20% remaining results in fast attacks, but parrying just after that results in no parry-haste at all?

EG:
Timer 100%, parry to 60%.
Timer on 61% parry to 21%
Timer on 59%, parry to 59%?

The article isn't clear if parries at 59% reduce swing time to 20%, or simply do nothing. If they do nothing as it implies, then parries only have an effect on swing speed 40% of the time. (Or possibly a double parry at 100%, if it reduces it to 20%. Can this happen with reckoning?)

You could use a swing timer mod, and only auto-attack and HOTR when the boss has less than 60% of his swing timer left. That way there would be no downside from parries. With a suitable weapon speed you might even be able to loose only 40% of your autoattacks this way.

[theckhd]

The parry mechanics were tested thoroughly in the link I posted upthread:
http://elitistjerks.com/f31/t15257-mele ... _mechanics
I also mentioned it in the combinatorics spike dtps post last page.

A parry at 59% would reduced the swing timer to 20%, as would any parry occurring with less than 59% on the swing timer. Parries that occur at 20% or less left on the swing timer do nothing.

[Candiru]

After reading that thread I am pretty sure we don't know fully how the parry mechanic is implemented. There are some strange "ultra-fast" swings when a parry happens very close to the start of a swing time which were never explained.

[theckhd]

By the way, I just overhauled the spike damage post and updated it to reflect DPE's properly. I also corrected a factor of two error in my spike DPS calculation. Please read it over and see if we can identify any more errors in the methodology.

The files I used to generate the values are:
ppks.m
calc_expertise_spike.m