Smooth

Turns on or off the notification shown when a contact dies permanently on an epic server. Kind requestArea Game.SocialNamed by beta, gamemapping One of the social "warn me when..." toggles the client mirrors to the server. THE SERVER HAS TO BE TOLD because it is the side that decides whether to push the notification; the client cannot honour the setting locally. IT IS SENT IMMEDIATELY ON EVERY FLIP, WITH NO DEBOUNCE. The option lives in Options -> General, in the Social block. Flipping it publishes a one-boolean event that a writer turns straight into this message. A script that toggles this in a loop produces a burst of requests that no human interaction could. SEND IT ONLY WHEN THE SETTING ACTUALLY CHANGES. It is a persisted client option replayed verbatim, not a query and not a subscription. It only means anything on a server with permanent death - see ServerType.EPIC. When you may send it Requires character_loaded observed Raised by: the player flips the toggle in Options -> General, Social block proven Related messages Nothing answers it - send it and move on it mirrors a stored client option to the server; no dumped build has a matching acknowledgement message Fields #FieldTypeMeaningYou set it 1enableboolTrue to be notified when a friend, guild member or character on the current map dies permanently; false to suppress it. The persisted client option, replayed verbatim.required 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: 1 of 2.

Turns on or off the notification shown when a friend, guild member or nearby character unlocks an achievement. Kind requestArea Game.SocialNamed by beta, gamemapping One of the social "warn me when..." toggles the client mirrors to the server. THE SERVER HAS TO BE TOLD because it is the side that decides whether to push the notification; the client cannot honour the setting locally. IT IS SENT IMMEDIATELY ON EVERY FLIP, WITH NO DEBOUNCE. The option lives in Options -> General, in the Social block. Flipping it publishes a one-boolean event that a writer turns straight into this message. A script that toggles this in a loop produces a burst of requests that no human interaction could. SEND IT ONLY WHEN THE SETTING ACTUALLY CHANGES. It is a persisted client option replayed verbatim, not a query and not a subscription. When you may send it Requires character_loaded observed Raised by: the player flips the toggle in Options -> General, Social block proven Related messages Nothing answers it - send it and move on it mirrors a stored client option to the server; no dumped build has a matching acknowledgement message Fields #FieldTypeMeaningYou set it 1enableboolTrue to receive the achievement notification for friends, guild members and characters on the current map; false to suppress it. The persisted client option, replayed verbatim.required 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: 1 of 1.

Answers the server's verification poll with a fresh cryptographic commitment - step 1 of a three-step proof of identity. Kind requestArea Game.Client.VerificationNamed by beta, gamemapping Answers ServerVerificationEvent. It opens a three-step proof that you hold a private key, and the value it carries is a COMMITMENT - not an identifier, not something you own, and not something you can look up. WHEN TO SEND IT IMMEDIATELY, ONCE PER POLL, AND FROM NOWHERE ELSE. The client builds it in exactly one place - the handler for the poll - and answers unconditionally. It reads NOTHING out of the poll; the event's arrival is the entire instruction. IT COMES EARLY. The poll can arrive on the bare connection, before the ticket exchange has finished, so this is one of the first things you ever send. Do not gate it on being logged in. WHAT TO PUT IN IT k = a fresh 400-bit random integer (50 random bytes, read little-endian) id = decimal string of G^k mod P P and G are not secret, not negotiated and not per-session: the client hard-codes the RFC 2409 768-bit MODP group - "Oakley group 1" - which is a published constant, with G = 2 and Q = (P - 1) / 2. The whole handshake lives in that one group. KEEP k. IT IS THE POINT OF THIS MESSAGE. Only G^k travels; k itself never does, and ClientChallengeProofRequest cannot be computed without it. Generate it here, store it, and use that exact value later. NEVER REUSE k. A Schnorr nonce answered against two different challenges leaks the private key by simple arithmetic - this is the classic way these schemes are broken. The real client draws a new one on every poll and overwrites the old, so a second poll silently invalidates any proof you had not yet sent. Recompute, do not cache. USE A REAL RANDOM SOURCE. The client uses a cryptographic generator. A predictable k is as bad as a reused one. IT IS A CORRELATED REQUEST. The client allocates an envelope uid for it, which most of the protocol does not - all three messages of this handshake do. The value is derived, never stored: it differs on every poll and on every run. IT STAYS ON THE MAIN CONNECTION. While a fight-server transfer has a second socket open (see IdentificationRequest) the client routes outbound traffic by message type, and all three verification requests are pinned to the FIRST connection. Gameplay traffic is what moves to the fight server, not this. 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 transport_established observed Related messages Answers ServerVerificationEvent Fields #FieldTypeMeaningYou set it 3idstringDecimal string of G^k mod P - a commitment to a fresh secret, not an identity. k is 50 random bytes read as a little-endian unsigned integer. Keep it: ClientChallengeProofRequest needs it and it never travels.required; recomputed on every poll, never reused Recovered with score 185, confidence 0.94, margin 185 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.

