You're hyphenating it wrong. It's a 1-deep server spell queue, not 1 deep-server spell queue.

I disagree.
I think it's perfectly reasonable to assume lag would be a function in all spellcasting, just as it is in all other games. Online gaming has an inherent lag component to it, such that users with more robust conntections or better locations relative to the servers they are playing on have an advantage.
/stopcasting, just like configuration commands, scripts, and other macros, involves using a legitimate, although under-documented game mechanic to help compensate for a hardware discrepancy. I agree that if you could cast spells faster than their component times (6 2.5 sec spells in under 15 seconds), that would be cheating, but just as in Counterstrike, where you could use timepushing to adjust for lag, and remove some smoke effects to shoot better, I think /stopcasting makes for a distinction; smarter players are better players.
I don't want the playing field to be continually evened out, in that scenario, we're rewarding mediocrity. If reading forums such as this didn't improve online performance, why would we all do it? I like having something to shoot for, and to me, /stopcasting is no different than 10/48/3 mage spec, and a whole host of other things. We've found a way to play the game more effectively outside of the basic parameters of gear and style. For that, we should be rewarded.

So... queues have property called "depth"? Or do we measure queue size in "deeps"? Shouldn't it basically be "server-side 1-spell queue"?

That's right, but this lag component is usually related to delay and requiring higher latency players to react faster, not added cast time to their spells.

/stopcasting is focusing on staring on your cast bar (just like you already stare on boss timers and threat meters) instead of having fun. So you can have timepushing to adjust for lag, but does it cancel something if you do it too early? As for fog effects that is a kind of cheating. But back to /stopcasting, you either highly overrate it, or in our guild like noone uses it at all. As for smarter players are better players, this is how it works because some people just suck ridiculously no matter what.

You might as well want to play right from their datacenters and have some super-computer to have 500 fps always. Your online perfomance in PVP is improved directly by your ability to use all game mechanics, geometry and in raids it is improved directly by proper understanding of tactics and ability to react for everything and of course using proper spell rotations.

[quote]As we have noted "Cast Spell #N" that actually starts casting server-side is sent before receiving "Spell #2 is complete", that is amount of time we save compared to spamming normal button, without /stopcasting. This amount of time saved might of course be lower than amount of time saved by timing /stopcasting /cast macro, but this is more reliable and doesn't require extra focus (that is you won't miss some important boss ability)
[quote]
I understand it now I think, but I think that the delay you would get by spamming is about (or exactly) equal to the delay you would've gotten if you never used /stopcasting in the firstplace. Plus you'd have to alternate constantly between /stopcasting /cast macro and a normal cast hotkey.
On top of that, clicking too early during a bugged cast starts a client-side global cooldown, meaning if you clicked too early by 1ms, you will not be able to recast for 1.499 seconds after your spell was completed. You can move to clear that global cooldown, but global cooldowns only get cleared after the server approves. On top of that if the spell actually fired during your global cooldown (which will happen if you pressed 1ms too early) nothing can be done to clear the global cooldown and you will lose nearly 1.5s worth of casting time due to clicking too early during a bugged cast

The worst case scenario is when your bugged cast arrives to server right before completion of current spellcast. However, even in that case client will unlock casting when receiving "another action is in progress" and that will be a moment before receiving "spell complete", in this case you save a minimum amount of time very close to 0.

The best case scenario is when your bugged cast arrives to server right after completion of current spellcast. In this case you get perfect spell chaining.

On average you will in fact save about half of the time lost compared to not using /stopcasting at all. On top of that delays involved in processing your keypresses and displaying stuff will reduce benefit of /stopcasting by a certain amount.

> On top of that, clicking too early during a bugged cast starts a client-side global
>cooldown, meaning if you clicked too early by 1ms, you will not be able to recast for
>1.499 seconds after your spell was completed.
This is simply not true. This is worst case scenario, in which case you receive "another action is in progress" from server which both unlocks casts and clears global cooldown for client, you still save 1 ms compared to no /stopcasting.

Now as for alternating between normal spell hotkey and /stopcasting /cast macro, how about binding /stopcasting separately and using it as necessary and just spamming normal hotkey otherwise? Just bind to some mouse button 5 or whatever...

The WoW client is much more concerned about performance than it is about stopping cheaters. Observe the bevy of teleport hacks over the years. I wonder if you hacked the client to remove the GCD somehow, if the server would allow you spam instants?

It actually makes sense though, from Blizzard's PoV - they just flag and eventually permaban cheaters, rather than adding lag to everyone to make sure it doesn't happen in the first place.

