Clean separation of view direction (head) vs. model orientation (body). Constraints on view depending on model orientation to be imposed by server. Used for all entities, no player/client specific data stored.
In Q2, the view angles are currently not cleanly separated from
the movement/object orientation angles. For clients, which
imply the concept of a "player's head" rotating more or less
disconnected from the body, this is confusing. For mods which
want to take that separation further (3rd person perspective,
chasecam, mechs, drone players for VR helmets), it is not
clean enough.
I propose to change the gi.Pmove processing and the creation of usercmd_t so that view angles and object orientation are fully separated. A second set of angles (or a second quaternion) provides the orientation. I also propose moving the actual storage of both to entity_state_t to remove the artifical distinctions between entities with and without client/camera attached, avoid redundancy. Potential applications are FOV sensitive AI and observers switching to any entity at runtime.
Advantage:
Disadvantage:
None known.
Effort:
Requires rewrite of the client side gi.Pmove handling and generation of usercmd_t. Without means to convice the client side POV movement prediction that certain view angle changes should not affect the body/movement angles, this feature could not be exploited fully.
Alternative:
Changes to the client side handling of look/move commands alone might be sufficient to do this separation. There is already a good deal of redundancy in the angles transmitted in playerinfo updates. Special additions like kick_angles add to the confusion.
Should be fallout of any attempt to use Quaternions.
Submitted 980407, revised 980420, revised 980421, revised 980504, comments to bk@gamers.org.