Smooth

One active bonus: an amount and the kind of bonus it applies to. Kind structArea Game.BonusNamed by stringtable A single entry of BonusesEvent. It is never sent on its own. An entry pairs an AMOUNT with a KIND. Several entries may carry the same kind and they stack, so group them by kind rather than assuming one entry per kind - a captured trace carried five entries sharing a single kind. The kind's VALUES are deliberately left unnamed; see the signature notes. Not sent on its own — it is only ever a row of BonusesEvent.bonuses. proven Used by BonusesEvent Fields #FieldTypeMeaningYou set it 2amountint32How much this bonus grants. Several entries may share one kind and stack.never 3typetype not documented yetWhich kind of bonus the amount applies to. Values are left unnamed on purpose.never Recovered with score 180, confidence 0.83, margin 180 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.

Where a sub-entity hangs off its parent look: pet, rider, carried entity, or decoration. Kind enumArea Game.CommonNamed by beta The category member of SubEntityInformation. It is what tells a mount's rider apart from a pet apart from a carried entity, which is the only part of the look tree most scripts care about. NOTE THE GAP: value 5 is not declared. The numbering runs 0-4, then 6 and 7. Treat an unknown number as unhandled rather than mapping it onto a neighbour. Not sent on its own — an enum is never sent on its own. inferred Used by SubEntityInformation Values ValueNumberMeaning HOOK_POINT_CATEGORY_UNUSED0Placeholder for an unset binding point. HOOK_POINT_CATEGORY_PET1A pet following its owner. HOOK_POINT_CATEGORY_MOUNT_DRIVER2The rider sitting on a mount. HOOK_POINT_CATEGORY_LIFTED_ENTITY3An entity being carried by another. HOOK_POINT_CATEGORY_BASE_BACKGROUND4Decoration drawn behind the entity. HOOK_POINT_CATEGORY_BASE_FOREGROUND6Decoration drawn in front of the entity. HOOK_POINT_CATEGORY_UNDERWATER_BUBBLES7The bubble effect used underwater. Recovered with score 206, confidence 0.81, margin 206 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 13.

Empty server poll asking the client to report its measured latency. Kind eventArea Game.BasicNamed by beta, gamemapping Carries no payload - the message IS the question. Answer it with BasicLatencyStatsRequest carrying a latency in milliseconds. ANSWER IT. A capture shows the real client replying within milliseconds. A client that receives these polls and never answers is trivially distinguishable from a real one. It arrives in the same frame as SequenceNumberEvent, and the two are answered independently a few milliseconds apart. Report a value consistent with your actual round trips - a real client derives it from its PingRequest / PongEvent samples, and the server can compare what you claim against how long you took to answer. When you may send it Requires authenticated observed Related messages You must then send BasicLatencyStatsRequest observed — the poll is unanswered until the client reports a latency Unsolicited - nothing you send causes this the server polls on its own schedule; nothing you send asks for it Sequence Step server_poll.2 observed — the server emits both polls in the same frame; of 2 observations Recovered with score 110, confidence 0.84, 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: 0 of 0.

A shop token for the in-client shop back end. In practice it never arrives. Kind eventArea Game.BakNamed by stringtable IN PRACTICE THIS NEVER ARRIVES, AND THAT IS THE MOST USEFUL THING TO KNOW ABOUT IT. The shop-token request that would provoke it has NO CLIENT WRITER in any dumped build: the message type exists, but nothing in the client ever constructs or sends it. Since this event is a reply and the client never asks, the server has no occasion to send it. A live capture bears that out - the sibling BakApiKeyEvent appears, this one never does. DO NOT SEND THE SHOP-TOKEN REQUEST TO PROVOKE IT. No dumped client does, so doing it is a behaviour no real client produces. The record is here so that its silence is documented rather than mistaken for a gap in the catalogue. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this nothing in any dumped client asks for it, and a live capture never shows it Fields #FieldTypeMeaningYou set it 1shop_tokenstringThe shop token. The only member the client reads. Never populated in a real session.never Recovered with score 245, confidence 0.90, margin 245 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.

