MapCurrentInstanceEvent

The server moving the character to a map, in the form it uses for an INSTANCED map. It is the twin of MapCurrentEvent: same area, same purpose, and the official client feeds its map_id into the very same map-change routine. A script that handles only MapCurrentEvent misses every map change the server announces this way and waits forever for a map that has in fact changed.

WHAT TO DO WHEN YOU RECEIVE IT

1. YOU ARE ON map_id NOW. It plays exactly the role of MapCurrentEvent.map_id: the map to load, and the map your position, cells and interactive elements belong to from now on. 2. FORGET THE PREVIOUS MAP: its actors, interactive elements and movement state. You are on another map. 3. DO WHAT MapCurrentEvent SAYS, WITH THIS map_id: load the map, THEN send ContextReadyRequest and MapInformationRequest carrying it, and fill the map from MapComplementaryInformationEvent when it arrives. The official client does exactly this: it stores map_id as its current map (narrowed to 32 bits), announces the change internally, loads the map, and sends the two requests once the map has loaded - the same chain, in the same order, as for MapCurrentEvent. 4. instantiate_map_id NEEDS NOTHING FROM YOU. No request carries it and the current client never reads it. Keep it only if you want to tell two instances of one map apart.

HANDLE BOTH MESSAGES IN ONE PLACE. Wherever a map change can happen - at world entry after ContextCreationRequest, after MapChangeRequest, after a teleport - accept EITHER MapCurrentEvent or this message as "the map changed", and run the same steps. Which of the two the server sends is its own decision, presumably whether the destination is an instanced copy of a map; the client never has to know in advance, because it treats both the same.

WHAT THE OFFICIAL CLIENT DOES NOT DO HERE. For MapCurrentEvent several other client services react too: the entity view clears itself, the subarea service compares the new map's subarea with the old one, per-map caches reset. In the current client only the map service listens to this message, so none of that happens on it. Step 2 is still right for a script: whatever the official client keeps, the old map's actors are not on the new map. If you track subareas, look the subarea of map_id up yourself here too, as MapCurrentEvent describes.

THE TWO IDS ARE BOTH int64 AND MUST NOT BE SWAPPED

map_id               the map to load - the same id space as
                     MapCurrentEvent.map_id, MapInformationRequest
                     and MapComplementaryInformationEvent. It is the one
                     the official client loads.
instantiate_map_id   which instance of that map; never sent back, never read
                     by the current client.

Field numbers are no guide: the builds renumber these two fields, and on the current build map_id is field 2. Use the names, never the numbers.

Some builds pad this message with a decoy int32, an enum or a third int64; the client reads none of them.