According to my tests the server still runs his own global cooldown, based on the fact that if you spam your instant spell that's global-cooldown limited fast enough, if the first cast had 200ms ping and the 2nd cast had a 199ms ping, your client will think for a sec that your 2nd cast works but in fact it'll reach the server 1ms before the GCD is ready and the server will tell you you can't cast and your spell and global cooldown will cancel - but until it tells you that you're unable to cast anything, which means you just lost an amount of time very close to your ping. Due to ping variance being very small in my experience this doesn't happen a lot, but every few casts you'll see it.

As for spamming your normal spell cast, I just don't see it working. Trying to click anything while I have a bugged castbar (castbar moving but no cast animation because I just used /stopcasting /cast) will start a client-side global cooldown, and there's nothing I can do about it. Clicking too early = lose a global cooldown.

Sigh.... I can swear here that when I tested it last weekend server sent that good "another action is in progress" for spamming nukes with bugged cast bar, but... it doesn't any more Honestly this looks like Blizzard starts hotfixing issue server-side 2 patches ahead....

Hm, I'm a bit surprised no one has posted about the solution.

I attended the Blizzcon UI panel where this question was specifically asked. The answer given was that the "you are casting" type check was going to be moved to the server side, instead of it remaining on the client. What this does is allow the client to "cast 2 spells", and the server determines whether or not the 2nd spell can really begin or not.

Overall, seemed like a very minor change. I'd still use Quartz, I'd still hit the button in the "red" area to account for latency, but I would no longer need to macro my primary nukes to have a /stopcasting in them (though, I doubt still having/using such macros would hurt anything).

The real question is then if we'll be able to spam or will the server need to tell us if our cast went through or not before we can "spam" the button again? For example with items like "use" trinkets you're unable to perform any action until the server approves (or disapproves) your trinket clicking. Same goes for trying to dispel/clean someone who has nothing dispellable on him.

So they're basically reverting it back to the way it used to work over a year ago. This means you can get very close to optimal spell casting with good timing.

However, if it's just like how it used to be, then it means the client does not allow more than 1 outstanding spell cast request to the server. That means you can't spam, and if you click too early, you'll get a client-server-client turnaround before you can spam again (~100ms).

Seems like a reasonable solution at almost no development cost.

What would be really elegant would be if the server when telling the client that the spell is being cast sent back a time-stamp telling it when the casting bar should end. The bar then auto-adjusts for that timing and then if you were to spam the casting macro near the last bit of casting the spam would hit the server and then the instant that the next cast was allowed it would start casting it (which would remove all lag except for that associated with the very first command to cast) and send back a new time-stamp telling your client when the next cast would be complete.

Only downside would be the need to spam the casting command as you near the end of your current cast (to make sure that the command hits the moment the server allows the next cast to start). So the client allows you to spam the server during the last second of the cast and receives a signal to start a new casting bar from the server with time-stamps to determine the length of the casting bar. Only lag seen during a chain-cast would be with the start of the new casting bar on the client but it wouldn't actually have any effect on the actual casting times.

At least thats how it would seem to work from my understanding. Really can't wait for it to hit the PTRs to play around with it.

The issue with this approach is synchronizing the client and server system clocks with millisecond accuracy. If you don't do that, the server's concept of time doesn't mean the same thing as the client's, so the data is not relevant. It's certainly possible to synchronize but it's not particularly easy, since latency is rarely constant.

It doesn't have to be accurate to within milliseconds if they allow for some spam in any chaincasting situation. The casting bar will disappear and the next cast will start soon after and the casting bar will be shortened to account for the latency delay between server and client so that you have an approximate idea of when to start spamming the next spell in the chain cast again to prevent any pauses in the casts.

Only really works if they allow client spam to hit the server so that the hit can occur right as the server determines that another spell can cast. With casting/channeling as a protected function, spam wouldn't hurt dps unless linked to a /stopcasting macro. Only issue would be a disconnect between the casting bar and when movement would actually be allowed but if the bar was anywhere close to accurate normally latency would seem to prevent this from being too big of an issue.

I think they like the notion of spamming the casting keys since it adds an adrenaline type thing to a chaincasting situation. Similar to the key-spam that they designed Rogues around (old blue comments were about the design of Rogues and how they were designed around energy to give a reason to "spam" the keys). Guess we shall see what they are doing when 2.3 hits the PTR but it would seem to fit with what I think the developers would want for a solution.

Well, imagine for a second that spell_start event received from server contained a timestamp in UTC. If your local machine have the same UTC time (which it should), you can show precisely when on the server the cast is going to end, regardless of lag or time taken to receive the message from the server.

