ender-wiggin wrote:3.0.10
scoreboard ping stddev was broken on empty teams
intermission pings were silly
dont allow spectators to see spawntimes before joining a team
fixed some player movement bugs with b_optimizedprediction
primed grenades didnt have timer set properly when they were dropped upon being killed
333fps speedhack hopefully fixed
b_antiwarp fixes (make it more consistent with pmove_fixed, eliminate some fps dependencies)
What does pmovefixed do exactly? I believe it is a client cvar? which makes the player move faster?
What does b_optimizedprediction do? Is it server or client side?
Since Quake 3, the function that's responsible for game physics (amongst other things) is named Pmove(). Normally, this function is run once every client frame, and this is where framerate-dependant physics (most notably jump heights) come from.
pmove_fixed is an attempt to level the playing field by running this function at a
fixed rate (every
pmove_msec milliseconds.) The default pmove_msec of 8 is equivalent to normal physics at 1000 / 8 = 125 frames/second.
pmove_fixed can be set on either the client or the server--the client will default to the value on the server (and, on non-etpro servers, it'll be reset to the server's value quite frequently due to some silliness in the code.)
pmove_msec can only be set on the server side.
b_fixedphysics (which you didn't specifically ask about, but is worth mentioning) is a server-side setting with similar goals to
pmove_fixed.
b_fixedphysics 1 avoids rounding the velocity at all (removing the framerate-dependent behavior in movement); however, it offers
b_fixedphysicsfps to adjust the jump velocity to emulate the old framerate-dependent behavior. This is the best of both worlds—no movement speed problems (as several people observed at 333fps) nor any of the problems that
pmove_fixed brings with it (some parts of the game behave poorly at high fps, most notably mounted MG42 and mortar aiming), but the same jump heights trickjumpers would kill us for taking away.
b_fixedphysics 2 is a cross between normal behavior and fixed behavior, which effectively just caps the maximum framerate-dependent behavior to 166fps.
b_optimizedprediction is a client-side setting that (theoretically) has no effect other than increasing performance. Basically, etmain (and RTCW, and Q3) will re-do all the physics computations for up to the previous 64 frames in order to figure out where you should be for the current one.
b_optimizedprediction will store the result of the previous computations and reuse them (if the results look acceptable based on the latest data the client has from the server) instead of doing all the math again. This provides a rather dramatic performance boost, especially if you have a high ping.
If one of the other people on the documentation team wants to reformat that a little and post it in the documentation forum, be my guest.