Smooth

Which channel a server text message is routed to. Kind enumArea Game.ChatNamed by beta WHERE THE MESSAGE GOES. The client derives the chat channel from this value, so it decides whether the text appears as an ordinary line, an error, a popup, fight-log chatter, or speech from an entity. TEXT_INFORMATION_POPUP is the one that opens a popup rather than writing a line; TEXT_INFORMATION_ERROR is the error styling. EXPECT VALUES YOU DO NOT KNOW. The set has grown from nine to thirteen since the reference build and the four newer ones have no published names, so treat an unknown value as 'display it plainly' rather than switching exhaustively. Not sent on its own — it is a member type of TextInformationEvent, never sent alone. proven Used by TextInformationEvent Values ValueNumberMeaning TEXT_INFORMATION_MESSAGE0General information, shown as an ordinary message. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_ERROR1An error, shown in the error style. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_PVP2PvP information. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_FIGHT_LOG3A line of the fight log. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_POPUP4Shown as a popup rather than inline. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_LIVING_OBJECT5Text spoken by a living object (a pet or similar). The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_ENTITY_TALK6Text spoken by an entity on the map. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_FIGHT7Fight information. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. TEXT_INFORMATION_EVENT8Event information. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 declares nine values 0-8 and every dumped 3.x build still declares all nine, adding 10-13 on top and skipping 9 - growth that is append-only, which is what makes the low numbers safe to carry. No dumped client distinguishes one value from another by name, so only the NUMBER is proven here. Recovered with score 220, confidence 0.83, margin 220 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: 9 of 13.

A system line pushed into the chat log, sent as a message id plus substitution arguments rather than as text. Kind eventArea Game.ChatNamed by beta, gamemapping ONE OF THE HIGHEST-VALUE INBOUND MESSAGES THERE IS. Almost everything the server tells you in words - fight results, PvP notices, item and object notifications, entity speech, event announcements - arrives here. THE SERVER DOES NOT SEND YOU TEXT. It sends message_id, an identifier into the client's own information-message table, plus parameters, an ordered list of substitution arguments. The CLIENT renders the localised sentence. A script that expects a readable string finds none. So match on message_id, not on words. That is both more reliable and language-independent: the same event carries the same id whatever locale the client runs in. If you need the sentence, you need the client's information-message table to resolve the id and its template. message_type selects what KIND of line this is and therefore which chat channel it lands in. parameters are positional and their meaning depends entirely on which message id they accompany. The client splits and inspects individual entries before formatting, so do not assume they are all plain strings. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this the server narrates whatever it wants to narrate; no request asks for it Fields #FieldTypeMeaningYou set it 1message_idint32Which information message this is, as an id into the client's message table. (info message id) MATCH ON THIS, not on rendered text - it is stable across locales.never 2message_typeTextInformationTypeWhat kind of information line this is, and therefore which chat channel it lands in.never 3parametersrepeated stringOrdered substitution arguments for the localised template. Positional; their meaning depends on the message id. The client splits and inspects individual entries rather than treating them all as plain text.never Recovered with score 110, confidence 0.83, margin 110 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: 3 of 3.

A system notification, sent as a message id plus arguments, optionally forcing a blocking display. Kind eventArea Game.ChatNamed by beta, gamemapping Like TextInformationEvent, this carries an id and arguments rather than text - but it is the SYSTEM notification path, and one flag on it matters a great deal. hang_up TRUE IS THE DISCONNECT WARNING. The client takes a different branch for it: before rendering anything it invokes an action on its connection service, and only then displays the message through the blocking path. In practice this is the "you are being disconnected" class of notice. A script that ignores it keeps playing into a session that is about to end. message_id is resolved against the same information-message table as TextInformationEvent.message_id but with a SYSTEM-MESSAGE NAMESPACE OFFSET ADDED FIRST. The raw ids from the two messages are not interchangeable. parameters are the positional substitution arguments, same rules as the information line. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this the server raises system notices on its own Fields #FieldTypeMeaningYou set it 2hang_upboolWhether this notice is on the disconnecting path. True makes the client call its connection service before displaying, and display through the blocking path.never 3parametersrepeated stringOrdered substitution arguments for the localised text. Positional; their meaning depends on the message id.never 4message_idint32Which system message this is. (info message id) Resolved after adding the system-message namespace offset - not the same id space as TextInformationEvent.message_id raw.never Recovered with score 220, confidence 0.95, margin 220 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: 3 of 4.

