The ability delay: the cause and how to avoid it

[Tiron_Raptor]

The 'ability delay' is not an animation issue. Activating another ability, including an instant-cast 'interrupt' ability, DOES break channels. The actual cause is pretty simple:

 

The 'ability action queue window' is malfunctioning. It's either not setting the delay before firing properly or the function that activates it is sometimes taking longer than the remaining GCD to process, or some other similar thing. Regardless, the result is the same: if you try to activate an ability BEFORE it is off GCD, it takes longer than the remaining GCD before it activates in most cases. There seems to be a minimum amount of time after something is queued before it can fire.

 

There are two ways to work around this: one mitigates, the other eliminates.

 

It can be mitigated by setting the ability action queue window (in the 'control' section of the options) to 1.0 and trying to hit abilities as early as possible: the later in the GCD they're hit, the longer the delay after the GCD before they fire in most cases. At 1.0, hitting as early as possible, the delay after GCD end is VASTLY reduced, and occasionally eliminated...though not often.

 

It can be eliminated outright by...not hitting the button until the GCD's actually finished. If the ability is already off GCD, the ability action queue is not used and there is no delay. If you hit it PRECISELY when the GCD is finished, you can actually get it so tight that the icons never light between the end of one GCD and the start of the next.

 

Setting the ability action queue window to 0.0 eliminates any possibility of encountering the delay, but also makes it so you MUST wait until the end of the GCD to activate an ability: if you hit it early, even by a microsecond, it simply fails silently and never goes off at all(though it would make spamming the button actually work as expected).

 

In short, if you're experiencing 'ability delay', you are hitting the ability too soon.

[Yazule]

well waiting for the GCD to be off has its own delay, the amount of time it takes for you to realize the GCD is off and click the button or press the key, so it is just creating a new delay that is 100% dependant on you and your focus on the buttons instead of the game. I did what you suggest a few days ago chaning the setting to 1.0 and it helps a lot, better than trusting my reflexes to not only see the gcd end but the time to get to the next action.

[dcinnitt]

Ok so when I log into my Sage and press my big heal. The cast bar finishes and then the ANIMATION finishes and the heal takes place... This is an ability queue malfunction... Yeah right ****.

[Tiron_Raptor]

well waiting for the GCD to be off has its own delay, the amount of time it takes for you to realize the GCD is off and click the button or press the key, so it is just creating a new delay that is 100% dependant on you and your focus on the buttons instead of the game. I did what you suggest a few days ago chaning the setting to 1.0 and it helps a lot, better than trusting my reflexes to not only see the gcd end but the time to get to the next action.

 

If you're really, really, really good you can anticipate the GCD perfectly (it's the same every time) and chain abilities with EXTREME precision.

 

Functionally, the 'delay' is a penalty for hitting it early, while still having it go off with only one keypress. If you hit it a fraction LATE it goes off instantly.

 

The super freak uber precise ultra-mega-uber-twitch gaming types might prefer to turn the queue off and just try to do it perfect. If you're spamming the button trying to stop it delaying, it's already queued from the first one and so doesn't go off any earlier... Unless you set the 'ability action queue window' to 0.0, in which case hitting it early does nothing and it'll go off the first time you press it after.

 

So if you're spamming buttons already, I'd say turn the queue off. If you're not that precise, set it to 1.0 and try to hit it early.

 

Or just leave it on, try to hit it precisely, and accept the delay as your penalty for failure.

 

I did bug report it though, so hopefully they'll fix it.

 

Ok so when I log into my Sage and press my big heal. The cast bar finishes and then the ANIMATION finishes and the heal takes place... This is an ability queue malfunction... Yeah right ****.

 

That is either: an ability specific bug or a deliberate choice to make it look better: WoW did something similar with damage spells, having the client delay SHOWING the damage until the spell 'bolt' appeared to hit the target: the damage was actually already received and calculated, it was simply a cosmetic delay to look like the damage hit instantly when the 'bolt' did...which also hid the effects of server-client latency.

Edited January 4, 2012 by Tiron_Raptor

[blackcerberus]

The 'ability delay' is not an animation issue. Activating another ability, including an instant-cast 'interrupt' ability, DOES break channels. The actual cause is pretty simple:

 

The 'ability action queue window' is malfunctioning. It's either not setting the delay before firing properly or the function that activates it is sometimes taking longer than the remaining GCD to process, or some other similar thing. Regardless, the result is the same: if you try to activate an ability BEFORE it is off GCD, it takes longer than the remaining GCD before it activates in most cases. There seems to be a minimum amount of time after something is queued before it can fire.

 

