Generic Client Side Prediction

Modify the client side POV movement prediction to a more generic scheme, add several modes. Short of moving the gi.Pmove code into a client side DLL, this is the only way to overcome certain limitations that various mods are facing.

Benefits:

Implementation of forces and effects, movements, power ups and modes exploiting full 6 DoF, better and different underwater movement, inventive new physics simulations would be possible.

Despite appearances, Q2 is not a full 3D game. It makes various simplifications based on the assumption that player and entity movement is basically restricted to a 2D XY plane projection, and that UP vector orientation corresponds with the Z axis.

This bias originates from DOOM, and was expressed e.g. in the John Romero statement "Quake has gravity - down is down".

In consequence, certain mods, e.g. 6 DoF zero gravity games (Descent-like) are not possible without shutting down the client side prediction. As the per refresh frame processing of user input for movement/rotation is done within this gi.Pmove mechanism, this procssing is also lost, and has to be blocked.

Benefits are a learning experience for Trinity, forcing id to remove the old bias. It also opens the door for various ambitious mods that rely, one way or the other, on changing the definition and behavior of gravity.

Problems:

We might fail to forsee the various modes needed for a given mod. This solution is more involved, and less flexible than alternatives (see below).

Feasibility:

From the original exchange with John Carmack:

We can expand client side parameters reasonably easily.

Implementation:

Requires rewrite the gi.Pmove and the related parts of the DLL. While the former has a limited scope, the replacement of Z equals down could draw some sweat. The latter is required because of the interaction of gi.Pmove with the player state as used in the DLL.

It should be noted that any mod taking full advantage of this will have to make a lot of more or less subtle fixes on the monster movement/AI/collision response/ on ground detection/muzzle flash offset handling/ rotation and orientation code/physics of friction, gravity/implementation of Floaters/Flyers ... etc.. The same bias (Z assumption) present in the gi.Pmove implementation will be find in all those places.

Change q_shared.h::pmove_state_t to provide a generic set of 6DoF parameters for full integration:

   short  position[3];
   short  velocity[3];
   short  accel[3];           

   short  orientation[4];       // quaternion
   short  angular_vel[4];
   short  angular_acc[4];

Within the svc_frame updates for the player, the following data has to be included if changed:
```
   short  mass;        // scales forces to acceleration
   short  inertia;     // scales momentums to angular acc.
   short  force[3];    // current forces
   short  momentum[4]; // current momentum
```
This covers basic physics while still making simplifications. E.g. inertia against rotation is axis independend here. No separation of velocity dependend forces (friction) is done. Also, surface as opposed to air friction has to be sorted out on the server into forces and momentums (no separation of contact vs. non contact forces). This requires that jump is executed by the server and not predicted by the client.
Note that user inputs modeled as forces have to be calculated based on wall clock time, to be refresh/sampling independend. This is true for client side prediction as well as server side handling of additional movement commands.
Calculation of player volume and density (buoancy), surface and friction in media, friction on ground etc. will be done server side. All this, including gravity, thrusts, currents etc. will be collapsed in the force vector and momentum. Explosion blasts etc. should be applied at once, and not persistent as force. This means that any server side physics simulation is only sampled at FRAMETIME, which should suffice for almost all purposes.
Client side processing of
```
moveleft/moveright
movedown/moveup
forward/back

lookdown/lookup
left/right
```
should be modified to scale with mass/inertia properly. Basically, user inputs exert up to a maximum force on the player avatar, which moves/rotates accordingly.
New commands are needed:
```
roll_cw/roll_ccw
```
Prediction modes have to be reworked:
```
PM_NORMAL
PM_SPECTATOR
PM_DEAD
PM_GIB
PM_FREEZE
```
The most important change is to PM_NORMAL. Currently, this is fixed to a player orientation along Z/gravity pointing down along Z. Instead, it should take into account the current force affecting the player. That means that movement (forward/back, left/right) is not done in XY plane by default, but on the plane the current force points at. The server has to set PMF_ON_GROUND accordingly - ground is not the XY plane by default.
View angle changes (looking up/down, left/right) again have to be interpreted with respect to the plane the force points to (left/right) and the current orientation (up/down).
Prediction modifiers might have to be reworked, or new ones added:
```
PMF_DUCKED            
PMF_JUMP_HELD          
PMF_ON_GROUND          
PMF_TIME_WATERJUMP     
PMF_TIME_LAND           
PMF_TIME_TELEPORT

PMF_TIME_TUBMLE
       
PMF_NO_PREDICTION    
```
If a player is subject to a momentum, or rotated away from the default orientation (which is always along the current acting force), the normal interpretation of movement/look commands might not make sense. If the player is head over heels (or flat on his back), movement should be ignored.
New prediction modes are needed:
```
PM_FREE
```
In this mode, the force is ignored, and all movement and rotation is interpreted relative to the view coordinate system, instead of a mix of world and view coordinates. This mode is most suitable for Descent-like free movement in space, even in the presence of forces and ballistics.
All parameters and constraints used by gi.Pmove should be put into per-entity/per-client updates, instead configstrings, e.g. cl_forwardspeed, cl_sidespeed would become
```
   short  max_forwardspeed;
   short  max_sidespeed;
  
```
The same holds for constraints on angular velocity, forces, etc. The idea is to have all parameters used by the client side prediction under server control during the game, for runtime changes and client specific settings that can not be overridden w/o server consent.
Further, it seems appropriate to sample user inputs for clc_move messages at a fixed rate (e.g. 35 Hz) instead of tying it to refresh rates. The current per-refresh handling introduces a bias towards high-refresh players, which create more bandwidth and server load in exchange for smoother gameplay. Prediction can still handle user inputs per refresh frame, but the overall result should be transmitted to the server with a fixed timebase, independend of both FRAMETIME and screen refresh.

Related Proposals:

Entity extrapolation is the flip side of client side prediction. It makes no sense to have the POV more right, only to have the entities be interpolated in various invalid ways.

This proposal does compete with a Client Side DLL, in which gi.Pmove could be exposed and modified as needed. The latter is the most flexible solution, at the cost of added complexity.

The parameter/constraint addition is a response to the MaxSpeed proposal, which gives an excellent example of the gameplay/gamedesign restrictions resulting from client side prediction.

Submitted 980321, revised 980406, revised 980420, revised 980504, comments to bk@gamers.org.