RoundTripLatency calculation when simulating Lag

[wormszer]

Version Number and Operating System(s):

Windows 10 64 Bit 2389acd

Expected behavior:

Running the tool clumsy to simulate latency on the network the NetworkingPlayer.RoundTripLatency should be calculated to reflect the added latency.

Actual behavior:

Using the Ping command the latency is taken into account. The method used in the UDPPacketComposer.MessageConfirmed function, looks at a specified network time of the last completed packet. This method is failing to take into account the latency.

While the actual data being transmitted is taking the expected time, Forge thinks that this reliable packet should of been acked, and resends it. This results in the network being flooded with resends.

For example: the simulated latency is 250ms, the error calculation says its is 2ms. So every 2ms it tries to resend the data.

A side note if there is no data being sent, then the NetworkingPlayer.RoundTripLatency will be correct, because in the NetworkingPlayer.NextComposerInQueue will issue an actual ping when idle.

Steps to reproduce:

Start a network game that is sending data every tick. Start clumsy, introduce lag. Client will start lagging, can look at wireshark to see resends happening extremely fast. Put a break point in UDPPacketComposer.MessageConfirmed to look at RoundTripLatency

[Optional] Discord Username:

shadowworm#6629

[wormszer]

Looking at it more it might be that, because the latency is not correct. Its resending lots of messages, It finally gets a completed message back, and looks at the last time of the last resend, compared to the completed message. This ends up being very short, because it has been spamming resends. Instead of looking at the actual time of the completion packet was sent. Seems it should be something like the time from the first send to the completion event