There are two ways to work around this: one mitigates, the other eliminates.

 

It can be mitigated by setting the ability action queue window (in the 'control' section of the options) to 1.0 and trying to hit abilities as early as possible: the later in the GCD they're hit, the longer the delay after the GCD before they fire in most cases. At 1.0, hitting as early as possible, the delay after GCD end is VASTLY reduced, and occasionally eliminated...though not often.

 

It can be eliminated outright by...not hitting the button until the GCD's actually finished. If the ability is already off GCD, the ability action queue is not used and there is no delay. If you hit it PRECISELY when the GCD is finished, you can actually get it so tight that the icons never light between the end of one GCD and the start of the next.

 

Setting the ability action queue window to 0.0 eliminates any possibility of encountering the delay, but also makes it so you MUST wait until the end of the GCD to activate an ability: if you hit it early, even by a microsecond, it simply fails silently and never goes off at all(though it would make spamming the button actually work as expected).

 

In short, if you're experiencing 'ability delay', you are hitting the ability too soon.

 

thats half the issue at best. even when off the GCD by a long mile some skills just have a massive delay. examples of this are Smash, check youtube videos for plenty proofs of that.

 

and then you have the skills that oftenly will play the animation but actually do nothing, like Ravage, and dont go into cooldown. Some times you will have to use ravage up to three times so the animation actually damages the target.

 

 

That isnt explained by any "queue". the animations on this game are a MASSIVE cause of sorrow, and nothing will ever fix that.

Edited January 4, 2012 by blackcerberus

[Tiron_Raptor]

thats half the issue at best. even when off the GCD by a long mile some skills just have a massive delay. examples of this are Smash, check youtube videos for plenty proofs of that.

 

and then you have the skills that oftenly will play the animation but actually do nothing, like Ravage, and dont go into cooldown. Some times you will have to use ravage up to three times so the animation actually damages the target.

 

 

That isnt explained by any "queue"

 

Those would likely be ability specific bugs and not a general input issue. If they were general issues, all abilities of the same type would display them, and this just isn't the case.

 

And if you're spamming the same ability in rapid succession trying to get it to go off, it's possible you're doing it so fast that the later attempts are CANCELLING The earlier ones!

Edited January 4, 2012 by Tiron_Raptor

[blackcerberus]

And if you're spamming the same ability in rapid succession trying to get it to go off, it's possible you're doing it so fast that the later attempts are CANCELLING The earlier ones!

thats not it. I can wait for the animation to complete (which is much longer than the GCD), use the skill again and get sme results. animation goes off, damage doesnt happen.

 

also, I'd like you to explain why simply summoning a mount and moving after the cast bar is done cancels the mount.

 

thats the simpliest example anyone can think to back up the skill delay issue, and easily tested by about anyone out there

 

check the way WoW handles this

 

now try to do the same in SWToR and tell me your results

 

 

 

 

 

 

also another frequent bug is the way you use an INSTANT skill, it starts the animation but a split second later it cancels itself without actually connecting. in general terms, all the skills not subject to the gcd show this problem

 

the skill doesnt go off, no damage/effect happened, but more likely than not the skill will be on cooldown as if it succeeded.

Edited January 4, 2012 by blackcerberus

[myrmexaw]

except it does not account why we get dismounted after moving forward once the cast bar tell us it's over or why you can still fail a pvp flag capping when the cast bar for the flag you're using clearly state it was capped ?

[Gurkburkenen]

So everyone playing SWTOR, hoping for a change should leave SWTOR and go back to wow? Because its the only game with a great Combat system in it ?

 

Why dont we do like this: Bioware gets this Character Responsiveness changed so its like World of Warcraft. If they dont, people that wants a somewhat higher level PVP, hopefully there will be a arena later in the game and if they fix "Character Responsiveness" SWTOR could MAYBE just MAYBE enter the E-SPORT world.

 

If they dont fix it, everyone will start leaving once they finish their "story" on their character. Exactly what has happend with the other "new" mmorpgs, but without the story part.

[Tiron_Raptor]

except it does not account why we get dismounted after moving forward once the cast bar tell us it's over or why you can still fail a pvp flag capping when the cast bar for the flag you're using clearly state it was capped ?

 

Those are both network latency issues, and WoW has them too...though my initial impression is that they're more sensitive on ToR, but it's been 3 years nearly since I stopped playing WoW so I can't really compare.

 

