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

[Shurrikhan]

Tests by whom? I certainly don't recall any of the sorts from us, especially not Theoryjerks beyond prior work from Orinx, Alo and I.

However, we since know animation locks with absolute certainty from more recent, current discoveries.

Anim lock is sent with the Effects message from the server as a float, which requires rtt ms (ping ms * 2) or round trip time since ActionStart sends out a request and the server acknowledges, then sends a reply back with the anim lock in Effects that the client then processes.

Instant weapon skills/spells, and most oGCDs are 600ms. If you haven't, read my previously posted link:


Divide the difference of gcd - 1800ms by 6 and that's the threshold.

How they execute after the fact is subject to such a myriad of factors that it's not even just up to latency.

But your numbers are incorrect for how things process it most definitely is not ms * 3. If it were I certainly wouldn't take 3s to double weave! We have done the research for the timings at various levels of latency.

Last I'd seen these things researched in detail, most agreed that the ping lacked margin only in at most one direction, the client being able to queue skills (send its query) in advance and the server needing only send a confirmation that the skill could be used, thus costing the ping effectively only once per GCD. At that time, it did not appear that 0 and 83 ms (or, 33 and 116) ping, for instance, were .5 seconds of double-weaveable GCD apart, as they would be if the effect of ping was twice that ping value, without any margin, per animation.

I live very close to the new location of the XIV servers, which is about as far as possible from the former location while remaining within the continental US. Over that shift, I shed about 75 ms of ping. The difference to my double-weaving, however, was less than .1 seconds, on frame testing. Between other factors in typical instanced gameplay, the server move had virtually no effect on what GCD I could double-weave at.

If there are more recent studies, I'm glad to hear them, but I never said anything about... anything taking 3 seconds. Neither 1899 ms nor 1999 ms are... 3 seconds. Am I missing something else here?

I'm assuming I did and am reading through your link now, which I'd somehow missed before.

Oh, and to answer the first question: The tests were from Bluegarter and Dervy, with process documents only from the latter. I suspect I slightly misremembered the era-context of the tests, however, as there were apparently changes reported near the end of Heavensward due to alleged speedhacking on skills exceeding the GCD down to a GCD's time (most noticeably on BLM, though I suppose that may have also affected double-weaving in some way(?)). Either Dervy and BG got it wrong or things really did change at that point and their and my tests were simply done prior and are therefore now obsolete. In either case, though... damn, double the effect of ping. That's... pretty harsh on the vast majority of players. I have to wonder if there's any way they can preemptively query the server to give some safety margin when queuing skills over which ping wouldn't affect us.

[Renkei]

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.

[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.

[Renkei]

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.

As a Dragoon Main i am aware of the Timings regarding animation lock, I am telling you that you can Action Queue OGCDs, that's the only way to get the Optimal Recovery from the animation lock, I've done plenty of research on this subject as well it is dependent on lots of different factors including frame rate, But the check for oGCD usage aka the server check doesn't account for animation lock. Animation Lock is client-side. The Server check determines whether or not the attack occurred within the oGCD Timer (so you can't jump twice in 30 seconds, or jump every 25 seconds, this is to prevent cheating.) It's been common knowledge since ARR that oGCD's are 600ms. some of them are even longer (1200ms Star-Diver)

Ping is a Factor Yes, but so is Frame rate- Input delay Etc, A Player with 60 fps vs 120 fps

4.16ms = 240 fps

8.3ms = 120 fps

16.7ms = 60 fps

33.3ms = 30 fps

the best thing you can do is is try reducing the amount you need to double weave, or sit there and keep running dummies over and over, and write down every abilities oGCD time, remember that you can start queuing an ability at 600ms and the second ability at 1200ms, Animation Lock itself isn't ping dependent. What your Referring too is the oGCD Check by the server, It has no effect on whether you use the ability or not.