Closes the proof-of-identity handshake by answering the server's challenge with a Schnorr response. Kind requestArea Game.Client.VerificationNamed by beta, gamemapping Answers ServerChallengeEvent and ends the three-step exchange opened by ClientIdRequest and ClientChallengeInitRequest. WHEN TO SEND IT IMMEDIATELY ON ServerChallengeEvent, once, unconditionally. One construction site and no other path. THE WHOLE SCHEME, END TO END This is the one page that carries the complete algorithm. It is a Schnorr proof of identity, and everything below is read out of the client rather than guessed: CONSTANTS the client hard-codes one group and never negotiates it P the RFC 2409 section 6.1 prime, 768-bit MODP, "Oakley group 1" G 2 Q (P - 1) / 2 SECRETS neither ever travels x int(1024 random bytes, unsigned, LITTLE-endian) mod P drawn ONCE per process, kept for its whole life k int( 50 random bytes, unsigned, LITTLE-endian) drawn afresh for every verification poll THE FOUR STEPS 1 ServerVerificationEvent -> ClientIdRequest id = decimal string of G^k mod P (commitment R) 2 ServerSessionReadyEvent -> ClientChallengeInitRequest challenge_key = decimal string of G^x mod P (public key A) 3 ServerChallengeEvent carries c, a decimal string 4 this message proof = decimal string of (k + c*x) mod Q and if that came out negative, add Q back WHAT THE SERVER CHECKS It recomputes G^proof mod P and compares it with (id * challenge_key^c) mod P. Those agree exactly when you knew both secrets, which is the entire point of the exchange. The arithmetic works because 2 generates the order-Q subgroup of that prime. If you skipped either earlier message there is nothing to compare against, and no amount of guessing here will pass. FOUR WAYS TO GET THIS WRONG, ALL OF THEM SILENT Each of these produces a well-formed message that simply fails, with no error you can see and nothing in the traffic to tell you which one you hit. ENDIANNESS. Both random values are read LITTLE-endian and unsigned. Most big-integer libraries default to big-endian, and the number you get is completely different. DECIMAL, NOT HEX. Every value on the wire is a base-10 string. There is no hex, no base64 and no binary anywhere in this exchange. P VERSUS Q. The two exponentiations reduce modulo P; the proof reduces modulo Q. Swapping them is easy and fatal. THE SIGN. The client reduces modulo Q and then adds Q back if the result came out negative. Languages disagree about the sign of a remainder, so normalise explicitly rather than trusting your own operator. IF THE CHALLENGE IS ABSENT, YOU ANSWER YOURSELF The challenge field has explicit presence, and the client checks whether it is there. If the event arrives with NO value, the client does not skip the reply and does not error - it derives its own challenge and answers anyway: c = SHA-256 of the decimal strings of G, G^x mod P and G^k mod P, concatenated with the client's device fingerprint, and read back as a big-endian integer proof = (k + c*x) mod Q, forced non-negative, exactly as above THAT BRANCH SIGNS A MACHINE IDENTIFIER. The device fingerprint is the uppercase hex SHA-256 of the machine's unique device id concatenated with the MAC addresses of every network interface. So two machines answering the same value-less event produce different proofs, and the same fingerprint is also sent during login on the separate connection-server exchange. If you are reproducing the client's behaviour you have to reproduce this too, and if you are not, be aware of what it identifies. THE NUMBERING GAP IS PADDING. This message also declares a six-value enum that no dumped build ever writes; proto3 leaves a zero-valued enum off the wire entirely. There is nothing for you to set there. IT IS A CORRELATED REQUEST, like the other two steps. WHAT IS READ AND WHAT IS INFERRED The constants, the byte counts, both formulas and the value-less branch are read out of the client's own code, and the same structure is present in every dumped build. Two things are NOT: the verification equation above is what the server must be doing for this arithmetic to mean anything, but nothing in a client dump can see the server; and no capture has been observed of a challenge arriving without a value, so that branch is code that certainly exists rather than behaviour that has certainly been seen. THIS IS AN ANTI-TAMPER HANDSHAKE, NOT A SECURITY BOUNDARY. A 768-bit MODP group has been below recommended strength for many years, and nothing here is encrypted - the exchange proves that whoever is talking held a key across three messages, and that is all it proves. Do not read more assurance into it than that, in either direction. IT STAYS ON THE MAIN CONNECTION. While a fight-server transfer has a second socket open (see IdentificationRequest) the client routes outbound traffic by message type, and all three verification requests are pinned to the FIRST connection. Gameplay traffic is what moves to the fight server, not this. When you may send it Requires authenticated observed Related messages Answers ServerChallengeEvent Fields #FieldTypeMeaningYou set it 1proofstringDecimal string of (k + c*x) mod Q, normalised non-negative. k is the nonce from ClientIdRequest, x the private exponent behind ClientChallengeInitRequest, c the server's challenge, Q = (P-1)/2 for the RFC 2409 768-bit group. When the challenge arrives with no value the client hashes its own, including a device fingerprint - see the description.required Recovered with score 130, confidence 0.94, 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.