One look attached to another: a mount carrying its rider, a pet beside its owner, an entity being lifted. Kind structArea Game.CommonNamed by beta The element of EntityLook.sub_entities. It nests an EntityLook of its own, SO THE STRUCTURE IS RECURSIVE - bound your traversal. binding_point_category says what the attachment IS (see BindingPointCategoryEnum); binding_point_index says which slot within that category. The category is the one worth reading: it is how you tell a rider from a pet from a carried entity. THE NUMBERS ARE REVERSED ON THIS BUILD - the look is 1, the index 3 and the category 4, with a decoy string sitting at 2. None of the three is read from its number. Not sent on its own — it is only ever an element of EntityLook.sub_entities. proven Used by EntityLook Fields #FieldTypeMeaningYou set it 1binding_point_categoryBindingPointCategoryEnumWhat kind of attachment this is. A BindingPointCategoryEnum value.never 2binding_point_indexint32Which slot within that category the sub-entity occupies.never 4sub_entity_lookEntityLookThe attached entity's own appearance. An EntityLook, which may carry sub-entities of its own.never Recovered with score 255, confidence 0.86, margin 255 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: 3 of 4.

The seven availability states a character can be in, from offline to solo. Kind enumArea Game.CommonNamed by beta The states carried by CharacterStatus. Every dumped build declares exactly these seven, numbered 0 to 6 in this order, so the numbering is the real wire contract rather than a declaration-order artefact. TWO OF THEM LOOK ALIKE AND ARE NOT. STATUS_IDLE is set by the CLIENT when it notices inactivity; STATUS_AFK is set deliberately by the PLAYER. Reporting AFK when you merely went quiet is a claim about intent that the real client does not make on its own. STATUS_PRIVATE and STATUS_SOLO both decline contact but differ in kind: the first is "do not disturb", the second declines party and group invitations specifically. Not sent on its own — an enum is never sent on its own. inferred Used by CharacterStatus Values ValueNumberMeaning STATUS_OFFLINE0Not connected. STATUS_AVAILABLE1Connected and open to contact. The normal state. STATUS_IDLE2Connected but inactive. Set by the CLIENT on noticing inactivity, not by the player. STATUS_AFK3Away from keyboard. Set DELIBERATELY by the player. Not the same as idle. STATUS_PRIVATE4Do not disturb: visible, but declining contact. STATUS_SOLO5Playing alone - declines party and group invitations. STATUS_UNKNOWN6Unknown or unrepresentable state. Recovered with score 125, confidence 0.94, margin 125 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: 7 of 7.

The state of every stated element on the map, sent when the character arrives. Kind eventArea Game.InteractiveNamed by beta The map's stated-element snapshot, and the baseline that StatedElementUpdatedEvent deltas apply on top of. IT IS A SNAPSHOT - REPLACE, DO NOT MERGE. It arrives once per map arrival. Read it together with InteractiveMapUpdateEvent: the two lists describe the same objects from different angles and join on StatedElement.element_id. Neither alone tells you both what a node IS and what state it is IN. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server sends the snapshot on map arrival Fields #FieldTypeMeaningYou set it 1stated_elementsrepeated StatedElementEvery stated element on the map. Element type StatedElement.never Recovered with score 130, confidence 0.88, margin 130 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.

One stated element changing state: a door opening, a lever thrown, a resource going from full to harvested. Kind eventArea Game.InteractiveNamed by beta The delta counterpart of StatedMapUpdateEvent. THIS IS THE MESSAGE THAT TELLS YOU A RESOURCE WAS TAKEN. Combined with InteractiveElementUpdatedEvent it is how a harvesting script learns that a node it was heading for is no longer worth walking to - including when somebody else took it. Match by StatedElement.element_id and replace the element in your model. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server publishes state changes as they happen Fields #FieldTypeMeaningYou set it 3stated_elementStatedElementThe element whose state changed. A whole StatedElement - replace your copy rather than patching it.never Recovered with score 130, confidence 0.88, margin 130 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 3.