A fresh API key for the in-client shop back end, answering the token request. Kind eventArea Game.BakNamed by stringtable The reply to BakApiTokenRequest. NEVER PUSHED UNSOLICITED: no request, no key. Its arrival drives the client's whole key lifecycle. On receiving it the service stores the key, CLEARS the in-flight latch that the send routine set - releasing the next request - and arms a one-hour timer for the next refresh. If you reproduce the request's timer, reproduce this side too: without clearing the latch on arrival, a faithful implementation sends once and never again. The key itself is only useful for the shop back end. Nothing in the game protocol is gated on it. When you may send it Requires authenticated observed Related messages Arrives after BakApiTokenRequest Fields #FieldTypeMeaningYou set it 2api_keystringThe shop back end's API key. The only member the client reads.never Recovered with score 245, confidence 0.90, margin 245 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.

The submitted ticket was rejected; the game session does not open. Kind eventArea Game.ConnectionNamed by beta, gamemapping Answers IdentificationRequest on failure. Carries no reason - refusal is the whole message, so there is nothing to branch on beyond the fact of it. The usual causes are a ticket that was already consumed, has expired, or was issued for a different server than the one you connected to. Recovering means going back to the login-server exchange for a fresh ticket, not retrying this message. When you may send it Requires transport_established observed Related messages Arrives after IdentificationRequest Recovered with score 100, confidence 0.99, 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 0.

The submitted ticket was accepted; the game session is open. Kind eventArea Game.ConnectionNamed by beta, gamemapping Answers IdentificationRequest on success. Carries no payload - arrival is the whole message. In a capture it opens a burst delivered in the same millisecond: TimeEvent, ServerSettingsEvent, OptionalFeaturesEvent, AccountCapabilitiesEvent, AccountRightsEvent, TrustStatusEvent and ServerSessionReadyEvent. Do not treat any of those as separately requested; they are pushed. When you may send it Requires transport_established observed Related messages You must then send CharacterListRequest proven — the handler of this event constructs the list request unpopulated and hands it to the network service; without it you never learn which characters exist Arrives after IdentificationRequest Recovered with score 110, confidence 0.95, 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: 0 of 0.

The whole anomaly board: one row per subarea with its anomaly state, reward bonus and closing time. Kind eventArea Game.AnomalyNamed by beta, gamemapping, stringtable The answer to AnomalySubareaInformationRequest. ROWS ARE SENT FOR SUBAREAS WITH NO ANOMALY TOO. The row's PRESENCE means nothing; AnomalySubareaInformation.has_anomaly is what says whether one is there. Filtering by presence gives you every subarea in the game. Each row is an AnomalySubareaInformation. Replace your board wholesale, then apply AnomalyStateEvent deltas on top of it. When you may send it Requires character_loaded observed Related messages Arrives after AnomalySubareaInformationRequest Fields #FieldTypeMeaningYou set it 1subareasrepeated AnomalySubareaInformationOne row per subarea. Element type AnomalySubareaInformation. Rows exist for subareas without an anomaly too.never Recovered with score 150, confidence 0.88, margin 150 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 subarea's anomaly state: whether one is there, what bonus it grants and when it closes. Kind structArea Game.AnomalyNamed by beta, stringtable One row of the board, declared nested inside its event. READ has_anomaly, NOT THE ROW'S EXISTENCE. Rows are sent for subareas with no anomaly, so a script that treats every row as an anomaly walks to empty subareas. reward_rate is the bonus granted while an anomaly is there - the client shows it as an experience and loot bonus. It is what ranks one anomaly against another. subarea_id and reward_rate ARE BOTH int32 AND NOTHING ON THE WIRE SEPARATES THEM - they are told apart only by which slot of the client's row object each lands in. Read them by name. Not sent on its own — it is only ever a row of AnomalySubareaInformationEvent.subareas. inferred Used by AnomalySubareaInformationEvent Fields #FieldTypeMeaningYou set it 1has_anomalyboolWhether an anomaly is currently in this subarea. THIS, not the row's presence, is what says an anomaly is there.never 2subarea_idint32Which subarea this row describes. (subarea id) Same width as reward_rate; nothing but the recovered name separates them.never 3anomaly_closing_timeint64When the anomaly closes. The client counts down to it.never 4reward_rateint32The bonus granted while an anomaly is in this subarea. Shown by the client as an experience and loot bonus.never Recovered with score 180, confidence 0.90, margin 180 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 subarea's anomaly is now open or closed, with the time it closes. Kind eventArea Game.AnomalyNamed by beta, gamemapping The delta for one subarea, and THE ONLY MESSAGE THAT REPORTS A CLOSURE - AnomalyOpenedEvent only ever announces openings. open false is how an anomaly ends. Apply it to the board you got from AnomalySubareaInformationRequest, keyed by subarea_id. closing_time tells you when the anomaly ends, so you can decide whether it is worth travelling to before it does. The message declares a second int64 beside closing_time; the named one is the one the client actually loads. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this the server publishes anomaly state changes as they happen Fields #FieldTypeMeaningYou set it 1openboolWhether an anomaly is now in this subarea. FALSE IS A CLOSURE, and this is the only message that reports one.never 2closing_timeint64When the anomaly closes. The record declares a second int64 beside this one that the client does not read.never 3subarea_idint32Which subarea changed. (subarea id)never Recovered with score 190, confidence 0.89, 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: 3 of 3.

