◊ Kalman

That's exactly what the function should be; however, it's only meaningful on skills with cast times, which is why I have my doubts about the shield block macro. Block doesn't trigger GCD (right?) so there's literally no reason at all for stopcasting to affect it, except in block/stop/other macros.

The way it works for caster /stopcast macros is:

The client sends a stopcasting to the server along with a cast new command (which is only allowed because the client has *locally* canceled the spell), timed such that the server receives the stop message after it processes the previous cast. This allows the previous cast to go through and the new cast to be started, without having to wait for server->client acknowledgement of the previous cast's completion.

 

Apate

/stopcasting tells the client not to wait for a server response that says "ok, spell complete"

So, if you've got a spell with a 2.5s cast time + 300ms latency, for example:
scenario 1: no macro - your spell begins. At T+2.5sec, the server says "done." At T+2.8sec your client receives the message. If, at 2.7 seconds, you tried to cast a spell, your client would sya that you are currently casting.

scenario 2: stopcasting macro - At some time past T+2.5sec but before T+2.8sec, you hit the /stopcasting macro to start another spell. The client sees that you "cancelled" the spell and allows you to cast. When the cancellation message reaches the server, it is meaningless since the server has already sent the "done" message to your client. You gain up to 300ms in your effective casting time.

I just don't know what warrior spell might flag the client as "Spell in Progress" as Slam is the only non-instant, non-"on next attack" skill I can think of.

EDIT: What Kalman said :P

See you, auntie.

 

Ward

That's essentially it. At time=0 the client receives your spell instruction. The server receives the original instruction at time=latency and then sends back a message to the client that arrives at time=2*latency to say "ok, the player can cast another spell" so instead what happens with stopcasting is at time=0 you hit an instant cast spell (or your spell actually finishes casting (spellcasting duration-latency)) and then it's sending out this signal to the server saying "do this spell". Now you hit the stopcasting, next spell macro. This sends a signal immediately after your original saying "stop doing nothing and let me cast my next spell". Your original spell hits at time=latency and your next spell hits (or starts casting) immediately after time=latency. Instead of decreasing your throughput, by using these macros latency is a single delay. Of course it doesn't work perfectly and there is still some throughput decresae, but it's significantly smaller.

 

Ward

Unfortunately, Blizzard is very bad at coding sometimes. I'm pretty sure they just implemented the same casting mechanics which I posted above for both instants and cast time spells. Which I agree shouldn't be the way to implement that functionality. From our observations, we know there is some kind of latency effect on shield block. We'll have to go back to Onyxia to test whether it's actually this type or not. I think we'll test crush percentage with and without the shield block macro.

God ... on second thought ... that's gonna be a lot of phase 1's until we get statistically significant results. Maybe some other people can go and we can pool our data.

 

Norwest

Ok, just to confirm that I'm understanding this:

The problem is:
Your client waits for confirmation from the server that your GCD is up, or your spell has cast. The client won't allow you to send a second spell to the server until it gets confirmation that you have finished your first.

Solution:
You can bypass this lag if your first spell is a timed cast, by using:
/stopcast
/cast second spell
And timing it carefully

If your first spell is based on the GCD, then you can't do anything to bypass the lag, because /stopcast won't do anything. There's no way to let your client cast ability 2, without confirmation that GCD is up.


Is that right?

 

Apate

What message is the combat log reporting that you are parsing to check for latency issues? The largest problem with latency that I've experienced is combat messages arriving out of order.

This should all be fairly easy to test if you have acess to a player with a significant amount of latency, right? At least 750ms+? Using a rogue could make it easier.

See you, auntie.

 

Frag

I'm not sure, but the following things are observable:
Given the macro:
/cast <ability on gcd>
/cast <ability not on gcd>
or
/cast <ability not on gcd>
/cast <ability on gcd>

Pushing the button once will only trigger one of the two (spamming the button will trigger both eventually.)

Changing the macro to place a /stopcasting between the two will cause a single keypress to trigger both abilities.

It's also very observable that a /stopcasting /cast Berserker Stance can swap stances in cases where a plain /cast Berserker Stance will not (this is very noticable if you tank nightbane without shamans or fear ward.) Similarly a /stopcasting /cast Taunt macro will let you taunt in cases where the Taunt skill alone will not.

Personally I suspect that the issue is that there is a period where the client is waiting for an acknowledgement from the sever that a command has been sent, and in that period the client won't let you send another command normally, and /stopcasting short circuits this check allowing you to fire another command to the server sooner.

 

Dralmoo

I've noticed the "lag" with Taunt not firing when you think it should, and same for stance switching but never with Shield Block. I feel like whenever I press Shield Block it consistently fires no matter what else I've been doing.

