ClientMovePacket
Sent each frame (each time the client's screen is redrawn), this message indicates to the server how the player is moving. Each message contains not only how the client is moving currently, but how the client was moving for the last two frames. Along with how much time passes between frames (which is also included), this gives the server three data points with which to work. Therefore, it can do prediction based not only on velocity, but on acceleration.
The please note the section that is repeated 3 times (once for the current move, once for the previous move, and once for the move before that).
| Field | Length | Notes |
|---|---|---|
| CheckSum | Byte | The checksum is calculated based on the contents of the rest of the move message. This page discusses the checksum in greater detail. |
| Frame Number | Long (4 bytes) | This is value of the frame that the client last received from the server via a `SVC_FRAME` message. |
| The following is the set of fields that is included **3** times. | ||
| BitMask | Byte | This bitmask indicates what fields are included. The next 8 fields are checked against this byte, and if their bit is set then that field is included in this message. If it is not set, then it is not included. |
| Orientation (Pitch) | Short (2 bytes) | This is the pitch angle of the client. It indicates how much the client is looking up or down. Please keep in mind that the axes are **reversed**. A positive pitch indicates the player is looking down, and a negative pitch indicates the player is looking up (like flying an airplane). A zero value indicates the client is looking straight ahead. Conversions between angles and shorts can be done with this code. This field is present if bit 0x01 is set in the bitmask. **NOTE**: Be sure to subtract the pitch value from the DeltaAngles field sent in a `SVC_PLAYERINFO` message. |
| Orientation (Yaw) | Short (2 bytes) | This is the yaw angle of the client. It indicates what direction the client is facing in the X/Y plane. This table explains how yaw angle relates to then direction the client is facing. Conversions between angles and shorts can be done with this code. This field is present if bit 0x02 is set in the bitmask. **NOTE**: Be sure to subtract the yaw value from the DeltaAngles field sent in a `SVC_PLAYERINFO` message. |
| Orientation (Roll) | Short (2 bytes) | This is the roll angle of the client. It is not used in most Quake games (ever see a player turn cartwheels!?), and is included only for completeness / future use. Conversions between angles and shorts can be done with this code. This field is present if bit 0x04 is set in the bitmask. **NOTE**: Be sure to subtract the roll value from the DeltaAngles field sent in a `SVC_PLAYERINFO` message. |
| Velocity (Forward) | Short (2 bytes) | This is the speed the client is moving forward (or backward, if negative). The actual direction you move in relation to the X/Y coordinates on the map depends on the **yaw angle**. This field is present if bit 0x08 is set in the bitmask. |
| Velocity (Right) | Short (2 bytes) | This is the speed the client is moving (strafing) to the right (or left, if negative). The actual direction you move in relation to the X/Y coordinates on the map depends on the **yaw angle**. However, **right** is always 90° to the right of whatever direction **forward** is. This field is present if bit 0x10 is set in the bitmask. |
| Velocity (Up) | Short (2 bytes) | This is the speed the client is moving (usually swimming, or sometimes flying) up (or down, if negative). It will also indicate a "jump" when positive, or a "crouch" when negative. This field is present if bit 0x20 is set in the bitmask. |
| Buttons | Byte | This is a bitmask that indicates what other actions the client is performing. The bitmask fields are listed below. This field is present if bit 0x40 is set in the bitmask. |
| Impulse | Byte | This indicates what "impulse" command the client has issued for special server functions. This field is present if bit 0x80 is set in the bitmask. In the original Quake, the impulse value was used for weapon selection. However, this has been abandoned in favor of the "use <weapon name>" command, which is sent as `CLC_STRINGCMD` message. |
| Milliseconds | Byte | This is the amount of time (in milliseconds) between this move command, and the previous (remember, there are three in a single move message). It is approximately the time it takes the client to render one complete frame. If you know the frames per second (FPS) of your client, this value should approximately be equal to (1000 / FPS). |
| Lighting | Byte | This is the amount of light directly under the client's player model as rendered by the client. There are 256 possible values (0x00 is complete darkness, 0xFF is bright light). |
| End set of repeated fields | ||
Indicates how the player's coordinates change when "Forward" and "Right" are positive.
| Yaw Angle | "Forward" | "Right" |
|---|---|---|
0º |
X+ |
Y- |
| 90º | Y+ | X+ |
| 180º | X- | Y+ |
| -90º | Y- | X- |
| Value | Name | Description |
|---|---|---|
| 0x01 | BUTTON_ATTACK | Indicates "+attack" |
| 0x02 | BUTTON_USE | Indicates "+use" |
| 0x80 | BUTTON_ANY | Indicates that at least one key is pressed Used to proceed to the next level during intermission |
In order to prevent CLC_MOVE messages from being altered during transmission (like by a proxy bot, for example), each must include a checksum of its contents. The checksum (also known as a "Message Digest") serves as sort of a digital signature, or fingerprint. If the value of the checksum does not match what it should be based on the contents of the move packet, the entire move packet is ignored.
To calculate this checksum, iD Software uses an algorithm from RSA Data Security, Inc. known as MD4 (MD meaning "Message Digest"), by Ronald L. Rivest at the Massachusetts Institute of Technology. For more information, read the document Internet RFC 1320, or view the MD4 source.
