Protocole Dofus

ChallengeBonusChoiceSelectedEvent

ChallengeBonusChoiceSelectedEvent

Which reward the fight's challenges give: the bonus kind the team picked (experience or drops).
Kind event · Area Game.Challenge
The kind of bonus the fight's challenges reward, as a ChallengeBonus value.
WHAT TO DO WHEN YOU RECEIVE IT
1. Store it for the fight. The client refreshes its challenge window's reward display with it. 2. SEND NOTHING BACK.
It follows a ChallengeBonusChoiceRequest, and may also arrive on its own when the fight is set up.
THE VALUES ARE NOT NAMED HERE: see ChallengeBonus. Beta declares an experience bonus and a drop bonus.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeBonusChoiceRequest Fields
#FieldTypeMeaningYou set it 1challenge_bonusChallengeBonusThe bonus kind the fight's challenges give; values are not named, see the enum.never

• summary: Which reward the fight's challenges give: the bonus kind the team picked (experience or drops).
• area: Game.Challenge

• 40 vues

Smooth

Octobre 13Oct 13

ChallengeListEvent

ChallengeListEvent

The full list of the current fight's challenges; it replaces the list you hold and ends the challenge choice.
Kind event · Area Game.Challenge
Every challenge of the current fight, as challenge records.
WHAT TO DO WHEN YOU RECEIVE IT
1. REPLACE your challenge list with ChallengeListEvent.challenges. Each record is a challenge id (resolve it in the game data for its name and rules), its targets, its state and its bonuses. 2. Close any challenge choice in progress: the client closes its choice window when this message arrives (ChallengeProposalEvent opened it).
WHEN IT ARRIVES. After the choice is validated (ChallengeValidateRequest), or on its own when the challenges are drawn at random. 3. SEND NOTHING BACK.
LATER CHANGES ARRIVE ONE BY ONE: ChallengeAddEvent adds or replaces one challenge, ChallengeTargetsEvent updates its targets and ChallengeResultEvent its outcome.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeValidateRequest Fields
#FieldTypeMeaningYou set it 1challengesrepeated ChallengeThe fight's challenges; replaces the list you hold.never

• summary: The full list of the current fight's challenges; it replaces the list you hold and ends the challenge choice.
• area: Game.Challenge

• 35 vues

Smooth

Octobre 13Oct 13

ChallengeMod

ChallengeMod

How a fight's challenges are decided: chosen by the team or drawn at random. The type is named; its values are not.
Kind enum · Area Game.Challenge
The challenge mode of a fight, carried by ChallengeModSelectedEvent.challenge_mod, by the ready request of the placement phase and by the mode-selection request.
THE VALUES ARE NOT NAMED HERE. Beta declares CHALLENGE_CHOICE = 0 and CHALLENGE_RANDOM = 1, but enum numbers are not trusted across builds and nothing read so far separates them by behaviour: the client only shifts the value by one into its own mode enum. Keep the value you received and echo it back unchanged.
Not sent on its own — an enum is never sent on its own. inferred
Used by
ChallengeModSelectRequest ChallengeModSelectedEvent ChallengeReadyRequest No fields you may set.

• summary: How a fight's challenges are decided: chosen by the team or drawn at random. The type is named; its values are not.
• area: Game.Challenge

• 42 vues

Smooth

Octobre 13Oct 13

ChallengeModSelectRequest

ChallengeModSelectRequest

Asks to switch the fight's challenge mode between choosing challenges and getting them at random.
Kind request · Area Game.Challenge
Changes how the fight's challenges are decided.
HOW TO SEND IT
1. Only during placement, from the challenge settings: the official client sends it when the random-challenges switch is toggled, and when the settings window opens. 2. Put the wanted mode in ChallengeModSelectRequest.challenge_mod, a ChallengeMod value. Its values are not named here: reuse a value you received in ChallengeModSelectedEvent rather than guessing a number. 3. Wait for ChallengeModSelectedEvent: the mode is only in effect when the server announces it.
NOT THE READY CLICK. ChallengeReadyRequest carries the same type but is sent by the placement ready button.
When you may send it
Requires context_ready inferred Raised by: the player toggles the random-challenges switch of the fight's challenge settings (the window also sends the current mode when it opens) proven Related messages
You will then receive ChallengeModSelectedEvent inferred — the server announces the fight's mode to every fighter; the client updates its widget from that event, not from this request Fields
#FieldTypeMeaningYou set it 2challenge_modChallengeModThe challenge mode to switch to.
Type ChallengeMod; its values are not named.required

