Edghar

Are you suggesting that because this person hasn't mentioned the issue, it must not exist? Contrary to all the people here suggesting otherwise, of course.

 

galzohar

My post above was refering to instant casts, not 3s cast spells. Namely buffing people and getting an error, which is easy to see when you're not spamming and just clicking the buff icon once per person every 1.5s, but do it tightly with very little spare time after the buff's 1.5s GCD.

While I see the severness of this problem and agree it needs to be addressed, didn't it already exist in 2.2 and just didn't get fixed? If I'm wrong, how was this any better back in 2.2?

 

ebbv

In 2.2 the GCD didn't start on instants until your Client received the success message.

 

Muphrid

I shall observe whether this is the current functionality next time I log in. However, to have the client's GCD reset after preempting a current cast with a new one that succeeds introduces asymmetry;

0.000: client - /cast Fireball, begin client GCD
0.200: server receives message, starts casting Fireball, sends success message back to client
0.400: client receives success message, puts up a casting bar
1.500: client finishes GCD - server's Fireball has had 1.3 seconds to cast
3.000: client /cast Fireball, begin client GCD - note that there are still .4 seconds on the client's casting bar left
3.200: server finishes Fireball, casts a new Fireball
4.500: client GCD finishes - server's Fireball has had 1.3 seconds to cast, as before

In other words, having the client's GCD reset would mean an initial cast of a spell has less time taken up by the GCD than other casts. If the GCD resets, then it would look like...

3.400: client receives success message, GCD reset
4.900: client GCD finishes, server's Fireball has had 1.7 seconds to cast

The first cast is always 1.3 seconds, and subsequent 1.7? This is very bad mechanics.

 

Muphrid

Proof?

Consider YouTube - Ice Lance. Blow it up to full screen if you must. While your buttons are still outlined in yellow, you have not received a successful server spellcast message, yet you can clearly see the GCD is cycling while the button is still yellow.

Unless you're suggesting it was that way for 2.2 but not before 2.2?

 

ebbv

This is a low quality video, but I am working right now and don't have time to find a better one this shows a Fury warrior's abilities not starting GCD while the yellow border is present:

YouTube - Hallows End - Headless Horseman PTR

 

Muphrid

Perhaps, then, there was an inconsistency between melee abilities and spells prior to 2.3?

Edit: I found this - http://stage6.divx.com/user/Nasbin/v...Hunter-PvP-@70

At time 1:27 or so you can see an attempt to use wing clip that starts the GCD until there's a facing error, at which point it resets.

I do seriously consider the possibility that melee and ranged may have been under different restrictions regarding whose abilities begin the GCD on press and upon success at the server, but this is making me wonder what exactly is going on...

 

tadrinth

when tanking, I use a program called Autohotkey to simulate a G15 keyboard, along with a castsequence macro that does shield slam, revenge, devastate, devastate. this allows me to do an optimal tanking rotation by holding down a button, thus saving myself from carpal tunnel.

when i tanked kara post-patch, i noticed that the macro seemed to be much less effective. it seemed to get hung up on abilities, especially revenge. not sure if i was just getting stunned/knocked down and not realizing it or if its actually an issue with the new server side checks. if revenge is now being checked server side for a parry/dodge/block within the past 5 seconds, that might explain it. i won't get a chance to test this further until saturday.

also, how is this affecting hunter steady shot macros? ie, a macro with a castsequence for steady shot, auto shot. those are normally spammed as fast as possible, and it seems like they would be badly affected by this change.

 

Thud00

deleted

 

Chirality

I don't use a program like Autohotkey, but I used to use the following macro:

/cast Shield Block
/castsequence Shield Slam, Revenge, Devastate, Devastate

And I noticed the exact thing--revenge hangs even when it shouldn't.

This adds further to the aggravation of not being able to efficient spam-click the macro...

Indeed, I would say that the number of instant attacks I push through in a 6 second window has visibly decreased because of the GCD change occassionally reseting Devastate/etc casts .2 or .4 seconds after I first attempted to hit it.

Perhaps you can set your Autohotkey program to put a small delay on the key press?

e.g:


press button '1'
wait 1.5 seconds
repeat.



And compare the number of attacks with this made to

press button '1'
wait .2 seconds
repeat



I suspect the 'wait 1.5 seconds' would lead to far more instants being used.

 

