- summary: The server putting the character into a game context - roleplay or fight. It replaces the current context; nothing has to be sent back.
- area: Game.Context
The server putting the character into a game context - roleplay or fight. It replaces the current context; nothing has to be sent back.
Kind event · Area Game.Context
Tells the client which game context the character is in from now on: the ordinary
world (GameContext.ROLE_PLAY) or a fight (GameContext.FIGHT). Roleplay
messages - map, movement, NPCs, interactive elements - belong to the roleplay context,
fight messages to the fight context.
WHAT TO DO WHEN YOU RECEIVE IT
1. Record the context kind. It REPLACES whatever you held: the client keeps exactly
one current context.
2. SEND NOTHING BACK. No handler of this message builds a reply; the client answers
it with local state changes only.
3. Wait for what the context brings. In roleplay the next thing that matters is
MapCurrentEvent (or MapCurrentInstanceEvent on an instanced map); the
requests you owe hang off that message, not off this one.
WHEN IT ARRIVES
- At world entry, about 30ms after ContextCreationRequest, as the first message
of the burst that answers it (roleplay).
- When a fight starts (fight), and when it ends (roleplay again). The server decides
this on its own. ContextCreationRequest is sent once per game entry and never to
cause these switches.
HOW THE CLIENT SWITCHES. Its context service compares the kind with the current
context. A different kind: it leaves the current context - which switches that
context's services off - enters the new one and announces the change internally. The
same kind: nothing happens. It does not need ContextDestroyEvent first; a creation of
the other kind replaces the current context by itself. A kind it does not know leaves
it with no context at all.
WHAT ELSE THE CLIENT DOES - NONE OF IT OWED. On every creation its market-price service
checks whether its cached average prices date from today and, if not, starts the loop
that sends ObjectAveragePricesRequest and repeats hourly. That is a client cache
refresh; a script that keeps no prices never needs it. A map-side service that also
follows MapCurrentEvent and InteractiveUsedEvent switches behaviour between
roleplay and fight.
ONE DECLARED MEMBER IS REAL. Builds pad this message with an int64, a bool, a map, a
second enum or a nested decoy; the client reads only ContextCreationEvent.context.
When you may send it
- Requires
character_loadedinferred
State it changes
- Establishes
context_readyinferred — on arrival the client's context service enters the roleplay or the fight context this message names - Establishes
roleplay_contextinferred — when it namesGameContext.ROLE_PLAY: the client enters the roleplay context, whose services own map movement and interactive elements - Invalidates
roleplay_contextinferred — when it namesGameContext.FIGHT: the client replaces the roleplay context with the fight context
Related messages
- Arrives after
ContextCreationRequest - Reply not yet recovered: besides world entry, the server switches the context when a fight starts and when it ends; the fight messages around those switches have no signature here.
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 1 | context | GameContext | The context the character is now in. A GameContext. The client maps ROLE_PLAY to its roleplay context and FIGHT to its fight context; any other value leaves it with no context. | never |