Kasi

There is a lot of stuff out there flying around right now about how exactly it works and if/how you should treat it differently compared to 2.2. Now previous to 2.3 I wasn't using stopcasting. I did use it for one night of testing, but since I was learning a lot of new fights I didn't want to get locked into looking at bars.

From my limited experiences yesterday it seemed that spamming worked, but that it was like the old stopcasting that you could get a new spell off by spamming it at the end of your current cast. Basically still like the old one where you started casting once you got to quartz red part and then hit the cast. Now normally I have just been a spammer, I prefer to watch the fight and raid health and not my cast bars. So if there is no detriment to doing that way this is how I would prefer to do it.

But according to Altitis: Global Cooldown 2.3 Revisited, mashing is bad.

There is also this dialogue taking from the Mage thread:

Here's my comprehension of the way the current casting system works. More advanced tests to be done this week to clarify some details.

0.00 - you cast fireball
0.00 - the 'cast fireball' is sent to the server whether or not you're currently casting (as opposed to 2.2 where it wouldn't let you)
0.00 - a client-side GCD is triggered (this is where the details are a bit hazy)
0.20 - the server receives the message 'cast fireball'
0.20 - the server responds to the client saying 'spell is not ready' because you were already casting a fireball previous to this
0.40 - the client receives the answer from the server
0.40 - the client side GCD is removed as a result of receiving the message

In other words, to avoid players spamming the server with casts, as long as you don't get an answer from the server you can't cast other spells (lets call it a temporary GCD).

Also, it seems that consecutive casts of the same spell can be chain-casted server-side. Here's my best understanding of it:

- If the server receives a cast message 250 ms prior to the end of the ongoing cast, and that both spells are the same (ie: consecutive casts of fireball), then once the current casts completes on the server, it will begin to cast the next one immediately.


The parts that needs extended testing is the following questions:

1- Make sure the 'temporary GCD' does exists.
2- Is it possible to cast 200 fireballs in a row and that it would take precisely 600 seconds to execute with no haste gear ? (ie: that the '1 spell deep' queue does exists) (also ie: no latency penalty)
3- If yes, does it apply only to consecutive casts ? This is easy to test, alternate between fireball/frostbolt.
4- And for good measures, try with a G15/N52 spamming fireball to see the results.

1- It does, and I guess it is affecting Rogues, Warriors, etc. too and they're pretty upset about it because you can hit a Hamstring or something on someone who turns out to be out of range and you get locked out of being able to hit it again before the temporary GCD is removed. At least that's my understanding of how it's affecting them I haven't played my Rogue or Warrior yet in 2.3.

2- The problem with pulling this off is it seems the "queue window" (the time frame in which you can hit your next spell and the server will automatically begin casting it when the current spell ends) is fairly small, and may even be adjusting with your latency (more testing required here.)

3- I rotated in Scorches and had no problem hitting them somewhat before the red area on Quartz (with obviously no /stopcasting macro), which was usually a good amount before my Fireball finished. So I don't think it has to be the same spell.

4- Gonna have to wait for someone else here I don't have one.

I just want to consolidate the discussion in one thread instead of scattered around 3-4 different ones and would like to get some dialogue on dangers/pitfalls of the new system that could be unforseen by people who don't understand it, me included.

Edit: From the undocumented changes thread it seems the biggest issue is with chaining instants that use the GCD. Which means this affects healers and melee dps a lot more than it would affect any casters, although locks/spriests might want to beware.

 

Muphrid

I must emphasize one thing.

