[Melee Combat] Riddle me this - Parry Mechanics

• Disquette · 08/15/07, 5:03 PM

So I buckled down and did about 5700 seconds worth of testing on a blasted lands mob (level doesn't matter). I used a 3.6 speed 2 hander, and did a /combatlog to capture the results. The result, with respect to parry effect on the swing timer, is shown in the graph below.

Here is the raw data file, manipulated to get the information for that graph:
http://www.discofiend.com/wow/ShamanCalc/Parry_Data.xls

So, compare that data (275 data points) against the statement in wowwiki here:

Formulas:Parry - WoWWiki, the Warcraft wiki

When a player Parries, their next normal melee swing becomes a counter-attack sped up by as much as 50%. There does not appear to be a discernible pattern which determines the amount of swing-time reduction a player receives, and it may indeed be possible for the attack to be sped up even faster depending on the circumstance.

It was previously posted that a Parry reduced swing-time by a flat amount of 40% and could not reduce it to less than 20%. Combat log parsing (taking server latency into account) shows this does not appear to be the case.

...

The above shows a timer reduction range between 14% and 50% and does not abide by the 40/20 rule. With more extensive combat log parsing, timer reductions do not appear to line up to set numbers but instead cover the entire range. It appears based on server delay and the time the Parry occurs -- in many cases, it appears the counter-attack occurs about 1 second after the Parry (though this does not always hold true, either).

To me, it seems like there is a pretty discernable pattern of a constant 40 to 45% next-swing reduction, but maybe my eyes deceive me.

Possible problems:

1) Lag - obviously if lag weren't an issue, we would never have more than 3.6 seconds left between auto-attacks. We do, however (hence the negative numbers on the x axis). This confounds many things.

2) There are a few really weird points on the far right, where the swing should be reduced down to about 2 seconds (a parry right after an auto-attack), but instead it's reducing the swing timer far more. I'm not sure if these outliers are lag, or some other odd mechanic.

3) The curve appears to flatten between 0.5 and 2 seconds on the x axis. Is this a fluke within the data set, or something that is being affected by actual game mechanics?

If anyone else is willing to do combat log generation, I'd be really appreciative. The more data the better, and spending over 1.5 hours doing nothing but dropping totems started to wear on me. On the positive side, at least I finally had a use for my gorehowl.

Spades · 08/15/07, 5:09 PM

Originally Posted by Disquette

3) The curve appears to flatten between 0.5 and 2 seconds on the x axis. Is this a fluke within the data set, or something that is being affected by actual game mechanics?

I'm going to guess this is because the game does a check to see how much time is left on your swing before it gives you a shortened time, and 2s is the cutoff for higher returns.

Do you just want a combat log? I can take my paladin (also with a gorehowl) out there and beat on things with Light judged for hours if you like.

• Disquette · 08/15/07, 5:14 PM

That would be fantastic!

◊ Lord BEEF · 08/15/07, 6:54 PM

Thank you for doing the extremely boring to provide us with helpful information!

Spades · 08/15/07, 9:33 PM

Check your e-mail Disq, my server came up early and I got a little under 3 hours (I think) of swinging in. An orc warrior was camping me so I quit. :|

• Disquette · 08/15/07, 10:09 PM

Superb! I'll do the analysis tomorrow, I can't thank you enough. :-)

• Disquette · 08/16/07, 11:13 AM

Alright, thanks to spades's willingness to do the mindnumbing work, I think we can confirm some of how this works. Check out the graph from his combat log (much cleaner than mine in terms of lag):

So, what we have here is actually really close to the original statement regarding how parry works. In other words, my understanding of it was pretty darn wrong. I thought I was going to find something new, but the data doesn't bear that out:

When parry gets a % reduction, the swing timer is reduced by 40% of the orginal weapon speed, except in the event that it would take the weapon speed faster than 20% of the total weapon speed. That's why the slope of the line before the flat part is 45 degrees. Each one of those points is 3.6 (weapon speed) * 40% = 1.44 faster than the swing otherwise would be.

