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.
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.
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.
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.
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.
"Existence has no pattern save what we imagine after staring at it for too long."
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.
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.
@ 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!
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.
 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.