Stopcasting, Quartz, and Patch 2.3

Author’s note: I have quit playing WoW before patch 3.0.5. Warcraft-related content is no longer being updated, and information in this post may not reflect the live game any more.

OK, so there appears to still be quite a lot of confusion on what the changes in patch 2.3 in regards to /stopcasting actually mean.

First, let me stress this again, patch 2.3 doesn’t remove the /stopcasting command, it introduces a mechanism which removes the need to use /stopcasting to chain spells faster than what the normal latency between your client and the wow server allows for.

What it really fixes is the risk of canceling a spell if you hit /stopcasting too soon, which is a risk on long cast times, as the latency Quartz displays is an estimate based on the time it took between the moment you hit a spell command in your client and the server sent back an acknowledgment that it had begun casting.
GCD in 2.2
But as the saying goes, a picture is worth a thousand words, so let’s illustrate all this. Figure 1 to the right shows what happens today:

  1. The player hits a spell button, the global cooldown (GCD) triggers on the client
  2. The command hits the server, the spell starts casting “for real”, and an acknowledgment is sent back to the client
  3. The client receives the acknowledgment and now starts its own cast including animation. Quartz and similar addons have measured the gap between 1. and now, and display that at the end of your casting bar
  4. If you use /stopcasting here, the client will believe you have interrupted your current cast and send a new one to the server
  5. Due to the latency, however, the /stopcasting reaches the server after your spell is fully cast, and a new spellcast is immediately started. You will, in practice, have gained up to half of the red bar.

Now the weakness, in particular on long casts, is that latency can change very rapidly. If you have a long roundtrip from 1. to 3. when you start casting Pyroblast, for instance, 5 seconds later the latency may suddenly be a lot better, and you risk sending a /stopcasting too soon, canceling your current spellcast.

The change in 2.3 fixes that by removing the need to use /stopcasting to achieve such an effect. Right before we illustrate the new behaviour, let me stress this again: patch 2.3 doesn’t prevent you from continuing with the same /stopcasting methods as today, it simply gives you an alternative removing the risk of canceling if you make a timing mistake.GCD in 2.3 when all is well
On Figure 2 you see the new behaviour as described by Slouken on the US UI & Macros forum:

  1. As before, you hit your spell button and the global cooldown begins immediately.
  2. The cast command reaches the server which acknowledges it is starting to cast. Further, the acknowledgment also tells the client that triggering the GCD was justified.
  3. The acknowledgment hits the client, the casting animation starts on the player end, the GCD finishes, Quartz estimates the duration of the round-trip and colours the end of the bar in red like before.
  4. You send a new /cast command without /stopcasting. The GCD gets triggered and the spell starts its trip to the server
  5. If the previous cast is finished, the new one starts and the acknowledgment gets sent back. If however you are too soon, the signal will be sent back that the spell failed and the GCD will be reset on the client
  6. If all went well, you’d get the acknowledgment back and your spell animation would start in your client.

Again, the key difference here is that the client will send the new /cast command to the server early even if it believes that its current spell isn’t yet done with, but it will trigger the GCD immediately as well.

Now some people have interpreted the announced changes as an incentive to buttons-mashing, like Girl Meets WoW (note to self: need to read more on her blog, looks like there’s plenty of interesting stuff here). But reading into Slouken’s explanations on the intended behaviour, what really happens if you mash is depicted on figure 3:GCD in 2.3 when mashing

  1. You start your first cast as usual
  2. The cast starts on the server, the acknowledgment comes back to the client
  3. The acknowledgment is received by the client and the client begins its casting
  4. You hit the next spell too soon, the global cooldown triggers, preventing you from mashing or doing any other spell action tied to the GCD
  5. The server receives your command, sees that it’s too early, sends back a denial
  6. The denial is received by the client, the GCD is interrupted and you get an error message. You can cast again, triggering the GCD
  7. The new spellcast reaches the server, which sees it has not action going, and you’re back to step 2.

The key thing here is, during the GCD, the client will no longer accept any casting commands from your side until a) the GCD has run its full course or b) it has recieved a notification from the server that it wasn’t actually legit and stops the GCD. Basically, button-mashing, which is possible nowadays, will actually carry a higher penalty than today on spells with cast times longer than 1.5s

