Request for Native High-Ping Compensation Feature

[Jeeqbit]

They could try to replicate that, but the easiest way for them to do it would be to simply not have delays on abilities. It just makes them feel bad to use, especially at higher pings.

I think a delay makes sense when using the same ability twice, because I often had an issue with two gap closers being used at once in the past after they got charges added.

Another issue is swiftcast. The time it takes to communicate with the server and back just to prevent your client from beginning a cast is too long, but if the effect was clientside I could see it being a problem. Nevertheless, it's probably the other main problem that happens at high pings and ways to improve it should be looked at.

[Iselion]

It's not even just the delays, it's that jobs that are extremely heavy on weaving such as Ninja, Machinist and Gunbreaker completely fail to function at higher pings. From what I've seen, somehow, third party tools seem to be able to ameliorate this without altering the client detectably. I cannot explain why it does so, nor do I want to break the rules in using one, so I'm left to speculate that it is some front-end problem where the client pings the server after clicking a button and waits for a response before allowing you to use another one. I can't for the life of me understand why it would be this way.

[Jeeqbit]

I cannot explain why it does so, nor do I want to break the rules in using one, so I'm left to speculate that it is some front-end problem where the client pings the server after clicking a button and waits for a response before allowing you to use another one. I can't for the life of me understand why it would be this way.

My understanding is that's still the animation delays. The way the delays are implemented, they apparently don't account for ping, so high ping makes the delays longer. That's why the delays should just go. Then they wouldn't need to account for high-ping because there wouldn't be a delay in the first place.

Might that allow for quadruple weaving? Sure, but there are two ways they could handle that. They could either accept that as a thing or they could implement a hardcoded limit on the number that can be pressed in a given 2.5 seconds or make each GCD usage allow the usage of 2 OGCDs.

The reason they feel bad to use is because of the delays and removing them would solve one of the main things that causes people to feel the gameplay isn't smooth compared to other MMORPGs.

[Absimiliard]

Might that allow for quadruple weaving? Sure, but there are two ways they could handle that. They could either accept that as a thing or they could implement a hardcoded limit on the number that can be pressed in a given 2.5 seconds or make each GCD usage allow the usage of 2 OGCDs.

I don't believe quadruple weaving is something they would even need to account for. Those ogcd abilities will still be kept in check by their cooldowns.

[Jeeqbit]

I don't believe quadruple weaving is something they would even need to account for. Those ogcd abilities will still be kept in check by their cooldowns.

That's my thinking as well. Does it actually matter if someone quadruple weaves and then doesn't weave at all the next GCD? As long as they get pressed then they get pressed and go on cooldown.

We could argue that it then becomes suboptimal to not quadruple weave but the same argument could be made now for when people don't double weave and they still clear everything.

[Shurrikhan]

It's not even just the delays, it's that jobs that are extremely heavy on weaving such as Ninja, Machinist and Gunbreaker completely fail to function at higher pings. From what I've seen, somehow, third party tools seem to be able to ameliorate this without altering the client detectably.

Yep. They track your ping and then subtract the time added by the confirmation message resetting your animation lock timer, making it seem as if it didn't add to your animation lock timer.

As such, rather than a 250 ms player having a 750 lock-out and a 50 ms player having a 550 ms lock-out, they just all have the set 500 ms of lock-out.

Which just brings us back to the heart of the matter: You can have ping compensation, just like those plugins provide, to keep things fair and smooth for everyone... or just not arbitrarily sabotage the experience in the first place, by not having the confirmation reset the animation-lock timer. Either way works.

For my part, I like that there's the consistent minimum, at least, so our animations aren't all being garbled.

I wouldn't even mind it being slightly higher (up from .5s to .65s at most) or GCD-scaled (from three-tenths to a third of a GCD, allowing for almost exactly double-weaves [three animations per GCD] each time), assuming we allowed any and every action to queue correctly and maybe including a tiny bit of QoL whereby buff durations fading don't start until their animations (or animation lock timers) complete.

I just don't like latency impacting what one can and cannot do when that latency is smaller than the queuing period anyways.