Publishes the client's long-lived public key, opening the session half of the proof-of-identity handshake. Kind requestArea Game.Client.VerificationNamed by beta, gamemapping Answers ServerSessionReadyEvent. It carries your PUBLIC KEY - the value the server will check your proof against. WHEN TO SEND IT IMMEDIATELY ON ServerSessionReadyEvent, once, unconditionally. One construction site, no timer, no other path. That event closes the burst that follows a successful IdentificationRequest, so in practice this is the first thing you send once the session exists. WHAT TO PUT IN IT x = your private exponent, drawn ONCE at start-up challenge_key = decimal string of G^x mod P P and G are not secret, not negotiated and not per-session: the client hard-codes the RFC 2409 768-bit MODP group - "Oakley group 1" - which is a published constant, with G = 2 and Q = (P - 1) / 2. The whole handshake lives in that one group. x IS PER-PROCESS, NOT PER-CONNECTION. The real client draws it once, when its verification service starts, and keeps it for the life of the process: 1024 random bytes read as a LITTLE-endian unsigned integer, then reduced modulo P. Every connection that process makes publishes the SAME challenge_key. Redrawing it per connection is not what the client does, and it is a difference a server can see across reconnects. x IS THE SECRET THE WHOLE EXCHANGE PROTECTS. It never travels. Anyone who learns it can answer any challenge in your name, so treat it like a password rather than like a session value. DO NOT CONFUSE IT WITH THE OTHER EXPONENT. ClientIdRequest publishes G^k for a throwaway k that changes on every poll; this one publishes G^x for the long-lived x. Both are decimal strings in the same group and they look identical on the wire. Sending the wrong one makes the proof fail with no useful error. IT IS A CORRELATED REQUEST: the client allocates an envelope uid for it. Do not read too much into that - when ServerChallengeEvent comes back the client matches it by message type and never looks at the uid. The server answers with ServerChallengeEvent, which you close with ClientChallengeProofRequest. IT STAYS ON THE MAIN CONNECTION. While a fight-server transfer has a second socket open (see IdentificationRequest) the client routes outbound traffic by message type, and all three verification requests are pinned to the FIRST connection. Gameplay traffic is what moves to the fight server, not this. 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 Answers ServerSessionReadyEvent You will then receive ServerChallengeEvent observed — the server answers the init with its own challenge Fields #FieldTypeMeaningYou set it 1challenge_keystringDecimal string of G^x mod P - the client's public key for the proof exchange. x is drawn once per process, not per connection, so this value is stable across every connection the same client makes.required Recovered with score 160, confidence 0.94, 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: 1 of 1.