1. The "temporary GCD" already existed in 2.2. It was actually quite an easy latency check I used to do when I was on dial-up well before 2.0, even. I would conjure a mana gem and then try to conjure another of the same kind: the GCD would momentarily trigger then cancel when the client received a cancel message from the server (because you can't have 2 mana gems of the same kind).

It is for this reason that I firmly believe there is another culprit for the problems melee are having now with casting. 1 thing I have verified myself is that spamming an ability while moving into range can reset the GCD for no apparent reason while you are spamming, when all that should happen is that casts after the first one fail because the GCD is up.

 

ebbv

Muphrid what we had before is different from what we have now. What you describe did indeed happen in 2.2, that is to say, when your client believed you would begin a cast, it would start a GCD which could end early if it received the fail message from the server.

Now, however, your client will ALWAYS start a GCD when sending a request to the server, not just when it knows it can begin a cast. For example the client could believe you are 1.6 seconds into a Fireball cast and you hit Fireball again. The client will start a GCD to stop you from sending another request until it hears back about this one. This was added to stop the type of spamming available to people who have G15 keyboards or similar devices, or by simply mashing keys non-stop.

This is what is different and what is affecting Rogues and Warriors because it is starting a GCD whenever you send a request to the server.

edit:

To clarify this was not necessary in 2.2 because your client would not send requests to the server during a cast. Most people probably realize this but just wanted to be sure it was spelled out.

 

Muphrid

Are you suggesting the client is starting new GCDs while old ones are in effect? Because otherwise, there would be no way for the client to adversely affect rogues and warriors in the manner you describe.

 

ebbv

No. I purposely chose 1.6 seconds into a Fireball in my example because the GCD of that Fireball would be over with. If you have a GCD you can't initiate a new request and thus start a new GCD. I thought this was pretty obvious.

 

Muphrid

How would that affect melee, then?

 

Prinsesa

I believe the situation being described by as undesirable by melee is as thus (and correct me if I'm wrong on this):

Assume a player has 200 MS latency
T-0 : Joe McWarrior clicks his Hamstring button
T-0 : Joe's client sends the "I want to cast Hamstring" message to the server and starts a GCD on Joe's client
T+0.2 : The server receives Joe's message, but finds that Joe is out of range. It sends a "clear the GCD from Joe" message back to the client
T+0.4 : The client receives the server's message and removes the GCD

In this case, Joe can only try to cast Hamstring once every 0.4 seconds, as opposed to 2.2 where Joe could keep spamming his Hamstring and not get a GCD from attempted casts that the client thinks should be disallowed.

While I play a Paladin, I have never attempted to melee in an environment as fluid as PvP - I only either tank or play PvE Ret, so I have no real basis for knowing which of the above behaviors would be better; let you cast whenever you want but only every (latency * 2) seconds, or let you keypress whenever you want but lose potential successful casts blocked by an inaccurate client assumption.

"We do want Sanctuary to be the tanking seal"

- Ghostcrawler

 

Dustwhisper

I noticed something like a hookline lag when swapping from spamming a spell to throwing in another (eg fireball spam then fireblast or scorch). This would go hand in hand with client interpolation used together with server-prediction for spamming spells.

 

Veryberry

WoW Forums -> New GCD, post disagreements here.

This is 100% not true. I can spam any button while a spell is being cast and it doesn't affect my GCD. I can get off a Frost Bolt followed by Ice Lance and then Fireblast basically at the same time. Remove all addons, go back to all defaults. Your buttons have a "clock" on them which is the GCD, you watch it go around and around no matter how often you click or what you're doing. It never "resets" or "sets back". I recorded me spamming all kind of buttons and watched the GCD clock go round and round, when it was at 12 it cast a spell. You can easily make it "blink" (when you try to cast a spell but can't) 4-5-6 times/GCD but it never moves back.

The thread is full of reports like that one which are simply not true (just go test it out), maybe those players are on a bad connection (post patch lag, everybody spamming their buttons like hell), are still using /stopcasting macros (what does that do now anyway? ...) or action bar addons which are causing problems.

There are plenty people who can play just fine, with very low latency and also high latency.

It will also prevent laggy people from backstabbing me from miles away, because units on their screen are in a different place than on mine. The position on the server is correct, meaning with my good connection I will get a near perfect representation of the current state of the game. Actually now thinking about it, I haven't noticed any of those weird gouges for quite a while (where the rogue ends up behind you). Nice change Blizzard!

Maybe it would help if somebody experiencing this "problem" resets their UI (kill WTF/WTB) and then try to reproduce the issue and record it. Because I *can't* make the GCD go backwards. Also quite interesting nobody has actually made a movie yet. It's like "Onyxia Deep Breath buffed".

 

ebbv

Prinsesa's description is correct. When you attempt to hit Hamstring or whatever now it will start a GCD until your client receives the Failed message.

Veryberry, maybe it's harder to see this problem with Shadowbolt due to its lower cast time. One thing I did not mention in my example above, again because I thought it was obvious and this is EJ, so the level of discussion should be higher, is that if you hit your next Fireball close to when you would have hit your /stopcasting macro in the past, the server will "queue" your request and begin the next Fireball right when the current one ends.

This may be where your confusion is coming from in saying that hitting Shadowbolt or Searing Pain during a cast does not cause a GCD. If you hit it too early, it will in fact cause a GCD which will end once the client receives the "Failed" message. So it may be very brief or very long depending on your latency. But if you hit it at the "right" time it will queue up that spell and start it when the current one ends.

 

Veryberry

As I said, I was randomly pressing my hotkeys and and I never noticed a wait for a GCD to finish. Only when I successfully cast a spell the GCD "clock" started to go around the buttons and during that time it didn't matter how many hotkey I pressed.

Why does nobody make a movie?

 

Trazhenko

They aren't talking about pressing during the GCD of a successful cast. Of course you can't do anything during the GCD. Your client knows that. The issue arises in situations where the client believes you can cast, but you really can't (i.e. every melee class trying to hit a moving target, ever).

 

Muphrid

It's fairly easy with a mage, if you have one. Conjure a mana gem and try to conjure it again. The GCD will go backwards or reset. This happens any time the server tells the client that the attempt to cast failed--not when the client stops an attempt because you failed a client-side check.

Both the client and the server check range. Even if you pass the client-side check, the server check can fail, which will reset the GCD and stop the cast. This is pretty easy to do by running towards something spamming a button the whole way. If you watch closely, you will see GCD cycle that will reset before another cast attempt succeeds.

 

Veryberry

No.

I conjure my Gem, then try conjure the same one again (hotkey) while spamming my iAE hotkey. iAE always casts basically immediately (eg. I don't have to wait the 2*200ms a server confirmation roundtrip...?). Also while doing that the GCD clock maybe moves to 1 or 2 o'clock (like 10ms, until the bag check is done I guess).

 

Twid

I get this when spamming instant cast buffs on my arena team during preparation. I can make a fraps of it when I get home, but suffice it to say, it does not appear to be just affecting casts that are not able to be performed (ie: Duplicate mana gems).

When casting a buff, and immediately following it up with another buff (taking care to start the second cast immediately after the GCD) results in a noticeable delay. The GCD for the second cast appears clientside, however after around 3-400 ms, the GCD will reset and give me an error "You can't cast that yet".

 

ebbv

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.

 

galzohar

The "you can't do that yet" is basically becuase your 2nd cast was done with lower latency than the first, resulting in it reaching the server before the server-side GCD was finished, while your client assumes fixed latency and allows you to cast, hence the error message. This doesn't seem to happen with spamming 1.5s spells though (at least when it's the same spell), as even if your message does arrive to the server too early it seems to not send an error back, and possibly as had been said here earlier, "que" your next cast and do it. If queing is what's happening for 1.5s spells that would be the fix for instants (including buffs obviously) as well.

 

Muphrid

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.

 

ebbv

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.

 

Plankel

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

 

Veryberry

Season 3 Delayed, BGs Are Fun Again, AR/Prep The MVP Build of 2.3 from World of Ming | GAMERIOT

Anyone mind telling me why WoW Whiner #1 hasn't complained about it yet? He seemed to have played just fine according to this post so?

 

ebbv

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

 

Muphrid

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...

 

ebbv

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.)

 

ebbv

No, it isn't. It's the Lockout GCD which is started before the #1 Fireball cast ends. A new GCD is needed to coincide with the beginning of actually casting Fireball #4. If you watch closely, this is exactly what happens. There was also no need to quote my entire post for your one line reply.

To clarify, if this GCD was not aborted then the GCD would end only 1.1 seconds into the cast of the next Fireball. Hope this makes it clear why the Client aborts and starts a new one to coincide with the beginning of the next cast.