Quote:
|
Originally Posted by Iagoe
I changed my assumptions around a bit. Assuming that Verant didn't use any of the rounding functions available in C++ and just used integer math, I believe this is the table you would get:
Weapon Haste New With
delay needed delay Shissar
40 91 20 25%
35 95 17 29%
30 88 15 22%
29 94 14 28%
28 87 14 21%
27 93 13 27%
26 86 13 20%
25 93 12 27%
24 85 12 19%
23 92 11 26%
22 84 11 18%
21 92 10 26%
20 82 10 16%
19 91 9 25%
18 81 9 15%
17 90 8 24%
16 78 8 12%
15 88 7 22%
14 76 7 10%
13 86 6 20%
Most interesting is the 16 delay value. That implys that a level 60 monk with his epic can reach maximum haste on his fists with just shissar and a hangman's noose.
I'm assuming here that haste is stored as an integer and the haste modified weapon delay is always an integer. My guess for the formula to calculate new haste is:
INT((100 * delay) / (100 + haste))
Where:
INT is a function that drops all decimals places.
delay is the weapon's unmodified delay
haste is the haste value as an integer, 0 to 100.
Again, I'm not sure if this is how EQ is written. It would be an easy way to do it. Certainly EQ could store all values as floating point numbers and use a proper round function for better accuracy. I'm simply proposing that if EQ uses just integer math then there really isn't a need for 40% haste items at high level.
Anyone have more information on what the haste cap is below level 60?
Yours in science,
Iagoe the gnumber gnowing gnome.
|
Don't know what haste has been mentioned/programmed before, but there we are - haste equation.
I'm pretty sure that slow will work with negative percents being added (subtracting percents for those who forget how to add a negative), and that the equation should hold up the same way.
The guy has a suitable formula, and no complaints or outliers have been found, so I think he hit the nail on the head. I assume we'll have 1 or 2 delay errors, but I'm willing to live with that.
Threaded Mode
