Movement and position is divided into three parts: the players origin, the players velocity and the players view angles. Angle vectors are interpreted as Pitch, Yaw, and Roll; all represented in degrees. Yaw is when you look to the right and left. Pitch is when you look up or down. Roll is when you tilt your head to the right or left. When you die, your head is tilted 90 degress.
The edict for the player is quite elusive. We have several different origins and velocity attributes:
edict_t has: velocity, avelocity, move_origin
entity_state_t has: origin
pmove_state_t has: origin, velocity
gclient_t has: oldvelocity, kick_origin
There are also origins and velocities in the edict_t's moveinfo_t.
The truth is that not all of these are used for the player. However, many of them are and the only way to understand this is to understand how the different data structures are used and when they are used.
The entity_state_t's origin is the state of the player, and also the state for any other object in the world. Needless to say, in physics, velocity belongs to object state and should be an attribute of entity_state_t. The edict_t's velocity and the entity_state_t's origin are used through out the game code to target enemies, calculate paths of trajectory, etc.
The origin in pmove_state_t is only used in ClientThink. In ClientThink the player's position is calculated and modified by objects in the world. A pmove_t, with a pmove_state_t as attribute s, is prepared with the information from entity_state_t's orgin and edict_t's velocity. They are both converted to type short and mulitplied by eight. This structure is then sent into the engine, via Pmove of the game_import_t API. The engine presumably uses this to adjust the position of the player in the world. In return, Pmove writes a new origin and velocity into the pmove_state_t structure. These two attributes are divided by eight and copied back into the edict_t's velocity and entity_state_t's origin. In other words, the DLL can affect the velocity and origin of the player and send that information to the engine. The engine gets the final word and calculates the actual position, which is written back into the structures of the game DLL. Any changes made to the velocity due to conveyor belts, a push by another object, etc are made to edict_t's velocity and transferred to the engine, and the client, in ClientThink. The true origin, however, can only be set by the engine; apart from the spawning of the player, which is set by the DLL.
Finally, gclient_t's oldvelocity is only used for calculating damage after a free fall. It is updated to be a copy of the edict_t's velocity in ClientEndServerFrame, which is called at the end of each server frame. The edict_t's move_origin is only used by turrets (see g_turret.c).
Avelocity in edict_t is used for rotations. The velocity vector is interpreted as pitch, yaw and roll. The unit is degrees. The player doesn't use this. View direction is calculated as described below.
Kick_origin is only used for weapon kicks and only affects the view angles of the player.
edict_t has: angle, ideal_yaw, yaw_speed, move_angles
entity_state_t has: angles
gclient_t has: v_angle, v_dmg_roll, v_dmg_pitch, kick_angles, kick_origin, killer_yaw, oldviewangles
player_state_t has: viewangles, viewoffset, kick_angles
pmove_state_t has: delta_angles
pmove_t has: viewangles, viewheight
The truth about view angles is tightly related to the mechanisms the ClientThink function. The entity_state_t's angles is the aiming direction of an entity. This also holds for a player, but the view rendering for the player is based on the value in player_state_t's viewangles. However, those view angles are seldom used in the DLL. Instead, the DLL uses v_angle in gclient_t for various calculations. Especially when firing weapons. The player's entity_state_t's angles are set in ClientEndServerFrame, to the value in gclient_t's v_angle. Until then, almost all calculations are based on v_angle in gclient_t.
The delta_angles of pmove_state_t of the gclient_t are updated when the player is pushed by other entities. Inside ClientThink, the engine receives those delta_angles. In return, the pmove_t's viewangles from the engine, are copied into gclient_t's v_angle and the player_state_t's viewangles. The pmove_t's viewangles are entirely used for carrying data from the engine to the DLL. In other words the engine, and presumably the player, dictates the view angles.
The kick_angles in gclient_t are used for kicks from weapon fire. These does not enter the engine through the Pmove function. However, the engine must know about them to calculate the camera shaking induced by weapon kicks. They could be referenced by the engine indirectly, since the engine knows the whereabouts of the client in the global g_edicts array. Probably, the engine looks at the player's player_state_t, because that is where the kick_angles are stored after summing them up in SV_CalcViewOffset. SV_CalcViewOffset uses v_dmg_roll and v_dmg_pitch as factors for computing the player_state_t's kick_angles. SV_CalcViewOffset is called from ClientEndServerFrame.
The edict_t's ideal_yaw and yaw_speed are only used by monsters to turn. Killer_yaw in gclient_t is used when the player is dead, to have him look at the entity that killed him.
Oldviewangles in gclient_t is updated to the value of player_state_t's viewangles in ClientEndServerFrame. It is then used in SV_CalcGunOffset to make the weapon aiming lag a bit when the player turns.