Sends a private message to one player, addressed either by character name or by account tag. Kind requestArea Game.ChatNamed by beta, gamemapping Talks to one player rather than a channel. THE RECIPIENT IS A ONEOF - SET EXACTLY ONE BRANCH. name addresses a CHARACTER by its displayed name; tag addresses an ACCOUNT by its tag, which is a name plus a numeric discriminator and reaches the person whichever character they are playing. Setting neither sends a whisper to nobody; the message is not rejected for it. content is the text. It is the singular string that is NOT inside the oneof - worth saying, because the name branch is also a string. metadata carries the same rich attachments as a channel line; see Metadata. UNSOLICITED WHISPERS ARE THE FASTEST WAY TO GET A SCRIPT REPORTED. Whatever you do here is read by a human on the other end. When you may send it Requires character_loaded observed Raised by: the player sends a private message from the chat window observed Related messages Reply not yet recovered: the server delivers the whisper and confirms it to the sender through the private-message event, which has no signature here yet. Fields #FieldTypeMeaningYou set it 1metadataMetadataRich content attached to the whisper. See Metadata. Beta called this field object.optional 2contentstringThe text to whisper. The singular string outside the target oneof.required 3namestringThe recipient, addressed by character name.one of the two target branches 4tagtype not documented yetThe recipient, addressed by account tag - a name plus its numeric discriminator. Reaches the account rather than one character.one of the two target branches Recovered with score 225, confidence 0.85, margin 225 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.

Says something on a chat channel. This is the message a script sends to talk. Kind requestArea Game.ChatNamed by beta, gamemapping Talk on a channel. The server echoes your own line back as ChatChannelMessageEvent, so do not render it locally - wait for the echo, as the client does. channel DECIDES WHO HEARS YOU AND IT IS EASY TO GET WRONG. It has no explicit presence, so leaving it unset does not mean "default channel" in any safe sense: it means the enum's zero value, which is Channel.GLOBAL - the loudest channel in the game. Set it deliberately every time. TO WHISPER ONE PERSON, THIS IS THE WRONG MESSAGE. Use ChatPrivateMessageRequest. metadata carries rich attachments - item and monster-group links - and stays present but empty for an ordinary line. The visible words always go in content; the link data rides alongside so the recipient's client can render and hover it. Chat is the most visible thing a script does. Rate, timing and repetition here are what a human moderator looks at first. When you may send it Requires character_loaded observed Raised by: the player types a line in the chat window and presses enter observed Related messages You will then receive ChatChannelMessageEvent observed — the server echoes the line back to the sender as well as to everyone else on the channel Fields #FieldTypeMeaningYou set it 2channelChannelWhich channel to say it on. A Channel value. NO EXPLICIT PRESENCE: unset means the zero value, Channel.GLOBAL, not 'unspecified'.required 3contentstringThe text being said. The only string the message carries.required 4metadataMetadataRich content attached to the line - item and monster-group links. Present but empty for an ordinary text message. See Metadata.optional Recovered with score 185, confidence 0.80, margin 185 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 5.

