[Grummet]

I am not sure I am following the table you posted. I understand the first column is the weapon delay, but the second the total haste, the third the weapon delay after haste, and the fourth the item haste needed on top of shissar? Assuming that, his data is incorrect.

Regardless, from my own extensive parsing and others (namely monks at monkly-business), the guy's equation is incorrect. Using it, for example a 40 haste item on a 16 delay weapon, you would get a delay of 11.42, rounding to 11, which is incorrect. The delay, as calcuated out, should be 12.8.

The haste percentage is actually run a counterintuitive way. 100% haste is what is needed to halve the delay. Based off that, then you can easily make a calculation for the delay, one which has been held up in actual parsing. The error I've noted across a variety of weapons is only .4, but usually it's right on or .1; I attribute this to not understanding how the game rounds the numbers.

Hasted Dly = WeapDLY - ((WeapDLY/2)*PercentHaste)

I am not entirely sure where the INT value should be applied, or even if it should at all. There is no reason why the program cannot handle tenths of a delay, is there? Regardless, I feel confident that that equation will hold up under testing within a small error (for any possible rounding, only). Try it... to get a slow, merely use a negative value for percent haste, and that will yield the necessary increase in speed. Coding wise, you need to just make sure there is a trigger for spell haste to be bypassed during the duration of a slow if a slow lands. Of course, that does necessitate an accurate delay for every mob in the database, nothing which a dedicate core of parsers can't find.

Grummet