ContextCreationRequest

THIS IS THE STEP THAT PUTS YOU IN THE WORLD. Before it, the server knows who you are and which character you picked, but you have no map, no entities and no context. After it, everything gated on a game context becomes legal. It carries no payload - the message IS the ask.

WHEN TO SEND IT

ONCE PER GAME ENTRY. NOT ONCE PER MAP. This is the single most expensive mistake you can make with this message. Map changes, teleports, zaaps and fight transitions do NOT re-create the context and the real client does not re-send this - what it re-sends on every map is ContextReadyRequest and MapInformationRequest. The client has exactly two places that build this message, and neither of them is on the map-change path.

PATH 1 - ENTERING THE GAME. The chain starts at a successful CharacterSelectionEvent and runs entirely inside the client:

CharacterSelectionEvent (success)
  -> the client starts its enter-game routine
  -> it shows the loading screen and WAITS ONE FULL SECOND
  -> it loads the character-selection-to-game data set
  -> it waits for the account options to be loaded
  -> it switches on the first batch of gameplay services
  -> ContextCreationRequest                        <-- here
  -> it switches on the rest of the gameplay services

So the honest rule is: send it after the selection succeeded, and after a delay. A capture shows it about 1.4 seconds behind the character finishing loading, and the one-second wait above is a literal constant in the client, not jitter. Firing it in the same millisecond as the selection result is a timing no real client produces.

CharacterLoadingCompleteEvent arrives during that window, which is why a capture makes it look like the cue. On this path it is not: the client does not key on it. It is still a good practical checkpoint, because it always lands before the request does.

PATH 2 - ARRIVING ON A FIGHT SERVER. When the client is handed over to an arena server it opens a SECOND game connection beside the first (see IdentificationRequest), and on that connection the rule is different: the moment CharacterLoadingCompleteEvent arrives there, the client sends this request immediately, with no delay and no gate. The check is on which socket the event arrived on - the same event on the ordinary game connection does nothing.

So: once when you enter the world, and once more per fight-server hand-over, on the new socket.

WHAT COMES BACK

About 30ms later the server pushes a context-creation event carrying the context kind (roleplay or fight), followed by the map and character state. Only then is anything gated on a game context legal. Nothing about this exchange is correlated: the request goes out on the plain send path, so its envelope uid is -1 and there is no response to match against it. Watch for the inbound burst, not for a reply.

THE CONTEXT IS NOT PERMANENT. The server tears it down and rebuilds it during the session - entering and leaving a fight is the obvious case - and it does so on its own initiative, by pushing destroy and create events. Treat the context as a state the server owns and announces, not as a latch you set once. What you must not do is try to drive those rebuilds yourself by re-sending this request.