2.3 Casting Mechanics - Page 3

matthra · 11/19/07, 12:26 AM

Originally Posted by Thud00

Sort of. When you cast a spell its sent to the server this triggers UNIT_SPELLCAST_SENT (autoshot slightly different). If you can write mods you can hook onto this event and watch it get triggered. This now also triggers GCD.

The server will process it and reply triggering either
UNIT_SPELLCAST_START - All is well your spell is being timed on the server.
UNIT_SPELLCAST_SUCCESS - Instants either succeed or fail. They dont get the START event.
UNIT_SPELLCAST_FAILED - Something was wrong, "no LoS" etc.
UNIT_SPELLCAST_FAILED_QUIET - You sent a request while your current spell was still timing.

Whilst your spell is still timing you may get

UNIT_SPELLCAST_DELAYED - Pushback on your cast
UNIT_SPELLCAST_INTERUPTED - Someone has stunned you etc.

Assuming all has gone well you will end up with a UNIT_SPELLCAST_SUCCESS. GCD will end with the SUCCESS event unless you are casting an instant or something under 1.5s. And thats pretty much it.

Mobs targeting you will make you target them back if you have nothing on target. You can turn off attacking them from the interface options "Attack on Assist".

The sequence manager code is as below:

As you can see it only moves the sequence on when it gets a SUCCESS event. Ie the previous action was succesful.

Interesting, so the cast sequence validations occur after the last action receives a success statement. That would seem to imply that it would have received the results of the last action in the sequence as well, unless there is some kind of delay between the success statement and the death statement. I'm curious how the recent changes made in 2.3 as explained above make a stop casting macro unnecessary.

matthra · 11/19/07, 1:32 AM

I verified and I don't have have attack on assist on, and in ZA it happened when the mob was targeting a tank and not myself. So I'd say that something else is going on, I don't think Thud00's post explains the circumstances. Thud had mentioned that auto attack worked differently, does anyone know what he is talking about?

Kendrathe · 11/19/07, 2:27 AM

So.

Ever since the recent patch, if I'm not in stealth and stealth is on a Cooldown, I will spam the stealth key waiting to restealth. When the cooldown is up, i'll restealth, but then a half second later stealth will drop. On my screen, it says stealth is not on a cooldown, i'm just not in stealth. However, it will not let me restealth as if there was a regular stealth cooldown.

I don't suppose this could be related?

matthra · 11/19/07, 4:12 PM

Originally Posted by Kendrathe

So.

Ever since the recent patch, if I'm not in stealth and stealth is on a Cooldown, I will spam the stealth key waiting to restealth. When the cooldown is up, i'll restealth, but then a half second later stealth will drop. On my screen, it says stealth is not on a cooldown, i'm just not in stealth. However, it will not let me restealth as if there was a regular stealth cooldown.

I don't suppose this could be related?

Probably, I think all of these kind of issues and the recent problems with instant attacks are all related to the casting mechanics change. It would be helpful it blizzard was a little more transparent on the change, but lacking their assistance I still think its possible to get an idea whats going on.

The more I think about it the more reason I have to think that the change revolves around not waiting for UNIT_SPELLCAST_SUCCESS before allowing subsequent commands to be sent to the server. This was changed from waiting for UNIT_SPELLCAST_SUCCESS, which people were bypassing with the stop casting macro's. This would involve removing validations on the client side, and modifying cast sequences to move to the next step of the sequence on UNIT_SPELLCAST_SUCCESS amongst many other changes.

I think we have a plausible theroy, the question is how to test it. From Thuds post it would be a simple matter of seeing if a UNIT_SPELLCAST_SENT occurs after a UNIT_SPELLCAST_SENT but before UNIT_SPELLCAST_SUCCESS/failed/failed_quiet. Can anyone check this and let us know?

Trickykid · 11/19/07, 4:31 PM

Originally Posted by mylek

I would like to go back to one button per spell.

If I'm not mistaken, you can still /stopcast the same way as before. The only thing that has changed is that now without a /stopcast macro, you will start a spell in the lag-window between client and server.

Zaldinar · 11/19/07, 8:19 PM

Originally Posted by matthra

Probably, I think all of these kind of issues and the recent problems with instant attacks are all related to the casting mechanics change. It would be helpful it blizzard was a little more transparent on the change, but lacking their assistance I still think its possible to get an idea whats going on.

The more I think about it the more reason I have to think that the change revolves around not waiting for UNIT_SPELLCAST_SUCCESS before allowing subsequent commands to be sent to the server. This was changed from waiting for UNIT_SPELLCAST_SUCCESS, which people were bypassing with the stop casting macro's. This would involve removing validations on the client side, and modifying cast sequences to move to the next step of the sequence on UNIT_SPELLCAST_SUCCESS amongst many other changes.