Asks to enter the world with one of the account's characters. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping Sent after reading CharacterListEvent. The id MUST come from that list. The real client also sends it automatically for the first listed character when the player has enabled auto-selection, so a capture may show it without any visible interaction. SELECTING WITHIN A FEW MILLISECONDS OF RECEIVING THE LIST IS FASTER THAN ANY HUMAN. In a capture of a real sign-in the gap is about two seconds - the time a person takes to look at the screen and click. Add a plausible delay. On success the server starts the session and pushes a long burst of character state, ending with CharacterLoadingCompleteEvent. When you may send it Requires authenticated observed Forbidden while character_selected observed Raised by: the player picking a character from the list proven Related messages You will then receive CharacterSelectionEvent observed — the server answers with success or an error You will then receive CharacterLoadingCompleteEvent observed — closes the long inbound burst the selection opens; 1 of 1 login capture Fields #FieldTypeMeaningYou set it 1character_idint64Id of the character to play, taken from CharacterListEvent. (character id)required Recovered with score 110, confidence 0.93, 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: 1 of 1.

Enters the game with a character as a replay rather than an ordinary selection. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping THE THIRD WAY INTO THE GAME. CharacterSelectionRequest enters with a character you have played, CharacterFirstSelectionRequest with one you just created, and this one with a character the client resolves to a replay instead. WHEN TO SEND IT FROM THE SAME SCREEN ACTION AS THE OTHER TWO. All three come out of one method in the real client, chosen by two flags the character-selection screen passes with the character id: no flags means the ordinary selection, one means first selection, the other means this. The replay path is raised from a closure inside the screen's own choose-a-character handler, so it is a decision the screen makes about the character you picked, not a separate menu. IF YOU ARE SCRIPTING SELECTION, the safe default is CharacterSelectionRequest. Reach for this one only when you are reproducing a client that resolved the character to the replay path; there is no server-side signal in this exchange telling you that you should have. WHAT TO PUT IN IT THE CHARACTER ID - AND ON SOME BUILDS THE REAL CLIENT SENDS NOTHING AT ALL. That is not a guess: on three of the seven dumped builds the client allocates this message, populates no member, and sends it. On the other four it writes the character id. The member is therefore recovered where the client proves it and left unnamed where it does not. The practical reading: send the character id. It is what the message is for according to the reference build, and what the more recent clients do. WHAT COMES BACK The ordinary game-entry sequence - there is no dedicated reply. Uncorrelated, so the envelope uid is -1 and there is nothing to match against. When you may send it Requires authenticated observed Raised by: a client-side state change: the character-selection screen resolving a chosen character to the replay path rather than an ordinary selection. A closure inside the same screen method that handles an ordinary choice raises an intent carrying only the character id inferred Related messages Reply not yet recovered: the game-entry burst follows, the same as for an ordinary selection. Those messages are recovered but not documented yet. Fields #FieldTypeMeaningYou set it 2character_idint64The character to replay.required Recovered with score 195, confidence 0.92, 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: 1 of 3.

Asks the server to propose a character name. Empty payload. Kind requestArea Game.CharacterNamed by beta, gamemapping Carries nothing - it is a pure "give me a name". Any field the current build declares here is unused by the client and is left unresolved; send it empty. One request yields one suggestion. Asking repeatedly to fish for a name you like is a traffic pattern a human clicking a button does not produce at machine speed. When you may send it Requires authenticated observed Raised by: the player asks the creation screen for a name suggestion inferred Related messages You will then receive CharacterNameSuggestionEvent inferred — the server answers with one proposed name Recovered with score 215, confidence 0.83, 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 0.

Asks for the account's characters on this server. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping Carries no payload. Send it once, straight after authentication is accepted - in a capture it goes out ~35ms after AuthenticationTicketAcceptedEvent. NOTHING PUSHES THE CHARACTER LIST. If you never send this you never learn what characters exist, and you cannot select one, because the id required by CharacterSelectionRequest is only obtainable from the answer. When you may send it Requires authenticated observed Forbidden while character_selected observed Related messages Answers AuthenticationTicketAcceptedEvent You will then receive CharacterListEvent observed — the server answers with the list ~30ms later Recovered with score 120, confidence 0.99, margin 120 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.

Enters the game with a character for the first time, and asks for the tutorial. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping USE THIS FOR A CHARACTER YOU JUST CREATED, and CharacterSelectionRequest for one you have already played. Both enter the game with a character; this one additionally tells the server to run the tutorial. WHEN TO SEND IT WHEN YOU VALIDATE A CHARACTER THAT HAS NEVER BEEN PLAYED. In the real client both messages come from the same screen action - validating your choice on the character-selection screen - and the screen decides which of them applies from a first-selection flag it raises with the character id. You are choosing between them on the same signal it uses. SENDING THE WRONG ONE IS NOT A NO-OP. Send this for an existing character and you are asking the server to run the tutorial flow for someone who has already played. Send the ordinary one for a fresh character and you skip the tutorial the server would have set up. DO_TUTORIAL IS ALWAYS TRUE IN THE REAL CLIENT. It writes a hardcoded true into that member on every dumped build - it is never a player choice. False is a legal wire value that no client has ever sent, so treat it as untested. THE THIRD BRANCH. The same screen action has one more outcome, CharacterReplayRequest, for a character in a state that needs replaying rather than selecting. If you are implementing the screen, all three come from one place. WHAT COMES BACK The ordinary game-entry sequence, exactly as for CharacterSelectionRequest - there is no dedicated reply to this message. It is uncorrelated, so its envelope uid is -1 and there is nothing to match against. READ THE MEMBERS BY ROLE. Both have moved field number across builds, and some builds pad the message with a second bool beside the real one. When you may send it Requires authenticated observed Raised by: a client-side state change: the player validating their character choice on the selection screen for a character that has not been played yet. The screen raises one intent carrying the character id and a first-selection flag, and the selection dispatcher turns the flag into this message instead of the ordinary one inferred Related messages Reply not yet recovered: the game-entry burst follows, the same as for an ordinary selection. Those messages are recovered but not documented yet. Fields #FieldTypeMeaningYou set it 1character_idint64The character to enter with.required 2do_tutorialboolWhether to run the tutorial. The client always sends true here.required Recovered with score 235, confidence 0.92, 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 2.

Destroys a character. This is irreversible and there is no further confirmation exchange. Kind requestArea Game.CharacterNamed by beta, gamemapping STEP 3 OF 3, AND THE DESTRUCTIVE ONE. THE CHARACTER IS GONE. There is no undo, no grace period, and no second confirmation on the wire - the moment this is sent the decision is made. If you are writing automation, the honest answer is that THIS MESSAGE HAS NO LEGITIMATE AUTOMATED USE. Deleting a character is a decision a person makes once; put it behind a human, not behind a script. secret_answer_hash IS NEVER THE PLAINTEXT ANSWER. The client sends the lowercase hex MD5 of the UTF-8 bytes of: <character_id>~<secret_answer> with a literal tilde between them. The separator, the digest and the hex casing were all read out of the client rather than assumed. Send the plaintext and it will not match; hash without the id prefix and it will not match either. Whether the hash is required at all comes from CharacterDeletionPrepareEvent.need_secret_answer. Read that first. Two builds declare a second int64 beside character_id; the named one is the one the hashing writer actually stores. When you may send it Requires authenticated observed Related messages Answers CharacterDeletionPrepareEvent Reply not yet recovered: the character list is re-sent afterwards; the deletion's own acknowledgement has no signature here yet. Sequence Step character_deletion.3 inferred — of 3 steps; the flow is a fixed ask / terms / confirm exchange If you get it wrong the hash must be MD5 of <character_id>~<secret_answer>; sending the plaintext answer, or hashing without the id prefix, produces a value that cannot match inferred Fields #FieldTypeMeaningYou set it 1character_idint64The character to destroy. (character id) Also the prefix of the hashed string - the two must agree.required 3secret_answer_hashstringLowercase hex MD5 of the UTF-8 string <character_id>~<secret_answer>. NEVER the plaintext answer. The tilde separator, the digest algorithm and the hex casing were all read out of the client.required when the prepare event asked for it Recovered with score 225, confidence 0.80, margin 225 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.

