Whirlwind Breakpoints

[Ruvanal]

Zath:

delay = a1_frames*256 / ((weapon ias+wsm+100)*anim speed/100) = 14.61

Looking at Hammerman's breakpoint table, a "delay" of 14.61 would correspond to a "real delay" of 8 frames. The sequence of events in one WW will therefore be...

It should be...
delay = a1_frames*256 / ((weapon ias+wsm+100)*anim speed/100) = 14 (no fractions)

From Hammermans breakpoint table this 14 would yield a "real delay" of 6 frames.

The game in almost all cases will be using integer calculations (data storage and processing time are major reasons). In integer calculations there will not be any fractional value stored at any point of the calcualtions.

1): What is one unit of WW? Or in other words, how can I tell when the WW sequences in the above samples will end and grant me two more free hits with more mana consumed?

You have sort of answered your own question. Basically it is "one unit of WW" if you would not have needed to click again to have continued attacking. Try it some in a safe area without any mana leech to get the feel for it. Normally it not too long of a distance that you will travel unless you accidently click on a fleeing target (oh, what fun Whirlwinding after a fallen across the Stoney Fields).

2): Is it true that there is a cap on hits per WW at "weapon range +3"? Or is there a cap at all?

Answered for you by Tharn in this thread.
http://www.theamazonbasin.com/d2/forums/in...ST&f=54&t=25873

5): Is there some point along the formula where I should round up or down?

Yes, as I mentioned the game is using integer calculations. Here is the "delay" calculation that I used in a spreadsheet for example.

Code:

=INT(B$2*256/INT(($A3+100)*256/100))

where B$2 is a1_frames and $A3 is the WIAS-WSM factor.

3): How do I read Hammerman's breakpoint table for "delay" to "real delay" conversion? If the "delay" is 5, should I go for 4 frame or 6 frame "real delay"?

4): Why are "real delay" values always even? Is this just how it is coded in game, or have the odd values been omitted?

This appears to be one of the numerous internal tables that are in the DLLs. As such they can potentially be very arbitrary. The value in the "real delay" would be used if your "calculated delay" is equal to or greater than the "tables delay" value. That is why the 14 delay is translated to a "real delay" of 6 and not an 8.

Here is an additional spreadsheet calcualtion for those that may be intereseted in checking my earlier tables.

Code:

=IF(B3<12,4,IF(B3<15,6,IF(B3<18,8,IF(B3<20,10,IF(B3<23,12,IF(B3<26,14,16))))))

B3 is a lookup of the cell output of the previous formula. This calculation was translating the "delay" value to the "real delay" in frames.