has valve ever explained how tickrate relates to server fps? I don't recall. I'd always thought that as long as server fps is greater than tickrate then you shouldn't notice any hiccups in the game at all. But if server fps falls below tickrate, then not every tick is producing new data. I don't know that that is correct, though.
On 8/2/05, Whisper <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > This is how I understand it: > > tickrate = the amount of times per second a calculation of all player > actions and physics is done > > fps or server fps = the amount of times per second Inputs and Outputs are > monitored > > The reson for wanting a higher fps is that it gives you a finer granularity > over I/O's than you would otherwise have, if left at Windows default of 60 > times a second. It is also important in context of a server because there > are multiple clients connected to it, thus the server needs to be able to > deal with incoming data from multiple sources, and when running a high > tickrate/high rate server, with clients who also run at equally high fps and > rates, there is a hell of a lot more I/O going on than if server & client > was all running at default. > > In any case there is no reason to believe what I have just said, the > important thing is how the server feels once the changes to tickrate, > fps_max, sv_maxrate & sv_maxupdaterate have been implemented. > > Those of you who have the hardware and connection to cope will know that > playing on a well configured server with a great Internet connection with a > client that also hardware capable, with a suitable Internet connection, and > properly configured rates, is a vastly superior gaming experience than > playing with defaults. > > The fact of the matter is, in many case, somewhere along the line a crucial > part of this very precarious balancing act falls down and somebody (never > the client god forbid) has to take the blame. > > Too many times a poor gaming experience can be attributed to either a poorly > configured server for the resources available and/or a poorly configured > client. > > People tend to forget that the Valve defaults tend to cater to the lowest > common denominator, which provides for a reasonable, and more importantly > hoped for trouble free experience, but these setups are less than optimal so > long as all pieces of the puzzle can cope with optimization of Valves > default setups. -- Clayton Macleod _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