Anyone else have the same experience?

EDIT: to clarify with regard to the OP, obviously there is a window where you can still get crushed before the shield block buff is gained, but I feel like I always (eventually) get the buff. Whereas with taunt, sometimes it doesn't fire at all.

 

Twid

A related note: Be very careful where you put /stopcasting in tanking macros. If it's a button that you hit regularly, you will be canceling out your heroic strike queues. To test this, hit bloodrage and queue up a heroic strike. Press the macro that has a /stopcasting in it.

 

notreallyunique

I wrote a kernel extension to simulate latency (yay Mac OS X). I set one-way latency to 2 seconds, which results in a round trip latency of 4s (surprisingly, the in-game lag meter seems to measure round-trip latency, I always though it measured one-way).

First I played with normal abilities. Some observations (most of this is pretty obvious, but it's nice to get confirmation):

- The "UI lockout" triggers for any warrior ability I tried, GCD or no, and lasts for the round trip time. During this time the ability is highlighted, other abilities look normal, but don't respond to clicks.

- Abilities like shield block show up at the server 2s after triggered, and show up on my warrior's screen 2s after that (duh).

For the next tests I used 2 macros:

/stopcasting
/cast Sunder Armor(Rank 6)
/stopcasting

and

/stopcasting
/cast Shield Block
/stopcasting

Adding stopcasting immediately removes the UI lock. You can click another button right away. This second action appears to be immediately sent to the server as well. For GCD abilities the send happens after the cooldown ring completes, for instants the second send happens right after the first. The cooldown ring isn't affected by lag when using stopcasting.

In short, stopcasting does appear to be very effective in increasing your block snappiness and general warrior actions per minute under latency.

For the next test, I took out the second stopcasting from my sunder armor macro, and used the sunder macro followed by block. The stopcasting of the block cleared the UI lock, and except for how the visual feedback looked it behaved exactly the same as the double stopcasting version (in the double version you never get visual feedback on the UI lock).

 

Dots

Played around with this for a bit on the PTR (because I have higher latency there, around 400ms).

As expected, I was unable to do anything for 400ms after entering an action unless I used /stopcasting. This only seemed to make a difference with instants though. My latency time was not added on top of the GCD, instead they ran down at the same time. So unless my latency is higher than 1.5 seconds, there is no need for /stopcasting on GCD abilities because the UI lock runs out before the GCD anyways.

There is another pretty big disadvantage to adding /stopcasting to ever ability: it unqueues your Heroic Strike. I am a bit of a button masher (as I assume many tanks are) to get the most use out of the GCD. So with that Sunder Armor macro I would end up unqueueing my HS all the time.

However, adding /stopcasting to SB and HS macros seems to be quite effective. I'm going to give the following 2 macros a shot. Hopefully I won't unqueue my HS with the SB macro too often, if ever.

/stopcasting
/cast Shield Block

and

/stopcasting
/cast Heroic Strike(Rank 10)

I know I sometimes fail to queue up HS because of the UI lock, so I will probably end up using that macro anyways. Not sure if the SB macro will make much of a difference for me, because my usual latency is around 100ms and SB already lasts half a second longer than the cooldown.

 

Delta5

The one observation that annoys me is that latency will effectively increase the cooldown of any ability by an amount equal to your latency. This would be because the cooldown of an ability is tracked from when it shows the animation and goes off client side, after it gets told by the server that it can be used.

Example with 1 second latency (for simplicity)

0 seconds- I cast Bloodthirst
1 second- Bloodthirst is used and starts the Cooldown
7 seconds- Cooldown is up and cast again
8 seconds- bloodthirst gets used again.

Ect..

This hurts classes that also rely on cooldowns to do DPS or tank. It also would increase the cooldown of shield block also, increasing crushes taken by the tank which seems to be close to the problem the original post is talking about.

 

Grubsnik

It seems a lot of these issues are concerned with different "anti-spam" safeguards, built into the client, each having a separate error message

"Another action is already in progress"
This means the client has sent an action, but not gotten a completed-confirmation from the server yet. This can avoided with the /stopcasting command. This applies to regular cast-time spells as well as instants. Interestingly enough it does not apply to channeled spells, meaning you have to take extra care not to cut off the last tick from them (common knowledge i'm sure).

"You cannot do that yet"
This is cooldown related, the client is out of sync with the servers cooldown, meaning you try to perform an action before the server side cooldown is ready, this goes for regular cooldowns as well as global cooldowns. The client does not update the display.
pure speculation: The client blocks that command (or nearly all commands if it's the GCD) until it gets a "cooldown completed" command from the server, resulting in getting a 1½*lag block on actions(client-> (command) -> server -> (rejected, cooldown) -> client + server -> (cooldown done) -> client.)

Conclusion:
/stopcasting is your friend.
If you are "surfing" the GCD, and often getting stuck in it, it might be worth it to give it just a little more slack, so you are sure the server is not blocking you.
I have no way of actually verifying my theory, short of setting up a packet sniffer, and trying to capture the action when it happens + decode it. Anyone have a better suggestion?

On a related subject, is there any way to detect if you are already "casting" say, heroic strike. So you could expand your macro into

 

Demi9OD

Logic statements like "if" are no longer supported in wow macros.

 

Cel

Couldn't you possibly put /cast Heroic Strike at the end of a /stopcasting macro to make sure it queued up?

Given there's no global on Heroic Strike queuing, and with a /stopcasting macro, your client will send both commands near simultaneously, you should always queue a heroic strike regardless of what skill you use if you tag the end of your macros with it. Question being, only, if you actually want to use Heroic Strike as often as possible.... I'm no tank, so I really don't know. :p

"There is much pleasure to be gained from useless knowledge." - Bertrand Russell

Alpha is recruiting... go go.

 

Dots

You could, but you don't want to Heroic Strike every time you do something else either.

 

Ward

Implementing this could rely on an add-on that would switch which hotbar you use, one with heroic strike at the end of the stop casting and the other without. I *think* you can do this although it couldn't be accomplished simply by macroing.

 

Grubsnik

That part shouldn't be too hard, think you might even be able to /script a function to swap hotbars and just use that on the HS button... the issue is swapping back to the "normal" hotbar after each melee swing.

 

• Falk

I don't think that has anything to do with latency - more to do with the server-side processing and it's just as likely to happen to someone with 10ms as it is to someone with 900ms. (Hi)

Why do mobs who technically should be chain-casting spells by design melee between casts anyway? (Aran, Netherspite breath phase, Vek'lor, I'm looking at you) How do we get parried backstabs, or two backstabs on an incapitated mob? (To clarify, first backstab should by all rights have broken incapitate, and the mob turns around, preventing a second - but I've got a screenshot of two shreds in a row while farming mobs)

I've just put it down to concurrent processes on the server having some timeline inconsistencies. As an example, the classic "You die" "X heals you for 5000" case. Process replies "yes" to a heal's "is this guy alive, hence the heal will be succesful?" query, but registers the damage and death before the heal processes the 'yes' reply and sends a heal event.

I shred the incapitated mob. Incapitate wears off. However, there's so much going on server side at that instant that I manage to shred again before the server process controlling the mobs AI catches up and tells it that it should be attacking me.

Mind you, that's a really tiny window of time for that kind of glitching to happen, but it does. I'm tempted to say in perfect test conditions with low server load, the window is so small that it doesn't happen at all, but when the server gets busier and busier and has to compute more and more events (in real time) the delays cause windows to expand for concurrency issues to crop up.

I'd say during internal testing, Aran never melee's or runs away from the center if you don't lock out all three trees. I'd say during internal testing, Netherspite never budges or melee's in breath phases. I'd say during internal testing, at release, the gate in Naxxramas opened after you killed Anub'Rekhan. (Oh wait!)

Coming from a culture where the average raid ping is in the 700's, I just wanted to point out, we never saw more of those situations than the average person. Sure, everything registers on the server later than usual, but game logic is all handled server side anyway. All you're doing on your client is playing puppeteer with your entity on the server, with latency being how long it takes for your 'strings' to move your puppet. The game logic interacts with your server puppet, not the character you see on -your- screen


That aside, latency = blargh.

Our Naxxramas raids had, at best, one to two people with a latency below 300ms. Not exaggerating. We still scraped by. I've personally healed Twin Emps during the crud gear phase (tanks & healers) and Patchwerk at 900ms. I've done C'Thun, Heigan, Thaddius with 900ms. It's doable. Now, obviously it would have been better with a lower ping, but the game's mechanics rarely actually penalizes you for having a ping, beyond the delay. The exception to this rule is matters pertaining to the GCD.

You can adapt to practically everything latency related, except GCD. Fastcast (back then)/stopcasting macros fix spells with a cast time. You learn how to adapt to situatins where latency kills you - 'leading' at Heigan, the 4-camp adaption at Thaddius, miscellaneous tricks to run earlier/faster during Anub'Rekhan.

However, GCD... there's nothing we can do about it. It's been said a hundred times at the demise of Fastcast in December, and many, many times in this thread, but woe, I still have to say it... WHY isn't there some kind of spell-queueing functionality in the game?

Anyway, thread before this post had some really good discussion going... I shouldn't be derailing away from it.