An anomaly has just opened in a subarea. Kind eventArea Game.AnomalyNamed by beta, gamemapping, stringtable An anomaly opened. The client turns it into a chat announcement carrying a clickable travel link to the place. IT ONLY REPORTS OPENINGS. There is no matching "closed" event on this message - closures come through AnomalyStateEvent with its open flag false. A script that tracks anomalies from this message alone accumulates anomalies that ended hours ago. It carries the subarea and nothing else. For the reward bonus and closing time you need the board - see AnomalySubareaInformationRequest. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this the server announces openings as they happen Fields #FieldTypeMeaningYou set it 1subarea_idint32Which subarea the anomaly opened in. (subarea id)never Recovered with score 170, confidence 0.93, 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.

The character's alignment and honour standing, carried on the character sheet. Kind structArea Game.CommonNamed by beta The alignment half of the character sheet. TWO MEMBERS THE REFERENCE BUILD DECLARED ARE GONE. It had a character id and a character level here and NO DUMPED BUILD CARRIES EITHER. That is a real schema reduction; do not go looking for them, and do not read the surviving members positionally on the assumption that they are still there. alignment is which side the character is on - see Alignment. extended_information carries honour standing and attackability, and its members are not individually recovered. Not sent on its own — it is only ever carried by CharacterCharacteristics. inferred Used by CharacterCharacteristics Fields #FieldTypeMeaningYou set it 2alignmentAlignmentWhich alignment the character belongs to. An Alignment value.never 3extended_informationtype not documented yetHonour standing and attackability. Its members are not individually recovered and stand obfuscated.never Recovered with score 160, confidence 0.79, 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: 2 of 6.

Which alignment a character belongs to: none, neutral, Bonta or Brakmar. Kind enumArea Game.CommonNamed by beta The five alignment values, carried by AlignmentInformation. Every dumped build declares exactly five values numbered 0 to 4 in this order, so the numbering is the real wire contract. ALIGNMENT DECIDES WHO MAY ATTACK YOU. A script that walks through contested territory should read this on other characters, not just on its own. A live capture of an ordinary character carried NEUTRAL. Not sent on its own — an enum is never sent on its own. inferred Used by AlignmentInformation Values ValueNumberMeaning UNKNOWN0Unset or unrepresentable. WITHOUT1No alignment. NEUTRAL2Neutral. This is what a live capture of an ordinary character carried. ANGEL3Aligned with Bonta. EVIL4Aligned with Brakmar. Recovered with score 125, confidence 0.83, 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: 5 of 5.