The thing most people fail to understand, is that what your client shows you is an illusion. The client determines nothing, it merely relays requests to the server (yes, requests), when you attempt to do something and displays what the server tells it happened. The only state that matters is the state of things according to the server.

 

Trick being if the client waits for the server's response to render the results, there's a noticeable delay (equal to your ping time), which really truly looks awful. So what happens is that the client anticipates: it simulates what it THINKS the server is going to say will happen as a result of your request. If it guesses wrong and the server sends back something different, it abruptly corrects itself.

 

The system is designed this way because the client can't be trusted: it can be hacked, or the messages it sends can be modified before they get to the server, etc... which means anything that the client is given the authority to determine can easily be hacked to give otherwise impossible results. World of Warcraft gave the client authority over movement, and this resulted in a large number of movement hacks and exploits. Teleport hacks, speed hacks (Saw a troll farming in wintergrasp a few times, he'd 'teleport'(not the spell) forward short distances on foot in quick succession, ending up going faster than an epic mount, and was able to go straight up sheer cliffs), the ability to change a common model to a large climbable one and then climb up it to reach inaccessible places (this was what got model editing disabled).

 

When you hit the mount button(or any other, for that matter), this is what happens:

 

The client sends a message to the server telling it you're trying to mount, but immediately starts an estimated castbar so as to avoid a visible delay. Some milliseconds later (Approximately but not necessarily half your your ping at that moment), the server receives that message, and if there's no conflicts begins its own timer (if there are conflicts, it sends back a 'cast aborted' message along with whatever caused the conflict). The slight delay between the client sending and the server receiving results in the server's timer being exactly that amount behind the client's simulated castbar.

 

On the client, when the castbar ends, it simulates your character getting on their mount, again so that there isn't a hang between the end of the castbar and your character actually mounting. At this point, the server's timer hasn't finished yet: according to it you're not mounted yet, not for some number of millseconds (equal to whatever the delay was when the client sent the initial mount message).

 

When you move after summoning your mount, your client sends a message to the server stating that you've moved. If by some circumstance or another, that message arrives at the server before the server's timer for when you'll be mounted ends, it sends back a message saying 'you cancelled your mount cast dummy, you're not mounted', which causes the client to abruptly correct its simulation of you mounting to what the server states the real state was: you never got mounted at all.

 

There's a few ways this can happen, all require you being very precise about moving immediately after the castbar ends.

 

The simplest, and completely unsolvable, is that the latency between your client and the server was lower when you moved than it was when you hit mount. If it was the same or greater, the message would arrive after the server had decided you were already mounted and you would not be dismounted.

 

There could be some sort of delay between the castbar starting and the client actually sending the message, that isn't present in a movement command: this could be netcode or some other issue.

 

There could be a mismatch in timing: the timer on your client runs slightly faster than on the server, causing the castbar to finish just a bit too soon. (This can be simply from variation in hardware and not any defect of design, though it should be EXTREMELY minute in this case).

 

The trick being that you CAN do this in World of Warcraft as well: I distinctly remember many occasions where I ended up walking forward in a cloud of smoke, with both the 'roar' of my black war tiger and the dismount sounds ringing in my ears. I can also remember jumping when trying to use my Black Netherdrake(which I did keep using in Wrath, Thank you.)

 

The other trick being that you can actually do this with ANY Cast-time spell. Move too close to the end of the castbar while shooting off a fireball, and you'll get the fireball zinging off at the target, the end of the cast animation, and glowing hands, just a tiny moment before you're informed that it was actually cancelled and end up doing no damage.

 

It's just more noticeable with mounts because you're much more likely to try to move precisely at the end of the cast than you are casting a normal spell. Try it: find some Mob somewhere, don't aggro it. Fire a cast time spell at it and try to move precisely at the end of the cast bar, the same as you would when mounting. Sooner or later, you'll see the ability fire and then get cancelled, and fail to damage or even aggro the mob.

Edited January 4, 2012 by Tiron_Raptor

[Gurkburkenen]

You are able to write a wall of text, but not able to understand that you are wrong and clearly dont know what you are discussing.

[Vorlia]

In wow, dismounting only happens if you guess wrong at your latency and try to jump the timing just a bit too fast. I have as much experience as anyone on this. There will never be normal case where you can wait for the blizzard-cast-bar to finish, then move and get dismounted.

 