One scenery object whose visual state the server drives: a door, a lever, a gate, a harvested stump. Kind structArea Game.InteractiveNamed by beta A map object whose STATE the server owns. Where InteractiveElement says what you may do with an object, this says what it currently looks like: open or closed, full or harvested. state IS AN OPAQUE PER-ELEMENT VALUE, NOT A SHARED ENUM. The client feeds it straight to its animation layer; what state 2 means depends entirely on the element type. Compare it against the previous value for the same element rather than assigning meanings to numbers. element_id is the SAME id as InteractiveElement.element_id and InteractiveUsedEvent.element_id. That is what makes the two element families join: the interactive record tells you a node is harvestable, this one tells you it is currently full. cell_id is a single map cell index. A DOFUS map has 560 cells, which is why the client can safely narrow this value to 16 bits. on_current_map FALSE MEANS DROP IT, as with interactive elements. Not sent on its own — it travels inside the stated snapshot or update events. inferred Used by MapComplementaryInformationEvent StatedElementUpdatedEvent StatedMapUpdateEvent Fields #FieldTypeMeaningYou set it 1on_current_mapboolWhether the element belongs to the map the character is standing on.never 2stateint32The visual state the server is putting the element into. Opaque and per-element-type: open/closed, full/harvested and so on. The client passes it straight to its animation layer.never 3element_idint32Identity of the stated element, shared with the interactive element of the same object. (interactive element id)never 4cell_idint32The map cell the element stands on. (map cell id) Range: 0-559 on a standard mapnever Recovered with score 100, confidence 0.95, margin 100 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: 4 of 4.

One per-spell modifier currently in effect on the character. Kind structArea Game.CommonNamed by beta One modifier applied to one spell - a range increase, a cost reduction and so on. ITS MEMBERS ARE NOT INDIVIDUALLY RECOVERED HERE and stand with their obfuscated names. The reference build declares a spell id, two enum selectors saying which property is modified and in what way, and two integer amounts distinguishing the contextual part from the equipment part - but nothing in the current build separates those roles behaviourally, so nothing is claimed. If you need spell modifiers, read them positionally against the reference layout and verify against the character sheet in game before relying on them. Not sent on its own — it is only ever an element of CharacterCharacteristics.spell_modifiers. inferred Used by CharacterCharacteristics No fields you may set. Recovered with score 100, confidence 0.91, margin 100 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: 0 of 6.

The full contents of one of the player's shortcut bars: spells, items, presets, emotes and cosmetics. Kind eventArea Game.InventoryNamed by beta, gamemapping One bar's worth of slots. It arrives once PER BAR during the connection burst, so expect several of these, distinguished by bar_type. IT IS ONE WHOLE BAR, NOT A SLOT UPDATE - REPLACE THAT BAR, DO NOT MERGE. A slot missing from the list is an empty slot. KEY YOUR MODEL BY bar_type, NOT BY ARRIVAL ORDER. Nothing guarantees the bars arrive in a fixed order, and a second message for the same bar replaces the first. shortcuts lists only the OCCUPIED slots; each carries its own slot index. Do not read these members by field number: the list and the bar selector are declared in the opposite order to the reference build, and have been since the earliest dumped 3.x build. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this sent once per bar during the connection burst, and again whenever the server resends a bar Fields #FieldTypeMeaningYou set it 1shortcutsrepeated type not documented yetEvery occupied slot of the bar. Only occupied slots appear; each carries its own index.never 2bar_typetype not documented yetWhich of the player's bars this content belongs to. Key your model by this, not by the order the messages arrive in.never Recovered with score 350, confidence 0.87, margin 350 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: 2 of 2.

The current state of one equipment set: which of its pieces are worn and which bonuses that grants. Kind eventArea Game.InventoryNamed by beta, gamemapping Sent when the character's equipment changes in a way that affects a set bonus. IT IS THE WHOLE STATE OF ONE SET, NOT A DELTA - REPLACE, DO NOT MERGE. The message names a set and lists every piece currently worn from it together with every bonus currently active. Removing a piece produces a new message with a SHORTER list, not a removal instruction, so a script that merges never sees a bonus expire. Key your model by set_id. The client does exactly that: it uses the same value as a dictionary key for set state and as the subject of its own notification. effects are the bonuses granted at the CURRENT number of worn pieces, not the set's full table. They are ObjectEffect values and carry the same branch-on-the-oneof rule. The record declares additional members no dumped build reads. They stand with their obfuscated names. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this the server pushes it when equipment changes; no request asks for it Fields #FieldTypeMeaningYou set it 1effectsrepeated ObjectEffectThe bonuses active at the current number of worn pieces. Element type ObjectEffect - branch on its oneof.never 3set_idint32Which equipment set this update is about. (set id)never 4objects_uidrepeated int32The unique handles of the set pieces currently worn. (item instance ids) These are ObjectItem.uid values, not template gids.never Recovered with score 310, confidence 0.99, margin 310 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: 3 of 4.

