MapChangeRequest

Asks the server to move your character to the NEIGHBOURING map, the one beyond the edge of the current map you have walked to. This is how a character leaves a map by its north, east, south or west side.

YOU ARE ASKING, NOT MOVING. The map changes only when the server answers with MapCurrentEvent - or its instanced form MapCurrentInstanceEvent - naming the new map. Until then you are still on the old one.

HOW TO CHANGE MAP - do exactly this, in this order. It is what the official client does, read from its code.

1. BE ON A LOADED MAP IN ROLEPLAY. You are in the roleplay context and the current map has arrived (MapCurrentEvent) and been loaded.

2. PICK THE SIDE AND READ THE TARGET MAP FROM THE MAP DATA. The current map's data gives its four neighbours: topNeighbourId (north), bottomNeighbourId (south), leftNeighbourId (west) and rightNeighbourId (east). The neighbour of the side you leave by is the map_id you will send. Never compute it, never take it from anywhere else.

3. PICK AN EXIT CELL ON THAT SIDE. Only cells on that edge that the map data marks as an exit towards that side can be left by - the cell's mapChangeData bit field holds one bit per direction. The official client takes the exit cell of that side nearest to where the player clicked.

4. WALK ONTO THAT EXACT CELL with the normal movement handshake: MapMovementRequest, follow the path the server grants (MapMovementEvent), MapMovementConfirmRequest when the walk is done. If you already stand on the exit cell, skip the walk.

5. CHECK WHERE THE WALK ENDED. The change goes on ONLY if you are standing on the exit cell you walked to. If the server granted a shorter path, or refused the walk (MapMovementRefusedEvent - then there is no walk to confirm either), the official client does NOT send this request - walk again or give up.

6. WAIT FOR MapMovementConfirmResponse. The client waits until no walk is in progress and the server has confirmed the last one before it sends this request.

7. ONLY NOW SEND THIS REQUEST with map_id = the neighbour of step 2 and auto_pilot = false (leave it absent) - unless you are the client's auto-travel, see AUTO-PILOT. Set nothing else. Send it ONCE: the client forgets the pending change the moment it is sent.

8. WAIT FOR MapCurrentEvent OR MapCurrentInstanceEvent with the new map id - accept either, the client handles both the same way - then do what that message says: forget the old map, load the new one, and send ContextReadyRequest and MapInformationRequest.

WHAT CANCELS A PENDING MAP CHANGE BEFORE IT IS SENT

The client remembers ONE pending change (a target map and its flag) between step 2 and step 7 and drops it, sending nothing, when: - you click a cell to walk somewhere else (an ordinary walk never changes map); - you click an interactive element (unless the client's auto-travel did it); - a new map change replaces it (only the latest target is kept). Choosing a map change also drops any element use that was waiting for a walk to finish (see InteractiveUseRequest): the two never queue together.

AUTO-PILOT

auto_pilot is true only when the client's auto-travel feature drives the map change; every map change a player clicks sends false, which is absent on the wire. Leave it false. What the server does differently for true is not visible in the client.

WHAT COMES BACK

- MapCurrentEvent with the new map id: the change happened. Everything that belonged to the old map is gone. - MapCurrentInstanceEvent instead, when the server announces the new map in its instanced form: the same change, handled the same way, with its map_id. - A refusal: the map area declares no failure message for this request, so what a refused change returns is not established. Do not wait forever for either message; if neither comes, you are still on the old map.

THE MAP ID IS AN int32 HERE. MapCurrentEvent and MapMovementRequest carry map ids as int64; this request carries the neighbour id as int32, which is the type the map data stores neighbour ids in. The client keeps the target as a 64-bit pending value and sends its low 32 bits. Use the same number.

LIVE CAPTURE (3.6.12.16): map_id 154010883 and auto_pilot absent (false), sent when the player clicked towards a side of the map to cross into the neighbouring map.

The current build declares nothing else in this message; other builds pad it with a same-typed int32 or an optional string that no client code ever writes. Never set them.