[Question]: What happens if Ping Plugin value is inaccurate?

[AnzeG8]

I use a split-tunnel VPN and the Ping Plugin reports the ping much higher than it really is. Game is set to bypasses the VPN, but the Ping Plugin reads a value like it was going through it. What would happen with DoubleWeaver in this case? Say the game has 250ms ping in reality, but PingPlugin gives a 350ms value. Will it overcompensate and cause a negative 'cheat' ping result?

[Bluefissure]

There's a 500ms limit to the laggingTime, if PingPlugin is detecting the ping to be larger than 500ms it'll take 500ms as the latency. 350 is not exceeding the limit so it takes 350ms as the latency.

As for the cheating worry, actually, the latency is not the only thing considered when modifying the animation lock, the actual elapsedTime from action starts is also considered, it will be counted if it is smaller than the ping latency.

[AnzeG8]

Neat, so I shouldn't run into any issues going below what should be allowed, regardless of PingPlugin accuracy.

I've tried to get the plugin now, but the only one that comes up when I add your repo is MapLinker. Has it been updated for Dalamud 6.0 release?

[Bluefissure]

Neat, so I shouldn't run into any issues going below what should be allowed, regardless of PingPlugin accuracy.

I've tried to get the plugin now, but the only one that comes up when I add your repo is MapLinker. Has it been updated for Dalamud 6.0 release?

I forget to change the link in README to my api4 repo, sorry. You can find it at https://github.com/Bluefissure/DalamudPlugins/tree/Bluefissure-api4.

[AnzeG8]

Thanks, working now!

Minor question, does the /doublewaver command mentioned in the ingame description do anything? It doesn't return any info text or open any config window. Sorry to be such a bother and thank you for your help

[Bluefissure]

Thanks, working now!

Minor question, does the /doublewaver command mentioned in the ingame description do anything? It doesn't return any info text or open any config window. Sorry to be such a bother and thank you for your help

That command does nothing for now, maybe I can add a simple UI combined to it in next version.

[AnzeG8]

There's a 500ms limit to the laggingTime, if PingPlugin is detecting the ping to be larger than 500ms it'll take 500ms as the latency. 350 is not exceeding the limit so it takes 350ms as the latency.

As for the cheating worry, actually, the latency is not the only thing considered when modifying the animation lock, the actual elapsedTime from action starts is also considered, it will be counted if it is smaller than the ping latency.

Hmm, I've done some testing with split-tunnel vs full vpn vs normal connections and how the plugin reacts. It feels like it does overcompensate when split-tunneling is on with wrong ping displayed. I could triple weave in that scenario but not in others. Might try taking it into instanced content and see if FFlogs will reject it with this setup. Any chance a debugg window would be added at some point with realtime info?

[Bluefissure]

There's a 500ms limit to the laggingTime, if PingPlugin is detecting the ping to be larger than 500ms it'll take 500ms as the latency. 350 is not exceeding the limit so it takes 350ms as the latency. As for the cheating worry, actually, the latency is not the only thing considered when modifying the animation lock, the actual elapsedTime from action starts is also considered, it will be counted if it is smaller than the ping latency.

Hmm, I've done some testing with split-tunnel vs full vpn vs normal connections and how the plugin reacts. It feels like it does overcompensate when split-tunneling is on with wrong ping displayed. I could triple weave in that scenario but not in others. Might try taking it into instanced content and see if FFlogs will reject it with this setup. Any chance a debugg window would be added at some point with realtime info?

In that case, I think it's better to modify the limit to 300ms or so, can you provide the debug loglines so I can check?

You can change the dalamud log level to Debug (by calling /xldev, and go to Dalamud -> Log Level -> Debug), and it will output log lines containing the action id, elapsed time, RTT from PingPlugin, lagging time from RTT and elapsed time, and the final animation lock change status. You can open the dalamud.log file on your disk or call the /xllog command in game to open a log window.

[AnzeG8]

No VPN no vpn.txt

Full VPN full vpn.txt

Split-tunnel (game set to bypass the VPN, but whatever the ping plugin is doing seems to report VPN'd ping) split_tunnel.txt

Didn't know Dalamud had this debug built in, neat. I did a test sequence on my RDM against a dummy: hardcast veraero -> verthunder -> fleche (oGCD) -> contre sixte (oGCD) -> Engagement (oGCD) -> veraero for all 3 of those. Small sample size of one for each so maybe my inputs were not the exact same ms.

[AnzeG8]

I think I will set up a mouse macro tomorrow to do these same inputs but with exact time intervals so it's identical in each test. From reading these logs I feel like my inputs aren't consistent enough to make any determination.

[Bluefissure]

Thank you for the detailed log files! That helps a lot.

I've done some analysis to the log files and found for the split-tunnel log, it does overcompensate as if there's no delay for the human/player reaction. You can take a look at the relative timeline of action request & receive.

-5.16 veraero ->
0.000 verthunder ->
0.299 -> verthunder 451ms -> 0.750
0.750 fleche (oGCD) ->
1.257 contre sixte (oGCD) ->
1.305 -> fleche (oGCD) 323ms -> 1.628
1.618 Engagement (oGCD) -> 
1.805 -> contre sixte (oGCD) 326 ms -> 2.131
2.312 -> Engagement (oGCD) 284ms -> 2.596
2.590 veraero ->

You can see that you're not actually inserting three oGCDs into the interval of verthunder and the second veraero, but you only delayed ~90ms for inserting the third oGCD, which is not possible because human need time to actually move their fingers and the server latency cannot be real 0. It is possible in this case because the ping plugin didn't get the accurate RTT and the leftover time is used to press the third oGCD.

Moreover, the detection of in-game actions didn't consider the server processing time, which means it assumes

• there's no server latency
• the server can process the action request instantly.

And the second one may be the reason why it overcompensates when the PingPlugin is not accurate.

I'm thinking of adding a constant server processing time to the elapsed time detection (~100ms, which is ~50ms converted to the server latency). Hope this will fix the problem.

BTW I'll change the server latency limitation to 300ms. 500ms is too large since animation lock is usually only 600ms.

I can make the change and test it later today, if it's all good I can do an upgrade as well.

Thanks for helping by providing the detailed log files again.

[Bluefissure]

Upd: I had trouble connecting to the CN game server yesterday (and my sub is up in the global server), I can take a look this weekend.

[AnzeG8]

No rush. Thank you for looking into this, I appreciate it.

[Bluefissure]

Upd: I updated v1.0.4.1 just now, you can take a look. @AnzeG8

[AnzeG8]

Awesome. Feels much better now new splitVPN.txt Here's a log with 2 attempts at triple weave attempt and it clips for sure now. 2 is still ok.

Thanks a ton, I appreciate your work on this