Server-initiated challenge that obliges the client to identify itself. Kind eventArea Game.Client.VerificationNamed by beta, gamemapping YOU MUST ANSWER THIS. The client's own handler ignores the event's contents entirely and replies with ClientIdRequest; nothing in the payload is needed to build the answer. The answer is not a constant. The real client generates fresh random handshake state, computes a modular exponentiation from it, and sends the result as a decimal string. A replayed or fixed value is not what a real client produces. When you may send it Requires transport_established observed Related messages You must then send ClientIdRequest proven — the client's handler computes the identifier and hands back the request Unsolicited - nothing you send causes this the server opens the verification exchange on its own Recovered with score 138, confidence 0.94, margin 138 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: 0 of 0.

Which ruleset family the connected game server runs: classical, arena, tournament, epic or seasonal. Kind enumArea Game.ConnectionNamed by beta Carried by ServerSettingsEvent. It tells you what KIND of server you are on, and that changes what your script may safely do. EPIC IS THE ONE THAT MATTERS. Epic servers have permanent death: a character that dies there is gone. A script that treats death as a recoverable state - walk to the phoenix, carry on - is wrong on those servers in a way that cannot be undone. Check this before writing any combat automation. TEMPORIS servers are seasonal and temporary; anything you build on one has a known expiry. Not sent on its own — an enum is never sent on its own. inferred Used by ServerSettingsEvent Values ValueNumberMeaning UNDEFINED0No recognised ruleset. CLASSICAL1A standard game server. KOLIZEUM2A dedicated Kolizeum arena server. TOURNAMENT3A tournament ruleset server. EPIC4An Epic ruleset server. PERMANENT DEATH. A character that dies here is gone for good. TEMPORIS5A temporary seasonal Temporis server. Recovered with score 100, confidence 0.96, margin 100 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: 6 of 6.

The server's environment: language, community, ruleset and account limits. Kind eventArea Game.ConnectionNamed by beta, gamemapping Pushed once, in the burst that follows a successful IdentificationRequest. Nothing requests it. Worth storing rather than ignoring: it tells you which ruleset the server runs and whether the account is restricted to one character at a time, both of which change what later requests are legal. When you may send it Requires authenticated observed Related messages Arrives after IdentificationRequest Fields #FieldTypeMeaningYou set it 1is_mono_accountboolWhether the account may only play one character at a time on this server.never 2arena_leave_ban_timeint32How long a player is barred from arena after leaving a match. (minutes)never 3has_free_autopilotboolWhether autopilot is available without a subscription here.never 4item_max_levelint32Highest item level this server allows.never 5game_typeServerTypeThe server's ruleset.never 6communityint32Community id the server belongs to.never 7languagestringThe server's language, e.g. fr.never Recovered with score 145, confidence 0.96, margin 145 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: 7 of 7.

The game session is ready to complete its cryptographic handshake. Kind eventArea Game.ConnectionNamed by beta, gamemapping Carries no payload. Arrival means the server is ready for the session handshake, and the client answers with ClientChallengeInitRequest. In a capture it closes the burst that follows acceptance of IdentificationRequest, and the answer goes out a few milliseconds later - notably as one of the rare CORRELATED requests, meaning the client allocates an envelope id for it and expects the reply routed back to that id. When you may send it Requires authenticated observed Related messages You must then send ClientChallengeInitRequest inferred — the client's handler derives the session value and sends the init request Arrives after IdentificationRequest No fields you may set. Recovered with score 160, confidence 0.92, margin 160 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: 0 of 1.