I am telling you this because Cast timers are Client side, but there is a server side check to make sure the cast was done within the GCD Window, but the check only occurs if the action happens during the server Tick, Other Animations are Client Side too, If you have ever ran into someone cheating in front line for example. the reason why its like this is because you cannot have an animation check server side, the server doesn't do animation checks, it does action checks andALLGCD checks to prevent cheating. oGCD's can be queued after 25% of a GCD but multiple Cannot. (Second Ability can be used at 1200ms but cannot be queued. go ahead and try it, Animation lock isn't an issue for single weaves because of this, double weaves tend to be the issue, which shouldn't be a thing, honestly there does need to be minor adjustments to abilities, some things do need to be extended by 1-2 seconds just for quality of life reasons.

[Renkei]

(i have no clue what they have tested, But there's huge pointers that animation lock is client side.) these metrics are based on my own personal testing, I did in fact use a frame limiter in order to test these, the best way to test this is to use a high speed camera, a mouse with an LED attached to the switch, or a macro that weaves in perfect intervals, There is also Priorities in the game such as Player-Identification-Number, Which Determines who gets hit in what order, For Example, If the boss were to knock back EVERYBODY, everybody doesn't get knocked back at the same exact time, they get knocked back based on their priority, this also has an effect on ability usage. when you go into an instanced server, every player is marked by the server with a number from 1-8, this Priority effects the delay at which it checks each users data, as the data cannot be handled asynchronously. People are always talking about Their latency they forget to take into account the games Netcode, Which is very very far from perfect, which is why abilities are client side, but the timers of the GCDS are client side with a server side check, is it possible to spoof the server side check? Probably, I don't recommend trying. Input delay itself will shift the ability back and apart, there isn't much that can be done to get the ability to queue perfectly in a double weave.

Think of it this way, All Abilities have a client side timer and a Server side timer, but all Animations are Client side only, the server does server side checks to see if an ability is ready, as if it didn't do these checks you would be able to cheat client side, the checks prevent you from cheating but at the same time don't because the timers themselves only become out of sync with cheating, the Execution of the second ability earlier is prevented by client side animation lock not server side animation lock because there is no server side check for animation lock, there is only a server side check for ability timers.

The Animation locks were put in place on purpose to balance classes so you don't have the Capability to use all your cool downs after your first attack which would be inhumanly possible.

The Game Does use an internal clock, The Theory you were mentioning was saying that Each Ability has a Server Side Animation Check, But Since Animations are Handled Client Side - Frames Per Second does actually effect the speed at which the game processes, which is why at the launch of shadow bringers the Devs tried locking the max frame at at 90, Lower frame time results in lower input delay which in turn gives you faster input, allowing you to shave time off the Second ability weave as soon as the animation lock ends. The Issue SE seems to be having here is that they cannot allow " /ActionQueue " which is actually a command in game, to function on anything but GCD and oGCD Abilities on first use, because if they allow action queue to work at all times it would allow macros to effectively execute multi weaves with hardly any spam, i guess its just a way to make the game funner and more engaging.

The Game does Operate with a timer like all games, Surprisingly from my Calculations the net-code isn't the best around, we are talking about Incoming 1hz server refresh rate, which means the game checks you every 1 second, In Total the game runs at about 2HZ, Checking input at 1hz, and output at 1hz, the game checks within a time stamp frame and margin of error to determine whether or not an action is legit, the fluidity is more in the games client side exceptions, which the game actually prefers over server side interactions, Monster Abilities on the other hand and your Defense is absolutely Server side, while Offense is handled Client Side, for the most part, there are in fact server side checks, but they are checking timers of GCD's, a timer for animation lock doesn't exist, i don't see why the server would even ask "is the character animation locked successfully?" because there are some instances where your animation lock can be interrupted (Pulled or knocked back)

In my opinion everyone would have a better experience if there was an improvement to net-code i have always advocated an improvement of Net-code over an improvement of the Games Graphics.

[Nemekh]

TJ (or what will soon be rebranded as Allagan Studies) is the group Dervy founded that my colleagues and I lead on now, which includes Yugl from Bluegarter and other notable theorycrafters for the game. Dervy alas doesn't really play anymore, but he hangs about here and there. Our latest How To Be a Math Wizard doc is meant to include the more recent findings on anim lock. Any findings from bluegarter and dervy prior are going to be really dated.

Saying they are not subject to ping is false, because the net packet communication is what has to happen first before the server assigns the anim lock to a specific address in the game memory for the client to prevent you from doing anything. It is also incidentally, during this anim lock, that queueing is possible because during this window particular action inputs are then assigned elsewhere in memory as a "do this thing next" process. Things that don't get assigned to this part of the memory incidentally cannot queue like regular actions, such as the System action Sprint and consumables such as pots and food. As well as the AST action that more recently was changed.

Hardcast GCDs also have animation lock at the tail end, the server enforces 0.1s which is what we've dubbed caster tax and why a GCD hardcast is actually GCD+0.1. This is also dependent on the Effects message from the server, however, GCDs have an element of ping correction that OGCDs do not. This is why on Japanese servers with 270ms I have a faster average GCD than I do on Chaos with 14ms.

As for the 3s mention, it's because of the fact that my main is on NA servers where I play with >200ms. On Chaos I can triple weave faster than I double weave on NA.

Fps does matter, but fps is a factor after the fact, where it's 2* ping -> enforced client anim lock from the server (where queueing is possible) -> fps as the anim lock timer decays. Naturally there are many other factors, many of which I outline on my site for smn in that same section, as well as the big meme that is instance server quality where a normal "fast" instance will make things feel like a hot knife through butter, then a slow instance will make things feel like wading through treacle.

What lead to us knowing locks with absolute certainty is more suited for the doc and website resources. The irony is that it was under our noses the entire time.

[Renkei]

I think that is misleading, Because you can disconnect from the game, Receiving no Commands from the Server and before you disconnect, you still have the ability to use Abilities that are oGCD and GCD and you still are at the Mercy of Animation lock. What i am Implying is Animation lock is NOT handled Server side, What is handled Server side is Action Queues, Action Queues and Animation lock aren't the same thing clearly.

I've used Packet Detecting Programs to Detect how the game Looks at Action Queues and the Game does in fact Queue things based off the Client, then has a Server side check to see that the client isn't being Manipulated. No where in those Packets does it issue a command outside of Memory itself to apply the Animation Lock, I Appreciate all the Research you guys have done, But Animation Lock itself has nothing to do with Ping, You are clearly confusing the Action Queue System with Animation Lock.

Of course Ping Effects things, but does it? Does it actually, what you see on your screen and what you see on the server are two different things no matter how you look at it, and within margin of Error of 200ms like Yoshi-p has said, your actions will always be adjusted, because each action comes with a time stamp that is send to the server and adjusted within margin of Error, The Effects Messages you are Talking about Applies to Effects such as buffs and debuffs Registered as a server Event, These Server Events include knock backs and stuns, but Skill Animation Lock is client side, there is no effect check, otherwise you would be stunned by the server which would prevent you from using any action completely, Imagine how impossible it would be to run this effect perfectly after a GCD usage when the game server has to adhere to a set clock? it would have to complete the cycle as soon as the next tick starts.

Animation Lock is 100% Handled Client Side. There's only a server side check for Ability timers. If the game had an Animation Lock Check then in Theory if you were to somehow Magically be able to use two abilities before the Animation Lock Check the game would Cancel the Effects Animation Lock Call . just like it cancels a GCD when used impossible fast. I know from testing 100% that its client side. The Action Queue Lock your describing is purely Action Queue Lock, and Not Animation Lock.

[Nemekh]

You can call it misleading but that's how it works. When you pokeball you literally have 0 anim lock and can spam everything seamlessly because the server is never responding back to you with the anim lock your ActionStart is trying to get a response for. That is how the infinite hellfrog spam examples were possible during the really bad Chaos dc connection issues. Whether this spam actually gets processed by the server is another matter, hence the packet loss problem where barely anything occurs despite your best efforts. The game however, will still typically enforce an action rate of 500ms even with animation lock completely removed.

It was already explained earlier that anim lock is sent from the server as a float in the Effects message that the client then enforces(which is the part you're saying is client-side, this part is correct and is not being disagreed with). That is a matter of fact. Queueing also happens during said animation lock. That is also a matter of fact.

When damage and enmity are confirmed is entirely separate and after the fact.

I wouldn't admit to using ToS infringing tools in that manner, fwiw.

[Renkei]

That action you are talking about is Called Action Queue, The Action Queue Determines a Successful Usage of an Action Server Side, then sends the data back to the Client Whether or not the Action was Successful or not, it has no bearing on the Amount of Time an Animation is locked, I Don't Recommend using any tools that go against the ToS Neither am i telling anybody to use them. Nice Straw-man though.

The Server Side Action Queue does not determine Animation lock, That's why i am saying you are being misleading, I'm aware the game enforces action rates to prevent obvious cheating.

But The Action Queue System and Animation lock systems are entirely different things, the Effects message you are Mentioning is the Action Lock System. It prevents GCDs from being used faster then intended, It does so by Running a 500ms check every server tick (1000ms if not in a high end duty.) , there are abilities that do run this check when you are in animation lock, but is separate from animation lock. this check happens after a queued ability whether its GCD or oGCD. This is purely the Action Lock State that determines in 500ms whether or not an ability contacts or not. if the client fails to respond accurately in 500ms the GCD resets, which is why you get GCD resets in packet loss if the server fails to receive the Action Lock State after an action is successfully queued.

What you are Describing as i keep repeating is the ACTION LOCK, not animation lock. Hellfrog doesn't even really have animation lock, it doesn't and never has locked you in place.
Animation lock is clearly when you Cannot move, We are talking about Abilities like Assassinate (Server Side Lock if i remember correctly.) , Jump.

Action Lock is Different, Action Lock Prevents abilities from going off, Not Animations, if it only prevented animations then the abilities would still go off, That's why i am explaining to you why it sounds misleading.

You have Action Queue > Action/Ability Lock > Server Tick (Damage and Effects Resolve Anti Cheat Check)

The Action Queue and Ability Lock happen at the same time, the Ability Lock Check Occurs , then the server checks it with a Lockstep protocol Obviously this protocol prevents anyone with 500ms ping from avoiding the 500ms Action Lock check. I know these things from working with and on net-code.