- summary: Tells the server the client has finished loading a map and is ready to play in it. Once per map, every map.
- area: Game.Context
- confidence: 0.86
Tells the server the client has finished loading a map and is ready to play in it. Once per map, every map.
- Kind request
- Area Game.Context
- Named by beta, gamemapping
THE SERVER GATES THE WORLD ON THIS. Until it arrives your character is loaded but not live: actors do not move for you, interactive elements do not respond, and the map's contents are not sent. It is the second half of being on a map, and the half you have to do yourself.
WHEN TO SEND IT
ONCE PER MAP LOAD, EVERY MAP LOAD. This is not a session handshake and it is not the
same kind of thing as ContextCreationRequest, which you send once for the whole
session. This one fires again on every teleport, every zaap, every map change and every
fight transition, for as long as you are connected.
THE CUE IS YOUR OWN LOADING, NOT THE SERVER'S MESSAGE. The client does not send this when the map data arrives on the wire; it sends it when its map renderer picks up the loaded map asset and announces it internally. Everything that cares about "a new map is here" hangs off that one announcement - the grid generator, the interactive-cell manager, several gameplay services, and two outbound requests:
map asset finished loading -> ContextReadyRequest (this message) -> MapInformationRequest -> the client's own map-dependent services wake up
That is why MapInformationRequest and this message go out together, in the same
millisecond in a capture. They are two subscribers to one event, not a sequence. For a
script the practical translation is: whatever you treat as "I have the map now", send
both from that same point.
WHAT TO PUT IN IT
SEND THE ID YOU WERE JUST GIVEN, NOT ONE YOU REMEMBER. The client copies the map id off the notification that carries the freshly loaded map and writes it unmodified. It never consults a cached "current map", and that matters: during a transition your idea of the current map and the map that just finished loading are different for a while.
WHAT COMES BACK
The map's contents: actors, interactive elements, stated elements. There is no Response and nothing acknowledges the request itself - the traffic that follows IS the answer. The envelope is uncorrelated, so its uid goes out as -1; do not allocate one and do not wait to match anything against it.
IF YOU NEVER SEND IT you stay connected, the connection looks healthy, and nothing arrives. That silence is the symptom.
When you may send it
- Requires
context_readyobserved - Raised by: a client-side state change: the client's own map-loaded notification, published by the map renderer the moment it starts handling a freshly loaded map asset. It fires once per map load - every teleport, zaap, map change and fight transition - and the writer copies the id straight off that notification proven
Related messages
- Reply not yet recovered: the map's contents arrive immediately: actors, interactive elements and stated elements. Those messages are recovered but not documented yet.
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 1 | map_id | int64 | The map that just finished loading on the client. (map id) Take it from the load you are reporting, not from a cached "current map" - the client copies it unmodified off its own map-loaded notification, and during a transition the two are not the same value. | required |
Recovered with score 170, confidence 0.86, margin 170 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 1.
Aucun avis à afficher.