It looks like it may be the same case, yes.
And a few others I'm noticing in my parser. It's split about 50/50 between those that are > 100 and < 100.
Relooking at the code, I don't think it was REALLY acting like a slow... I'll paste a couple snippets for your enjoyment.
Code:
int haste = 0;
int haset2 = 0;
if (buff[i].effect == SE_AttackSpeed) {
int32 value = buff[i].effectMaxVal;
if (value > 100 && value-100 > haste2)
haste += value-100;
}
}
if (buff[i].effect == SE_AttackSpeed2) {
int32 value = buff[i].effectMaxVal;
if (value > 100 && value-100 > haste2)
haste2 += value-100;
}
}
return (100 + haste + haste2)
Attackspeed2 is overhaste. So it's not giving you giving you anything if it's lower than 100.
But in the slow code...
Code:
int32 slow = 100;
if (buff[i].effect == SE_AttackSpeed) {
int32 value = buff[i].effectMaxVal;
if (value < 100) {
do alot of stuff that isn't important here
}
}
return slow;
There is no statement checking for an SE_ATTACKSPEED2 here, so the over haste effect < 100 just does nothing. Nothing. DO YOU HEAR ME EYATE NOTHING!
NOTHING! Your DPS gain is all in your mind, or lucky hits while the couple tick effect happens to be on!!!!!!!!!!!
All that's needed is to add 100 to overhaste effects that aren't there yet, and all is well in the world.
PS: No that's not 100% the real code, and yes parts of the base ARE that crappy and inconsistent. We have better things to do then refactor it all.