Please let reduced GCDs scale with the base GCD (Attack Speed/SkS/SpS)

[Shurrikhan]

They do it's called Action Queue, If you Press The Attack ONCE at the last .5 second window it'll carry over the attack with a 200ms grace period you can use this technique to 5 cleave at 380 skill speed on warrior too.

That's the case for GCDs. It does not, however, appear to be the case for oGCDs or therefore animation lock. Check out Nemekh's link on the previous page. His and his friends' research is the most recent. That said, even the old stuff I'd been referencing showed a safety margin of at best 55 ms for oGCDs, and it's probably outdated, with animation locks having gotten more ping-dependent since.

[Interesting informative stuff]

(Sorry for the Edit-reply. I've run out of daily posts.)

I see. Or, mostly, I see. Probably.

To be clear, what I meant was that I thought, from what Namekh had mentioned, that the servers cannot respond to give the skill permission to activate before the previous animation lock ends, thus incurring additional uptime penalty based on ping. I am using the term "animation lock" and "minimum delay of future actions consequent to taking any other action" interchangeably here. I realize that there have been several exceptions to the standard animation lock, such as Assassination, Plunge (formerly), Wind Tackle/Riddle of Wind, Jump (formerly even more so), Spineshatter Dive (when closing a distance), Dragonfire Dive (when closing a distance), Star-Diver, etc.

Doesn't this conflict with theoryjerks' findings, though? And why is it, then, that some players can weave the exact same combination of oGCDs when queued equally early while others cannot? I can't imagine the game literally timestamps its individual frames and waits until not even a split fraction of the last frame's timer remains before allowing the next animation to start instead of simply using an internal clock that functions regardless of frame count. I know frame-based exploits have been possible in previous FF games but it seems basically unthinkable that a modern MMO would take such a roundabout and inefficient method...

Moreover, wouldn't whatever input delay merely shift things back, not actually split them further apart?

I'm pretty confused, so I'll be doing some fiddling about with a frame monitor (and maybe a mechanical macro to get the timing perfect during the testing) if only to try to figure whether I'm correctly understanding what you've said. Personally, I tend to spam my second oGCD very quickly when very close to the end of my first oGCD, so I'm not sure if I'll notice much more to optimize.

Thank you, by the way, to both of you. I clearly thought I knew a lot more than I actually did and it's good to be made aware of my shortcomings here, especially to guide whatever future suggestions I might have.