So in 2.3 Blizzard introduced a system where you can send spell requests before your current spell is finished, this supposedly is going to create a game where /stopcasting macros aren't needed anymore, and that addons will not give you such a great advantage in DPS. The exact mechanics of how this works have been talked about, theorized, and debated. Sounds like a perfect subject for some hard research to me!

First we have to establish how the entire system seems to work. Using my addon set up to record every event and situation I can locate in spellcasting to identify steps in the process here is a simple timeline for a fireball cast:

2484418.8960 - Spell Cast Request sent for spell Fireball.
2484418.8980 - GCD started.
2484418.9930 - Start Cast Bar for spell Fireball predicted end at 2484421.993.
2484420.4140 - GCD cleared.
2484421.9930 - Predicted end of Fireball Cast Bar.
2484422.0360 - Stop Cast Bar for spell.
2484422.7380 - Spell success registered for Fireball.

Arranging this with the Cast Request as T+0.0000 we get:

0.0000 - Spell Cast Request sent for spell Fireball.
0.0020 - GCD started.
0.0970 - Start Cast Bar for spell Fireball predicted end at 2484421.993.
1.5180 - GCD cleared.
3.0970 - Predicted end of Fireball Cast Bar.
3.1400 - Stop Cast Bar for spell.
3.8420 - Spell success registered for Fireball.

So, the GCD starts 2 msec after the spell request, indicating that the GCD is initiated client side (things we already knew include).

The cast bar starts 97 msec later, my ping floats between 60-130 or so, so this indicates that the start of that cast bar has to be directed by the server, and is *not* synced to the event request, something I find odd.

The GCD clears at 1.518 seconds, noting that it was expected to clear at 1.502, this 16 msec delay is likey just UI delay, so the GCD would seem to also finish client side, so we aren't waiting on a GCD done event from the server.

The predicted end of the cast bar passes at 3.097 seconds, with an actual clear of the cast bar at 3.14 seconds, indicating that the server has to tell the client that the spell has finished. This makes sense, since it wants to hold out until the last moment for interrupt/pushbacks, and the server is the side that actually knows about those.

And at 3.842 seconds the actual spell damage event hits, thats a delta of 702 msec, this is fireball, so it has a missile time to take into account. Let's now take a look at a scorch cast for a zero-missile time sampling:


2484397.5420 - Spell Cast Request sent for spell Scorch.
2484397.5440 - GCD started.
2484397.7390 - Start Cast Bar for spell Scorch predicted end at 2484399.239.
2484399.0580 - GCD cleared.
2484399.2390 - Predicted end of Scorch Cast Bar.
2484399.2920 - Stop Cast Bar for spell.
2484399.3910 - Spell success registered for Scorch.

Same trend, 2msec for the GCD to start, 197 msec for the cast bar to start, 1.516 seconds to clear the GCD, 53 msec from the predicted end to the actual end, and spell success, and 99 msec from the end of the cast bar the damage event occurs.



So, overall we have an idea now of how we can observe the different events and how they fit together and where it is indicated teh server needs to authorize events. Server needs to tell you that you're starting casting, you're ending casting, and that your damage occured.


Now, lets do an example of casting a spell and trying to cast other spells while the cast bar is going:

2496975.8360 - Spell Cast Request sent for spell Pyroblast.
2496975.8370 - GCD started.
2496975.9680 - Start Cast Bar for spell Pyroblast predicted end at 2496981.968.
2496977.3400 - GCD cleared.
2496981.7840 - Spell Cast Request sent for spell Pyroblast.
2496981.7850 - GCD started.
2496981.8840 - GCD cleared.
2496981.9680 - Predicted end of Pyroblast Cast Bar.
2496981.9840 - Stop Cast Bar for spell.
2496982.5540 - Spell Cast Request sent for spell Pyroblast.
2496982.5560 - GCD started.
2496982.6860 - Start Cast Bar for spell Pyroblast predicted end at 2496988.686.
2496982.6880 - Spell success registered for Pyroblast.
2496984.0580 - GCD cleared.

So we request our cast, the GCD starts, the spell bar starts, the GCD clears, and we try to cast again, start our GCD again, and it clears 99 msec later, this is the game saying "no dummy, you can't cast yet!". We then request another spell, GCD Starts, the spell bar starts, the first pyro goes off, and the GCD clears. Next spellcast continues as above.


So, with all this we come up with a few interesting things that we can gather. Doing a few full rotations on Dr Boom with spamming of keys and careful timing and then parsing gives us some useful data. For anyone curious, because of the way floating point operations work timestamps with four decimal places of precision were returning differences out to an infinite level of precision (for details see http://www.rocketaware.com/perl/perlfaq4/Why_am_I_getting_long_decimals_.htm for why it happens that way). I'm lazy, and just copy-pasted from my data sampling to four decimal places.


GCD Info:

Max GCD Observed: 1.5359
Min GCD Observed: 0.0979

The Max GCD is the longest time from the start of a cooldown to the end of a cooldown observed on the spell "Remove Lesser Curse". As shown it indicates that 1.5 seconds and processing delay is the highest value that GCD will return.

The Min GCD is the shortest time observed, this is for when you press a spell request before the system wants to accept one while you're casting and it starts ticking your GCD, but finishes early, this gives a good measurement of your ping time and the systems processing time.


Max Cast Times:

Scorch: 1.6049
Fireball: 3.2749
Pyroblast: 6.1160

These represent the highest time from the cast bar starting to it actually finishing, and give your actual cast times for the spells.


Min Cast Times:

Scorch: 1.5010
Fireball: 6.0019
Pyroblast: 3.0039

Same as above, but minimum.


Bar To Bar Min times:

Scorch: 1.4750
Fireball: 2.9569
Pyroblast: 5.9329

These represent the lowest time it took from the start of a spell cast before another cast bar started, and represent effectively our 'spam speed' of the spell. Of note is that these values are *lower* than the min cast time values for the spells, this occurs when a spell request is sent and the cast bar is started before the first ends. This would seem to be a system worked out by Blizzard to attempt to mitigate the lag factor.


Max delta from spell requests to ends:

Vs Observed End:
Scorch: 0.0320
Fireball: 0.1999
Pyroblast: 0.0049

Vs Predicted End:
Scorch: 0.0639
Fireball: 0.1310
Pyroblast: 0.0339


These represent the highest negative value from the observed and predicted ends of spells where a cast request was made and succeeded in generating a new cast. This is what we could call our "buffer" where you are able to successfully request a new spell.


What can we conclude from this? It looks like with propper timing you can get spells down to pretty much exactly their cast time, and even cheat your way under ever so slightly (about 40msec). Now, as far as exactly how to time this, to get those bare bar to bar min times I was using Quartz actually, so it would seem to still be a pretty good indication of when you should cast. This however will HURT your DPS if you're a button spammer like me, since you will incur those tiny GCDs, and if you are 10 msec before your window where you can request the spell and you start a 90 msecsec mini-GCD, you'll lose 80 msec of cast time.

So, blizzards change which was intended to make it so the masses wouldnt need an addon to be competative, failed, it just made the system a bit cleaner, and people who button spam (those who didnt do the /stopcasting, basically) still have a disadvantage vs those who dont.


And for the TL:DR crowd - The change to the spell cast system in 2.3 to eliminate /stopcasting macros does what they said it was going to do. Quartz is still the best way to go, you just dont need the /stopcasting macros.


Edit: Rearranged some data to have it with the right spell names.

******************************************************************************************************************************************
Edit: Previews of 2.4 patch notes (http://www.mmo-champion.com/index.php?topic=4018.0) indicate that haste will START influencing the GCD for spells down to a 1 second GCD. Until 2.4 hits this research stands as the behavior of the GCD in relation to haste effects.

Edit 2: 2.4 PTR testing confirms that the GCD is now able to be lowered to a minimum cap of 1.0 seconds. Research can be found here: http://forums.worldofwarcraft.com/thread.html?topicId=4665457295
******************************************************************************************************************************************


And as a follow up post to the main body of research. In this thread (http://forums.worldofwarcraft.com/thread.html?topicId=965509274) I established a measurement technique to show that the GCD was not reduced by haste or heroism. This was challenged by some research done on the EJ forums (http://elitistjerks.com/381155-post19.html) with a tag saying that cast time spells behaved differently than instacast in this regard, since my first method of testing relied on using fireblast to generate the GCD.

Using this addon I've made for this test, I got a shammy to buff me with heroism (many thanks to Fourstorms), and spammed the scorch key like crazy, this is what I came up with for data:

Max GCD observed of: 1.5509
Min GCD observed of: 1.5019
Max cast time for spell Scorch was 1.2050
Min cast time for spell Scorch was 1.1550
Min start bar to next start bar time for spell Scorch was 1.4539

Noting that I was *UNABLE* to generate a request before the spell had ended, so the other two datapoints were not collected. To make the point of this completely clear, I have been unable to get a spell request to occur before the GCD clears with any spell, the GCD displayed on your buttons is 1.5 seconds, it is always 1.5 seconds, and while it is present button pushes are ignored.

Conclusion? the GCD, is not lowered, by Heroism/Bloodlust.

For a more in depth exploration of how this system seems to work, heres a timeline of what it appears to me is going on when you shoot a fireball:

T-0.000 - Player pushes button, generates UNIT_SPELLCAST_SENT event
T-0.002 - GCD starts, no UNIT_SPELLCAST_SENT requests will fire until this clears
T-0.100 - cast bar actually starts, this timestamp is a bit floaty, since it may actually get the order to start later on, but comes with a 'start at' timer, without further inside knowledge of the code its difficult to tell if this start time is directed by the server, or reactionary by the client. This means we arent sure if the server says "Hey, at T+0.100 start that spell cast", or if the server says "Hey, start that spell cast" and the client happens to see the current time as T+0.100 at the time it is told. As indicated by the bar-to-bar times where the start of one spell can occur before another actually ends, the server telling it to start at a given time seems likely.
T+1.500 - GCD Clears, UNIT_SPELLCAST_SENT requests will now be able to fire
T+3.100 - Expected end of cast bar occurs, this is not where the spell seems to actually cast
T+3.200 - Actual end of cast bar occurs (UNIT_SPELLCAST_SUCCEDED), this seems to be server directed, so the server gets to the cast time and says "okay, you launched client".
T+3.900 - Fireball damage event lands, this has no bearing on your actual ability to chaincast, it's just informational and delayed by animations and missile time etc.

That's nice work. Thank you.

I wish understood half of it.

But I get the conclusion at least: keep using quartz.

Think you mixed up pyro/fireball at the end of the first post.

---

Q u o t e:
Think you mixed up pyro/fireball at the end of the first post.

---

Whoops, yep, thanks, will rearrange.

I believe Syrma (or some variation of those letters...if all else fails, my response is in my post history) posted a threat with the tentative indication that spamming may actually be better than timing with quartz. This, however, was troubled by what I consider a small sample and wide variation. Further research would not be unwarranted, however.

---

Q u o t e:
I believe Syrma (or some variation of those letters...if all else fails, my response is in my post history) posted a threat with the tentative indication that spamming may actually be better than timing with quartz. This, however, was troubled by what I consider a small sample and wide variation. Further research would not be unwarranted, however.

---

I saw that thread, and disagree completely based on my findings.

If you spam you run the risk of eating over your window of being able to send the request before your current spellcast is complete with a min-gcd. Spamming works fine for scorch, since the GCD keeps you from getting rejected requests, but on anything with a cast time greater than 1.5 seconds will fall into the mini-gcd problem.

---

Q u o t e:
bloodlust has never lowered the GCD. people who thought it did were on crack or playing with 600ms

---

I concur, but people have brought forth tests that indicate it, but the tests are not precise enough to prove it, I believe this test conclusively and definitively shows it. more nails in the coffin.

this was the assumption I came to as well. Keep quartz to time your spells (much more fogiving in 2.3 than hitting /stopcast too early). Its nice to see some of the number crunchers out there doing more tests on this. Much appreciation to all.

~Q

---

Q u o t e:
you sir need to go outside, see what sun light is, go and find a girl, get laid and then realize that this is a game....for christ sakes man, your @%%**ing about miliseconds here....

---

Duly noted. I think for starters I'll run five miles in the morning. I don't get to see the sun much, I'm awake before its up, then in a building with no windows until it goes down. As for the rest, I like my forum posting privileges, so will avoid that topic.

Fascinating work, Thank you. How did you find out the GCD internals?

Couple questions -

1. Regarding "cheating" the system , casting 0.40 seconds earlier - is there any way we can control this? Or is it random effect of the lag alinging perfectly?

2. Using Quartz - can you elaborate more on how you used this addon? If you are spamming the button, were you spamming all throughout or specifically at any point? (like the red portion of quartz timebar)

From my experience, I have been able to start casts even before the timer reaches the red portion - I play with about 700-850 ping.

About the UI lag - I've seen it varies markedly in Raids compared to single target testing - it might be the large amount of particle effects flying around or the syncing of channels/ dmg meters or /combatlog or just too much happening ... but lately is been a significant problem ><

Once again, thanks - keep up the good work. Your experiments and testing methodologies are always very knowledgeable, unlike most other experiments I've seen.

If you are spamming then quartz doesn't matter. However, if you want to just click the spell once then you can still use quarts and hit the spell when you would normally do your /stopcast macro, and the server will accept the request before the spell finishes.

---

Q u o t e:
From my experience, I have been able to start casts even before the timer reaches the red portion - I play with about 700-850 ping.

---

My experience with Quartz's latency feature is that it's fairly imprecise. While I've been using it for a long time I never attempted to use stopcasting macros because I'd end up canceling a spell even after the cast was quite visibly in the red zone. My ping is generally 150-200 so it's less of a big deal to me anyway. I attributed this weirdness with network latency or just short lag spikes; never really looked into it much so it might be something completely unrelated. If your latency changes while casting the cast bar won't actively update that fact, which could be the cause of the issue.

---

Q u o t e:


My experience with Quartz's latency feature is that it's fairly imprecise. While I've been using it for a long time I never attempted to use stopcasting macros because I'd end up canceling a spell even after the cast was quite visibly in the red zone. My ping is generally 150-200 so it's less of a big deal to me anyway. I attributed this weirdness with network latency or just short lag spikes; never really looked into it much so it might be something completely unrelated. If your latency changes while casting the cast bar won't actively update that fact, which could be the cause of the issue.

---

It would be impossible or at best extremely inefficient for Quartz's 'red bar' to be fully precise, since lag is so variable. It's meant as a guideline. Learning where to time the cast (even before with stopcasting) just takes practice, but I can say from personal experience that it still matters a lot even with 150-200 lag (this is what mine rides at).

I'm not entirely sure they've got all of the kinks out of the system yet on the new mechanic because stopcasting seemed for me to be a bit more reliable. Maybe once or twice in a 10-minute boss fight I'll press the button the same time as always and get the message 'the spell is not ready yet.' It's definitely not a GCD issue because I'm just single-pressing fireball (and I would be able to see that with Quartz anyway).

Then again, maybe it's just because I'd gotten so used to stopcasting I would go days without self-interrupting.

I guess in the end it makes sense for Blizzard to fix the fact that using macros that fundamentally violated game mechanics was necessary for casters to dps well.

---

Q u o t e:
Fascinating work, Thank you. How did you find out the GCD internals?

Couple questions -

1. Regarding "cheating" the system , casting 0.40 seconds earlier - is there any way we can control this? Or is it random effect of the lag alinging perfectly?

---

That would seem to be a function of timing it absolutely perfectly and the lag also working to your advantage.

---

Q u o t e:
2. Using Quartz - can you elaborate more on how you used this addon? If you are spamming the button, were you spamming all throughout or specifically at any point? (like the red portion of quartz timebar)

From my experience, I have been able to start casts even before the timer reaches the red portion - I play with about 700-850 ping.

---

Theres a mix of it all in there. I tried spamming, noticed I wasnt getting in the pre-end of spell window very often, so started timing my spells instead. TIming is definitely more effective.

---

Q u o t e:
About the UI lag - I've seen it varies markedly in Raids compared to single target testing - it might be the large amount of particle effects flying around or the syncing of channels/ dmg meters or /combatlog or just too much happening ... but lately is been a significant problem ><

---

I concur, and it it is heavily system related as well as situationally related.

---

Q u o t e:
Once again, thanks - keep up the good work. Your experiments and testing methodologies are always very knowledgeable, unlike most other experiments I've seen.

---

I aim to please, inspire, and educate. Thanks mate for the feedback.

thankee sai

I didn't read the big walls of text, but even if Blizzard's new system worked perfectly it seems like you would still want to use quartz because:

1) It would let you know when you would need to start spamming....I'm not a big fan of spamming 24/7.

2) It lets you know when you can move and the cast will still complete, something Blizzard's new system does nothing to help with.