One visible actor: who it is, where it stands, and what it looks like. Kind structArea Game.CommonNamed by beta, gamemapping The element of GameRolePlayShowActorsEvent, and reused by the map-complementary snapshot and by fight synchronisation - so the same record describes an actor in roleplay and in combat. actor_id IS THE HANDLE FOR EVERYTHING AFTERWARDS. Every later event that moves, turns, animates, addresses or removes this actor names it by this id. Index your world model by it. disposition is where the actor stands and faces - see EntityDisposition. actor_information carries the appearance (EntityLook) plus a oneof selecting what KIND of actor it is: a named character, a monster group, an NPC, a prism, a portal, a tax collector, or a fighter. Branch on that oneof; it is what tells a monster apart from a player. NOTHING ABOUT THE LAYOUT IS STABLE. Field numbers move in every direction across the dumped builds and the record is padded with live-looking decoys. Read by name. Not sent on its own — it travels inside the actor-list events. proven Used by GameRolePlayShowActorsEvent MapComplementaryInformationEvent Fields #FieldTypeMeaningYou set it 1actor_informationtype not documented yetThe actor's appearance and what kind of actor it is. Carries an EntityLook plus a oneof selecting a roleplay actor or a fighter - branch on it.never 2actor_idint64Server-assigned id of this actor, unique within the current context. (actor id) Every later event about this actor names it by this id.never 3dispositionEntityDispositionWhere the actor stands and which way it faces. See EntityDisposition.never Recovered with score 370, confidence 0.93, margin 370 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.

The account's permission flags for this session, as an opaque block of five booleans. Kind eventArea Game.AccountNamed by stringtable Pushed during account setup. You receive it, record it, and never reply - nothing in the protocol is gated on having processed it. THE FIVE FLAGS ARE NOT INDIVIDUALLY RECOVERED and are deliberately left unnamed. Every line of evidence that names things elsewhere in this catalogue fails here: the unobfuscated reference build has no account-rights type in the game protocol, the early 3.x name map has none either, and the client's handlers branch only on the BLOCK's presence, never on an individual flag. Read them positionally as opaque flags, or ignore them - see Rights. THE DECLARATION CARRIES TWO FIELDS OF THE SAME NESTED TYPE and only one is ever read. Five consumers across two services all read the same member and never touch the other, which is what makes the named one the real one. This record describes the current build. Earlier builds either lack the message or carry a different shape. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this no client writer constructs it in any dumped build and there is no matching request message Fields #FieldTypeMeaningYou set it 1rightsRightsThe account's permission-flag block. See Rights. The only member any client consumer reads. The declaration carries a second field of the identical type that nothing reads.never Recovered with score 220, confidence 0.87, 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: 1 of 2.

An account information update, carrying the subscription end date. Kind eventArea Game.AccountNamed by beta, gamemapping Carries the subscription end date, which the client copies straight into its player-state service. ZERO IS THE PROTOBUF DEFAULT HERE, so a zero does not distinguish "no subscription" from "the field was not sent". If your logic depends on subscription state, treat zero as unknown rather than as expired. The message carries further members that no dumped build reads; they stand with their obfuscated names. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this the server pushes account state; no request asks for it Fields #FieldTypeMeaningYou set it 1subscription_end_dateint64When the account's subscription ends. Zero is the protobuf default and is indistinguishable from an absent field.never Recovered with score 131, confidence 0.98, margin 131 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.