I think we have a plausible theroy, the question is how to test it. From Thuds post it would be a simple matter of seeing if a UNIT_SPELLCAST_SENT occurs after a UNIT_SPELLCAST_SENT but before UNIT_SPELLCAST_SUCCESS/failed/failed_quiet. Can anyone check this and let us know?

Spellcast success is not involved. You can actually even send spell requests before the cast bar finishes.

Edit: er, sorry, confused myself with my own verbage from my addon. The spellcast success event represents the 'yes you finished' call, which indeed does matter, which is the end of the cast bar. Don't mind me, my own function names got me confused. (my function for dealing with the combat log entry for the damage done by the spell is HandleSpellSuccess(), derr)

Full thread about the mechanic here on the main WoW Mage forums:

WoW Forums -> 2.3 "Quartzless" spellcasting mechanic

And heres the skinny of what I found in more technical terms than the main WoW forums, since people here will actually get it.

UNIT_SPELLCAST_SENT can occur now any time that you don't have a GCD active, it would seem, when it fires you'll have a GCD start a few msecs later (obviously created client side) that will be canceled shortly there after (obviously by the server saying "You cant cast now dummy").

If you send a UNIT_SPELLCAST_SENT towards the end of the spell cast bar (old quartz-ing range) it would seem that it goes through and requests the spell for you. as with before the GCD starts ticking as soon as that request is sent, and you can even get a cast bar to start before the previous one has finished clearing. Basically you can get a start to start cast time of slightly below the cast time of the spell (~50 msec at most I found). All that this change seems to have accomplished is made built in /stopcasting effects in spell requests, that instead of canceling the spell if you do it early, incur a mini-gcd (ping time basically).

So button spammers lose out, Quartz users win, and blizzard didnt really gain anything for the average joe by doing this.

matthra · 11/19/07, 11:33 PM

Thank you, thats a very interesting read.

Habanero · 11/19/07, 11:51 PM

Originally Posted by Zaldinar

So button spammers lose out, Quartz users win, and blizzard didnt really gain anything for the average joe by doing this.

I would not come to this conclusion unless you assume the resolution of a button-spammer's timing is below their ping. Most people seem to have around 100 ping, and I doubt button spammers spam more than 10 times per second.

Zaldinar · 11/20/07, 12:14 AM

Originally Posted by Habanero

I would not come to this conclusion unless you assume the resolution of a button-spammer's timing is below their ping. Most people seem to have around 100 ping, and I doubt button spammers spam more than 10 times per second.

True, however if your timeline of cast is:

0.000 - Start initial cast
2.900 - Start zone where you can request next cast
3.000 - End initial cast

And you make a spell request at 2.899 that gets kicked back, lets say with a 100 msec delay, you're now at 2.999 before you can start your request for a spell (since while under the GCD you cant send new spell requests), losing 99 msec. During the testing I was actively trying to get in casts at every part of the window between where Quartz was telling me to cast, and the very end of the spell. If I beat out Quartz and got mini-gcd'ed I was unable to get another request in before the previous spell completed, which equates to probable lost DPS time.

So my assumption is not that every time you cast a spammer will lose out, but that every time they spam they have a chance to lose out, and over time those chances will add up to lost DPS that a Quartz user would not see. Effectively, the change that was supposed to remove our reliance on quartz and stopcasting macros did not work in half of its intent, we still need Quartz, it just does the stopcasting for us.

Prinsesa · 11/20/07, 1:00 AM

we still need Quartz, it just does the stopcasting for us.

This was apparent (to me anyway) from the moment the change was announced. The only benefits I see from this are:

Saving on macro slots since we no longer have to put a /stopcasting on everything.

Saving on *some* DPS from hitting your stopcast macro early. There were just some situations where hitting my FOL button early interrupted the current cast even if I was as careful as possible, simply because Quartz's "red-zone" can still be inaccurate at times.

Habanero · 11/20/07, 2:24 AM

Originally Posted by Zaldinar

True, however if your timeline of cast is:

0.000 - Start initial cast
2.900 - Start zone where you can request next cast
3.000 - End initial cast

And you make a spell request at 2.899 that gets kicked back, lets say with a 100 msec delay, you're now at 2.999 before you can start your request for a spell (since while under the GCD you cant send new spell requests), losing 99 msec. During the testing I was actively trying to get in casts at every part of the window between where Quartz was telling me to cast, and the very end of the spell. If I beat out Quartz and got mini-gcd'ed I was unable to get another request in before the previous spell completed, which equates to probable lost DPS time.

So my assumption is not that every time you cast a spammer will lose out, but that every time they spam they have a chance to lose out, and over time those chances will add up to lost DPS that a Quartz user would not see. Effectively, the change that was supposed to remove our reliance on quartz and stopcasting macros did not work in half of its intent, we still need Quartz, it just does the stopcasting for us.

