Below is a brief discussion of the Quake 3 command, sv_fps
. No one has really cleared up what it does and how it can benefit players. This topic usually starts pointless debates of which setting it better runs at, etc... Though, this short tutorial will show you the ins and outs of sv_fps
and which setting is right for you.
Firstly, I'd like to quote a question from another Message Board posted nearly a year and a half ago:
Originally Posted by "sv_fps", Mar 9 2004,10:22 AM
I noticed many old 'competitive' Quake 3 servers use to have their sv_fps set to '30' or '40', while players had their snaps set, respectively. When you decrease the snaps to 10 (both server and/or client), the game runs more choppy. If you increase this number, what are the advantages and disadvantages?
Will increasing sv_fps from 20 to 40, assuming the server is willing and able, make the game smoother in online play? What, if any, factors have not been documented yet about this?
I think the answer to that question would be best explained if we discussed the Quake 3 command snaps
This setting is the number of 'snapshots' that you receive from the server per second. A snapshot is a 'picture' of what is happening in the game since the last snapshot. This is the data transmission equivalent of a frame-rate.
This setting should be set equal to the server's sv_fps
setting (default is 20). Some servers use sv_fps
30 or 40. I have never seen a server using a sv_fps
greater than 40. Regardless of how high you set your snaps
setting, you will not be able to receive more than the rate at which the server runs which is defined by its sv_fps
setting. So you can set your snaps
to 40 and play on a sv_fps
30 server without needing to adjust your snaps
— it will run at 30 anyway.
If you have dialup you will probably be better using snaps
20. The higher the snaps
the more bandwidth will be needed, so snaps
30 or 40 may cause a dialup connection to be less stable. Pings
The 'tweaking' was really 'show what our pings really look like' — at sv_fps
20, anyone with a ping under 50 shows up as a solid 48 on the scoreboard. Note this is a shows up as
and not a fully accurate representation of your ping. This could be for all Q3 servers at sv_fps
20, but i wouldn't know — sv_fps
30 is standard for OSP.
It has been said that sv_fps
20 was hiding our real pings, so it could be if sv_fps
is changed it might better represent what they are. The 'drop' in ping was, in essence, only a drop on the scoreboard — in essence the same amount of lag would still be there if the server was at sv_fps
From what I know the client's snapshots should be set to the server's value of sv_fps
, respectively. Here's another quote from a different Message Board:
The game is hardcoded around a 50ms frame time. 30fps = 33.333ms frames. This causes all kinds of problems in the game — from rounding errors to just plain breaking stuff totally. |
It might "lower your ping" but it also increases the bandwidth required. This usually makes the game play worse even though your ping might look "better".
As we know, this contradicts our discussion on Pings above. The scoreboards display of a client's ping is broken
. The idea of sv_fps
has nothing to do with your ping, literally. It's rather improving the gameplay, hence the additional bandwidth
needed to transfer more snapshots of the game. In response to the previous quote, there was some controversy on that note:
Using sv_fps 30, as you rightly point out, shaves a good 17ms off the round trip between client and server, making the game both more responsive and much less soupy in large firefights. |
The problems associated with it largely boils down to client inexperience, i.e. not setting snaps to the corresponding value, and server host inability to provide the extra bandwidth. And no, it doesn't make your ping look better; as it happens the scoreboard ping code is broken with regard to other values of sv_fps and as a result ends up looking higher.
It benefits those with client console knowledge experience, and high-end servers that can handle the extra amount of bandwidth required (including the clients
). Knowing this, you should be able to find which setting works best in your case.