What the account is allowed to do: whether it may create a character, whether the tutorial is offered, and its staff role. Kind eventArea Game.AccountNamed by beta, gamemapping Read-only session state describing what this account may do. Nothing is gated on having processed it - you record it and move on. can_create_new_character USED TO BE A BOOL AND IS NOW A THREE-STATE ENUM. Measured across the dumped builds: 3.5.3.1 bool, bool, Hierarchy 3.5.17.26 bool, bool, Hierarchy, int64 3.6.10.10 CanCreateNewCharacter, bool, Hierarchy That is a real protocol change, verified against what the client reads, not a recovery gap - which is why this record is documented for the current build and does not describe the older ones. Code written against the boolean will misread the enum: value 1 is a REFUSAL, and as a boolean it reads as true. status is the account's staff role - see Hierarchy. On an ordinary account it is the player role and stays that way. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this the server pushes it during login and character selection; there is no request for it Fields #FieldTypeMeaningYou set it 1tutorial_availableboolWhether the tutorial is offered to this account.never 3statusHierarchyThe account's role in the staff hierarchy. A Hierarchy value. Ordinary accounts carry the player role.never 4can_create_new_characterCanCreateNewCharacterWhether the account may create another character, and if not, why. A CanCreateNewCharacter value. WAS A BOOL BEFORE THIS BUILD. Do not read it as one - value 1 means refused.never Recovered with score 112, confidence 0.97, margin 112 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 client telling the server it found a mod loader. Empty on purpose. Kind requestArea Game.Client.VerificationNamed by gamemapping THE CLIENT'S ANTI-TAMPER TELLING THE SERVER IT FOUND A MOD LOADER. It is sent ONLY on a positive detection and it carries no payload at all: the fact that it was sent IS the whole report. ========================================================================= WHAT THE CLIENT ACTUALLY LOOKS FOR ========================================================================= Everything below is decompiled from 3.6.10.10, not inferred. The scan runs against the GAME INSTALL ROOT, computed as Application.streamingAssetsPath + "/../../" CHECK 1 - LOADER DIRECTORIES. It tests whether any of these exists directly under that root, and stops at the first hit: MelonLoader BepInEx dotnet MelonLoader and BepInEx are the two mainstream Unity mod loaders; dotnet is the runtime folder they install beside themselves. CHECK 2 - MANAGED PROXY ASSEMBLIES. If no directory matched, it recursively enumerates *.dll under the same root (SearchOption.AllDirectories) and flags any file whose name without extension is one of: Core Animator2D Il2Cpp__Generated UnityEngine THIS IS THE CLEVER HALF, AND IT IS WORTH UNDERSTANDING. Dofus is an IL2CPP build: it ships ONE native GameAssembly.dll and no managed assemblies with those names. Those four files are what an IL2CPP interop layer GENERATES when someone attaches a loader to the game - the managed proxies a modder needs in order to write code against Core, UnityEngine and the generated glue. Their presence on disk is therefore evidence of tooling rather than of a modified game, and the check finds a prepared modding environment even when nothing is injected at run time. The scan is deliberately gentle: it awaits UniTask.NextFrame() between files, so it walks the tree one entry per frame rather than stalling the game. ========================================================================= WHEN IT IS SENT, AND WHEN IT IS NOT ========================================================================= Either check firing calls the same reporter, which sends this message and stops. Neither check firing sends nothing at all. A clean install is therefore SILENT - which is why this message will not appear in an ordinary capture, and why its absence carries no information. The whole routine is also gated on a configuration value read from the client's configuration service: if that value is 4 or greater the scan returns immediately without checking anything. ========================================================================= IT DELIBERATELY TELLS THE SERVER NOTHING ELSE ========================================================================= The client computes a reason internally - "detected dir" or "detected DLLs" - and then DISCARDS it. The reporter takes that string as a parameter and the async method that actually sends this message has no string field at all, so the reason never reaches the wire. So the server learns exactly one bit: this client tripped the check. It does not learn which loader, which file, or which of the two checks fired. That is consistent with the message having no members in the first place - it is not an empty message that happens to mean something, it is a deliberate one-bit signal. ========================================================================= WHERE IT SITS IN THE PROTOCOL ========================================================================= It belongs to Game.Client.Verification, and it is the ODD ONE OUT. Every other member of that area is a REPLY or a server-driven prompt: ServerVerificationEvent server obliges the client to identify itself ClientIdRequest client answers with a fresh commitment ClientChallengeInitRequest client publishes its long-lived public key ServerChallengeEvent server's challenge ClientChallengeProofRequest client's proof, closing the handshake FileCheckEvent server names a game file to measure FileCheckRequest client returns the measurement CheckType which measurement: byte length, or a checksum Those are a three-step proof-of-identity handshake plus an on-demand file-integrity probe, and every one of them is started by the server. THIS message is the only one the client raises on its own initiative, unprompted, and the only one that reports an observation rather than answering a question. ServerSessionReadyEvent shares the same generated .proto file but is documented under Game.Connection, because it belongs to the connection handshake rather than to verification. ========================================================================= IF YOU ARE WRITING A CLIENT ========================================================================= There is nothing to fill in and nothing to wait for - the send is fire-and-forget from an async void, and no client code awaits a reply. A well-behaved client never sends it. Sending it volunteers a report about yourself, so the correct behaviour for a reimplementation is simply to never emit it. Note also what it does NOT do: it does not scan process memory, does not enumerate loaded modules, and does not hash anything - it is a filesystem check and nothing more. File integrity is a separate channel, and the server drives that one through FileCheckEvent. When you may send it Requires transport_established inferred Related messages Nothing answers it - send it and move on nothing in the client waits on a reply; the send is fire-and-forget from an async void Recovered with score 140, confidence 0.85, margin 140 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.