Kyuki

Now I have not been testing this extensivly, I mainly noticed that I simply got to do more heals when spamming my heal buttons and was working really well.

However on the PTR when I was trying out the new Elemental changes, I experienced this "extra" GCD when spamming LBs.
This was only the case the second time I logged on to the PTRs to try it out though. The first time, when I was chaining LBs and spamming it, I didnt notice this at all - felt like how it's working now for healing.

I'm wondering (I know it's old), but does this not indicate that this problem is fixed? WoW BlueTracker: Analysis of 1.5 s cast problems on Test

 

Thud00

One of the wierder aspects is if you cast a HW on yourself, 1.5s into it GCD ends so you cast another HW on yourself. Now hit ESC. You stop casting the current spell as expected but the second one that you queued begins. It confuses my cast bar.

 

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?).

 

Morwen

This isn't directly related to the GCD discussion, but it seems to touch on updated casting mechanics:

Since the patch I've been getting an effect where spells in progress will auto-cancel when the target of a previous spell dies. Haven't been able to reliably reproduce this but it's happened enough that I don't think I'm just misclicking targets or accidentally moving.

Start casting a spell at Mob A which is near death.
Select Mob B, start casting the next spell.
About halfway through the cast, Mob A dies (while the previous spell is still in the air?), and the current cast is interrupted.

 

Antoine

I believe this only happens when you have a spell queued.

 

Morwen

That would explain it. I can now reproduce it easily by hitting the second spell sufficiently early.

 

Ignus

I understand how the new GCD effect works for us casters pretty well I think, and that it's definitely possible to add a short section of extra lag while the GCD is up but the server has not informed the client the spell is not ready to cast yet, but my question is about how melee abilities are affected by this.

it would seem to me that instant abilities should be working the same, as well as anything that casts within 1.5 seconds, before the GCD wears off. since the functionality has only changed when trying to use an ability "early" the client will still lock you out of sending requests to use any instant melee abilities before it would have been allowed anyways. as for moving in and out of range, if you are moving into range, your client thinks you are in range, sends the request to the server, starts the GCD, and then ends it when it recieves the message that your charachter was not in range, how is that different from 2.2? there does not seem to be a way to send a request to use an ability before it would normally be available via what the client thinks in terms of timing.

 

Thud00

Mechanics look to have changed again.

I can send a new request while casting after GCD ends. But if it reachs the server while it is still timing the last then get a UI_ERROR_MESSAGE with arg1 of "Another action is in progress" a short while later. Enough time later to suggest its coming from the server. So you have to time your SEND to reach the server just as the last ends. This is an improvement over the stopcasting in that you cant accidently cancel but your spell may be rejected.

Couldnt believe that UI_ERROR_MESSAGE was all the client got so open wow.exe in text editor and scanned for UNIT_SPELLCAST strings. Found a new one UNIT_SPELLCAST_FAILED_QUIET. Sure enough on registering this I found that this event is triggered whenever you SEND too soon and your cast rejected.

 

ebbv

You are not understanding the situation, please re-read the thread as it is explained quite clearly.

Fortunately it looks like Blizzard is trying to correct it.

 

• Sservis

Blizzard essentially did a "technology, mods/macros, should not give an advantage" fix, as all casters have the same behavior as /stopcasting without losing the spell for early recasting. We're still stuck timing the end of the spell in a fluctuating latency environment, but at least those who don't write macros don't have to write macros (were raiders/high PvP teams really QQing over macros, and does anyone else really need this?). They fixed the selective tech advantage and tech "misuse" from intended, but not the user headache.

It seems they don't care about the pain of staring at the bars to time either a /stopcasting or the next nonmacroed press as much as they care about game imbalances due to technology over the stock UI. It might have been incorrect to assume that they were working to fix the pain of staring at bars and twitch timing the next cast, when instead they didn't like the style of the macros written and what they did for us vs people who didn't bother to write macros. I know I was hopeful they would fix both, but not optimistic after they publically shot down the spellqueue.

 

ebbv

It really has nothing to do with Blizzard "not liking macros" or anything like that. This change was meant as a fix to their spell casting system which previously required a "hack" in the form of /stopcasting macros in order to help casters to get closer to their intended DPS.

