Make sv_fps independent from the code
According to SD, the ET engine is "designed" to run at sv_fps value of 20.
If posible, make this variable independent from the code.
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.
Forum discussion link: http://dev.etlegacy.com/boards/3/topics/348
#4 Updated by Dragonji over 6 years ago
Is setting sv_fps higher than 20 still recommended?
It’s a somewhat common practice to raise the server framerate to 30 or 40 to make the gameplay “smoother.” What “smoother” means in this case is that Quake 3’s built-in 50ms lag becomes 33ms or 25ms, and everyone sees things a bit more like how they happen on the server.
Those are really the only two reasons to do it. Now, when Unlagged is running, full compensation or not, the built-in lag is taken care of completely. There goes one reason. It also does every hit test based on what players see rather than what’s actually happening, so the second reason isn’t any longer valid either.
It does have some detrimental effects:
- More incoming bandwidth is required of players
- cl_timenudge can’t extrapolate as much, meaning it’s less effective (this becomes an issue when sv_fps is over 33)
- Higher pings (it seems the client engine holds onto snapshots a little longer)
- Other players may be “jerkier” since more samples mean less smoothing in general
- The new skip correction becomes less effective
So no, I wouldn’t advise higher server framerates. There aren’t any advantages anymore, and there are plenty of disadvantages.
Maybe legacy mod just needs "Unlagged" so the whole thing with sv_fps would be invalid?