Asserts the complete set of chat channels the character is on, as a subscribe list and an unsubscribe list. Kind requestArea Game.ChatNamed by gamemapping A COMPLETE STATE ASSERTION, NOT A DELTA. The client enumerates every channel it can map and puts each one into exactly one of the two lists. A channel you leave out of both is not "unchanged" as far as the real client's traffic shape is concerned - it simply never happens. So: build both lists from your full channel model, every time. Sending a one-element subscribe list is a shape the real client does not produce. subscribe is what you want on, unsubscribe what you want off, and together they partition the mappable channels. The roles are read from the writer's own branch polarity, not from field order. The reference build had a singular subscribe-one-channel request instead; the batch form replaced it before the earliest dumped 3.x build, so there is no unobfuscated declaration for this one. When you may send it Requires character_loaded observed Raised by: the channel set changing; the writer always walks every mappable channel, so there is no incremental form proven Related messages Reply not yet recovered: the server re-states the resulting subscriptions through ChannelUpdateEvent and ChatChannelsEnabledEvent; whether both arrive depends on what actually changed, so react to what comes rather than waiting. Fields #FieldTypeMeaningYou set it 2unsubscriberepeated ChannelThe channels the character wants off. Element type Channel. Together with subscribe this is a complete partition.required 3subscriberepeated ChannelThe channels the character wants to be on. Element type Channel.required Recovered with score 235, confidence 0.84, margin 235 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.

Asks for the married partner's identity, status and map position. Kind requestArea Game.SocialNamed by beta, gamemapping It is one of a FIXED FOUR-REQUEST BURST the client fires once per entry into the world, straight after asking for the game context. The client's own name for the routine survives obfuscation: SendRequestAfterCharacterLoaded. The order is constant: ContextCreationRequest (the context first) 1. FriendListRequest 2. AcquaintanceListRequest 3. SpouseInformationRequest 4. GuildInformationRequest That order is not guessed from traffic: it is the order the routine allocates the four objects in, and a live capture reproduces it exactly - the first three land inside the same millisecond, the guild request three milliseconds later. SEND IT ONCE, AT THAT POINT. NEVER POLL IT. The trigger is "the character finished loading", not a timer. The client sends it unconditionally, married or not - it does not check first. Carries nothing. When you may send it Requires character_loaded observed Related messages Reply not yet recovered: the spouse information arrives as an event that has no signature here yet. Sequence Step post_character_load.3 observed — of 4 requests, in the order the client's own routine allocates them Recovered with score 175, confidence 0.92, margin 175 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.