For how little this helps a PvE damage caster in practice, unless they already /stopcasted quite well, it allows for what I think is the best overall possible chain casting ability for a healer (short of a spell queue). I might be the only person with a healer that feels this way, but the prospect of cancelling heals sometimes by accident made me shy away from using /stopcasting there. More often are those precious couple seconds critical when waiting for a heal to complete rather than a damage spell. Those with a more conservative casting behavior seem like they'd benefit the most. For standard "cancel-casting" as opposed to "stopcasting" there is no difference in normal behavior other than the way the stock cast bar looks.

Midnight · 11/20/07, 8:53 AM

Originally Posted by Kehoe

Maybe another MM hunter can back me up on this, but I have noticed after a steady / multi or arcane rotation, the autoshot timer will be halfway through casting before it lets me start another steady shot. My only assumption is that multi and arcane shot are no longer triggering a cooldown which delays autoshot, but does delay the next steady shot. It is something new with this patch, but I have no seen anyone mentioning this (no MM hunters?).

I assume you may be using a castsequence macro? If so, there is a possible explantation in the [Hunter]Help me please thread at page 52.

Originally Posted by Tibor

What I observed last night was that my Auto Shots could fire one of two ways, implicitly or explicitly. If I kept spamming my Steady » Auto macro, the game would be explicitly instructed to /cast Auto Shot immediately after my Steady Shot finished. This would not cause any hiccup in my macro. However, if I allowed Auto Shot to fire implicitly, by simply letting my Auto Shot timer elapse, the /castsequence would not acknowledge the implicit Auto Shot, and continue to wait for the explicit instruction to /cast Auto Shot.

A diagram might be instructive.

Scenario 1 - Spamming Macro
1. Spamming macro. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
2. Steady Shot fires. Continue spamming macro. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
3. Auto Shot fires. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
4. Return to Step 1.

Scenario 2 - Not Spamming Macro
1. Press macro once. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
2. Steady Shot fires. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
3. Allow Auto Shot timer to elapse. Macro status: /castsequence reset=2/target Steady Shot, Auto Shot
4. Press macro once to fire Steady Shot. FAIL, because macro status: /castsequence reset=2/target Steady Shot, Auto Shot[/i] The game is still attempting to cast Auto Shot, not Steady Shot.

Now, this speaks to either or both of two malfunctions:

1. An implicit Auto Shot should be, but isn't being, acknowledged as continuing/completing a castsequence. This suggests two corollary questions: should an implicit Auto Shot conclude a castsequence? Is this a new behaviour since 2.3? Or did we not notice because of....

2. The castsequence is ignoring the reset condition. Unless I misunderstand the reset condition, my castsequence macro should reset two seconds after its begun. In the event of an implicit Auto Shot, shouldn't my macro have reset back to Steady Shot by the time my Auto Shot timer elapses?

Also matthra, your problem seems to be related to the automatically switching between Auto Attack/Auto Shot setting which has been discussed in the same thread too.

Originally Posted by Njubee

Originally Posted by Slash

During the raid last night in SSC i noticed this annoying bug people have mentioned with my target automatically switching to a CCed target when the current one was dead.

We were clearing down to Leotheras, there were 4 sheeps wandering around and I was nuking the current MA. When the mob died, I noticed that my target had switched to the polymorphed mob as I was casting my next steady shot, this is without any Tab-targetting or any targetting at all. This happened four times in a row, I had to keep on my toes to cancel the steady shot before it broke the sheeps.

Has anyone else observed this behaviour and/or has a solution to it? I'm using the standard BM Steady/Auto/KC macro, and it was definitely my steady shot which was about to break the CC, not an auto-shot or my pet.

I had this issue too, but after unchecking the "Auto attack/Auto shot" setting under interface options it stopped.

Tacitus · 11/20/07, 1:53 PM

How should I program my G15 keyboard to take the most out of these new changes? I've dabbled a bit with the macros but I'm no pro.

TGS · 11/20/07, 2:29 PM

Originally Posted by Prinsesa

This was apparent (to me anyway) from the moment the change was announced. The only benefits I see from this are:

Saving on macro slots since we no longer have to put a /stopcasting on everything.

Saving on *some* DPS from hitting your stopcast macro early. There were just some situations where hitting my FOL button early interrupted the current cast even if I was as careful as possible, simply because Quartz's "red-zone" can still be inaccurate at times.

This is my take on it too.

However, I find (for whatever reason) that I am making more errors trying to time my casts with the new system. Maybe I just need to get used to it, or maybe I'm being too aggressive and hitting the next cast early. Has anyone else found themselves in this situation? It only took me 2-3 nights to get used to stopcasting, but I'm already at 5 raids with the new system and not comfortable with it yet.

Meltface · 11/20/07, 5:36 PM