Creates a character on the current server. One wrapper field carrying the whole appearance. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping ONE FIELD, AND EVERYTHING IS INSIDE IT. The request is a thin wrapper: the whole character - name, class, gender, colours, head - travels in CharacterRemodelingInformation. Read that record before building this one; it is where every rule about the payload lives. WHEN TO SEND IT ONCE, WHEN YOU HAVE CHOSEN EVERYTHING. The real client sends it from the creation screen's confirm button and from nowhere else. It is not idempotent in any useful sense: a second identical request is a second character, or a refusal. YOU MUST ALREADY BE ON A SERVER. This is game-server traffic, not connection traffic - you send it after you have picked a server and the game context is up. THE CLIENT VALIDATES BEFORE IT SENDS. It refuses to build the request at all when the name box is empty or the name fails its local check, and it fills the colour list to six entries first. None of that is enforced by the wire format, so a script that skips it simply gets refused by the server instead - see CharacterCreationResultEvent, which distinguishes the two. WHAT COMES BACK CharacterCreationResultEvent, always - success and every kind of refusal use the same message. It is uncorrelated, so its envelope uid is -1 and there is nothing to match against; watch for the event by type. ON SUCCESS the character list is what changes; the client re-reads it rather than being told the new character inline. When you may send it Requires authenticated observed Raised by: a client-side state change: the player confirming character creation on the creation screen. The screen builds one internal notification carrying the name, the class, the chosen head, the gender and the colour list, and the character service turns that notification into this request inferred Related messages You will then receive CharacterCreationResultEvent observed — the server answers with a result code, and a name reason when the name is what it rejected Fields #FieldTypeMeaningYou set it 1modeling_informationCharacterRemodelingInformationThe whole character you are asking for: name, class, gender, colours and head.required Recovered with score 265, confidence 0.88, margin 265 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 latency poll with the mean of the client's last 50 round-trip measurements, in milliseconds. Kind requestArea Game.BasicNamed by beta, gamemapping Answers BasicLatencyStatsEvent. One integer: how long your round trips are taking, in milliseconds. 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. There is no timer, no threshold and no proactive path. If you did not just receive the poll, do not send it. REPLY ON THE SOCKET THE POLL ARRIVED ON. The client answers on the originating connection, which only matters once you hold two at the same time (see IdentificationRequest): the measurement buffer is shared between them, the reply is not. WHAT TO PUT IN IT THE VALUE IS A MEAN, NOT A LAST READING. The client averages the round trips it has stored - at most the last 50 - and rounds to the nearest millisecond, ties going to the even value. It is not the most recent sample, and it is not smoothed or weighted. Those samples come from the PingRequest / PongEvent exchange and from nothing else. WITH NO SAMPLES IT REPORTS 0. There is no guard for an empty buffer: a client that has never completed a ping exchange reports zero. That is faithful, but over a long session it is also a tell - real latency is never exactly and permanently zero. If you are going to answer these polls, ping often enough to have something true to say. KEEP IT IN A PLAUSIBLE RANGE. The client casts its average through a signed 16-bit integer before writing this 32-bit field, so a value above 32767 would go out negative and one above 65535 would wrap. No real latency comes near that ceiling, which is the point: a number outside roughly 0-2000 is not something a real client can produce. IT IS SELF-REPORTED, AND CHECKABLE. The server can compare what you claim against how long you actually took to answer this very poll. THE TWO REPLIES TO ONE FRAME DO NOT LOOK ALIKE This poll arrives in the same frame as SequenceNumberEvent, and the two replies leave with different envelopes. This one travels as a correlated request: the client allocates a uid from a counter that cycles 0-65534 and puts it on the envelope. SequenceNumberRequest does not - it goes out with the uid set to -1. Giving both a normal uid, or neither, is a shape no real client produces. When you may send it Requires authenticated observed Related messages Answers BasicLatencyStatsEvent Fields #FieldTypeMeaningYou set it 1latencyint32The mean of the client's stored round-trip measurements. (ms) Range: 0 upward in practice; the client truncates through a signed 16-bit integer, so anything above 32767 goes out negative Averaged over at most the last 50 samples and rounded to the nearest millisecond, ties to even. Not the latest round trip. A client with no samples yet reports 0 - there is no guard for an empty buffer.required Recovered with score 165, confidence 0.86, 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.

