This message server sends this message when one of the following happens:
struct s2c_unit_move_t {
char type; // MSG_S2C_UNIT_MOVE
int owner_id; // Player ID owning the unit
int unit_id; // Unit ID which is unique across all units
int movement_started_at; // Unix timestamp (in sec.) when movement started on a server
int movement_started_at_ms; // Remainder for Unix timestamp in millisec.
int path_length; // Length of the path for the unit
};It is possible that path_length equals zero. It means that unit previously blocked on tile transition (unit state MOVEMENT_BLOCKED) is unblocked and can continue on the path it was moving before. Unit performs state transition to MOVING.
After that there are path_length of the following structures:
struct s2c_unit_move_point_t {
int row; // (row, column) - point on the map
int column;
};All points are in local coordinate system of the player. Path is valid and does not include starting point. If this is movement extension request, then movement path should be concatenated with the previously shared path.
Full timestamp is broken down in two fields: Unix timestamp in seconds and remainder in milliseconds.
Timestamp= movement_started_at* 1000 + movement_started_at_ms
Timestamp depends on the context of the message:
STOPPED state and started the move (transition to MOVING state), then timestamp defines starts of the movement from tile center.MOVEMENT_BLOCKED state and path_length is zero, then messages signals of movement continuation (transition to MOVING state) and timestamp defines starts of the movement from transition point.MOVEMENT_BLOCKED state and path_length is non-zero, then this is just movement trajectory sharing and timestamp must be zero.MOVINGstate and path was never shared before for the unit, then timestamp defines start of the movement from transition point.MOVINGstate and path was shared before for the unit, then this is path continuation message and timestamp must be zero.