Freon - new version on the server to test.

[Piglet]

There's a new version on the servers. Thanks holyspam for the work on this.

It's had some changes which may prevent the frozen corpse-slide issue - so the changes are only around what happens as you freeze.

There may be bugs or other unintended consequences. If you see anything wrong/different please can you let us know:

1. What did you see?
2. Is it a problem, and if so why?
3. How can you reproduce it so that we can investigate?

Thanks

[Piglet]

Reverting back to the old one for some small changes to be made

[holyspam]

New version of the server. A tweak made by Deaod(https://github.com/Deaod/UTComp/)

If you check the F7 menu, there will be a new option called "Desired Net Update Rate".
What this does is change the minimum interval that your client will send a new update to the server.
You can think of this as your client's tickrate.


Recommended value to set is close to your FPS or higher.

It cannot be less than what the server has as minimum or higher than your Netspeed/100 (for 15000 netspeed max is 150Hz)
This is a maximum limit, your FPS is what decides the actual rate.

Side-effects of using higher than the default of 90:

Better client responsiveness.(the interval between updates gets shorter)
Higher *measured* ping.
Higher data usage - minimum 10KB/sec upload for values above 180
If you have packetloss it might make it worse.

Explanation:
The default game behaviour up to 10000 netspeed - it processes your movements/inputs after every frame is rendered and checks a timer.
If 22.2milliseconds or higher have passed, then 1 network packet is generated containing your inputs, the timer is updated and another 22.2ms has to pass.

This is perfect up to 45 FPS, after every frame there is a new update packet,
BUT when your frames and inputs are processed at a rate faster than the 22.2ms of the timer, so 45.1 FPS and higher, the game will wait for the next frame to finish and the timer to expire, then it combine all your inputs into one update packet.

Increasing netspeed to 10001, reduces the timer rate to 11ms, but only if the number of players is 10 or less.(This is the biggest issue)

This allows every frame to send an update of your inputs/moves to the server up to 90FPS or 11.1 milliseconds timer.

Now what the default code does after 11 players are online, is to restore the default behaviour, which is 22.2 milliseconds timer.

Since this logic runs after every frame is finished, when you reach ~140FPS(7ms per frame) or higher, the client will wait not 1(7ms), not 2(14ms), not 3(21ms <22.2ms) but FOUR(>22.2ms) frames before an update packet is generated and sent to the server.

After every frame it combines your move from the previous frame with the next one, until at least 22.2milliseconds have passed.
The problem is your moves are not sent individually but instead interpolated into one big smooth move.

So the worst case scenario means that you can have 250FPS ingame(4ms) and 20ms ping (10ms client->server) and the server has 60 tickrate, so a regular update every 16.7ms.
The best possible latency should have been 4ms(FPS) + 10ms(Network) + 2ms(if you reach the server just before it "ticks"). total 16ms
What epic gives you is 4+4+4+4+4+4(24ms >22.2ms) + 10ms(Network) + 2ms (if you reach the server just before it ticks). total 36ms

That's 20ms difference right?
Well, no - because you missed the previous 2 server ticks(at 16.7 and 33.4) and the next one is at 50, so that's 34milliseconds more.
The worst case scenario will be if you miss the first tick.
What you get then is:

Beginning previous frame - 0ms - reset timer to 0ms
server ticks 0 = 0ms - no update yet on server

frame 0 = 4ms - 0ms < 22.2ms hold
frame 1 = 8ms - 0ms < 22.2ms hold + combine with frames 0
frame 2 = 12ms - 0ms < 22.2ms hold + combine with frames 0,1
frame 3 = 16ms - 0ms < 22.2ms hold + combine with frames 0,1,2
frame 4 = 20ms - 0ms < 22.2ms hold + combine with frames 0,1,2,3

server ticks 1 = 16.7ms - no update

frame 5 = 24ms - 0ms >= 22.2ms combine with frames 0,1,2,3,4 + generate update and send it(10ms to reach server) - reset timer to 24ms

frame 6 = 28ms - 24ms < 22.2ms hold
frame 7 = 32ms - 24ms < 22.2ms hold + combine with frame 6

server ticks 1 = 33.4ms - no update yet

update 0 arrives = 34ms - for next tick (at 50.1ms)
frame 8 = 36ms - 24ms
frame 9 = 40ms - 24ms
frame 10 = 44ms - 24ms
frame 11 = 48ms - 24ms

server ticks 2 = 50.1ms - your moves have been processed as one big smooth movement(frames 0-5) and your position has now been updated and sent to other players



With the new version.

Beginning previous frame - 0ms - reset timer to 0ms
server ticks 0 = 0ms - no update yet on server

frame 0 = 4ms - 0ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 4ms
frame 1 = 8ms - 4ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 8ms
frame 2 = 12ms - 8ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 12ms
update 0 arrives = 14ms - for next tick (at 16.7ms)
frame 3 = 16ms - 12ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 16ms

server ticks 1 = 16.7ms - your move has been processed and your position has now been updated and sent to other players as one distinct move

update 1 arrives = 18ms - for next tick (at 33.4ms)
frame 4 = 20ms - 16ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 20ms
update 2 arrives = 22ms - for next tick (33.2ms)
frame 5 = 24ms - 20ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 24ms
update 3 arrives = 26ms - for next tick (33.2ms)
frame 6 = 28ms - 24ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 28ms
update 4 arrives = 30ms - for next tick (33.2ms)
frame 4 = 32ms - 28ms >= 4ms generate update and send it(10ms to reach server) - reset timer to 32ms

server ticks 2 = 33.4ms - each of your moves has been processed(corrected every 4ms) and your position has now been updated and sent to other players as multiple distinct moves

[Blub]

*bump* for vkn and others