Individual Player MaxSpeed

Allow maximum player forward speed to be set on an individual basis by the game DLL. This is an example of parameters used in client side prediction that are not accessible to the server, and can not be set on a per-client basis.

Advantage: Speed constraint control would allow for interesting game variations where how fast a player could run depended on different factors:

• In a TeamFortress-type mod, your player class (sniper, soldier, medic, ....) could have different running abilities.
• In a CTF-type mod, you could have runes or techs that let you run faster (or cursed runes that made you run slower)
• Other mods might set a player's maxspeed based on how much weight they were carrying,  how fatigued they were, or what weapon they were wielding.

Disadvantage: A couple extra bytes would have to be sent to the client for each change, but bot per frame. If the constraints change often, the overhead will increase.

Effort: Probably add a new field to pmove_state_t, similar to the "gravity" field. Change the client to refer to that value. Change the default game to set that value for each player, at least based on whether they were on dry ground, in water, in slime. As blends for water etc. are handled server side, updating the maxspeed constraint could also be handled server side.

Comments: Without involvement on the client-side of things, forcing a player to move slowly mucks up client-side prediction. This proposal aims at getting control over at least one of the parameters used by gi.Pmove. It is a special case of the generic client side prediction.

Speed clipping as done by the Q2 DLL introduces a bias towards plane and space diagonals, with effective max speed varying up to 1.41 for walkers, and 1.73 for floaters. Thus bug can't be fixed w/o introducing incosistency with client side prediction.

Submitted 980418, revised 980504, by Barry Pederson.