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.
Pewsey has heard about tact and discretion, but tends to regard them much as children view vegetables.
There are only two kinds of MMOs: the ones people complain about and the ones nobody plays. (inspired by Bjarne Stroustrup)
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.
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.
Not to dispute the existence of a lag-induced "crush window," which it seems like you established pretty firmly, but a possible cause of unusually high crushing rates on Prince is his Thrash ability, which gives him 3 simultaneous attacks. This eats Shield Block charges faster than it can be reapplied, meaning that it is much easier for a crush to sneak in.
Not to dispute the existence of a lag-induced "crush window," which it seems like you established pretty firmly, but a possible cause of unusually high crushing rates on Prince is his Thrash ability, which gives him 3 simultaneous attacks. This eats Shield Block charges faster than it can be reapplied, meaning that it is much easier for a crush to sneak in.
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.
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.
I've tanked all of Karazhan, Maulgar, and OTed Gruul with my usual Australian 400-500ms latency. It's certainly... interesting. I find I rely a lot more on heroic strike due to the GCD being 'longer', but I can still put out solid threat numbers.
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.
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.
Frostbolt (Rank 5) - 2.5s
Average speed: 3.037s (N=38, s=0.1775)
Average cast time increase: 0.537s
Fireball (Rank 1) - 1.5s
Average speed: 2.0341s (N=44, s=0.1942s)
Average cast time increase: 0.5341s
Fireball (Rank 5) - 3.5s
Average speed: 4.0197s (N=23, s=0.2178s)
Average cast time increase: 0.5197s
The second test was run near Dalaran. My latency was 181-199ms (though I only checked twice, maybe it varied more)
Frostbolt (Rank 5) - 2.5s
Average speed: 2.8441s (N=46, s=0.1666s)
Average cast time increase: 0.3441s
Fireball (Rank 1) - 1.5s
Average speed: 1.8705 (N=52, s=0.1643s)
Average cast time increase: 0.3705s
Fireball (Rank 5) - 3.5s
Average speed: 3.8598s (N=35, s=0.2100s)
Average cast time increase: 0.3598s
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.
Frostbolt (Rank 5) - 2.5s
Average speed: 2.8610s (N=38, s=0.1775s)
Average cast time increase: 0.3610s
Fireball (Rank 1) - 1.5s
Average speed: 1.9378s (N=49, s=0.1642s)
Average cast time increase: 0.4378s
Fireball (Rank 5) - 3.5s
Average speed: 3.8670s (N=39, s=0.1787s)
Average cast time increase: 0.3670s
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.
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.
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?
Millions of words are written annually purporting to tell how to beat the races, whereas the best possible advice on the subject is found in the three monosyllables: 'Do not try.'
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?
Originally Posted by randomposter
Yeah, we do kinda need some way to do limited spell queuing, to reduce the effects of client lag. DAoC had this even in their horribly crippled UI, and it did do the job. Effectively you could queue up to 1 spell to fire after your current spell, and that action would take place server side, so the little lag at the end of your spellcast would not be seen on the server and you'd seemlessly start casting the next spell.
Originally Posted by slouken
That's not a bad idea, you should post it in the suggestions forum.
Maybe they just haven't done it yet? /spellstopcasting is by no means as good as a real server-side queue.
Melador> Incidentally, these last few pages are why people hate lawyers.
Viator> I really don't want to go all Kalman here.
Bury> Just imagine what the world would be like if you used your powers for good.
Maybe they just haven't done it yet? /spellstopcasting is by no means as good as a real server-side queue.
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?
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell
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.
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
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.
Last edited by Cel : 04/19/07 at 2:06 PM.
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell
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 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?
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.
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell