Veryberry, hit Pyroblast. After the initial GCD is done, while Pyroblast is still casting, hit another spell. It will do a very short GCD which will be aborted once your client receives the "Failed" message. If you don't see this then something funky is going on with your UI or something. This is not up for debate, this is what happens right now.

If this were the precipitating factor in this problem, though, there should be no difference between 2.2 and 2.3. That is, as long as 2.2 had a server-side GCD, 2.3 should not be showing any stranger effects due to latency variation.

Galzohar I'm not sure what you're talking about exactly. Let me run down the new system one more time so all the confused people can understand what's going on. We'll use Improved Fireballs for a nice simple example with 3.0s cast times. 200ms Latency.

0.00 - Fireball button is Pressed 1
0.00 - GCD on client starts
0.00 - Cast begins
0.00 - Request is sent to server
0.20 - Request is received by server
0.20 - Command successful sent back to client
0.80 - Fireball button is Pressed 2
0.80 - Client displays "Spell is not ready yet." no request sent
1.50 - GCD on client ends
1.60 - Fireball button is Pressed 3
1.60 - GCD on client starts
1.60 - Request is sent to server
1.80 - Request is received by server
1.80 - Failure message is sent back to client
2.00 - Failure message received by client
2.00 - GCD aborted on client
2.60 - Fireball button is Pressed 4
2.60 - GCD on client starts
2.60 - Request is sent to server
2.80 - Request is received by server
2.80 - Success message is sent back to client**
3.00 - Success message received by client
3.00 - GCD aborted on client
3.00 - GCD on client starts
3.00 - Second Fireball cast begins


So please note what is going on here.

1 - With the initial Fireball cast the Client begins the cast immediately because it knows nothing else is going on.

2 - With the second attempt to cast Fireball the Client knows a GCD is going on so you cannot cast, it displays the "Spell not ready" without sending out another request.

3 - The GCD is ended. In 2.3 the Client no longer makes assumptions at this point about whether or not you can start another spell, so it sends the request on to the Server and starts a new GCD to lock out spamming of buttons. The request is returned as a failure by the Server and the Client clears the GCD. Please note that if you have low latency this whole process may appear only as a brief darkening of the buttons.

4 - The 4th cast is sent near the end of the spell, when your Quartz bar will be nearer the red section. Here again the Client believes you are still casting but sends the request anyway and starts another GCD to lock out key spamming. In this case though the Server will return a success and you will immediately start your next Fireball cast when the current one ends. The details of the decision making process on the Server's end are not yet clear (size of this Window and whether it is adjusted for Latency), but it is definite that this is what's going on. You can hit your next spell slightly early and it will start up right when the current one ends.


Please also note that when I am talking about "key spamming" I am not talking about a human hitting the keys a little too often. What Blizzard was trying to block is G15 macros that send requests VERY quickly and/or someone constantly hitting the keys as fast as possible. Under "normal" 150-250ms ping times these lockouts only last half a second as it is, so you can still bombard the server pretty heavily.



** - This is what appears to be happening. The Server can receive a request before your current cast ends and it will "queue" it up, and allow for fast chain casts like this. More testing is required to see if this is being adjusted with latency or if there is a fixed window.


edit:

Clarification and correction of typo.

I assume this is just a typing error, but the GCD on client should not be aborted till 2.00

Yep it was indeed a typo. Thanks, I have corrected it along with a bunch of other clarification.

I want to note that there is no reason for the client to abort its GCD for attempt #4, as it's the GCD for that Fireball cast...

I really don't know or care about anything Ming has to say. One of many reasons I avoid the official forums.

Seriously, people saying "Oh it's fine" is not helpful. Lots of people said that when Counterspell got put on the GCD.

The change is real and it is hampering melee. Previously a Warrior could send a rapid succcession of Hamstring requests to the Server. This was important because when chasing someone under a 250ms ping environment, when your Client believes you are in range, you may not always be, so being able to get that request through for the brief period where you are in range is important. Now every time you send a request to Hamstring, there's a brief lockout before you can send another (approximately 2 times as long as your Latency, obviously.)

Are you suggesting that because this person hasn't mentioned the issue, it must not exist? Contrary to all the people here suggesting otherwise, of course.

My post above was refering to instant casts, not 3s cast spells. Namely buffing people and getting an error, which is easy to see when you're not spamming and just clicking the buff icon once per person every 1.5s, but do it tightly with very little spare time after the buff's 1.5s GCD.

While I see the severness of this problem and agree it needs to be addressed, didn't it already exist in 2.2 and just didn't get fixed? If I'm wrong, how was this any better back in 2.2?

In 2.2 the GCD didn't start on instants until your Client received the success message.

Proof?

Consider YouTube - Ice Lance. Blow it up to full screen if you must. While your buttons are still outlined in yellow, you have not received a successful server spellcast message, yet you can clearly see the GCD is cycling while the button is still yellow.

Unless you're suggesting it was that way for 2.2 but not before 2.2?