• summary: Asks to switch the fight's challenge mode between choosing challenges and getting them at random.
• area: Game.Challenge

• 41 vues

Smooth

Octobre 13Oct 13

ChallengeModSelectedEvent

ChallengeModSelectedEvent

The challenge mode of the current fight: whether the team chooses its challenges or gets them at random.
Kind event · Area Game.Challenge
Which way the fight's challenges are decided, as a ChallengeMod value.
WHAT TO DO WHEN YOU RECEIVE IT
1. Store the mode for the fight. 2. In choice mode, expect ChallengeProposalEvent and choose; in random mode the challenges simply arrive in ChallengeListEvent. 3. SEND NOTHING BACK. The client only updates its fight widget (the ready button's label) and its challenge settings.
WHEN IT ARRIVES. On its own when a fight's placement starts, and after a mode switch (ChallengeModSelectRequest).
THE VALUES ARE NOT NAMED HERE: see ChallengeMod. Compare with the value your own ChallengeReadyRequest or ChallengeModSelectRequest carried.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeModSelectRequest Fields
#FieldTypeMeaningYou set it 1challenge_modChallengeModThe fight's challenge mode; values are not named, see the enum.never

• summary: The challenge mode of the current fight: whether the team chooses its challenges or gets them at random.
• area: Game.Challenge

• 38 vues

Smooth

Octobre 13Oct 13

ChallengeNumberEvent

ChallengeNumberEvent

How many challenges the current fight will have; the client resets its challenge list to that many pending entries.
Kind event · Area Game.Challenge
The number of challenges the fight will have, before they are known.
WHAT TO DO WHEN YOU RECEIVE IT
1. Clear your challenge list and prepare ChallengeNumberEvent.challenge_number pending slots. The client does exactly that: it clears its list and fills it with that many placeholder entries, then refreshes the challenge display. 2. Wait for ChallengeListEvent (or ChallengeProposalEvent when the team chooses) to fill the slots. 3. SEND NOTHING BACK.
PADDING. Builds add unread int32s or a nested record; the client reads one int32.
When you may send it
Requires context_ready inferred Related messages
Unsolicited - nothing you send causes this the server announces the number of challenges when a fight's challenges are being prepared Fields
#FieldTypeMeaningYou set it 1challenge_numberint32Number of challenges the fight will have. (count)never

• summary: How many challenges the current fight will have; the client resets its challenge list to that many pending entries.
• area: Game.Challenge

• 37 vues

Smooth

Octobre 13Oct 13

ChallengeProposalEvent

ChallengeProposalEvent

Opens the challenge choice: the challenges the team may pick from and how long the choice stays open.
Kind event · Area Game.Challenge
The challenges the team may choose from, and the time left to choose.
WHAT TO DO WHEN YOU RECEIVE IT
1. Keep ChallengeProposalEvent.challenge_proposals as the current proposals. 2. Start a countdown of ChallengeProposalEvent.timer SECONDS. The client multiplies the value by 1000 and runs its choice timer in milliseconds. 3. To pick one, send ChallengeSelectionRequest with its challenge id, then ChallengeValidateRequest. The selection is echoed by ChallengeSelectedEvent. 4. The choice ends with ChallengeListEvent: the client closes the choice window when the fight's challenge list arrives.
WHEN IT ARRIVES. In choice mode, once the fighters are ready (ChallengeReadyRequest).
NOT THE FIGHT'S CHALLENGES. Proposals are candidates; only ChallengeListEvent and ChallengeAddEvent say which challenges the fight actually has.
PADDING. Builds declare a second list of challenge records, a bool or a nested record beside the real members; the client reads one list and one int64.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeReadyRequest Fields
#FieldTypeMeaningYou set it 3timerint64How long the choice stays open, in seconds; the client multiplies it by 1000. (seconds)never 4challenge_proposalsrepeated ChallengeThe challenges the team may choose from.never

• summary: Opens the challenge choice: the challenges the team may pick from and how long the choice stays open.
• area: Game.Challenge

• 40 vues

Smooth

Octobre 13Oct 13

ChallengeReadyRequest

ChallengeReadyRequest

Sent with the placement 'ready' click: says the player is ready and which challenge mode it is ready for.
Kind request · Area Game.Challenge
Tells the server you are ready, as far as challenges go, and in which challenge mode.
HOW TO SEND IT
1. Send it when you click 'ready' during placement, together with FightReadyRequest: the official client builds both from the same placement service. 2. Put the fight's current challenge mode in ChallengeReadyRequest.challenge_mod: the value the last ChallengeModSelectedEvent carried. Do not invent one; the values of ChallengeMod are not named here. 3. In choice mode, expect ChallengeProposalEvent once everyone is ready.
NOT THE MODE SWITCH. Changing the mode itself is ChallengeModSelectRequest, sent from the challenge settings, not from the ready button.
PADDING. Builds pad it with an int64 or a second field of the same enum type; fill only the recovered member.
When you may send it
Requires context_ready inferred Raised by: during placement, the player clicks the ready button of the fight widget; the fight-preparation service sends it beside FightReadyRequest, with the fight's current challenge mode inferred Related messages
You will then receive ChallengeProposalEvent inferred — in choice mode the proposals open once the fighters are ready; no capture of a challenge fight yet Fields
#FieldTypeMeaningYou set it 1challenge_modChallengeModThe fight's current challenge mode.
Type ChallengeMod; its values are not named.required

• summary: Sent with the placement 'ready' click: says the player is ready and which challenge mode it is ready for.
• area: Game.Challenge

• 41 vues

Smooth

Octobre 13Oct 13

ChallengeResultEvent

ChallengeResultEvent

A fight challenge is over: its id and whether it succeeded.
Kind event · Area Game.Challenge
A challenge of the current fight has been decided.
success = true: the challenge is won. success = false (or absent): it failed.
WHAT THE CLIENT DOES WITH IT
It sets the state of that challenge in its challenge list (success or failure) and updates the challenge display. An id it does not know is ignored (the client logs it). Nothing is sent back.
When you may send it
Requires character_loaded inferred Related messages
Unsolicited - nothing you send causes this the server announces the result when the challenge is decided Fields
#FieldTypeMeaningYou set it 2successboolTrue when the challenge is won; false or absent when it failed.never 3challenge_idint32The challenge that was decided. (challenge id (from the fight's challenge list))never

• summary: A fight challenge is over: its id and whether it succeeded.
• area: Game.Challenge

• 39 vues

Smooth

Octobre 13Oct 13

ChallengeSelectedEvent

ChallengeSelectedEvent

Tells the fight which proposed challenge is currently selected in the challenge choice window.
Kind event · Area Game.Challenge
Marks one proposed challenge as the selected one in the challenge choice window. The payload is a whole challenge record, but only its challenge id is used.
WHAT TO DO WHEN YOU RECEIVE IT
1. Read the record's challenge id. 2. Mark that challenge as selected among the proposals you got from ChallengeProposalEvent; unmark the others. 3. SEND NOTHING BACK. It echoes a ChallengeSelectionRequest. The selection is not final: the challenge only becomes part of the fight when the choice is validated and the fight's list arrives in ChallengeListEvent.
WHEN IT ARRIVES. Only in fights whose challenge mode lets the team choose (ChallengeModSelectedEvent), while the choice window is open.
NOT AN ADD. ChallengeAddEvent carries the same record type and inserts a challenge into the fight; this one only moves the selection.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeSelectionRequest Fields
#FieldTypeMeaningYou set it 1challengeChallengeThe selected challenge; only its challenge id is used.never

• summary: Tells the fight which proposed challenge is currently selected in the challenge choice window.
• area: Game.Challenge

• 39 vues

Smooth

Octobre 13Oct 13

ChallengeSelectionRequest

ChallengeSelectionRequest

Selects one of the proposed challenges in the challenge choice window.
Kind request · Area Game.Challenge
Marks one proposal as the team's pick, before it is validated.
HOW TO SEND IT
1. Only while a choice is open (ChallengeProposalEvent). 2. Put the proposal's challenge id in ChallengeSelectionRequest.challenge_id: the challenge id of one of the records of ChallengeProposalEvent.challenge_proposals. 3. Then confirm with ChallengeValidateRequest.
The official client sends it on each click on a proposal, and once by itself for the first proposal when the choice window opens.
When you may send it
Requires context_ready inferred Raised by: the player clicks a proposed challenge in the challenge choice window (the window also selects the first proposal by itself when it opens) proven Related messages
You will then receive ChallengeSelectedEvent inferred — the server echoes the selection to the fight; the client marks the selection from that event Fields
#FieldTypeMeaningYou set it 1challenge_idint32Challenge id of the proposal to select. (challenge id (game data))required

• summary: Selects one of the proposed challenges in the challenge choice window.
• area: Game.Challenge

• 44 vues

Smooth

Octobre 13Oct 13

ChallengeTargetsEvent

ChallengeTargetsEvent

Updates the targets of one challenge of the current fight: the fighters the challenge is about.
Kind event · Area Game.Challenge
Refreshes the targets of ONE challenge you already know. The payload is a whole challenge record, but only its id and its target list are used.
WHAT TO DO WHEN YOU RECEIVE IT
1. Find the challenge by the record's challenge id among the challenges of the current fight (from ChallengeListEvent and ChallengeAddEvent). 2. IF YOU DO NOT KNOW IT, IGNORE THE MESSAGE. The client logs a warning ("challenge ... not known. Skipping.") and changes nothing: this message never creates a challenge. 3. Replace that challenge's targets with the record's target list. Leave its state and bonuses alone. 4. SEND NOTHING BACK.
WHEN IT ARRIVES. After a ChallengeTargetsRequest (the client asks when it builds a challenge's tooltip), and on its own when a challenge's targets change.
DO NOT TREAT IT AS AN ADD. ChallengeAddEvent carries the same record and inserts or replaces the challenge; this one only updates the targets of an existing one.
PADDING. Builds pad this message with unread members; the challenge record is the only member the client reads.
When you may send it
Requires context_ready inferred Related messages
Arrives after ChallengeTargetsRequest Fields
#FieldTypeMeaningYou set it 1challengeChallengeThe challenge whose targets changed; only its id and its target list are used.never

• summary: Updates the targets of one challenge of the current fight: the fighters the challenge is about.
• area: Game.Challenge

• 37 vues

Smooth

Octobre 13Oct 13

ChallengeTargetsRequest

ChallengeTargetsRequest

Asks for the current targets of one challenge of the fight; the client sends it when it builds that challenge's tooltip.
Kind request · Area Game.Challenge
Refreshes the targets of one challenge before showing them.
HOW TO SEND IT
1. Put the challenge id in ChallengeTargetsRequest.challenge_id: the id of a challenge of the current fight (from ChallengeListEvent or ChallengeAddEvent). 2. Read the answer in ChallengeTargetsEvent.
The official client sends it every time it builds the tooltip of a challenge icon, so expect one per hover. A script rarely needs it: the targets also arrive unasked.
When you may send it
Requires context_ready inferred Raised by: the player hovers a challenge icon: the client asks for the challenge's targets while building its tooltip proven Related messages
You will then receive ChallengeTargetsEvent inferred — the targets come back in the targets event the client applies to its challenge; no capture yet Fields
#FieldTypeMeaningYou set it 1challenge_idint32Challenge whose targets are wanted. (challenge id (game data))required

• summary: Asks for the current targets of one challenge of the fight; the client sends it when it builds that challenge's tooltip.
• area: Game.Challenge

• 42 vues

Smooth

Octobre 13Oct 13

ChallengeValidateRequest

ChallengeValidateRequest

Confirms the selected challenge proposal as the team's choice.
Kind request · Area Game.Challenge
Confirms the pick made with ChallengeSelectionRequest.
HOW TO SEND IT
1. Only while a choice is open (ChallengeProposalEvent), after selecting. 2. Put the selected proposal's challenge id in ChallengeValidateRequest.challenge_id. The official client takes it from whichever of its proposal icons is selected. 3. Expect ChallengeListEvent: the fight's challenges, which close the choice.
When you may send it
Requires context_ready inferred Raised by: the player clicks the confirm button of the challenge choice window proven Related messages
You will then receive ChallengeListEvent inferred — the choice ends with the fight's challenge list, which closes the choice window; no capture yet Fields
#FieldTypeMeaningYou set it 2challenge_idint32Challenge id of the selected proposal to confirm. (challenge id (game data))required

• summary: Confirms the selected challenge proposal as the team's choice.
• area: Game.Challenge

• 41 vues

Smooth

Octobre 13Oct 13

CharacterCharacteristicUpgradeRequest

CharacterCharacteristicUpgradeRequest

Spend capital points on the six base characteristics in one go: one amount of points per characteristic.
Kind request · Area Game.Character
Spends capital points (the characteristic points the character earns by levelling) on the six base characteristics. One request carries the whole spread; the client does not send one request per characteristic.
HOW TO SEND IT
1. KNOW YOUR CAPITAL. The points left to spend are characteristic StatsPoints (3) of CharacterCharacteristicsEvent. 2. FILL ONE MEMBER PER CHARACTERISTIC with the number of CAPITAL POINTS TO SPEND on it, not the characteristic you expect to gain: CharacterCharacteristicUpgradeRequest.strength (StatId 10) CharacterCharacteristicUpgradeRequest.vitality (StatId 11) CharacterCharacteristicUpgradeRequest.wisdom (StatId 12) CharacterCharacteristicUpgradeRequest.chance (StatId 13) CharacterCharacteristicUpgradeRequest.agility (StatId 14) CharacterCharacteristicUpgradeRequest.intelligence (StatId 15) Leave a characteristic you do not boost at 0. 3. SPEND AT MOST YOUR CAPITAL in total. 4. READ THE RESULT in the next CharacterCharacteristicsEvent: each boosted characteristic's base value and the remaining StatsPoints. The values you sent are POINTS SPENT (the client fills them from each row's points used); the server converts them with your class's cost, which is why 3 points on wisdom read as a wisdom of 1 in the observed session.
USE THE NAMES, NEVER THE FIELD ORDER. Field numbers and declaration order differ in every build: 3.7 sends strength as field 7 and wisdom as field 8, 3.2 sends vitality as field 7.
OBSERVED (one session, 3.7.7.6): spending 1 point each on strength, vitality, chance, agility and intelligence and 3 on wisdom sent exactly those amounts, and was answered by InventoryWeightEvent and CharacterCharacteristicsEvent, every one of the six bases then reading 1 and 37 StatsPoints left.
PADDING. Some builds add members the client never writes: an int32 and a two-value enum on 3.7, an int32 and a nested list message on 3.6.12.16, a five-value enum on 3.3.20.19, a map<string, int64> on 3.2. Leave them unset.
When you may send it
Requires character_loaded inferred Raised by: the player validates the points spread in the character sheet's characteristic boost panel (full or minimized) proven Related messages
Reply not yet recovered: the protocol also declares an upgrade-result event (result code and points); it was not seen after the one observed successful upgrade, and it has no signature here yet. Fields
#FieldTypeMeaningYou set it 2vitalityint32Capital points to spend on vitality (StatId 11). (capital points)
0 leaves vitality unchanged.required 4chanceint32Capital points to spend on chance (StatId 13). (capital points)
0 leaves chance unchanged.required 5agilityint32Capital points to spend on agility (StatId 14). (capital points)
0 leaves agility unchanged.required 6intelligenceint32Capital points to spend on intelligence (StatId 15). (capital points)
0 leaves intelligence unchanged.required 7strengthint32Capital points to spend on strength (StatId 10). (capital points)
0 leaves strength unchanged.required 8wisdomint32Capital points to spend on wisdom (StatId 12). (capital points)
Observed: 3, which gave +1 wisdom, observed in a capture
Points spent, not wisdom gained: the server applies your class's cost.required

• summary: Spend capital points on the six base characteristics in one go: one amount of points per characteristic.
• area: Game.Character

• 46 vues

Smooth

Octobre 13Oct 13

ChatPrivateCopyMessageEvent

ChatPrivateCopyMessageEvent

Your own whisper, echoed back by the server with the recipient's name and id.
Kind event · Area Game.Chat
The server's confirmation of a whisper YOU sent with ChatPrivateMessageRequest. It carries your own text back together with who it went to, and the client prints it in the private channel as your side of the conversation.
THIS IS NOT A WHISPER YOU RECEIVED. target_name and target_character_id are the RECIPIENT - the player you wrote to - never you. A whisper sent TO you arrives as ChatChannelMessageEvent with channel Channel.PRIVATE, with the speaker in its sender fields.
USE IT AS THE SEND ACKNOWLEDGEMENT. Match it to the whisper you sent by target_name and content, and react when it arrives; do not block waiting for it.
date IS AN ISO-8601 STRING WITH OFFSET, NOT A UNIX TIME. It looks like "2026-10-11T13:45:21+02:00". Parse it; do not cast it.
content is the words only. Anything shift-clicked into the whisper - items, monster groups - rides in metadata as structured links (see Metadata), and the client merges the two before display. A script reading only content sees the sentence with the links missing.
target_character_id is a CHARACTER id: use it to address the recipient or to open a menu on them.
Recent builds declare extra fields beside these five. The client never reads them; leave them alone.
When you may send it
Requires character_loaded observed Related messages
Arrives after ChatPrivateMessageRequest Fields
#FieldTypeMeaningYou set it 1target_namestringThe recipient's character name, as displayed.
The player you wrote to, never you.never 3contentstringThe text you whispered, without the rich-link content.
The client merges this with the metadata links before displaying the line.never 4metadataMetadataRich content attached to the whisper.
See Metadata. Present but empty for an ordinary whisper. Beta called this field object.
Name ours, after its type Metadata: beta has no such field and no build names it.never 6datestringWhen the whisper was sent.
Observed: 2026-10-11T13:45:21+02:00
An ISO-8601 string with offset. NOT a unix timestamp.never 7target_character_idint64The recipient's character id. (character id)
The player you wrote to, never you.never

• summary: Your own whisper, echoed back by the server with the recipient's name and id.
• area: Game.Chat

• 43 vues

Smooth

Octobre 13Oct 13

Collect

Collect

The range of resources one use of a gathering skill yields: minimum and maximum.
Kind struct · Area Game.Job
How many resources one use of a gathering skill yields: between Collect.min and Collect.max. The client keeps both as 16-bit values.
The two members share one wire type and swap field numbers between builds; they are named from the client slot each is stored in, whose meaning beta's legible converter fixes. One build pads the record with a third, unread int32.
Not sent on its own — it is a record inside Timed, never sent on its own. inferred
Used by
Timed Fields
#FieldTypeMeaningYou set it 1maxint32Most resources one use yields.never 2minint32Fewest resources one use yields.never

• summary: The range of resources one use of a gathering skill yields: minimum and maximum.
• area: Game.Job

• 46 vues

Smooth

Octobre 13Oct 13

Completion

Completion

How far a quest objective has got: the current count and the count it needs.
Kind struct · Area Game.Quest
Progress of one quest objective: Completion.current_completion out of Completion.max_completion - for "kill 10", current goes 0..10 and max stays 10.
Carried by QuestObjective (the objective's state in the journal) and by QuestObjectiveUpdatedEvent (a later change to it). The client keeps both numbers as 16-bit values. The two members share one wire type and swap field numbers between builds; they are named from where the client stores each one, never from their numbers. Some builds pad the record with an unread bool or an unread optional int64.
Not sent on its own — it is a record inside quest messages, never sent on its own. inferred
Used by
QuestObjective QuestObjectiveUpdatedEvent Fields
#FieldTypeMeaningYou set it 1max_completionint64How much the objective needs in total.never 2current_completionint64How much of the objective is done.never

• summary: How far a quest objective has got: the current count and the count it needs.
• area: Game.Quest

• 39 vues

Smooth

Octobre 13Oct 13

ContextCreationEvent

ContextCreationEvent

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_loaded inferred State it changes
Establishes context_ready inferred — on arrival the client's context service enters the roleplay or the fight context this message names Establishes roleplay_context inferred — when it names GameContext.ROLE_PLAY: the client enters the roleplay context, whose services own map movement and interactive elements Invalidates roleplay_context inferred — when it names GameContext.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
#FieldTypeMeaningYou set it 1contextGameContextThe 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

• 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

• 58 vues

Smooth

Octobre 13Oct 13

ContextDestroyEvent

ContextDestroyEvent

The server ending the character's current game context, typically around a fight. Empty; nothing is sent back.
Kind event · Area Game.Context
Carries nothing. Arrival means: the context the character was in is over.
WHAT TO DO WHEN YOU RECEIVE IT
1. Drop everything scoped to the context: the actors you track on the map and, if you were fighting, all fight state. The client does the same - it leaves its current context, which switches that context's services off, and holds no context at all afterwards. 2. SEND NOTHING BACK. No handler of this message builds a request, on any dumped build. 3. Send nothing that needs a context until ContextCreationEvent names the next one.
IN A FIGHT IT ALSO ENDS THE FIGHT. Up to 3.4 the client's fight services handled this message themselves: its fight-preparation and fight-battle handlers close the fight locally, and when the fight was still marked as running - no result had arrived - the battle handler logs "Brutal end of fight (no known result)" and finishes it with an empty result. From 3.5 the context service leaves the fight context instead, which switches the fight services off. Read the log text literally: in a normal fight the result comes first and this message only closes the context; on its own, it means the fight was cut short and no result will follow.
IT IS NOT THE ONLY WAY OUT OF A CONTEXT. ContextCreationEvent of the other kind also leaves the current context, so do not wait for this message before accepting a new one.
A 3.4 build declares an optional int32 in it; the client never reads it.
When you may send it
Requires context_ready inferred State it changes
Invalidates context_ready inferred — the client leaves and drops its current context and holds none until the next ContextCreationEvent Invalidates roleplay_context inferred — the client leaves its current context, the roleplay one included, and holds none until the next ContextCreationEvent Related messages
Reply not yet recovered: what makes the server send it is not established here. It is the teardown half of a context switch, and the next context arrives as ContextCreationEvent; the fight messages around it have no signature.

• summary: The server ending the character's current game context, typically around a fight. Empty; nothing is sent back.
• area: Game.Context

• 40 vues

Smooth

Octobre 13Oct 13

ContextQuitRequest

ContextQuitRequest

Asks to leave the current game context; sent when the player leaves a fight. No payload.
Kind request · Area Game.Context
CARRIES NOTHING. Asks the server to take the character out of the current game context, which in practice means leaving (abandoning) the fight.
WHEN TO SEND IT
The official client sends it when the player clicks "Leave" on the fight's end-turn widget and confirms the popup. Leaving a fight early can count as a loss/abandon.
WHAT COMES BACK
The context is destroyed (ContextDestroyEvent) and a new one is created.
When you may send it
Requires context_ready inferred Raised by: the player clicks "Leave" on the fight's end-turn widget and confirms proven Related messages
Reply not yet recovered: The server tears the fight context down; the client then receives the context destruction and a new context.

• summary: Asks to leave the current game context; sent when the player leaves a fight. No payload.
• area: Game.Context

• 47 vues

Smooth

Octobre 13Oct 13

ContextRefreshEntityLookEvent

ContextRefreshEntityLookEvent

One entity in the current context changed appearance. Replace the look you store for it.
Kind event · Area Game.Context
Replace the stored look of entity_id with look. The entity itself stays where it is: its id, position and everything else you know about it are unchanged.
Step by step:
1. Find the entity under entity_id - the same id space as ContextRemoveElementEvent.element_id and ActorPositionInformation.actor_id. 2. Overwrite its whole EntityLook with look. It is a complete look, not a delta: sub-entities (a mount, a pet) are inside it and replace the old ones. 3. Send nothing back.
IT ARRIVES IN BOTH CONTEXTS. On a roleplay map the client redraws the actor; in a fight it redraws the fighter. Handle it the same way in both.
THE ID CAN BE YOUR OWN CHARACTER. Update your own look too, or your record of yourself goes stale.
An id you do not know is not an error: the client looks the entity up and changes nothing when it is not there. Do not create an entity from this message; entities come from GameRolePlayShowActorsEvent.
Some builds declare extra fields beside these two. The client never reads them; leave them alone.
When you may send it
Requires context_ready inferred Related messages
Unsolicited - nothing you send causes this the server sends it whenever an entity's appearance changes; nothing the client sends asks for it Fields
#FieldTypeMeaningYou set it 1entity_idint64The entity whose look changed: a player, monster, NPC or fighter in the current context. (entity id)
Same id space as ContextRemoveElementEvent.element_id. It can be your own character.never 2lookEntityLookThe entity's complete new appearance. It replaces the old look, sub-entities included.never

• summary: One entity in the current context changed appearance. Replace the look you store for it.
• area: Game.Context

• 53 vues

Smooth

Octobre 13Oct 13

Craft

Craft

A crafting skill: its success chance.
Kind struct · Area Game.Job
The crafting branch of SkillAction: Craft.probability, the skill's success chance. Its scale (percent or otherwise) is not established by client code.
Not sent on its own — it is the craft branch of SkillAction, never sent on its own. inferred
Used by
SkillAction Fields
#FieldTypeMeaningYou set it 2probabilityint32The skill's success chance.never

• summary: A crafting skill: its success chance.
• area: Game.Job

• 43 vues

Smooth

Octobre 13Oct 13

Details

Details

The step an active quest is currently on, and the objectives of that step.
Kind struct · Area Game.Quest
The progress half of QuestActive: which step the quest is on (Details.step_id) and that step's objectives (Details.objectives). It is declared inside QuestActive and travels nowhere else.
ONE STEP ONLY. It describes the current step, not the quest's history - earlier steps are not listed, and a finished quest carries no Details at all (see QuestFinished).
HOW THE CLIENT USES IT. It stores the step id beside the quest id, narrowed to a signed 16-bit value, and walks the objectives to build its per-objective state - each one filed as done or still to do, with its progress and its text parameters. When the step moves on the server sends a new QuestActive; replace the whole Details you held.
Not sent on its own — it is only ever the QuestActive.details member. inferred
Used by
QuestActive Fields
#FieldTypeMeaningYou set it 1step_idint32Which step of the quest is the current one. (quest step id)
Stored by the client as a signed 16-bit value.never 3objectivesrepeated QuestObjectiveThe objectives of the current step.
A list of QuestObjective.never

• summary: The step an active quest is currently on, and the objectives of that step.
• area: Game.Quest

• 40 vues

Smooth

Octobre 13Oct 13

EntitiesDispositionEvent

EntitiesDispositionEvent

New cells and facing directions for one or more entities of the current context, typically the fighters during placement.
Kind event · Area Game.Context
Moves entities without a walk: each entry is an EntityDisposition - which entity, the cell it now stands on and the direction it now faces. Nothing animates a path; the entity is simply put there.
WHAT TO DO WHEN YOU RECEIVE IT
1. For every entry, look the entity up by EntityDisposition.entity_id and OVERWRITE its cell (EntityDisposition.cell_id) and its direction (EntityDisposition.direction). 2. LEAVE EVERY OTHER ENTITY ALONE. It is not a snapshot: entities missing from the list keep their position. 3. SEND NOTHING BACK. No handler of this message builds a request.
WHEN IT ARRIVES. In the client it is handled by the fight services (the placement cells and the fighters' on-map positions). In a capture it arrived right after AttackMonsterRequest: first with the attacker alone, then four more times with the attacker and one monster each, while the fight was being set up. Expect it whenever a fighter is (re)placed during the placement phase, yours or someone else's - including after your own FightPlacementPositionRequest.
NOT THE PLACEMENT SWAP. The fight placement swap announcement carries the same kind of list but belongs to the fight-preparation protocol file; this one is the context-level message.
PADDING. Builds pad this message with an unread int32, or with a SECOND list of the same record type (3.6.10.10) that the client never reads. Read the recovered list only.
When you may send it
Requires context_ready inferred Related messages
Arrives after AttackMonsterRequest Arrives after FightPlacementPositionRequest Fields
#FieldTypeMeaningYou set it 2dispositionsrepeated EntityDispositionThe entities that moved, each with its new cell and direction.
Element type EntityDisposition. Only the listed entities change.never

• summary: New cells and facing directions for one or more entities of the current context, typically the fighters during placement.
• area: Game.Context

• 44 vues

Smooth

Octobre 13Oct 13