The server's experience multipliers, sent once and kept for the session. Kind eventArea Game.ServerNamed by beta, gamemapping THE SERVER'S EXPERIENCE MULTIPLIERS, sent once and kept for the session. There is no request for it and no refresh - it arrives unprompted early on. THE NUMBERS ARE OFFSET BY 100 - MOSTLY Two of the values are percentages expressed as a multiplier over normal, and the client subtracts 100 from each before storing them. A wire value of 200 becomes a stored 100, i.e. "+100%". A third value is stored exactly as sent. If you read these raw and show them to a user you will overstate every bonus by 100 points. WHICH IS WHICH IS NOT SETTLED, AND THIS RECORD DOES NOT PRETEND OTHERWISE. The reference build declares this message with a SINGLE field; the current one carries three the client actually reads. Only one canonical member name exists, so none of the three is named here - they keep their obfuscated names rather than being given a label by guesswork. What IS established is the shape: two offset-by-100 values and one raw one, all three stored into played-character state and read back from there. A FOURTH DECLARED MEMBER IS PADDING and no dumped client has ever read it. If you need one of these values specifically, capture it against a server whose rates you know - the transform above tells you how to interpret what you see. When you may send it Requires context_ready observed Related messages Reply not yet recovered: the message carries three live members and only one canonical member name exists for it; the members are therefore left with their obfuscated names. See the notes. No fields you may set. Recovered with score 215, confidence 0.88, margin 215 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: 0 of 4.

The server's challenge in the proof-of-identity handshake. The one message in that chain whose contents you must read. Kind eventArea Game.Client.VerificationNamed by beta, gamemapping Arrives because you sent ClientChallengeInitRequest, and must be answered with ClientChallengeProofRequest. THE HANDSHAKE DOES NOT COMPLETE UNTIL YOU DO. WHEN IT ARRIVES Shortly after your init request, and only then - the server does not send it on its own schedule. But it is delivered as an ordinary event: the client matches it BY TYPE, not by the envelope id it allocated for the init. There is only ever one of these exchanges in flight, so nothing needs correlating, and you should not sit waiting for a uid to come back. It is the third of four steps. ClientIdRequest and ClientChallengeInitRequest publish the two values this challenge is checked against; if you have not sent both, there is nothing here you can usefully answer. READ THE PAYLOAD - THIS IS THE ONE STEP WHERE IT MATTERS PARSE IT AS AN ARBITRARY-PRECISION INTEGER. The value is a decimal string and the real client parses it as a big integer, multiplies it by its private exponent and reduces the result. It is not bounded by anything you can hold in 64 bits, and truncating or overflowing it produces a proof that is silently wrong rather than an error you can see. ABSENT IS NOT EMPTY, AND ABSENT DOES NOT MEAN SKIP IT. The field has explicit presence and the client tests for it. When the value is missing the client does NOT stay silent and does not fail - it computes a challenge of its own by hashing its handshake values together with a device fingerprint, and answers with that. Treating a missing value as "nothing to do here" leaves the handshake open, which is exactly the state the exchange exists to detect. ClientChallengeProofRequest gives the full recipe for both branches. WHERE THE ANSWER GOES ON THE MAIN GAME CONNECTION, even when a second one is open. While a fight-server transfer is active the client holds two sockets (see IdentificationRequest) and routes outbound traffic between them by message type. All three verification requests are on the short list pinned to the FIRST connection - ordinary gameplay traffic is what goes to the fight server. Answering on the wrong socket is a mistake the real client cannot make. THE COMPLETE ALGORITHM IS ON ONE PAGE. Constants, both exponents, both branches, what the server checks and the ways an implementation goes wrong are written out in full under ClientChallengeProofRequest. Read that before implementing any part of this exchange. When you may send it Requires authenticated observed Related messages You must then send ClientChallengeProofRequest proven — the client's handler combines this value with its state and returns the proof Arrives after ClientChallengeInitRequest Fields #FieldTypeMeaningYou set it 1valuestringThe server's challenge, as a decimal string, combined with your handshake state to derive the proof. Explicit presence: absent is not the same as zero. Parse it as an arbitrary-precision integer. It is not bounded to 64 bits, and a truncated value yields a wrong proof rather than a visible error. Absent means "no challenge given" - and that is an instruction, not a rest: the client derives its own challenge and answers anyway. See ClientChallengeProofRequest.never; inbound only Recovered with score 144, confidence 0.92, margin 144 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.

