Closed albertok closed 4 months ago
Thanks @albertok, both for looking into it and providing this PR! This looks promising, I'll do some testing on my end too.
Tested locally as well - although it didn't disconnect ( somehow ) at 20% packet loss. The improvement is massive! It went from barely playable to playable with some slight jitters! Which is pretty good at a 200ms roundtrip with 20% packet loss.
This is the command I've used:
sudo tc qdisc change dev lo root netem delay 100ms loss random 20
Good catch on the unnecessary resimulations!
Tested locally as well - although it didn't disconnect ( somehow ) at 20% packet loss. The improvement is massive! It went from barely playable to playable with some slight jitters! Which is pretty good at a 200ms roundtrip with 20% packet loss.
This is the command I've used:
sudo tc qdisc change dev lo root netem delay 100ms loss random 20
I had been using
sudo tc qdisc add dev lo root netem loss 20%
which is a static 20% loss, random 20 I believe does 'random loss upto 20%'
Switches input rpcs to be unreliable but with redundancy.
The idea is we don't want a single lost or out of order packet to jam up the flow of our game. Something that becomes increasingly likely the more players you have or the faster you dial up the tick rate.
This simple change dramatically improved response times in my test games and stopped states of 'rollback choking' as Enet tries to recover from a packet discrepancy.
The other benefit is now UDP packets race to provide the next tick info at the cost of slightly more data.
Tested with upto 20% packet loss and game remained stable. At higher packet loss rates Enet kills the connection.
Relevant discussion: https://github.com/foxssake/netfox/discussions/194
How Enet works when set to reliable
Happy to change this to a switch if prefered. Let me know what you think :)