In ToR, you can wait for your cast to finish, then move, then the mounting fails. This is repeatable and anyone can try it without much trouble. Do you not think it's a problem that we can wait for the cast to finish, then move and have the mounting fail? No matter how you want to explain the root cause of it, it's undeniably broken.

[Tewnam]

In wow, dismounting only happens if you guess wrong at your latency and try to jump the timing just a bit too fast. I have as much experience as anyone on this. There will never be normal case where you can wait for the blizzard-cast-bar to finish, then move and get dismounted.

 

In ToR, you can wait for your cast to finish, then move, then the mounting fails. This is repeatable and anyone can try it without much trouble. Do you not think it's a problem that we can wait for the cast to finish, then move and have the mounting fail? No matter how you want to explain the root cause of it, it's undeniably broken.

 

It's a simple case of the client not being perfectly sync'd up with the server. Your client is telling you that you have finished casting and are mounting. After which you press the key to move, this command is sent to the server and the server says, "Hey, you were summoning your mount, so that gets cancelled since now you're moving!" The client gets the result from the server and then interrupts the mounting and leaves you unmounted. That is the proper result based on the events as they happened on the server.

 

Perhaps the actual cast time on the client-side is faster than what is configured on the server, or the server has a slight delay in processing the command. Regardless, every MMO that I've ever played has similar issues in the first few weeks. It's a matter of tweaking the system so that everything syncs up just right.

 

