Question: Server Frames (server fps)

[Wolfe]

Please, do not post answers unless you are 100% confidently sure. I need people with experience who know exactly what they're talking about.. not guessers.


Question 1:
Deviation (moving, firing, etc.) is based on server fps, correct?

Question 2:
To determine a server's fps, type renderer.drawfps 1 in the console, which returns two sets of numbers. The first number is your fps, and the second number is the server fps?

Question 3:
What affects server fps, i.e., what makes it go up or down?

Question 4:
What is the minimum and maximum server fps? 10-30?

Question 5:
What is the average?

[Masaq]

1. Yes.
2. Wrong. The second number is the time in miliseconds between frames. (E.g.: My FPS is 100, so there's a 10ms wait between each frame being rendered, as 1000ms per second divided by 100 frames makes 10. If your FPS is 30, your FPS will be displayed as: 30/33.3)
3. Server FPS is locked at 30. Think of it as an atomic clock, and the client PCs are radio-controlled watches and clocks at home. The atomic clock keeps on counting at the same speed, but the client clocks are less reliable and so run at varying speeds (due to framerates, latency etc). So every time the client clocks check in with the main clock, they're sending data that has to be adjusted by the atomic clock to ensure that everybody is actually running the right time... you with me?
4. It ranges between 30 and 30.
5. 30.

You're barking up the wrong tree if you're hoping to find some way of tinkering with deviation through server fps; the whole point of the server FPS is that it provides every client PC connected to it with the same information at the same speed.

This is why laggy players "skip" across the map; their PC is telling the server where the player is running.

The server receives the information after a delay, due to the long latency.

The server sends that information out to every other client, telling them where the laggy player seems to be headed.

In the meantime, the lagging player has altered his direction. Because of the high latency, this information is again handed out to the server after a slight delay.

The server passes the new information along, but in the meantime all the other player's PCs have been showing the lagging guy progressing on the first direction. When their computers receive the new direction, they suddenly warp the player's character a couple of meters to the 'new' location.

The server's conistent pace ensures that if a non-lagging player shoots at where he sees the laggy guy (even though a milisecond later the laggy guy warps 5 metres to the left), a hit will still be registered because the server 'knows' that the non-laggy guy was acting on the best possible information he had, and that the shot would have hit had the non-laggy guy not been warping around.

In theory, anyways. With BF2 hitbox detection, it can be a bit of a joke even with low latency lol.

[Wolfe]

Just wanted to verify if server FPS changed or not. It's locked at 30, which is excellent news, since it means my shot/move/turn recovery times will always be a constant. My concern was that server fps changed which would have made my calculations more difficult.

Thanks for the info.

[Masaq]

Np. G'luck on the tinkering.