Let me make sure I understand this:
GCDs on your client are supposed to prevent spellcast requests from being sent to the server?

Is there an exception made for the initial GCD on spellcast or something? I have WWS reports with MB (1.5s cast) -> SWD (Instant) consistantly landing at the same time. If I'm understanding the descriptions correctly, that shouldn't be possible if the GCD prevents spellcast requests.

Morwen · 11/20/07, 6:10 PM

Originally Posted by Meltface

Let me make sure I understand this:
GCDs on your client are supposed to prevent spellcast requests from being sent to the server?

Is there an exception made for the initial GCD on spellcast or something? I have WWS reports with MB (1.5s cast) -> SWD (Instant) consistantly landing at the same time. If I'm understanding the descriptions correctly, that shouldn't be possible if the GCD prevents spellcast requests.

(edited for my misinterpreting information)

The GCD starts when you request the MB cast, but you don't get a casting bar until the server receives it. (Quartz for instance will show the GCD bar as a step faster than the cast bar.) Thus the GCD will complete before the MB cast bar is done, and you will be able to send SWD at that time to get it to land at the same time.

jayowen · 11/20/07, 8:16 PM

laginfo

I've found the above mod quite useful for testing on Dr Boom and getting a feel for when to cast.

Bogeywoman · 11/30/07, 2:37 PM

I think Blizz has also been juggling the window size for the near-the-end-of-the-bar spell acceptance. Several raids back, I remember that I could be seriously sloppy with the next cast and basically just spam, and everything would end up fine with essentially chain-casted spells. Now, it seems as if spamming is more random -- either you fail and lose the whole window up until cast time end, or you succeed and get a slightly improved cast. And Blizz's view of the window is a little different than Quartz's.

Anyone else having issues here or seeing what I'm seeing, or am I going mad?

Arnath · 11/30/07, 5:57 PM

Since 2.3 I've had an issue where if I have a macro with /stopcasting (trinket macros in particular), I seem to have spells cancel completely more often than before if I try to cut it close at all (based on the Quartz bar). Is there some way to macro my trinkets into spells without /stopcasting?

Durakghar · 11/30/07, 5:58 PM

Originally Posted by Bogeywoman

I think Blizz has also been juggling the window size for the near-the-end-of-the-bar spell acceptance. Several raids back, I remember that I could be seriously sloppy with the next cast and basically just spam, and everything would end up fine with essentially chain-casted spells. Now, it seems as if spamming is more random -- either you fail and lose the whole window up until cast time end, or you succeed and get a slightly improved cast. And Blizz's view of the window is a little different than Quartz's.

Anyone else having issues here or seeing what I'm seeing, or am I going mad?

I have the same issues. After reading up on the mechanics here and personal testing, it seems that there is a sweet spot for sending your cast signal to the server before your current spell has completed. It looks like using the example from ebbv with the 200 ms delay on signal transfer from client to server you would ideally want to push your cast button 400 ms before the end of your previous cast. Click after this point and the time it takes to communicate from client to server and back will push back your actual casting time. Clicking before this point will result in the spell not being able to be cast because when you receive the signal from the server to cast the spell, you will still be casting your current spell.

If you cast at just the right time your cast bar is already casting again just a split second before your current spell is done. I almost feel like my spell got knocked back the reponse is so quick. If I miss that sweet spot then I run into the issues with the client started GCD which knocks back the cast of the next spell long enough to be noticed.

I have had success with hitting the sweet spot either by timing it exactly with one click or spamming. Seems like spamming is much more forgiving than if you miss with a single click.

Originally Posted by Arnath

Since 2.3 I've had an issue where if I have a macro with /stopcasting (trinket macros in particular), I seem to have spells cancel completely more often than before if I try to cut it close at all (based on the Quartz bar). Is there some way to macro my trinkets into spells without /stopcasting?

This is exactly what I'm talking about.

Kavan · 11/30/07, 5:59 PM

I indeed have a similar experience. When 2.3 first came out I could safely start casting 0.1-0.2s before Quartz estimation. Now for a week or so it seems a lot more similar to pre 2.3 /stopcasting. I don't remember seeing any changes in Quartz that could explain this.

BOHIC · 11/30/07, 6:06 PM

Originally Posted by Arnath

Since 2.3 I've had an issue where if I have a macro with /stopcasting (trinket macros in particular), I seem to have spells cancel completely more often than before if I try to cut it close at all (based on the Quartz bar). Is there some way to macro my trinkets into spells without /stopcasting?

You should be able to just remove the /stopcasting from the macro and have it work correctly. The only exception to this I found was a macro I had set up to use Troll berserking and then cast flame strike. When I deleted the /stopcasting from the macro, berserking would go off and I'd get the targeting icon for flame strike, but anywhere I hovered the icon was an invalid target. Adding the /stopcasting back in between berserking and flame strike resolved the issue.