Empty server poll asking the client how many events it has received. Kind eventArea Game.BasicNamed by beta, gamemapping Carries no payload - the message IS the question. Answer it with SequenceNumberRequest carrying how many of these polls have reached you on this connection, the one you are answering included. COUNT THE POLLS, NOT YOUR INBOUND TRAFFIC. The real client keeps one counter per connection that nothing but this poll touches: zeroed when the socket becomes active, incremented once per arrival, so the first reply carries 1 and never 0. See SequenceNumberRequest for the full rule. In a capture the real client replies in the same millisecond, and this poll arrives in the same frame as BasicLatencyStatsEvent. When you may send it Requires authenticated observed Related messages You must then send SequenceNumberRequest observed — the poll is unanswered until the client reports its counter Unsolicited - nothing you send causes this the server polls on its own schedule; nothing you send asks for it Sequence Step server_poll.1 observed — the server emits both polls in the same frame; of 2 observations Recovered with score 90, confidence 0.95, margin 90 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: 0 of 0.

Five account permission booleans whose individual meanings are not recovered. Kind structArea Game.AccountNamed by stringtable Five booleans, and we do not know which is which. THIS IS A DELIBERATE GAP, NOT AN OVERSIGHT. The reference build has no account-level rights type in the game protocol, the early 3.x name map has none, and the client never branches on an individual flag - only on whether the block is present at all. There is nothing to prove a mapping with, so nothing is claimed. Read them positionally as opaque flags if you must, and expect their order to be meaningless across builds. The safe answer is to ignore this record. The type name itself is real: it comes from the current build's own protocol type-name table. Not sent on its own — it is only ever carried by AccountRightsEvent. inferred Used by AccountRightsEvent No fields you may set. Recovered with score 130, confidence 0.89, margin 130 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: 0 of 5.

Grants or refuses the token that skips full authentication on the next connection. Check the flag before the token. Kind eventArea Game.ConnectionNamed by beta, gamemapping Answers ReloginRequest, and it is the only thing worth waiting for in that exchange. CHECK THE FLAG BEFORE YOU READ THE TOKEN A REFUSAL IS NOT AN ERROR MESSAGE, and it is not silence - the server answers, the flag is simply clear. Read the flag first. If you read the token unconditionally you will carry an empty string into the next connection and fail authentication there, far from the cause and looking nothing like this exchange. THE REAL CLIENT OVERWRITES ON REFUSAL. It does not keep the token it already had: on the refusal branch it stores an empty string over it, deliberately. Do the same. A stale token from an earlier session is worse than none, because it will be presented and rejected. WHAT THE TOKEN IS FOR The next connection presents it instead of a full authentication round. Store it, then proceed with whatever you were doing - the real client stores it and only then replays the menu action that asked for it. If you act first and store second, you can leave the server before the value is in hand. READ IT BY ROLE, NOT BY NUMBER The message is padded, and the padding is different in every build - a nested message here, a spare bool there, a map somewhere else - while the two members that matter keep swapping field numbers between builds. Two members are live: one bool that says whether a token was granted, and one string that carries it. Everything else in the declaration is padding no client has ever read. IT ARRIVES BY TYPE. The request went out uncorrelated, so nothing links this event back to it by uid. There is only ever one of these exchanges in flight, so nothing needs correlating. When you may send it Requires authenticated observed Related messages Arrives after ReloginRequest Fields #FieldTypeMeaningYou set it 1valid_tokenboolWhether the server granted a token. Gates the token below.never 2tokenstringThe relogin token, empty when refused.never Recovered with score 220, confidence 0.89, margin 220 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: 2 of 2.

Your position in the login queue while the server is full. Kind eventArea Game.Character.ManagementNamed by beta, gamemapping Arrives repeatedly while the account waits in the login queue, and stops once you are through. In a capture of an uncongested sign-in it still appears a few times in quick succession with a shrinking payload. WAIT, DO NOT RETRY. Receiving this means the server has your connection and is holding it; re-sending CharacterListRequest or reconnecting only puts you back at the end. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this the server pushes queue progress on its own; nothing you send asks for it Fields #FieldTypeMeaningYou set it 1positionint32Your place in the queue.never 2totalint32How many accounts are queued in total.never Recovered with score 126, confidence 0.97, margin 126 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: 2 of 2.

The current step of one quest and its objectives. Kind eventArea Game.QuestNamed by beta, gamemapping The answer to QuestStepInformationRequest. The real content is information - a QuestActive carrying the quest and the step it is on. player_id is USUALLY ABSENT, because the answer goes to the character who asked. Do not require it to be present, and do not use it as the key to match the reply against your request - use the quest id inside information. When you may send it Requires character_loaded observed Related messages Arrives after QuestStepInformationRequest Fields #FieldTypeMeaningYou set it 1player_idint64Whose journal the reply concerns. Explicit presence: absent is not the same as zero. (character id) Usually absent - the answer goes to whoever asked.never 2informationQuestActiveThe quest and the step it is currently on. A QuestActive. This is the actual answer.never Recovered with score 200, confidence 0.79, margin 200 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: 2 of 2.