Therefore, don’t mash in 2.3 :)

EDIT: In the meantime, the mechanism has been adjusted by Blizzard. At the time of this belated edit (May 2008), there is no mash penalty anymore.

This entry was posted in PvE, PvP and tagged , . Bookmark the permalink.

18 Responses to Stopcasting, Quartz, and Patch 2.3

  1. Adventsparky (84 comments) says:

    Interesting read. I would really really like o remake my ui a bit. I’ve been particularly lazy since 2.2 and get 2 addon errors upon logging in, because I didn’t update any of them. I also get an error when I leave bg or arena but I can live with that.

    I wish for one of 2 things, the time to do some research and rebuild my ui using up as little of the screen as possible, or that 2.2 had changed things so much I was forced to remake it as it was unplayable.

    Right now I’m in no-mans land It works, not very well, but good enough that it’s not an emergency. Decisions decisions…

  2. Leiandra (7 comments) says:

    Very interesting. I don’t remember a second cast triggering the GCD, but I haven’t done a lot of killing on the PTR either. I think I’m gonna have to log on there tonight.

    Excellent analysis.

  3. Gwaendar (217 comments) says:

    Keep in mind that the whole process as designed isn’t yet entirely implemented on the PTR, part of it may still not function as advertised… or changed by the time it goes live.

  4. gt (28 comments) says:

    I am going to have to read that again when not at work…. 面白い!

  5. Girl Meets WoW (3 comments) says:

    Great read. Adding you to my reading list, as well.

    I’ve actually been following this on the 2.3 changes thread, but haven’t revisited the issue on GMW yet because I’m still waiting to see how it changes over the Test patches. (I should probably put a note up, though.) What I gather from the current implementation is that if you have very low latency, it may still be worth your time to spam while approaching. If you have high latency, you’re better off waiting until your first cast has safely completed.

    My suspicion is that this is all going to get reworked a few more times before it hits live, but I guess we’ll have to wait and see.

  6. Leiandra (7 comments) says:

    It appears that it triggers the Global Cooldown, but if you’re still casting, the Global Cooldown will be reset. So, along with GMW’s comment. Low latency, you can spam, but with still some side effects (you won’t be able to click again until you get the message back form the server that you’re still casting). High Latency… well… get a better connection. lol. (Totally kidding on that last comment.)

  7. Captain O'bvious (1 comments) says:

    What about spells with their own cooldowns like Holy Shield? It’s important for tankadins to keep their Holy Shield up so I often spam my key for it as it’s cooldown is running out so that it casts as soon as it’s available. If I do this with 0.1 seconds left on its cooldown, a GCD will trigger and I won’t be able to cast it for another 1.5 seconds leaving me without Holy Shield for 1.4 seconds??

  8. Gwaendar (217 comments) says:

    No, what is going to happen:
    - You hit Holy Shield a split second too early
    - The client starts the global cooldown and sends a cast request to the server
    - The server sees that it’s too early, and sends back both a “spell not ready” error and a command to the client to stop the GCD for HShield.

    Spamming will become counter-productive with the new system, and I expect noticeably so if your average latency is above 150ms (as you get twice that amount since the signal needs a round-trip).
    What I advise for Parrot users is to make a separate notification area somewhere close to where you keep your eyes glued on, re-define a Holy Shield event routed to that notification area, and add a sound to it. It’s probably the best you can hope for.

  9. Green Armadillo (15 comments) says:

    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.

  10. Gwaendar (217 comments) says:

    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.

  11. Anonymous (8 comments) says:

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

  12. Anonymous (8 comments) says:

    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.

  13. Gwaendar (217 comments) says:

    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

  14. Anonymous (8 comments) says:

    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.

  15. Gwaendar (217 comments) says:

    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.

  16. Gwaendar (217 comments) says:

    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.

  17. Pingback: The new 2.3 GCD and Stopcasting on Live | Altitis

  18. Pingback: The AutoHotKey Thread - Elitist Jerks