sv_fps - unfortunately not a changeable cvar
I think this might be a big issue. Some people say RTCW/ET’s id Tech 3 has been designed to run @ 20 FPS. Is this true? If so are there any chances this can be "fixed"? I mean, with 20 FPS there is a built-in "lag" of 50ms, with higher FPS it’s obviously much lower. Are there any reasons to force server admins to use 20 FPS with current standards? Yeah, higher values could be problematic 10 years ago but we’ve got 2013 already.
In the topic above, Bani says "There’s good reason why ID chose sv_fps 20". But being honest, there WAS a reason. With current hardware this reason is invalid in my opinion.
PS. id Software increased sv_fps to 40 in their Quake Live: http://www.quakelive.com/forum/showthread.php?19862-Make-sv_fps-higher&s=c083eb2fc16673c83c8732bcb5bca01c&p=179267&viewfull=1#post179267
Is this even possible to fix that without breaking 2.60b compatibility?
Bump for this thread being in the top.
RE: sv_fps - unfortunately not a changeable cvar - Added by Jacker about 6 years ago
IF this will be fixed in the near future it shouldn’t break compatibility in any way shape or form, but as already pointed out to the 50ms delay is hardcoded to the engine in many places in the ET version of the tech and this causes a problem: We will need to look thru the server code with a microscope to find the problem points, and that takes (a lot of)time.
Just from reading that topic on SD forums I get shivers when thinking of the amount of work required to make it work. It would be nice to fix it though.
There’s a huge difference between 20 and 40 FPS, just take a look at screenshots I’ve made on silEnT mod. It would be a really great improvement for the gameplay of this old game if hitreg was freaking better.
RE: sv_fps - unfortunately not a changeable cvar - Added by Spyhawk about 6 years ago
It might be a good idea to add an issue about this is the bug tracker. Forums aren’t really known for being efficient at bug tracking
Edit: Done in http://www.etlegacy.com/issues/285
Yea, Dragonji wanted to discuss this first because of how complex it will be to fix it, but I think we can create a bug report about it, so we can track it. Assign the target version to ALL.