[DEV1234]Lift the delay/haste cap

[hiko]

yes give DRK 100% haste with their new JA that inhibit TP gain (since with100% haste the 2sec delay after WS will be a bigger lost in dmg than not wsing)

[Elexia]

yes give DRK 100% haste with their new JA that inhibit TP gain (since with100% haste the 2sec delay after WS will be a bigger lost in dmg than not wsing)

This would actually be a good adjustment for DRK.

[Cream_Soda]

yes give DRK 100% haste with their new JA that inhibit TP gain (since with100% haste the 2sec delay after WS will be a bigger lost in dmg than not wsing)

Not really, the mob would be dead far before you ever even get the chance to consider ws'ing, lol. 100% haste is infinite attacks.

You'd spend more time engaging and disengaging than doing anything else, lol

[RabidSquirrel]

Not really, the mob would be dead far before you ever even get the chance to consider ws'ing, lol. 100% haste is infinite attacks.

You'd spend more time engaging and disengaging than doing anything else, lol

I'd be willing to bet 100% isn't infinite. It all depends on if they allow more than one attack via auto-attack per frame, which I doubt they do.

[CrystalWeapon]

I'd be willing to bet 100% isn't infinite. It all depends on if they allow more than one attack via auto-attack per frame, which I doubt they do.

100% haste would indeed be infinite. The % is subtracted from your delay. If you take say 6 seconds to swing, at 80% haste you would take 1.2 seconds to swing. Which would be as stated earlier 5x your normal actions at 80% haste. At 90% you would take 0.6 seconds to swing. 10x your normal actions. The haste formula is one that approaches infinity the closer you get to 100.

If you took 0 seconds to swing it would be nonstop actions and the mob would die in an instant. If you imposed a restriction on how often an autoattack can initiate say 0.1 seconds is the lowest it could possibly go, then it's not truely 100%. For the 6 second swing example you would only have aprox. 98.3% haste, so it would never truely be 100%.

[Atomic_Skull]

100% haste would indeed be infinite. The % is subtracted from your delay. If you take say 6 seconds to swing, at 80% haste you would take 1.2 seconds to swing. Which would be as stated earlier 5x your normal actions at 80% haste. At 90% you would take 0.6 seconds to swing. 10x your normal actions. The haste formula is one that approaches infinity the closer you get to 100.

If you took 0 seconds to swing it would be nonstop actions and the mob would die in an instant. If you imposed a restriction on how often an autoattack can initiate say 0.1 seconds is the lowest it could possibly go, then it's not truely 100%. For the 6 second swing example you would only have aprox. 98.3% haste, so it would never truely be 100%.

If it wasn't capped somewhere what would happen is that 100% haste would cause a literal "divide by zero" situation. Whenever someone achieved 100% haste and attacked something the server software would lock up. I think what happened was that the whole issue went unnoticed until people started getting dangerously close to 100% haste and they went in with the intention of just capping it at 99% or something. But once they took a good look at it they said "holy %#&@ that's overpowered" and implemented an 80% cap.

[CrystalWeapon]

If it wasn't capped somewhere what would happen is that 100% haste would cause a literal "divide by zero" situation. Whenever someone achieved 100% haste and attacked something the server software would lock up. I think what happened was that the whole issue went unnoticed until people started getting dangerously close to 100% haste and they went in with the intention of just capping it at 99% or something. But once they took a good look at it they said "holy %#&@ that's overpowered" and implemented an 80% cap.

It depends on the number of attacks that you would need to process before the mob died, how many individuals are doing it at once, and how many people are nearby to see the damage. It would be the sheer number of attacks in quick succession that would have to be broadcast all at once to all individuals within range that would cause anything from massive lag to a complete network failure.

Even if the cap was 100%, haste would never truely be 100%. Like an infinite loop with no delays, it would always be limited by the processor that's computing the data. It's not as bad as a divide by zero error, but it's still pretty damn bad because of the fact that all the data has to be sent out exponentially to all individuals within range. I'd compare it to running several GOTO 10 programs on one server at the same time that all broadcast data across a network.

Note: I'm not arguing with you. I just felt like putting in my two cents because I'm a nerdy code monkey. Tech and programming talk makes me geek out.