Reduces the negative effects from playing with high latency (ping).
When you use an action, the client will apply 500ms animation lock, which will prevent you from using next action for a short amount of time. When the server processes the request, it will give your game client instructions about the supposed duration of animation lock (usually 600ms). Ideally, you should be able to use next action 600ms after the previous action, but the game client will let you use next action 600ms after server response, meaning that you're waiting for time taken for server response + animation lock time. Ideally, XivAlexander would simply get rid of time taken for server response part, but the server will rarely respond immediately even on sub-1ms ping, so you are given choices on how to make time taken for server response exclude your ping.
WARNING: Because of how it works, this addon is only a step away from flat out cheating. Changing temporal constants in code below the limit means you're effectively claiming that your latency is below zero, which is just impossible. Do NOT modify temporal constants in code, or you ARE cheating. You have been warned.
Example
[0.0s] Action A Request
[0.5s] Action B Request
[0.6s] Action A Response (1.0s lock)
[1.1s] Action B Response (1.0s lock)
By default, the client will let you input at 2.1s.
This addon will force the next input to be accepted at 2.0s.
Subtracts the round trip time measured from ICMP ping (or TCP_INFO_v0 if unavailable) from animation lock information response from the server.
When your ping fluctuates, it might take more than 500ms to receive a response from server, in which case, by game design, you are allowed to use next action regardless. Your client will receive two responses from the server, and only the latter animation lock information will take effect. Mode 2 and 3 will compensate for that by adding up animation lock information received.
Mode 2: Simulate RTT (75ms)
Simulates the environment where you would be receiving server response exactly 75ms after you use an action. From testing on sub-1ms connection to server, responses often took somewhere between 50ms and 100ms. Sometimes it takes less or more, but in any case, 75ms is the average.
Mode 3: Simulate Normalized RTT and Latency
Same with Mode 2, but will sample time taken for server response - round trip time measured from ICMP ping values, and use stabilized value in place of 75ms.