Tells the server which language community the character chats on. Kind requestArea Game.SocialNamed by beta, gamemapping DOFUS segregates the public chat by language, and this picks which segment you are in. It decides which community channel you read and write on - see Channel.COMMUNITY. The server answers with CommunityChannelEvent carrying the value it ACCEPTED, which is not necessarily the one you asked for. Read the answer rather than assuming. A VOLLEY OF ChannelUpdateEvent FOLLOWS IMMEDIATELY. Changing community re-states the character's channel subscriptions, so expect your channel mask to be rewritten right after. Do not race it. When you may send it Requires character_loaded observed Raised by: the player changing the chat-language control, and once on entering the world with the persisted account option. One user decision, one request; never on a timer proven Related messages You will then receive CommunityChannelEvent observed — the server states back the community it accepted, then re-states the character's channel subscriptions Fields #FieldTypeMeaningYou set it 1communityint32The community to chat on. Range: -1 to 4 -1 unset, 0 French, 1 English/international, 2 Spanish, 3 Portuguese, 4 German.required Recovered with score 165, confidence 0.88, margin 165 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.

Answers the server's sequence poll with how many of those polls this connection has received. Kind requestArea Game.BasicNamed by beta, gamemapping Answers SequenceNumberEvent. One integer: a counter this connection keeps. WHEN TO SEND IT ONCE PER POLL, IMMEDIATELY, AND FROM NOWHERE ELSE. The client builds this message in exactly one place - inside the handler for the poll - and replies unconditionally, before anything else looks at the event. There is no timer and no proactive path. WHAT THE COUNTER ACTUALLY COUNTS NOT INBOUND MESSAGES. NOT EVENTS OF EVERY KIND. It counts the SequenceNumberEvent polls that have arrived on THIS connection, and nothing else touches it. The whole rule is two lines: when the socket becomes active: n = 0 when a poll arrives: n = n + 1, then reply with n Three consequences, all of them visible to the server: IT RESTARTS AT EVERY RECONNECTION. The reset is bound to the socket becoming active, not to logging in, so a reconnect starts again from zero. Carrying a count across connections is wrong. THE FIRST REPLY CARRIES 1, NEVER 0. The counter is incremented before the reply is built. EACH CONNECTION HAS ITS OWN. If you hold two game sockets at once (see IdentificationRequest), each counts its own polls independently. There is no shared total. A bot that hard-codes a constant, counts the wrong thing, restarts mid-connection or carries the number across a reconnect is producing traffic no real client produces - and this is the one number in the exchange the server can recompute exactly, because it sent every poll itself. THIS COUNTER IS NOT THE ENVELOPE UID They are different numbers living in different places, and confusing them is the easy mistake here. The counter is the payload. The uid is transport-level - and for this particular message the client does not allocate one at all: it writes the reply straight down the connection rather than through the normal request path, so the envelope goes out with the uid set to -1. BasicLatencyStatsRequest, answering the poll that arrives in the same frame, does carry a real uid. Two replies to one frame, two different envelope shapes. When you may send it Requires authenticated observed Related messages Answers SequenceNumberEvent Fields #FieldTypeMeaningYou set it 1numberint32How many sequence polls this connection has received, counting the one being answered. (poll count) Range: starts at 1 on each new connection and increases by one per poll It counts THESE polls only, not inbound messages in general, and it is reset when the socket becomes active rather than when you log in.required Recovered with score 85, confidence 0.95, margin 85 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.