We see the cap at .72 seconds (20% of the weapon speed).

The interesting parts, which were what threw me to my initial suspicion of the parry hypothesis being wrong is that stuff that you see when the non-parry swing timer is already lower than 20% of the original weapon speed (which is why i assumed the 20% cap hypothesis had to be incorrect).

Apparently at that point the game realizes that you can't cap a swing at a longer time than it should take, and a new rule of parry mechanics takes over which simply says "hey, parry can't reduce you below 20%, so just let the swing land like it's supposed to".

So, there we have it, in a neat little bundle - The original theory was right, and I feel a bit dumb. But at least now I'm convinced of the original theory. I suppose someone could try to figure out why there are trace bands of extra haste in little bits, but the overall picture is pretty solid now imo.

The next step is to verify what happens parry wise when dual wielding - is it next swing haste, or always the main hand?

Again, super big thanks to Spades and his sacrifice at the hands of a warrior who thought it would be cool to gank someone doing testing :-p It made the graphs extremely easy to read.

Spades · 08/16/07, 12:52 PM

My pleasure. I blame the trace bits of haste on my fiddling about with other programs and causing lag spikes, including one very noticeable time where I tried to open a second instance of WoW (bad idea) and locked everything up for about seven seconds.

Re: dualwield testing, I think your shaman would be better suited to this than my rogue, unless I can find a paladin willing to hang around for a few hours in the Blasted Lands and autoattack to keep Light up while healing me occasionally.

• Disquette · 08/16/07, 1:03 PM

No doubt, I'll use my shaman for that. I'm jealous of your incredibly consistent ping times, though, I'll admit. I have no idea if your average ping is slower or faster than mine, but it's incredibly consistent.

Spades · 08/16/07, 1:08 PM

They make for a pretty graph, at least. Doesn't help me with "you must be behind your target" errors in PvP anyway. :| Good luck with the test.

Rezarel · 08/16/07, 1:12 PM

I've got a large quantity of dual wielding Blasted Lands data I could send you when I get home this evening. It's mostly with 5/5 Flurry, but a few runs are without it.

• songster · 08/16/07, 1:15 PM

Hold on, what's going on at the extreme right hand side of the graph there? You have a second line of data points, with much more extreme reduction. Looks to me like this is the line you get when you have two parries in quick succession. The line is about 0.8 - 0.9 below the main line, which is what you'd expect from two successive 40% reductions.

Could you check the logs to see if this is indeed the case, and that these points are down to double parries?

The interesting point is that this line isn't capped at 20% - the majority of the points are at less than .72 seconds on the y axis. So that's why parry streaks can insta-gib the main tank :-)

That suggests that there's a second cap to be reached there, at 4% (20% of 20%). In this case, that would mean that double parries can't reduce your swing time below 0.144 seconds. Interestingly, there's a pair of points at around (1.75, 0.3ish) that could be evidence for this. I would predict that these points come from double parries which got floored out at the second cap.

Soultroll · 08/16/07, 1:38 PM

@ Disquette: Please excuse my slight change in topic here, but I was just curious as to what program you use to graph your data. I'm compiling similar data on mace stuns and different procs and I really like how your data is output. I tried Googling to find some things, but I just figured I'd ask you as well. Thanks in advance!

• Disquette · 08/16/07, 1:41 PM

Rezarel - if it's easy to tell what hand is what (MH/OH), I'd be happy to look at your data. mail to disco at discofiend dotcom please

Songster - interesting observation - I'll go back through spades's log to see if I can confirm your theory.

[edit] I went back through the logs - there were no double parries like that preceding the super-hasted attack. Something consistent is happening, however, because each of the 15 instances of superhaste were a speed up between 2.345 and 2.477 seconds. That's a *really* tight band, considering lag effects. The next closest speed up to the 2.345 was 1.648 seconds, so I'd agree that there is something that triggers them. I've uploaded the excel file in case anyone wants to check them out.