The new system is actually much easier than the old one. The system is definitely allowing you to hit your spell early and starting the new cast as soon as the current one ends. You don't have to time it perfectly at all, just somewhere near the red area on your Quartz bar, or somewhere near the last 25% of the bar on a default UI cast bar, depending on lag.

 

matthra

Hey all I've been lurking here on the EJ boards for a while now, and I have greatly enjoyed the quality of post in this community. With that said me and a guildie had been in an argument about hunter macro's breaking CC, you see when a mob dies occasionally the hunters target switches to a randomly selected target, which has the predictable effect of breaking CC and making hunters look like noobs. I've been running some test and I thought I'd submit for peer review my ideas on whats going on. While a macro was my method of testing I think the below is a fairly good mock-up of the new casting mechanics, I look forward to your feedback.

Pulled from my board:
So I've been doing some more testing on the issue of queueing, I modified my cast sequence macro to use steady first and reset the sequence on target change. I had expected this to fix the issue of auto attack target switching, however it did not, which has some interesting implications for this conversation. For those not familiar with the process flow of cast sequence macro's let me briefly explain what happened.

For the relevant test I was in combat with two Garrang analyzers, I sicked my pet on one and traped the other. I then put my back to the trapped mob, and finish off the one on my pet. After the first analyzer dies I note that my auto attack is now on, and I have the mob behind me targeted.

So what had to have happened was that after my steady shot killed the first analyzer, it was followed by the auto shot/autoattack command which executed against the nearest mob. Here is the rub, once the mob died the target should have changed (to nothing) and made the next action a steady shot. Steady won't auto select a target, or turn on auto attack if it fails (because I'm to close or facing the wrong direction).
Given the above, the only possible conclusion we can come to is when auto attack portion of the cast sequence occurred the reset condition had not occurred, IE the mob was still alive. This is at odds with knowing the steady shot killed the mob. Having done some more research on the issue I can only see two possible answers:

1.) Queuing, The autoshot was queued server side, and when the client was given the go ahead, the orginal target was dead and it selected a random mob. Its not without flaws, for this to be true blizz has to be lying to us, or the CM are speaking without knowledge of whats really going on, both of which have occurred before.

2.) A new method of handling user input has been created/presented in 2.3. Something I've been wondering based on what we know from the about the GCD functions, is if wow handles user input in the same manner as the global cooldown. When you press the button it starts casting the spell, and waits for the server to send back a go ahead or a cancel, it will even do this while another spell is being cast. In order to prevent two spells being cast at once, it won't complete the casting until it receives the go ahead from the server. This would also explain what happened with the two analyzers, when I pressed the cast sequence, the cast sequence validation was active (IE: the same target as the sequence started with), so it sent the request for an auto attack to the server, by the time it reached the server the server had determined that I had killed the mob and sent me the go ahead command. By the time the go ahead command had reached me the mob was already dead, and I had no target, and with no target auto attack selects a target for you. This has the advantage of meaning the CM's are technically correct no queue exist, but their still wankers because they know that latency is creating a queue. If this is the case hunters are screwed, their is no way around the queuing affect of latency.

My intuition says that this change is what has been troubling the rogues, and other instant attack users. I don't know enough about how instant attacks used to work to hazard more than a guess, but if they started functioning as outlined in number 2 and previously did not that would explain why instant attacks have been off since the change.

 

galzohar

Hmm I *think* I was experiencing something similar when leveling my paladin... When I get attacked by 2 mobs, and try to judge the first one when it's almost dead and end up having an autoswing kill it before the judge actually goes off, it ends up judging the 2nd mob. Then again it's really hard to tell if queing a spell against 1 target will cast it on the 2nd target when it gets to the server and your target is dead since it all happens in <0.2s timeframe but it matches your problem with hunters breaking CC the way I understand it.

 

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.

 

mylek

My testing does not support the presence of a queue.

If a queue with a reasonable window existed it would be possible to cast spells back to back resulting in cast_time time spent per spell. From my tests with human input for casting I was not able to get very close to the exact cast time. (~0.1s lost per cast)

So now rather than one press per heal with stop casting we are left mashing the button from worst case to best case lag in order to get the fastest heal possible. We can actually cast a bit faster than before, because stopcasting only lets you safely remove the amount of lag from the best case (lowest latency) scenario without risking an interrupt.


So can you program the g15 to press a button 50 times per second for .3 seconds?

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