But that won't change the fact that the client cannot know ahead of time the time taken for the server to receive the begin_spellcast even from your client. So for 'spamming' and stopcasting purpose, you would still have to deal with lag in your stopcasting even with UTC timestamps.

That's my point exactly. Most system clocks differ from each other by at least a few seconds if not a few minutes. Try it right now by visiting The official US time to see what I mean. My system clock was only off by 1500 milliseconds, which is still far too much for this purpose.

To really synchronize the client and server, you need to ignore the client's host system clock altogether. The way you would do it is to send maybe 20 packets in a row, all containing the server timestamp that they were sent at. The client records the local time at which these were received and sends an acknowledgement back, at which point the server sends the next packet. From the round trip time you can analyze average latency and deduct that from the recorded client times to estimate when the message was sent. Then average together the offsets between client and server time. This value is the conversion offset from server time to client time. But the problem is that it's still just an estimate. I don't think you could get accuracy better than +/-50 ms.

At any rate, it really is a hard problem.

I have a funny feeling we're in agreement and yet still arguing. At any rate, by "hard" I meant, "more effort than Blizzard is willing to spend to solve the problem," not, "requires a PhD in Computer Science to solve". I just don't think this is the solution we'll see, that's all.

I understand what you mean, but there is plenty of open source code, with 'non restrictive licenses' that could be used within the WOW source code. Searching for the proper source code with a compatible license surely cannot be too hard :/

But if anything, what I meant to say is that server timestamps would only fix half of the problem.

To sum up everything I understand so far is that the only solutions that won't create new problems (be it worse or not as bad, but still problems) is either allowing to spam the server or spell queing...
Oh well, we got used to /stopcasting over the years, I suppose we'll just keep using it (or something similar that still requires good timing). I still don't like it, though.

Sigh, there was even a post here already about how they solve it. Easy and possibly efficient solution, yet everyone for some reason tries to show how smart they are and how to make easy thing hard.

What's use of synchronization when spells can be pushed back? You can't be certain that spell is complete until server tells your client that spell is complete and your client shows it for you on screen.

If client has to wait for answer before sending next cast the evil delay between spells will be halved on average, if client doesn't have to wait for answer than the delay will only be limited by your ability to spam buttons and framerate.

If the server is allowed to be spammed and the casting in progress block is placed server side why would there be any need for any complicated adjustments to the casting bar or anything of that nature in the first place?

If the signal to start the casting bar comes from the server you could just spam the casting command over and over and the server just won't allow any commands until it knows that the cast is complete and then it will accept the very next command to cast the next spell.

If a latency type mod was integrated into the client the casting bar length would be adjusted, giving a little bit of a cushion to account for things that would prevent the cast from completing such as movement (this way Blizzard's design would never be the cause of losing a cast from moving too soon, it would be personal responsibility for not allowing the casting bar to complete prior to initiating the movement). It would be a similar feel to mounting and then starting movement just before the casting bar completes. During a chain cast you would just want to start spamming the next cast a half second or so before the current one finishes, since all the commands would be ignored until the server determines that the current cast is complete. The spells would be exactly the casting time they are supposed to be (since that would be determined by the server's clock) except for the first one where you would only have the addition of downstream latency from client to server telling it to start casting.

If they wanted to be really fancy they could have the server adjust it's casting time based on the reply from the client that the cast had begun as well as from latency information sent in with the inital request. So client sends a request to cast a spell including current latency information, server replies spell casting to all clients, casting client starts it's casting bar and sends update to server notifying that it received the reply from the server again including current latency information, server receiving notification then looks at the latency in the request and then also determines the latency from the time delay between the requests and adjusts the casting time to account for the initial latency (that adjustment would probably be capped at 0.25 or something like that to prevent exploitation). After that inital cast, during a chain cast situation, there would be no need for any adjustments in casting time since the client would be able to spam the server near the end of the cast so that the next starts right after the last ends.

Even if someone hacked the client to stall the notification they really wouldn't see very much of an improvement since it would only affect the first cast and then would be limited in how much of an improvement they could expect to see. Also they would have to modify the latency reported on their computer as well as the actual timing of the responses to the server which seems like it would be a ton of work for minimal gain.

Sry to say but I took this tread to make a point!!

I see all these spreadsheets telling me what class is doing the most damage between 0 to 10 min.. well I as a raid leader can only say "what a load of crap".. the only thing that matter is raid dps and how you can improve it...


I would like to see a thread for raidleaders

Raid leaders unite... a place where we can discuss; raid healing, raid tanking and raid dps