Soultroll - I took the combat log in text format, opened it with MS Excel, and used the built in charting features (the graph type is "x y scatter", or something like that). I'm not sure, but I'd guess that Open Office has similar capabilities.

Soultroll · 08/16/07, 2:18 PM

Alright, thanks Disquette! I'm gonna give it a shot now.

• songster · 08/16/07, 3:34 PM

Hmm. Maybe if you parry a swing when there's less than 20% on the swing timer, it doesn't just drop the parry, but hastes the *next* attack instead?

That would then appear in the logs as a weapon swing of 2.16 seconds without any parry occurring during the swing. If I understand what you're doing correctly, you wouldn't see these, as you're only looking at swing intervals which do contain a parry.

However, if you got a parry-hasted swing immediately following one of these "saved" parry charges, you might get a double parry effect. That is, the swing would be hasted twice even though only one parry occurs during the swing itself. The total amount of haste on such a double-parry should be 2.304 seconds, which is very close to your observed values.

To confirm this, could you check:

a) Whether there are any "hasted" swings (i.e. swings at an interval of 2.16 seconds) which do not contain a parry.

b) If there are, do they always follow a "wasted" parry (i.e. a parry that occurs within the 20% cap zone)

c) Whether the "super-hasted" swings always follow a "wasted" parry.

Edit: Hang on, just noticed the other sheets in the workbook - I'll check myself

Edit2: And the answer is that I lack the brain power to work out what's going on. I tried to have a look at the swing times for hits immediately subsequent to "wasted" parries, but couldn't make out a pattern. There were hits at 3.6 seconds, 2.6 and even 4.6 seconds. There also seemed no obvious pattern of "wasted" parries immediately preceding the super-hasted swings. So. A mystery.

• Disquette · 08/16/07, 4:06 PM

Originally Posted by songster

How irritating, that was *such* a shiny theory :-(

Yeah, we've had a few of those that looked really promising for flurry mechanics as well, which never seem to hold up under complete scrutiny. There might be some new theories out there (or old ones) that are right, but absent some incredibly consistent ping responses like spades's, it's very hard to even understand what's happening, much less how to interpret it.

Spades · 08/16/07, 5:05 PM

Since I appear to be blessed by God with an insanely stable (ping wise) internet connection, is there anything else I could do to help you guys out? I don't have access to a shaman of appropriate level, but maybe I could use the PTR or "borrow" someone else's.

• Disquette · 08/16/07, 5:18 PM

To be objective, maybe yours is the norm, and it's just that mine is super sucky ;-) In any case, if a pally or rogue would be able to do some testing, I'll let you know, but you've already been incredibly helpful, so hopefully no more multi-hour test sessions will be necessary.

Rezarel · 08/24/07, 4:26 PM

I finally got around to parsing some of my test runs. The lag's pretty bad -- this was off the 2.2 PTR after all -- but I've got a lot of data. It looks like main hand attacks get the parry haste, and off hand attacks do not.

These are using two 2.7 speed swords.
MH: [Protector's Sword]
OH: [Protector's Sword]

Althir · 08/24/07, 4:51 PM

What are the practical implications regarding Parry-produced haste? Will it be worth the ridiculous item budget cost for tanks, to help with rage generation? Obviously parry can account for tanks getting smashed by boss mobs, but how relevant is the mechanic working the other way?

• Disquette · 08/24/07, 5:01 PM

Originally Posted by Rezarel

I finally got around to parsing some of my test runs. The lag's pretty bad -- this was off the 2.2 PTR after all -- but I've got a lot of data. It looks like main hand attacks get the parry haste, and off hand attacks do not.

These are using two 2.7 speed swords.
MH: [Protector's Sword]
OH: [Protector's Sword]

Awesome work - thanks man!

Fixation · 08/24/07, 6:28 PM

Originally Posted by Althir