- summary: Asks the server to walk the character along a path of map cells.
- area: Game.Gamemap
Asks the server to walk the character along a path of map cells.
Kind request · Area Game.Gamemap
Asks to move. YOU ARE ASKING, NOT MOVING - the server decides what actually
happens and answers with MapMovementEvent (the walk granted) or
MapMovementRefusedEvent (no walk; you are put back on the cell it names).
WALK THE PATH THE SERVER SENDS BACK, NOT THE ONE YOU ASKED FOR. The granted path can be shorter than the requested one, and applying your own path optimistically desynchronises your position from the server's. Everything else you do on the map - reading interactives, attacking, using a zaap - is validated against the server's idea of where you stand.
key_cells is the path as map cell ids, in order, starting from the cell
ADJACENT to where you are, not from your current cell. Cell ids are single grid
indexes, not coordinate pairs.
map_id must be the map you are actually on. The client reads it from live map
state at send time rather than from a cache, and so should you: after a
teleport, a stale map id is the difference between a move and a rejected one.
cautious is the careful-walking mode the client derives from its own movement
options. It is not a speed setting.
NEVER SEND TWO OF THESE LESS THAN 250 ms APART. The roleplay client stamps the time in milliseconds whenever it sends one, and a walk asked for within 250 ms of that stamp is ignored, not queued - except, it appears, when it re-targets the walk already under way. Faster walk requests are traffic no real client produces.
When the walk finishes, close the handshake with
MapMovementConfirmRequest. After a refusal there is no walk to confirm:
send no MapMovementConfirmRequest, take the cell the refusal names as
your position, and plan again from there.
When you may send it
- Requires
context_readyinferred - Raised by: the player choosing a destination. Two producers build it: the roleplay movement service (four sites, working from EntityPhysics and a validated MapPoint path) and the fight movement service (two sites, built around FightTurn) proven
Related messages
- You will receive one of
MapMovementEventinferred — the grant: the path the character will actually walk. The client's handler treats this event as the answer to this request - You will receive one of
MapMovementRefusedEventinferred — the refusal: the server will not move the character and names the cell it really stands on. The client's handler for it clears the walk under way and snaps the character to that cell
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 1 | key_cells | repeated int32 | The requested path, as an ordered list of map cell ids. (map cell ids) A cell id is a single grid index, not an x/y pair. The client derives these from an already-validated path, so it never asks for a route it believes is impassable. | required |
| 2 | map_id | int64 | The map the movement is requested on. (map id) Read from live map state at send time, not from a cached current map. | required |
| 3 | cautious | bool | Whether to move in the client's cautious walking mode. Derived from the player's movement and input options, not from the path. | required |