Asks for a fresh API token for the in-client shop back end. Empty payload, sent on a timer. Kind requestArea Game.BakNamed by stringtable Refreshes the key for Ankama's in-client shop back end. Carries nothing. THE TRIGGER IS TOKEN LIFECYCLE, NEVER USER ACTION, and the client's state machine has three parts worth reproducing: in-flight latch one request at a time. The send routine sets a latch and will not send a second while one is outstanding. 5,000 ms retry when it cannot send yet - the connection is not up - it re-arms on a 5 second delay and tries again. A real repeating cadence during bring-up. 3,600,000 ms after a successful answer, EXACTLY ONE HOUR before the next refresh. A long session re-sends this hourly, indefinitely. Both constants are read straight out of the client, one in the send routine and one in the receive routine. IT APPEARS DURING BRING-UP ALONGSIDE THE SOCIAL BURST, AND IT IS NOT PART OF IT. A capture shows it in the same handful of milliseconds as ContextCreationRequest and the four-request burst described under FriendListRequest - but it comes from a different service on a different trigger. Do not fold it into that sequence. Nothing in gameplay depends on having the key. When you may send it Requires authenticated observed Raised by: token lifecycle, never a user action: 3,600,000ms after each successful key, and a 5,000ms retry whenever the send cannot proceed; one in flight at a time proven Related messages You will then receive BakApiKeyEvent observed — the server answers with the key; observed in a live session Recovered with score 145, confidence 0.92, 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: 0 of 0.

Asks for the whole anomaly board: every subarea, whether an anomaly is there and what it pays. Empty payload. Kind requestArea Game.AnomalyNamed by beta, gamemapping, stringtable Carries nothing. One request returns the entire board - there is no per-subarea form. THIS IS THE MESSAGE A FARMING SCRIPT WANTS. The board says which subareas currently carry an anomaly and what reward bonus each grants, which is exactly the input for deciding where to go. Ask when you need to choose, not on a loop. The board changes when anomalies open and close, and AnomalyOpenedEvent and AnomalyStateEvent tell you about those as they happen - so you can keep your copy current without asking again. Three builds pad this message; no writer in any dumped build populates anything. Send it empty. When you may send it Requires character_loaded observed Raised by: one internal client notification, once per session - not a timer, not per subarea, not per map change. The bus hides what raises it, so send it once the session can render the map and zaap UIs inferred Related messages You will then receive AnomalySubareaInformationEvent inferred — the server answers with the whole board Recovered with score 150, confidence 0.86, 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: 0 of 0.

Asks for the players the character has recently met or grouped with, as distinct from added friends. 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. ACQUAINTANCES ARE NOT FRIENDS. These are players the character has recently met or grouped with; explicitly added friends come from FriendListRequest. The two lists overlap but neither contains the other. Carries nothing. When you may send it Requires character_loaded observed Related messages Reply not yet recovered: the acquaintance list arrives as an event that has no signature here yet. Sequence Step post_character_load.2 observed — of 4 requests, in the order the client's own routine allocates them Recovered with score 215, confidence 0.89, 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 0.

Claims the reward for a finished achievement, or every claimable reward at once. Kind requestArea Game.AchievementNamed by beta Claims one achievement's reward. achievement_id OF -1 CLAIMS EVERYTHING CLAIMABLE AT ONCE. That is a real value, not a sentinel for "unset": the client sends exactly that when the player accepts all rewards. Be sure you meant it - there is no per-item confirmation. The current build pads the message with a nested four-member message that no dumped build writes. Leave it alone. When you may send it Requires character_loaded observed Raised by: the player accepts a reward in the rewards menu proven Related messages Reply not yet recovered: the reward arrives as items - watch GameActionItemListEvent and your inventory - but the acknowledgement message itself has no signature here yet. Fields #FieldTypeMeaningYou set it 1achievement_idint32Which achievement's reward to claim, or -1 for every claimable reward at once. (achievement id) Range: a real achievement id, or -1 for all -1 IS MEANINGFUL, not a placeholder.required Recovered with score 155, confidence 0.87, margin 155 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.