Bug #285

Make sv_fps independent from the code

Added by Spyhawk almost 7 years ago. Updated over 5 years ago.

Status:New% Done:


Target version:ALL
OS: Arch:


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

Related issues

Related to ET: Legacy Development - Bug #735: Player model is shaking Fixed 18.12.2014

Associated revisions

Revision 48e59277
Added by Jacker over 5 years ago

changed the frametime value to be calculated based on sv_fps, refs #198


#1 Updated by Spyhawk almost 7 years ago

  • Category set to Server
  • Target version set to 2.78

#2 Updated by Spyhawk almost 7 years ago

  • Target version changed from 2.78 to ALL

#3 Updated by Dragonji almost 7 years ago

  • Tracker changed from Feature to Bug
  • Subject changed from make sv_fps independent from the code. to Make sv_fps independent from the code
  • Description updated (diff)

#4 Updated by Dragonji almost 7 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?

#6 Updated by Dragonji over 5 years ago

  • Description updated (diff)

#7 Updated by Dragonji over 5 years ago

As far as things rely on sv_fps 20 I suggest to block its value for release builds so admins can’t "break" the game.

#8 Updated by Spyhawk about 5 years ago

  • Related to Bug #735: Player model is shaking added

Also available in: Atom PDF