Comments on: Stopcasting, Quartz, and Patch 2.3

By: The AutoHotKey Thread - Elitist Jerks

The AutoHotKey Thread - Elitist Jerks — Sun, 18 May 2008 19:03:14 +0000

[...] Before any of you use this to quick-mash your dps button, you may want to take a look at this post: Stopcasting, Quartz, and Patch 2.3 | Altitis [...]

By: The new 2.3 GCD and Stopcasting on Live | Altitis

The new 2.3 GCD and Stopcasting on Live | Altitis — Sat, 17 Nov 2007 13:45:47 +0000

[...] anticipated previously, the new GCD mechanism which prevents any command to be sent to the server while the client is [...]

By: Gwaendar

Gwaendar — Tue, 06 Nov 2007 11:09:00 +0000

Scratch that, you’d have to hit at 2999ms earlier to cause a problem, at which point you’ll get denied until 3199ms, hit again and cast starts at 3300ms. New mechanism, no additional gap. Where it can cause issues is if you start washing way too early while lag is growing.

By: Gwaendar

Gwaendar — Tue, 06 Nov 2007 10:51:00 +0000

The problem arises from recasting just too early. Currently the client will allow a new cast attempt to be sent to the server a split second after its own cast count has ended, at 3200ms in your example. Mashing has no influence but in fact allows you to make sure you’re as close to 3200 as humanly possible, so your next cast starts indeed at 3300ms.
But if you hit at 3199, your client will think it’s under GCD until 3399ms, so you can hit your next cast at 3400ms and get it accepted at 3500ms. For tankadins trying to keep Holy Shield up permantently for instance, that’s actually doubling the time gap during which they are crushable.

By: Anonymous

Anonymous — Tue, 06 Nov 2007 10:19:00 +0000

I don't see the negative difference of influence lag has on casting to the way things are handled now.
As far as I understand it your next cast is delayed by your latency times two - 1ms. The way things are handled now, your cast is always delayed by your latency times two.

Assuming 100ms constant latency and 3 second cast:
(+ 0 ms) You send cast request
(+ 100 ms) Server receives request, starts casting
(+ 200 ms) Client receives confirmation, starts casting
(+ 3100 ms) Server finishes casting, client still shows castbar
(+ 3200 ms) Client finishes casting, allows next cast
(+ 3300 ms) Server starts next cast

Which means, your 3 second cast took 3.2 seconds (twice your latency) to finish and there's a gap of 200ms between your casts.

With the new casting system even the worst case scenario (in 2.3) shows a better performance than the current system does.

By: Gwaendar

Gwaendar — Mon, 05 Nov 2007 17:41:00 +0000

Sadly this won't happen, as Slouken has explicitely stated in response to the same concerns:

The designers aren't planning on adding a spell queue, since that destroys the immediate response between input and action.

The current thought is also that we won't be sending casts to the server during the global cooldown, both to reduce bandwidth (and flood disconnections) and to lessen the incentive to spam cast.

link here

By: Anonymous

Anonymous — Mon, 05 Nov 2007 17:11:00 +0000

same poster…

The correct fix to this is to allow the server to queue CD dependent spells. If the client says the 10second HS CD expired, and allows a 2nd HS cast, but the server receives the 2nd HS cast early, then the server should queue the HS cast until the 1st cast is complete, rather than rejecting it. Of course, that would be too elegant of a solution, so we won’t see it.

By: Gwaendar

Gwaendar — Mon, 05 Nov 2007 17:08:00 +0000

Quite frankly, I think it is a nerf to people with unstable connections before to any particuliar classes. If you have more or less constant latency over a couple of casts (as shown by Quartz’ red area remaining more or less the same lenght), you can adjust, but when it wildly varies, predicting where the cast will land is going to be harder the longer the casting time of the previous spell.

By: Anonymous

Anonymous — Mon, 05 Nov 2007 17:08:00 +0000

This majorly fucks tankadins, imo. Tankadin A has latency of 150ms when he casts his first holy shield. 10 seconds later, Tankadin A has latency of 140ms. Tankadin A casts holy shield the moment his client tells him the holy shield 10second CD is up. The 1.5sec GCD starts on client. Server receives 2nd HS request 9,990 ms after 1st HS request due to latency change. Server rejects this, since Holy shield has not yet reached appropriate CD. Server transmits back to client, spell failed, reset CD. 140ms later, the client cancels GCD, and the user is able to recast HS. 140ms after that, the server finally receives the 3rd HS request, and accepts it. That is 270ms AFTER the first holy shield expired on the server. That is 270ms of crushability, easily enough for prince to parry and crush the tank.

Pre 2.3, the tankadin could spam HS the moment his client CD was up, resulting in a maximum lag of 20-30ms of crushability(time between spam presses).

By: Green Armadillo

Green Armadillo — Mon, 05 Nov 2007 16:59:00 +0000

I don’t raid or arena and therefore haven’t felt the need to use /stopcast macros on my mage. What I will do is freeze a target, start casting frostbolt, and spam the ice lance button while the frostbolt is casting in the hopes of getting the instant cast ice lance off the instant the frostbolt finishes casting. (Ice lance travels faster than frostbolt does, so doing this creates the possibility of both spells hitting at the same time and both gaining the benefits of shatter against frozen targets.)

If I understand this correctly, I will now most likely have exactly one chance to cast the ice lance. If I push the button too early, the client will lock me in GCD until it hears otherwise from the server, which, for latency values greater than zero, most likely means missing the extremely narrow window for successfully casting the ice lance in time for it to arrive at the target at same time the frostbolt does. I’ll have to give this a try on the PTR, but that’s potentially a pretty big nerf to frost mages.