MapCurrentEvent

The server moving the character to a map. MapCurrentEvent.map_id is the map the character is on from now on.

WHAT TO DO WHEN YOU RECEIVE IT

1. Forget the previous map: its actors, interactive elements and movement state. The client drops them too - its entity view, per-map caches and subarea state reset on this message, and once the new map has loaded it sets the map's fight count (MapFightCountEvent) back to 0. 2. Load the map. A script that draws nothing can treat this as immediate. 3. THEN SEND ContextReadyRequest AND MapInformationRequest, both carrying this map id. The official client does this after EVERY MapCurrentEvent whose map it loads - at world entry and on every later map change alike - and never skips it. Whether the server refuses to go on without them is server behaviour, which a client dump cannot show; the ContextReadyRequest record reports that the map's contents only come after it. 4. Fill the map from MapComplementaryInformationEvent when it arrives.

HOW THE REAL CLIENT GETS FROM THIS MESSAGE TO THOSE TWO REQUESTS. Traced in the 3.6.12.16 client:

MapCurrentEvent
  -> map service: store the id as the current map, announce it internally,
     start its current-map routine
  -> wait one frame and until the map display is ready
  -> map renderer: look the map up, play the map transition, then load the map
  -> map loaded: the renderer announces the loaded map with its id
  -> the map service sends ContextReadyRequest
  -> the roleplay-entities message handler sends MapInformationRequest

So the two requests follow this message after the map transition and the load, not in the same instant. Nothing in the chain waits for anything else from the server, and neither handler of the loaded-map notification tests any condition before sending.

TWO CASES WHERE ONE MESSAGE DOES NOT MEAN ONE PAIR OF REQUESTS:

- Back-to-back messages collapse. The map service keeps only the latest map id and runs one current-map routine at a time; a message that arrives while that routine is still waiting just replaces the id. The client then loads - and sends the two requests for - the last map only. - A map the client cannot load produces nothing. When the map asset is missing the renderer never raises the loaded-map notification, so neither request is sent.

THE CLIENT DERIVES SUBAREA CHANGES FROM IT. It looks the new map up in its data centre to find its subarea and compares it with the previous map's. A script that needs subarea transitions can do the same from the map id alone.

INSTANCED MAPS USE A SIBLING: MapCurrentInstanceEvent, carrying the map id and an instance id. The client routes its map id into the very same map-change routine - and so into the same two requests. A script that follows only this message misses the map changes the server announces that way: handle both in one place.

ONE DECLARED MEMBER IS REAL. Builds pad this message with a decoy int64, a string, a bool or a nested decoy message; the client reads only MapCurrentEvent.map_id.