If this bug, and others, are game-breaking for you, then I would recommend not playing any MMORPG immediately at launch, because you will always be disappointed. The determination in the quality of the MMO developer is how they handle the first six months after release. Most major bugs (not that I've personally encountered any, but the forums bring up some) should be resolved by that time.

[Tiron_Raptor]

In wow, dismounting only happens if you guess wrong at your latency and try to jump the timing just a bit too fast. I have as much experience as anyone on this. There will never be normal case where you can wait for the blizzard-cast-bar to finish, then move and get dismounted.

 

In ToR, you can wait for your cast to finish, then move, then the mounting fails. This is repeatable and anyone can try it without much trouble. Do you not think it's a problem that we can wait for the cast to finish, then move and have the mounting fail? No matter how you want to explain the root cause of it, it's undeniably broken.

 

Trick being, it's EXACTLY the same thing on both games, as Tewnam states.

 

You're jumping the latency a bit, and never actually getting mounted, even though your client thinks you should've.

 

I can't precisely recall how OFTEN I had this problem on WoW, but I do remember having it. My gut feeling is that it's more COMMON on SWTOR, but I'm not sure if that's the case or just false remembrance.

 

It IS possible that it's worse, which could very well be because there's some factor, either in the client or the server, that's introducing some extra delay and increasing the discrepancy between your client's simulation and the server's mount timer.

 

Fundamentally however, it's a latency issue, and by the currently known laws of physics, cannot be entirely eliminated from any game, only minimized or worked around.

Edited January 4, 2012 by Tiron_Raptor

[Polychrome]

Dude the problem's been discussed over and over and the general conclusion is - the game prioritises animation over actual execution of abilities. It's so evident you don't even have to analyze it - it's all there! Try moving when the casting of speeder ends, try casting Crushing darkness during the process of flinching from a melee strike, try interrupting target's casting in the middle of casting your own spell. Thing is, pretty animations ruined character responsiveness. We are forced to watch our character strike a pose whereas what we ought to have is complete control over him. That, we don't. Not that it's game-breaking while doing solo content, but as far as more serious content like pvp, fps or ops are concerned, it's a certain fail on Bioware's side, which needs fixing ASAP. Anyways, they said they were looking into it, hopefully we get a fix soon...

[Tiron_Raptor]

Dude the problem's been discussed over and over and the general conclusion is - the game prioritises animation over actual execution of abilities. It's so evident you don't even have to analyze it - it's all there! Try moving when the casting of speeder ends, try casting Crushing darkness during the process of flinching from a melee strike, try interrupting target's casting in the middle of casting your own spell. Thing is, pretty animations ruined character responsiveness. We are forced to watch our character strike a pose whereas what we ought to have is complete control over him. That, we don't. Not that it's game-breaking while doing solo content, but as far as more serious content like pvp, fps or ops are concerned, it's a certain fail on Bioware's side, which needs fixing ASAP. Anyways, they said they were looking into it, hopefully we get a fix soon...

 

I've yet to personally see any case where an ability being used was delayed by an animation. Which might be in part because in combat, my limited attention is so focused on the quickslots, health bars, and buff icons that I barely even register the animations much of the time.

 

I've seen the ability action queue fail to fire an ability at the right time.

 

I've seen non-GCD abilities seemingly respecting the GCD anyway.

 

Other than that, I have seen no actual delay in the execution of abilities:

 

the ability is executed when the server accepts the command to execute it. This is represented on the client by a variety of things: the GCD and cooldowns starting (and not being reverted), resources being used/granted. And eventually, animating the attack and displaying the damage dealt in flytext and on the enemy's health bar.

 

The GCD, Cooldowns, and Resources are DRAMATICALLY more immediately responsive than the animations or damage indications, because the latter two are deliberately modified for cosmetic reasons.

 

Those are what you should pay attention to, not when the animation starts.

[Luewen]

You are able to write a wall of text, but not able to understand that you are wrong and clearly dont know what you are discussing.

 

And thats plenty of more info than you were able to type here. Why dont you just **** until you get something worthwhile to say and not whine line the rest of the "omagad, ability lag, fix it now. Crowd".

 

What Tiron is saying is exactly right and one reason for the so called ability lag. And if it were due the engine or bug, the everyone Sokos have it. But I am not having it atm or newer have had it on tor. Abilities go off when i press the button and not 0.5 secs later.

[oflow]

Please explain why using abilities off the GCD or ones used after using an ability thats not on the GCD often do nothing if activated, but still use our resources and reset the GCD?

 

See riposte, overload

[Tiron_Raptor]

And thats plenty of more info than you were able to type here. Why dont you just **** until you get something worthwhile to say and not whine line the rest of the "omagad, ability lag, fix it now. Crowd".

 

What Tiron is saying is exactly right and one reason for the so called ability lag. And if it were due the engine or bug, the everyone Sokos have it. But I am not having it atm or newer have had it on tor. Abilities go off when i press the button and not 0.5 secs later.

 

From what I can see, the problem is that most people are under the impression that the ability doesn't 'go off' until the animation is played and the damage registered.

 

It, in fact, goes off as soon as the server accepts you using it, as indicated by your GCD and/or ability specific cooldown activating and the appropriate resource being used/generated. These effects can START before the server accepts it, but will be immediately reverted if it rejects the command for whatever reason, causing an apparent 'short' GCD and no use of cooldown or resources.

 

The animation is just there to look pretty, and the damage appears when it does purely to make it look like it was the projectile that did the damage instead of you pushing a button.

 

The server has already calculated and applied the damage before you see it applied on your client: the way it's acting, I think possibly before you even see the animation START!

 

Please explain why using abilities off the GCD or ones used after using an ability thats not on the GCD often do nothing if activated, but still use our resources and reset the GCD?

 

See riposte, overload

 

Because there's an actual bug with non-GCD abilities that causes them to not interact correctly with the GCD. it's a very specific bug limited to a certain type of abilities.

 

That's got nothing to do with a 'delay', it's simply malfunctioning. It's also completely independent of all the other things people are lumping it in with.

 

It's like complaining that your car doesn't stop when you hit the breaks while you're riding on the rims because your tires came apart due to underpressure, have the brake pads installed backwards, don't have any brake fluid, and didn't think to use the emergency brake.

Edited January 5, 2012 by Tiron_Raptor

[Darkhosis]

You're wasting your breathe dude. They keep saying you don't get it when they're obviously the ones NOT getting it.

 

Blame your ISP and packet loss on your speeder dismount. I don't have this fabled delay issue... Seems more like a rumor that's gone out of control. None of the videos I've seen show me anything but lag and/or active queue window timer not set correctly.

 

Hard to fix a bug that doesn't exist or that is due to people's crap ISP. So packet loss happens? I think we can all agree on that.

[DirtyDozen]

I think the OP is on to something. I don't have the problem but I've always hated spamming buttons. So I work a rotation and try to time the GCD to where I setup my next ability within the queue time. Works perfectly for me. But I've been playing like this for a while now so it's natural for me.

 

I'm not saying people aren't having a problem though.

[Tiron_Raptor]

You're wasting your breathe dude. They keep saying you don't get it when they're obviously the ones NOT getting it.

 

Blame your ISP and packet loss on your speeder dismount. I don't have this fabled delay issue... Seems more like a rumor that's gone out of control. None of the videos I've seen show me anything but lag and/or active queue window timer not set correctly.

 

Hard to fix a bug that doesn't exist or that is due to people's crap ISP. So packet loss happens? I think we can all agree on that.

 

The queue window DOES have a problem, in that it generally takes it longer than the remaining GCD to actually activate the ability.

 

Trick being, it's described as a 'window', which suggests that the setting controls the MAXIMUM amount of time you can hit the button early. Your post implies that it just waits the amount of time you've specified...which would be misleading in the first place, and doesn't appear to correspond with what I've seen in the second.

 

It would correspond, however, with it not being very granular, and only having a few possible delays, of which it picks the shortest that is longer than the GCD.

[belialle]

Thank you for posting this, OP. Though I fear that it's going to go right over a lot of people's heads. They just won't take the time to read these posts and think about it. Good information though. I appreciate the insight.

 

As for myself, I am not experiencing any "ability delay". I have my action queue window set at 0.0 currently, and I am quite pleased with character responsiveness. I was pleased with character responsiveness when I had it set higher, too, though I think I prefer the way the game feels when I have it set quite low.

 

The mass hysteria over this is pretty baffling to me.

Edited January 5, 2012 by belialle

[DarthMurdek]

The 'ability delay' is not an animation issue. Activating another ability, including an instant-cast 'interrupt' ability, DOES break channels. The actual cause is pretty simple:

 

The 'ability action queue window' is malfunctioning. It's either not setting the delay before firing properly or the function that activates it is sometimes taking longer than the remaining GCD to process, or some other similar thing. Regardless, the result is the same: if you try to activate an ability BEFORE it is off GCD, it takes longer than the remaining GCD before it activates in most cases. There seems to be a minimum amount of time after something is queued before it can fire.

 

There are two ways to work around this: one mitigates, the other eliminates.

 

It can be mitigated by setting the ability action queue window (in the 'control' section of the options) to 1.0 and trying to hit abilities as early as possible: the later in the GCD they're hit, the longer the delay after the GCD before they fire in most cases. At 1.0, hitting as early as possible, the delay after GCD end is VASTLY reduced, and occasionally eliminated...though not often.

 

It can be eliminated outright by...not hitting the button until the GCD's actually finished. If the ability is already off GCD, the ability action queue is not used and there is no delay. If you hit it PRECISELY when the GCD is finished, you can actually get it so tight that the icons never light between the end of one GCD and the start of the next.

 

Setting the ability action queue window to 0.0 eliminates any possibility of encountering the delay, but also makes it so you MUST wait until the end of the GCD to activate an ability: if you hit it early, even by a microsecond, it simply fails silently and never goes off at all(though it would make spamming the button actually work as expected).

 

In short, if you're experiencing 'ability delay', you are hitting the ability too soon.

 

that may solve the delay on instant abilities but it still wont help my sniper get his snipe skill off without the bar going up twice.

[Tiron_Raptor]

Thank you for posting this, OP. Though I fear that it's going to go right over a lot of people's heads. They just won't take the time to read these posts and think about it. Good information though. I appreciate the insight.

 

As for myself, I am not experiencing any "ability delay". I have my action queue window set at 0.0 currently, and I am quite pleased with character responsiveness. I was pleased with character responsiveness when I had it set higher, too, though I think I prefer the way the game feels when I have it set quite low.

 

The mass hysteria over this is pretty baffling to me.

 

The delay caused by the queue is fairly slight, and easily mistaken for simple lag. The only thing that really gives it away is the sheer consistency of it, and the fact that it's practically always instantaneous if you hit the button after the GCD finishes.

 

The trick is, the queue doesn't delay you if you hit the ability after the GCD finishes, only if you hit it during the actual window before the GCD finishes. You can leave it on and attempt to time it correctly, and you'll only be delayed by the queue if you miss early. If you hit perfect or miss late, there's no delay even with the queue on.

 

Personally I think for most people 0.0 is a bad idea: it penalizes you pretty severely for missing early, so it's only useful if you want to be dead on SURE that there's never a queue-induced delay. And then you have to either have exact timing or spam the crap out of the button.

 

If you're spamming the crap out of the button ANYWAY, I highly suggest using 0.0 ability action queue window. Otherwise, I suggest leaving it on unless you're VERY sure you can time it precisely.

 

that may solve the delay on instant abilities but it still wont help my sniper get his snipe skill off without the bar going up twice.

 

I'm not sure what you mean by 'bar going up twice'. Do any other abilities of the same sort do the same thing, especially the smuggler equivalent?

 

It could be an ability specific bug like the one ravage sounds like it has, and not a general ability issue at all.

Edited January 5, 2012 by Tiron_Raptor