Asks for a one-shot token that lets the next connection skip full authentication. Empty - the message is the ask. Kind requestArea Game.ConnectionNamed by beta, gamemapping CARRIES NO PAYLOAD. There is nothing to fill in - constructing it and sending it IS the request. Send it BEFORE you hand this connection over, then read ReloginTokenEvent. WHEN TO SEND IT WHEN YOU ARE ABOUT TO LEAVE THIS GAME SERVER, and not otherwise. In the real client every path into it is a menu confirmation: go back to server choice -> ReloginRequest confirm a change of server -> ReloginRequest confirm a change of character -> ReloginRequest confirm server + character -> ReloginRequest Nothing in gameplay sends it. It is not a keepalive, it is not periodic, and it has nothing to do with PingRequest despite sitting beside it in the protocol. ONE AT A TIME. The client refuses to send a second request while an answer is still outstanding - it raises an error popup instead of asking again. Do not pipeline this and do not retry it while you are still waiting; if you never got an answer to the first one, the connection is the problem, not the request. THE CLIENT PARKS WHAT YOU ASKED FOR. It remembers the action that provoked the request, sends this, and only replays that action once the token has been stored. That ordering is the whole point of the exchange: if you act on the server change before the answer lands, you leave without the token you asked for and gain nothing. WHAT COMES BACK ReloginTokenEvent, with a grant flag and a token. Both branches are real - read that record before implementing either. MATCH IT BY TYPE, NOT BY UID. This goes out on the uncorrelated send path, so its envelope uid is -1 and there is no response to pair against it. Watch for the event. SENDING IT IS OPTIONAL. Skip it and nothing breaks here; the next connection simply has to authenticate in full instead of presenting a token. What is not optional, if you do send it, is waiting for the answer before you move. When you may send it Requires authenticated observed Raised by: a client-side state change: one of three 'leave this game server' intents raised by the menu screens - go back to server choice, go to a chosen server, or go to a chosen server to play a named character. The writer parks the intent, sends this request, and replays it only once the answer has been stored inferred Related messages You will then receive ReloginTokenEvent observed — the server answers with a token grant or refusal Recovered with score 165, confidence 0.88, margin 165 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.

Asks which step of one quest the character is on, and what that step's objectives are. Kind requestArea Game.QuestNamed by beta, gamemapping, stringtable Asks about ONE quest. There is no "give me every quest's current step" form - the journal listing and this per-quest detail are separate exchanges. quest_id is the quest to ask about. Take it from the journal rather than hardcoding it. The answer is an EVENT, not a Response, so there is nothing to correlate against - match QuestStepInformationEvent by arrival and by the quest id it carries. When you may send it Requires character_loaded observed Raised by: asking about one quest - and again whenever its step changes, if you want the new objectives inferred Related messages You will then receive QuestStepInformationEvent inferred — the quest service's handler treats that event as the answer Fields #FieldTypeMeaningYou set it 2quest_idint32Which quest to ask about. (quest id)required Recovered with score 130, confidence 0.91, 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 2.

Adds a quest, or one objective of it, to the followed list shown in the quest tracker. Kind requestArea Game.QuestNamed by beta, gamemapping ADDS A QUEST TO THE TRACKER. Its opposite number removes one, and the two are the only difference between two otherwise identical messages - read the section below before you pick one. WHEN TO SEND IT WHEN YOU START FOLLOWING SOMETHING YOU ARE NOT ALREADY FOLLOWING. That second half matters. The real client keeps its own list of followed quest ids and checks it before sending: if the quest is already there it sends the UNFOLLOW message instead, and if it is not, it sends this one and adds the id. So the client never sends a follow for a quest it already follows. Do the same. Track what you follow, and send this only for a quest you are not tracking - otherwise you and the server disagree about the list, and the client UI that reads it back will disagree with both. ONE INTENT, TWO MESSAGES. Both come out of the same UI action and the same client method; which one goes out is decided by that list check. There is no "toggle" message. WHAT TO PUT IN IT THE QUEST, AND OPTIONALLY ONE OBJECTIVE. Send -1 as the objective to follow the quest as a whole rather than a specific step - that is the sentinel the client itself tests against, and it is what a capture of "follow this quest" shows. Both values are 32-bit on the wire but the client carries them as 16-bit internally, so they are small ids, not handles. WHAT COMES BACK NOTHING DEDICATED. The followed list is state the server mirrors; no dumped client waits for a reply to this message. If you need confirmation, it arrives as the quest data the server pushes, not as an answer to this request. When you may send it Requires context_ready observed Raised by: a client-side state change: the player turning tracking ON for a quest or one of its objectives in the quest UI. The screen raises one intent carrying the quest, the objective and an on/off flag, and the writer checks its own followed-list first - it sends this only when the quest is not already in that list inferred Related messages Nothing answers it - send it and move on no dumped client waits for a reply; the followed list is client state the server mirrors Fields #FieldTypeMeaningYou set it 2quest_idint32The quest to follow.required 3objective_idint32Which objective of it to follow, or -1 to follow the quest itself.required Recovered with score 200, confidence 0.88, 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 3.