One quest the character has under way, with the detail of the step it is currently on. Kind structArea Game.QuestNamed by beta, gamemapping, stringtable A shared carrier, not a message anyone sends: the journal embeds a list of these and QuestStepInformationEvent embeds exactly one. details carries the current step and its objectives. That nesting is the point of the record - the quest id alone tells you nothing about progress. The current build declares a SECOND int32 and a SECOND message member beside the real ones. This signature names its members only on builds where each is unambiguous, so on a padded build they stand obfuscated rather than being guessed at from position. Not sent on its own — it is embedded in the quest journal and in QuestStepInformationEvent. inferred Used by QuestStepInformationEvent Fields #FieldTypeMeaningYou set it 1quest_idint32Which quest is under way. (quest id)never 2detailstype not documented yetThe step the quest is currently on, and its objectives.never Recovered with score 190, confidence 0.84, margin 190 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: 2 of 3.

A moderator's warning: who sent it and what it says, shown to the player. Kind eventArea Game.ModerationNamed by gamemapping, beta A MODERATOR IS TALKING TO YOU. The server pushes this unprompted and the client renders the moderator's name and their message. If you are running anything automated, this arriving means a human has looked at your account and acted. Treat it as a stop signal, not as chat. WHAT IT CARRIES author the moderator's displayed name content the warning text itself lock_duration an int32 NO CLIENT READS - see below DO NOT BUILD ANYTHING ON lock_duration. The name is Ankama's, but it is carried across from the reference build by elimination: it is the message's only int32 there and its only int32 here. NO DUMPED CLIENT READS IT - not this build, not any 3.x build, and not the unobfuscated reference build either, whose five handlers touch author_ and content_ and nothing else. Whatever the server puts in it, the game ignores it, so a value of zero is entirely normal and no client behaviour depends on it. It is named because the name is real, not because the field does anything observable. WHAT THE CLIENT ACTUALLY DOES It reads the two strings and hands them to the popup service. That is all. WHAT FOLLOWS The family completes with an acknowledgement round trip, and this part IS verified in the dumps: the client builds and sends a close request when the popup is dismissed, and consumes a closed event in return. On 3.2.7.15 both were empty; by 3.6.10.10 the close request carries a four-value enum - presumably how the popup was dismissed - while the closed event is still empty. Neither is recovered yet. So the server can tell whether the warning was actually seen and closed. Failing to acknowledge is itself a signal. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this no client code builds it; it is pushed by the server Fields #FieldTypeMeaningYou set it 1authorstringThe moderator's displayed name.never 2lock_durationint32An int32 no dumped client reads. Name carried from the reference build. NOT VERIFIED AT RUNTIME. The name is the reference build's and is assigned by type-elimination - one int32 there, one int32 here. No client in any dumped build reads this member, including the unobfuscated reference build, so nothing confirms it is a duration or that it has any effect. Expect zero and do not depend on it.never 3contentstringThe warning text shown to the player.never Recovered with score 195, confidence 0.88, margin 195 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: 3 of 3.

Server reply to a ping; the client turns it into a round-trip latency sample. Kind eventArea Game.ConnectionNamed by beta, gamemapping Answers PingRequest. On receipt the real client takes the clock again, enqueues the round-trip delta into a bounded sample queue, and exposes average, maximum and sample count from it. THOSE SAMPLES ARE NOT SELF-CONTAINED. They are the source of the value reported when the server polls with BasicLatencyStatsEvent, so skipping the ping exchange leaves you with nothing honest to report in BasicLatencyStatsRequest - a self-reported number the server can compare against how long you actually took to answer. Nothing else consumes this exchange, and no protocol decision depends on it. Two of its declared members are never read by any dumped build. When you may send it Requires authenticated observed Related messages Arrives after PingRequest Fields #FieldTypeMeaningYou set it 1quietboolThe quiet flag echoed back from the originating request.never; inbound only Recovered with score 192, confidence 0.94, margin 192 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 2.