You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This option was added in 7.0. While the concept to prevent accidental input is sound, the execution is flawed. Double weaving an ability and its changed ability causes unnecessary delay on the second ability because the setting uses a 1s recast timer instead of a shorter one. Further, the recast timer doesn't begin until the button changes icon, which is exacerbated by latency.
Consider these example timelines.
Setting off:
0s GCD
0.6s oGCD A
1.2s oGCD B
Setting on (0 ping):
0s GCD
0.6s oGCD A (button changes icon and 1s recast timer starts)
1.6s oGCD B
Setting on (200 ping w/ NoClippy)
0s GCD
0.6s oGCD A
0.8s (button changes icon and 1s recast timer starts)
1.8s oGCD B
In my opinion, the solution is to use a lower recast timer than the animation lock (say 0.3s), which prevents accidental queuing of the changed ability, but still allows it to be queued during the duration of the initial ability's animation lock.
Thanks!
The text was updated successfully, but these errors were encountered:
This option was added in 7.0. While the concept to prevent accidental input is sound, the execution is flawed. Double weaving an ability and its changed ability causes unnecessary delay on the second ability because the setting uses a 1s recast timer instead of a shorter one. Further, the recast timer doesn't begin until the button changes icon, which is exacerbated by latency.
Consider these example timelines.
Setting off:
0s GCD
0.6s oGCD A
1.2s oGCD B
Setting on (0 ping):
0s GCD
0.6s oGCD A (button changes icon and 1s recast timer starts)
1.6s oGCD B
Setting on (200 ping w/ NoClippy)
0s GCD
0.6s oGCD A
0.8s (button changes icon and 1s recast timer starts)
1.8s oGCD B
In my opinion, the solution is to use a lower recast timer than the animation lock (say 0.3s), which prevents accidental queuing of the changed ability, but still allows it to be queued during the duration of the initial ability's animation lock.
Thanks!
The text was updated successfully, but these errors were encountered: