Yes, I have looked at it some and you may not like the answer much. To be blunt and to the point, the calculators out there have some serious flaws out there for figuring some of the base speeds of using different weapon with certain character to start off with, much less when they are using a special skill like Zeal.
The game uses primarily data from animdata.d2 and certain IAS values for computing what frames to end up displaying (and from that is what you end up using to figure the frames per attack). The problem is that in some cases the data from animdata.d2 does not correctly match up with what is actually happening in the game. The formula that is typically used for figuring the frames per attack is
Frames = {256*(Base + 1)/[(100 + EIAS)*256/100]} - 1
EIAS = IAS/(1+IAS/120) - WSM + SIAS
which was derived emperically along with the Base speeds of different characters using a WSM=0 and IAS=0. From the information that was gained from others that looked at some of the animation routines (like Hammerman) and from decoding the animdata.d2 file, some of the factors were found to be actually the following:
the (Base+1) is FramesPerDirection factor from the animdata.d2 file.
the second 256 foctor in the first formula is actually the AnimationSpeed factor and may not always have a 256 value.
This would make the formulas more correctly be
Frames = {256*(FramesPerDirection)/[(100 + EIAS)*AnimationSpeed/100]} - 1
EIAS = IAS/(1+IAS/120) - WSM + SIAS
Now for the bad part.
A sorceress using a weapon like a sword is using animation type 1hs. From the empirically measured rates this is a 17 frame action. But in the animdata.d2 file we find
CofName_FramesPerDirection_AnimationSpeed_0_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19
SOA11HS_20_________________256____________0_0_0_0_0_0_0_0_0_0_0__0__1__0__0__0__0__0__0__0
SOA21HS_20_________________256____________0_0_0_0_0_0_0_0_0_0_0__0__1__0__0__0__0__0__0__0
the other trailing stuff is for when I get to the Zeal usage
The paladins on the other hand is normally listed as having a 14 frame 1hs attack and has his data like this.
CofName_FramesPerDirection_AnimationSpeed_0_1_2_3_4_5_6_7_8_9_10_11_12_13_14
PAA11HS_15_________________256____________0_0_0_0_0_0_0_1_0_0_0__0__0__0__0
PAA21HS_15_________________256____________0_0_0_0_0_0_0_1_0_0_0__0__0__0__0
If you run the numbers the paladins attack will come up correctly, but the sorceress will end up with a 19 frame base attack instead of the 17 frames that can be measured. There is something extra being done in the DLLs to modify either the EIAS value or the AnimationSpeed for some of the characters based on their attack mode. An early look at this was just started at the Phrozen Keep here (about a month after I first noticed the problem).
http://phrozenkeep.it-point.com/forum/view...e76c1704a61bcd9
I only did a good look at three characters at this point; the barbarian, amazon and sorceress. All the barabarian animations seem to match up correctly accross all types of actions. The amazon and sorceress match up for their casting and missile usage animations. But neither of them match correctly for any of their melee animations. It is worth noting to other that have not had a chance to dig through the files that when say an amazon is using a javelin that the same animation is used for both the melee and the throwing of the javelin. Considering that the frames measure out to be 12 and 15 respectively points to how much of an hidden adjustment is being done.
Now for the Zeal aspect. The zeal skill uses a 100% rollback of the animtion counter to do the repeated portions of the strikes. The rollback happens when the game gets to or past the frame on the action that is designated as the action frame for that attack. In the above listing that is what all those trailing 0's and 1's are for; the 1's indicate to the game that the melee attack is to take place at that point in the action. For a paladins 1hs attack this point is at what was empirically derived for the zeal repeat animation factor. For a sorceress the attack frame is considerably latter in the animation (overall and in realative proportion to the total length). But due to not having the correct factors to apply to determine what the actual animations lengths are it is hard to pin down an exact speed for this and in particular just what the IAS breakpoints are going to end up being.
While I had tried some quick 'kludge' factors in the formulas (a hidden SIAS modifier, a percent scaled EIAS and a rescaled AnimationSpeed) they all fell apart the farther I got from WSM=0 and IAS=0 when doing the testing. The best fit came from a hidden SIAS setting, but even that was not too good (off by about 30% at one point in the testing). And the standard formula fared the worst by the way.
