I remember similar occurences as a Rogue, getting crit by a boss for 5 digit figures after Vanish in the combat log, and taking 0 damage.

My most amusing was this one



This was lvl 60 - and I had ~= 7k hp and I was very much alive at the end - eaten by zombies soon after.

The top death (Bresanne) was the MT.

This happens once in a while.
I remember back in BWL, Firemaw tripple hitting me within one second and I took zero damage due to vanish.

Also in Alterac Valley, you vanish and then there's coming an arrow from one of the tower archers flying to you and sticking inside your chest, but you don't take damage.

Unfortunatley for *player* damage, this more often does not work (i.e. that pyro still hits you and tears you out of stealth).

Vanish has immuned stuff for a long time. Ever since 1.7 or so when they started "tuning" it to no longer remove combat. As far as queing and the GCD, IF they could implement a 1 spell/ability que they wouldn't even need to retune most of the bosses for 2.1. Raid DPS and Tank TPS would go up so much it would easily counter the consumable nerf. But I don't think it's going to happen any time soon.

Back to the original post, perhaps using a macro like this would help.

/stopcasting
/cast shieldblock

I don't see how it could hurt.

I *really* doubt any benefit from this, unless for some reason you are halfway through a Slam.

Actually, I think it might help.

We had done a back of the napkin kind of calculation for the number of crushes that he should have experienced during Prince. We're well aware of the mechanics behind the Prince fight and have downed him on a regular basis. The issue wasn't that he had a flat crush rate that was abnormally high, but a rate that deviated from our theory by quite a bit. At first we thought it might have been evidence that block rating played a more significant role in mitigating crushing blows than previously thought. However, we dispelled that notion rather quickly when testing on Onyxia.

How did the data show this? Or was this a separate observation?

It should. Shield block is off the GCD, right? The only thing preventing you from using it is your client thinking you're performing an action. Sending the /stopcasting makes it stop doing any action.

OT'ing Gruul as the Hurtful tank with a 1.4 second latency was interesting.

I use a /stopcasting macro for shield block as well as taunt IIRC as I need any benefits I can get due to shitty latency.

Why blizzard hasn't implemented a system to let us queue our next ability up when the GCD is done (ON THE SERVER) is beyond me.

Its not beyond me: because they want you to have full control over your next action. For example, how would you be able to cancel the next queued spell rather the one you're casting now? You'd introduce a complexity to the game that would effect EVERYONE not just raiders but the most casual casuals. So thats why its never been implemented.

Could be an interface option "Allow queueing? <Y/N>"

And you could have a little button to show the queue, and cancel it by right-clicking, same as your buffs.

I suspect it would add a *lot* of processing complexity to the server though, which is one reason they may not want to do it.

I did a small study on lag in the Fall that is somewhat relevant, here are the results of that.

All of the data was collected using the standard Blizzard combat logs in chain-casting situations and then post-processing them in Perl for averages/standard deviations.

The first test was done outside of Ironforge (high lag setting). My latency was in the 250ms-350ms range.
The second test was run near Dalaran. My latency was 181-199ms (though I only checked twice, maybe it varied more)
The third test was also run near Dalaran, but with all mods disabled. I checked my latency more often than the second test and saw it range from 161-181ms.
So this data more or less validates that the base cast time doesn't seem to be relevant. (I think at the time that my primary goal was to validate that). The numbers seem sortof close to double the latency, so they sortof support the idea that the client waits to finish casting until after the server tells it to stop and that the server doesn't start casting until after it receives the client's message about casting.

As a side comment, relating to the /stopcasting macro stuff, it seems like when you macro something to stopcasting before the cast and run the macro while not casting, it takes a longer amount of time to perform the spell than doing it without the macro. But when casting a spell, it seems faster to use a macro to cancel than anything else. My main experience with this is Spell steal and Counterspell, since those are both instants and I use /stopcasting macros on them. They both seem to work faster with the macro if I was already casting and seem to work slower with the macro if I wasn't casting.

Like was said, likely the server techs did not want additional calculation complexity on their servers.

Maybe the devs think /stopspellcasting is good enough for people that care about it?

An interesting method of handling this sort of thing is how Lord of the Rings: Online does things.

Granted it's a serverside game, rather than WoW which is clientside... but the way they handled skills was that you select the skill you want used next via a hot key or clicking, and as long as that skill is highlighted, it will fire up as soon as it's available. This would be a nice addition to the UI, and would save my fingers from smashing the keyboard when I really need Cloak of Shadows to go off as soon as Deathcoil expires.

--

/stopspellcasting is a new thought from reading the warriors who say they use it to fight latency... to what degree would a rogue see benefit from this /command in skill macros...? being able to shave ms off your instants simply because the client allows you to send another skill to the server would be a dps increase to be sure, if it actually helps. Do you need to have significant latency for this to help, or will it always give slight bonus when you're not 0ms?

I like the idea that they have, but the UI for it needs work. I find it difficult to weave autoattacks properly sometimes. Then again, action bars and buff are the worst part of that UI - I just want things with numbers on them

Oh I definitely agree with you.. there are serious problems with the interface in that game, including having several skills off cooldown and trying to chain them in quick succession leading to accidentally not casting the first due to taking it off queue by hitting the other button too early, though that's probably partially due to my lack of experience with the interface (I got to level 8 woo! I guitared things to death on my lil dwarf minstril.). I think there's a hidden global cooldown in LOTRO, but I didn't really care to do any testing cause I was just playing it cause it was free and new. If that's true, I would be able to queue the next skill without feeling like I was losing time between globals.

I tried this for fun for a raid and it *felt* like I had considerably lower response time getting Shield Block up, but I'm unsure how to actually parse for it/get some hard numbers. Any suggestions on that? I'll have a combat log of Prince tonight, could probably give that a go to see how it works out.

The reason I'm asking is that it's obviously feasible and definitely effective to just put a
/cast Shield Block
/stopcasting
in front of every other one of my specials - which doesn't matter in a 25man, or even on 10man bosses such as Prince, but I'd have to switch my bars around for 5mans each time since I usually find myself rage starved, and needing to make tradeoffs - a button activating two abilities at once doesn't seem pleasant at all for that.

Well, this case with /stopcasting and shield block is one that I'd be glad to be wrong about. Latency shouldn't have an effect on performance, ideally, and it would go a long way to minimize its impact.

What cast, exactly, is being "stopped" (clientside) to allow you to hit Shield Block faster?

It seems as if the way it works is it tells the client you've stopped whatever it is you just sent to the server, so the client frees itself up to send another command to the server thus making the not-really-cancelled skill (as the server will have already processed it) and the next skill fire off in quicker succession.

Please point out where I got it wrong if I've not got it quite right, as I'm still trying to get my head around this sort of functionality myself.