MapInformationRequest

Turns a loaded map into a playable one. A script that never sends this sees an empty world: no actors, no interactive elements, nothing to walk to.

SEND IT ON EVERY MAP LOAD, ONCE PER MAP - NOT ONCE PER SESSION. The client raises it from its internal map-loaded notification, so it fires again on every teleport, zaap, map change and fight exit.

SEND IT TOGETHER WITH ContextReadyRequest. They live in different protocol areas but the client raises both from the SAME notification, and in a capture they leave back to back carrying the same map id. Sending only one is not something the real client ever does.

USE THE ID OF THE MAP YOU JUST LOADED. The client reads it from its entity service's current map at the moment the map-loaded notification fires - the map named by the MapCurrentEvent that started the load - not from an older cached value.

Note the type mismatch with its sibling: map_id is int32 here and the same value travels as an int64 in ContextReadyRequest. A capture shows both leaving in the same millisecond with 153356290 in each. A width difference is not a different map.

DO NOT SET A CORRELATION ID. The client dispatches this uncorrelated, leaving the envelope id at -1.

ON THE WIRE, THE CAUSE IS MapCurrentEvent - or its instanced form MapCurrentInstanceEvent, which the client feeds into the same map load. The map load this request follows is started by that message: the client's map service receives it, the map renderer loads the map it names, and the loaded-map notification this request hangs off is raised at the end of that load. A script that loads nothing should send this right after either message, with its map id.