Smooth

The session identifier for Ankama's account and authentication web platform. Kind eventArea Game.HaapiNamed by stringtable Pushed during session bring-up, on the same service that handles the shop API key. It is never requested and cannot be replied to. The client's handler does exactly one thing: it forwards the string into its API-key service. NOTHING IN GAMEPLAY IS GATED ON IT, and a script that ignores it entirely loses nothing on the game protocol. The identifier is opaque - it identifies your session on Ankama's web platform. Treat it as a credential: do not log it, and do not put it anywhere it could leave your machine. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this no client writer constructs a request for it anywhere in the dumps Fields #FieldTypeMeaningYou set it 1session_idstringThe opaque web-platform session identifier. Treat it as a credential. The client forwards it unchanged and reads nothing else from the message.never Recovered with score 260, confidence 0.89, margin 260 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.

Authentication against Ankama's web platform failed. The message carries no payload. Kind eventArea Game.HaapiNamed by stringtable THE FACT THAT IT ARRIVED IS THE WHOLE MESSAGE. It carries nothing: no code, no reason, no text. It is the failure counterpart of the shop-key family - the client logs it as an error during the API-key request - so it arrives on the path that would otherwise have produced BakApiKeyEvent or HaapiSessionEvent. TREAT IT AS A FAILURE OF THE WEB-PLATFORM INTEGRATIONS, NOT OF YOUR GAME SESSION. The game connection is unaffected: you stay connected and everything that matters keeps working. Do not reconnect on it. There is nothing to reply to and nothing to retry from your side. When you may send it Requires authenticated observed Related messages Unsolicited - nothing you send causes this no client writer constructs anything that asks for it Recovered with score 210, confidence 0.92, margin 210 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.

When the guild's current mission week ends, as a text date. Kind responseArea Game.GuildNamed by gamemapping The answer to GuildWeeklyNextResetRequest, carrying the reset date AS TEXT. THE FORMAT IS NOT PINNED BY THE PROTOCOL AND THIS IS A REAL HAZARD. The client feeds the string straight to a culture-sensitive date parse - no fixed format string, no epoch, no offset. That means the string it accepts depends on the machine's locale, and a parser you write against one observed sample may fail on another. Parse defensively: accept what you can, and treat a failure as "unknown reset date" rather than as a crash. It arrives as a genuine Response rather than an Event, so it carries the uid of the request that asked - see Response. When you may send it Requires character_loaded observed Related messages Arrives after GuildWeeklyNextResetRequest Fields #FieldTypeMeaningYou set it 1reset_datestringWhen the guild's mission week ends. A TEXT date. The client parses it with the ambient culture - there is no fixed format on the wire.never 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: 1 of 2.

A character's gender, as the two-valued enum the protocol carries. Kind enumArea Game.CommonNamed by beta The gender of a character, carried by CharacterRemodelingInformation when you create or remodel one and by CharacterBaseInformation when the server describes one. THE VALUES ARE NOT NAMED HERE. No client behaviour dumped so far says which of the two means male; the client only ever turns the value into a yes/no by comparing it with 1. What the game data does show: each class has exactly two portraits, Head_<class id>0 and Head_<class id>1, and for the original twelve classes the male look uses skin <class id>0 and the female look <class id>1. If you need a portrait, append the gender value to the class id. Not sent on its own — an enum is never sent on its own. inferred Used by CharacterBaseInformation CharacterRemodelingInformation No fields you may set. Recovered with score 110, confidence 0.94, 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 2.

One or more actors have become visible on the current map. Kind eventArea Game.RoleplayNamed by beta, gamemapping The spawn message. Each entry is an ActorPositionInformation: who the actor is, where it stands, and what it looks like. IT IS ADDITIVE, NOT A SNAPSHOT. Unlike the map element events, this one adds to what you already know rather than replacing it - it is sent again whenever somebody walks into view. Add or update by ActorPositionInformation.actor_id and leave everything else alone. THE MATCHING REMOVAL IS ContextRemoveElementEvent. Without processing that one, your actor table only ever grows and you will keep believing in players who walked away. The client does two things with each entry: it materialises the entity from its EntityLook and hands it to the roleplay entity service, and separately registers the actor's on-screen name label. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server announces actors as they come into view; no request asks for this message Fields #FieldTypeMeaningYou set it 1actorsrepeated ActorPositionInformationThe actors that just became visible. Element type ActorPositionInformation.never Recovered with score 295, confidence 0.90, margin 295 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.

Items the server hands the character as the result of an action - a reward, a gift, a craft outcome. Kind eventArea Game.InventoryNamed by beta, gamemapping Announces items the character has just been given, with a caption describing why. The client renders it as the "you received" panel. IT IS AN ANNOUNCEMENT, NOT AN INVENTORY UPDATE. The items listed here are minimal descriptions meant for display - see ItemMinimalInformation, whose quantity and template id are NOT recovered and must not be guessed at. Treat this message as a cue to re-read your inventory, not as a source of truth about what you now hold. The members of this message are proven to exist by the way the client projects them, but none carries a recovered name yet, so they stand obfuscated. What you can rely on is the nesting: this event carries GameActionItem entries, each carrying ItemMinimalInformation entries, each carrying ObjectEffect values. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this it reports the outcome of a server-side action; no request of yours asks for this message directly No fields you may set. Recovered with score 135, confidence 0.99, margin 135 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 2.

One captioned group of items inside an action-item announcement. Kind structArea Game.InventoryNamed by beta A caption and the items it describes, as carried by GameActionItemListEvent. title is a localisation key, not display text. Resolve it against the client's own string table; printing it raw shows the reader an identifier. Not sent on its own — it is only ever reached inside GameActionItemListEvent. inferred Fields #FieldTypeMeaningYou set it 1titlestringThe caption for this group, as a localisation key rather than display text. Resolve it against the client string table before showing it.never 6itemsrepeated ItemMinimalInformationThe items this caption describes. Element type ItemMinimalInformation.never Recovered with score 180, confidence 0.97, 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 6.

An integrity challenge: the server names a game file and asks the client to measure it. Kind eventArea Game.Client.VerificationNamed by beta, gamemapping AN INTEGRITY CHECK. The server names a file and an algorithm; the client measures that file and answers with FileCheckRequest. What the client actually does, in order: it sanitises file_name with a regular expression, resolves it BENEATH THE APPLICATION DATA DIRECTORY, checks the file exists, reads its bytes, and then either reports the byte length as a decimal string or computes a checksum - whichever check_type selected. The reply carries that same enum back unchanged alongside the result. TWO THINGS FOLLOW FOR ANYONE WRITING A CLIENT. The path is relative and is resolved under the game's own data directory, so it never names anything outside the installation. And the answer is a measurement of a real file: an implementation that does not have the game's files installed has nothing honest to report. check_type decides which measurement is wanted - see CheckType. Echo it back exactly. When you may send it Requires authenticated observed Related messages You must then send FileCheckRequest proven — the client measures the named file and returns the result; leaving it unanswered is a shape the real client never produces Unsolicited - nothing you send causes this the server challenges on its own schedule Fields #FieldTypeMeaningYou set it 1check_typeCheckTypeWhich measurement the server wants. A CheckType value. Echo it back unchanged in the answer.never 4file_namestringThe game file to measure, as a path relative to the application data directory. The client sanitises it and resolves it beneath its own data path before opening it.never Recovered with score 200, confidence 0.99, 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 4.

The ceiling on how much money you may move in one exchange. Sent once, kept for the session. Kind eventArea Game.ExchangeNamed by beta, gamemapping A CEILING, NOT A BALANCE. It tells you the most money a single exchange may move. It says nothing about what you have. WHEN IT ARRIVES Once, early, unprompted. There is no request for it - the server volunteers it and the client stores it for the session. If you never see it, you have no limit information, not an unlimited one. WHAT TO DO WITH IT REMEMBER IT AND CHECK AGAINST IT BEFORE YOU OFFER MONEY. The real client does exactly one thing with this message: it copies the number into its played- character state and moves on. Nothing else happens, no UI updates, no confirmation. Every later check is against that stored value. IT IS A SESSION VALUE. Nothing in the dumped clients re-reads or refreshes it, so treat it as fixed once received rather than polling for it. READ THE INT64. The value is 64-bit and money in this protocol routinely exceeds 32 bits; truncating it gives you a limit that is wrong in the direction that gets your exchange refused. ONE DECLARED MEMBER IS PADDING - a nested message no dumped client has ever read. When you may send it Requires context_ready observed Related messages Unsolicited - nothing you send causes this the server volunteers it early in the session; nothing requests it Fields #FieldTypeMeaningYou set it 2limitint64The maximum amount of money a single exchange may move.never Recovered with score 235, confidence 0.89, 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: 1 of 2.

The failed branch of a character selection. It carries no payload at all. Kind structArea Game.Character.ManagementNamed by beta THE BRANCH ITSELF IS THE WHOLE MESSAGE. It carries nothing: no code, no reason, no text. The client only observes that this branch was taken and runs its selection-error path. So there is nothing to inspect and nothing to report to a user beyond "the server refused". Do not go looking for an error code that is not there, and do not read the success branch to find out why - see CharacterSelectionEvent. Not sent on its own — it is only ever the error branch of CharacterSelectionEvent. inferred Used by CharacterSelectionEvent Recovered with score 90, confidence 0.96, 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.

How to draw an entity: its skeleton, layered art, colour overrides, scale and attached sub-entities. Kind structArea Game.CommonNamed by beta The appearance record, shared by Character, ActorPositionInformation and every other message that shows an entity. MOST SCRIPTS DO NOT NEED TO DECODE THIS. It is rendering data. What it IS good for is telling entities apart cheaply - bones_id distinguishes a monster species from a player without resolving anything. indexed_colors IS PACKED, NOT A PLAIN COLOUR LIST. Each entry is (index << 24) | rgb: the high byte selects which colour slot is being overridden and the low three bytes are the colour. Reading it as a flat RGB list produces nonsense. The client carries these as unsigned values even though the wire type is signed, so a large positive index arrives as a negative int32 - mask, do not compare. scales is a percentage pair; a single entry means uniform scaling. sub_entities MAKES THE STRUCTURE RECURSIVE. A mount carries its rider as a sub-entity, whose look can itself carry a pet. Bound your traversal - do not assume one level. EVERY FIELD NUMBER MOVED between the reference build and this one. Read by name. Not sent on its own — it hangs off a character, an actor or a sub-entity and is never sent alone. proven Used by CharacterLook MonsterInGroupInformation SubEntityInformation Fields #FieldTypeMeaningYou set it 1indexed_colorsrepeated int32Colour overrides, each packed as (slot index << 24) | rgb. NOT a plain colour list - the high byte is the slot being overridden. Unsigned in the client, signed on the wire: mask rather than compare.never 2sub_entitiesrepeated SubEntityInformationAttached looks - a mount and its rider, a pet, a carried entity - each with its binding point. Element type SubEntityInformation, which nests another EntityLook. The structure is recursive.never 3skinsrepeated int32The art assets layered to draw the entity. (skin ids) The client holds these as 16-bit values.never 5bones_idint32Which skeleton animates this entity. (bones id) The cheapest way to tell one kind of entity from another.never 6scalesrepeated int32Entity scale as a percentage pair; a single entry means uniform. (percent)never Recovered with score 305, confidence 0.91, margin 305 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 6.

Where an entity stands and which way it faces, optionally naming who is carrying it. Kind structArea Game.CommonNamed by beta, gamemapping The positional half of ActorPositionInformation, and also sent on its own - as a bare list - to reposition entities already on the map. cell_id IS A SINGLE GRID INDEX, NOT A COORDINATE PAIR. Everything in the map protocol addresses cells this way. THREE OF THE FOUR MEMBERS HAVE EXPLICIT PRESENCE, SO ABSENT AND ZERO ARE DIFFERENT. Absent means unchanged; zero means cell 0, entity 0, or nobody. When this record arrives in a bare repositioning list, an absent member is the normal case, not an error. entity_id is what makes a bare disposition addressable at all - it is the only thing saying which entity the list entry is about. NOTHING ABOUT THE LAYOUT IS STABLE. Every member's field number moves across the dumped builds, and one build declares a SECOND field of the Direction enum beside the real one. Read by name. Not sent on its own — it travels inside ActorPositionInformation or as an element of a bare disposition list. proven Used by ActorPositionInformation Fields #FieldTypeMeaningYou set it 1entity_idint64Which entity this position describes. Explicit presence: absent is not the same as zero. (entity id) It is what identifies the entry when the record travels in a bare list.never 2directionDirectionThe entity's eight-way facing. A Direction value. One dumped build declares a second field of the same enum beside this one.never 3carrying_character_idint64The character carrying this entity, when one entity is being carried by another. Explicit presence: absent is not the same as zero. (actor id) Absent means nobody is carrying it.never 4cell_idint32The map cell the entity occupies. Explicit presence: absent is not the same as zero. (map cell id) A single grid index, not an x/y pair. Absent means unchanged.never Recovered with score 285, confidence 0.93, margin 285 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.

The complete list of emotes you know. A replacement, not an addition. Kind eventArea Game.EmoteNamed by beta, gamemapping THE WHOLE LIST, EVERY TIME. This is not "you learned an emote" - it is the complete set of emotes you know, sent as a replacement. Overwrite your state with it rather than merging into it. WHEN IT ARRIVES Once, unprompted, when your character loads. There is no request for it. Its siblings handle the deltas afterwards: one message adds a single emote and another removes one, so after this arrives you maintain the set yourself. WHAT THE IDS ARE EMOTE IDS FROM THE GAME DATA, not indexes into this list. The client looks each one up by id in its emoticon data and drops any it cannot resolve, so an id you do not recognise is a data-version mismatch, not a protocol error - and the order they arrive in is not a display order. An id in this list is what you may send to play that emote. One that is not in it will be refused. READ IT AS A SET. Nothing in the protocol promises the order is stable or meaningful, and the client does not rely on it either. When you may send it Requires context_ready observed Related messages Unsolicited - nothing you send causes this the server sends it when the character loads; nothing requests it Fields #FieldTypeMeaningYou set it 3emotes_idrepeated int32Every emote you know, by id.never Recovered with score 195, confidence 0.93, 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.

The eight-way compass facing shared by the map, movement and fight message families. Kind enumArea Game.CommonNamed by beta Every roleplay and fight entity faces one of eight directions on the isometric grid. Facing decides which sprite and animation set is drawn, and it matters mechanically: backstab bonuses depend on the relative facing of attacker and target. The eight values run CLOCKWISE FROM EAST: 0 EAST 1 SOUTH_EAST 2 SOUTH 3 SOUTH_WEST 4 WEST 5 NORTH_WEST 6 NORTH 7 NORTH_EAST ON THE ISOMETRIC GRID THE EVEN VALUES ARE THE DIAGONAL SCREEN DIRECTIONS and are the ones ordinary walking between adjacent cells uses; the odd values are the orthogonal ones. This trips people up because the compass names suggest the opposite. The numbering is unchanged across every build in the dump set, and it was checked rather than assumed - an enum can be renumbered between builds while keeping its member set, and that exact trap has been hit before on this protocol. Not sent on its own — an enum is never sent on its own. proven Used by EntityDisposition MapChangeOrientationEvent MapChangeOrientationRequest Values ValueNumberMeaning DIRECTION_EAST0Facing east. A diagonal screen direction, used for ordinary walking. DIRECTION_SOUTH_EAST1Facing south-east. An orthogonal screen direction. DIRECTION_SOUTH2Facing south. A diagonal screen direction, used for ordinary walking. DIRECTION_SOUTH_WEST3Facing south-west. An orthogonal screen direction. DIRECTION_WEST4Facing west. A diagonal screen direction, used for ordinary walking. DIRECTION_NORTH_WEST5Facing north-west. An orthogonal screen direction. DIRECTION_NORTH6Facing north. A diagonal screen direction, used for ordinary walking. DIRECTION_NORTH_EAST7Facing north-east. An orthogonal screen direction. Recovered with score 160, confidence 0.89, 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: 8 of 8.

Which kind of dialog a dialog-lifecycle message is talking about. Kind enumArea Game.CommonNamed by beta WHICH DIALOG. It is the only member of DialogLeaveEvent and the value you switch on to decide whether an announcement is about your dialog or someone else's. SWITCH ON THE NUMBER, NEVER ON POSITION, and ignore a value you do not recognise the way the client does - six services listen to the same event and each acts on its own handful of values, so "not mine" is the normal case, not an error. ALL SIXTEEN NAMES ARE ANKAMA'S, from the unobfuscated reference build, and the count has been sixteen in every build examined. What each NUMBER does is proven for a handful of them by client behaviour; the rest carry the reference name at the reference number and nothing more. The per-value notes say which is which - read them before treating a label as a fact about the current server. Not sent on its own — an enum is never sent on its own. inferred Used by DialogLeaveEvent Values ValueNumberMeaning DIALOG_BOOK0The proto3 zero value, named BOOK by the reference build. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_DIALOG1An NPC dialogue. Corroborated on 3.6.10.10: A service that also handles marriage and dungeon-assembly values tests this one. DIALOG_LOCKABLE2A code-locked container or door. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_PURCHASABLE3A purchase dialog. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_GUILD_INVITATION4A guild invitation. Corroborated on 3.6.10.10: A consumer switches from this number, and the three guild values are consecutive from it. DIALOG_GUILD_CREATE5Guild creation. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_GUILD_RENAME6Guild renaming. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_MARRIAGE7A marriage dialog. Corroborated on 3.6.10.10: Tested by the same service that tests the dialogue and dungeon-assembly values. DIALOG_DUNGEON_MEETING8The dungeon-assembly dialog. Corroborated on 3.6.10.10: Two services test this value; one of them exists only to run a small meeting feature and disables itself when it sees it. DIALOG_SPELL_FORGET9Spell forgetting. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_TELEPORTER10A teleporter, such as a zaap. Corroborated on 3.6.10.10: Tested by the service that reads the world's sub-area data - the data a teleporter destination list is built from. DIALOG_EXCHANGE11A trade or exchange window. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_ALLIANCE_INVITATION12An alliance invitation. Corroborated on 3.6.10.10: A consumer switches from this number, and the three alliance values are consecutive from it. DIALOG_ALLIANCE_CREATE13Alliance creation. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_ALLIANCE_RENAME14Alliance renaming. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. DIALOG_HAVENBAG_MEETING15A haven-bag meeting. The name is the reference build's; no dumped client distinguishes this value from its neighbours, so only its NUMBER is proven here. Recovered with score 230, confidence 0.83, margin 230 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: 16 of 16.

Announces that a dialog has closed, and which kind it was. Broadcast, not an acknowledgement. Kind eventArea Game.DialogNamed by beta, gamemapping IT IS A BROADCAST, NOT AN ACKNOWLEDGEMENT. It says "a dialog of this kind has closed" - and the server sends it whether YOU closed the dialog or something else did: you walked away, the NPC ended it, it timed out. Do not treat it as the receipt for your DialogLeaveRequest. READ THE TYPE AND DECIDE IF IT IS YOURS. One member, a DialogType. The real client has six independent services listening to this one event, and each does nothing unless the type is one of its own - the teleporter service ignores everything but the teleporter value, the meeting service ignores everything but its own. Copy that: match on the type, ignore the rest, and never assume the event that just arrived belongs to the dialog you were in. WHAT IT MEANS FOR YOUR STATE THE DIALOG IS ALREADY GONE. This is not permission to close, it is notice that it is closed. Anything you were going to send into that dialog is now too late, and the server will refuse it. ONE OF THE SERVICES SHUTS ITSELF DOWN when its type arrives, which is a good model: treat the matching type as "tear down whatever I was tracking for that dialog", not as "ask what happened". IT IS UNCORRELATED. Envelope uid -1, matched by type, with nothing tying it to the request that may or may not have caused it. THE SECOND DECLARED MEMBER IS PADDING. No dumped client has ever read it. When you may send it Requires context_ready observed Related messages Arrives after DialogLeaveRequest Fields #FieldTypeMeaningYou set it 1dialog_typeDialogTypeWhich kind of dialog closed.never Recovered with score 240, confidence 0.90, margin 240 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 element has left the current context. This is the despawn message. Kind eventArea Game.ContextNamed by beta, gamemapping THE DESPAWN. Process this or your world model only ever grows. element_id is the same id space as ActorPositionInformation.actor_id and InteractiveElement.element_id - a player, a monster, an NPC or an interactive object. Remove whatever you are holding under that id. A script that skips this will keep attacking monsters that are dead, walking to resources someone else took, and following players who left the map. It is the cheapest message in the protocol to handle and the most expensive one to ignore. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server announces departures as they happen Fields #FieldTypeMeaningYou set it 1element_idint64The context element that left: a player, monster, NPC or interactive object. (element id)never Recovered with score 235, confidence 0.93, 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: 1 of 1.

The community channel the server has actually placed this character on. Kind eventArea Game.SocialNamed by beta, gamemapping The server's acknowledgement of SetCommunityChannelRequest, carrying the community it accepted. TAKE THIS VALUE, NOT THE ONE YOU SENT. The two can differ, and everything about which community channel you can read depends on this one. The ChannelUpdateEvent volley that actually re-states your subscriptions follows immediately after this message. When you may send it Requires character_loaded observed Related messages Arrives after SetCommunityChannelRequest Fields #FieldTypeMeaningYou set it 2communityint32The community the server has placed the character on. Range: -1 to 4 -1 unset, 0 French, 1 English/international, 2 Spanish, 3 Portuguese, 4 German.never Recovered with score 155, confidence 0.86, 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 2.

One set of packed RGB colours applied to a character. Kind structArea Game.CosmeticNamed by gamemapping A palette is a list of PACKED RGB INTEGERS - 8025436 is 0x7A75DC, so red is (v >> 16) & 0xFF, green (v >> 8) & 0xFF, blue v & 0xFF. A character uses six colours. A palette may carry fewer, or none: the client fills whatever is missing from the character's BREED DEFAULTS, looking the breed up in its game data. So an empty palette means "the breed's own colours", not "no colours", and you should apply the same fallback rather than rendering a gap. The order is positional - colour 1 through colour 6 - not a set. Not sent on its own — it is a record carried by other messages, never sent alone. proven Used by CharacterColors Fields #FieldTypeMeaningYou set it 1colorsrepeated int32The palette's colours, packed RGB, in slot order.never Recovered with score 150, confidence 0.84, 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.

Which measurement a file check asks for: the file's byte length, or a checksum of its contents. Kind enumArea Game.Client.VerificationNamed by beta The algorithm selector shared by FileCheckEvent and FileCheckRequest. The two values are proven by what the client's own branches do: one reads the byte array's length and formats it as a decimal string, the other calls the checksum helper. Both results travel as a string. Not sent on its own — an enum is never sent on its own. inferred Used by FileCheckEvent FileCheckRequest Values ValueNumberMeaning LENGTH0Report the file's byte length, formatted as a decimal string. HASH_SUM1Report a checksum computed over the file's bytes. 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: 2 of 2.

The server telling the client which chat channels to switch on and which to switch off. Kind eventArea Game.ChatNamed by beta, gamemapping The server-side counterpart of SubscribeMultipleChannelRequest: two lists applied to your channel mask. ORDER MATTERS AND IT IS NOT OBVIOUS. The client ORs active_channels in FIRST, then AND-NOTs disabled_channels out. So A CHANNEL PRESENT IN BOTH LISTS ENDS UP OFF. Apply them in that order or you will disagree with the client about what you are subscribed to. This is availability, not preference: it says what the server permits, which is not necessarily what you asked for. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this the server states channel availability on its own schedule, not only in reply to a subscription Fields #FieldTypeMeaningYou set it 1disabled_channelsrepeated ChannelChannels to switch off. Element type Channel. Applied AFTER the active list, so a channel in both ends up off.never 2active_channelsrepeated ChannelChannels to switch on. Element type Channel. Applied first.never Recovered with score 175, confidence 0.89, 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: 2 of 2.

Somebody said something on a chat channel, including your own lines echoed back. Kind eventArea Game.ChatNamed by beta, gamemapping Everything said on every channel you are subscribed to, including your own lines coming back after ChatChannelMessageRequest. TWO SENDER IDS, TWO DIFFERENT PURPOSES. sender_character_id is the CHARACTER speaking - use it to address them or open a menu on them. sender_account_id is the ACCOUNT behind that character - use it to ignore a PERSON, who can otherwise come back on another character. They are both 64-bit and they are not interchangeable. date IS AN ISO-8601 STRING WITH OFFSET, NOT A UNIX TIME. It looks like "2026-08-26T21:51:44+02:00". Parse it; do not cast it. content is the words only. Anything shift-clicked into the line - items, monster groups - rides in metadata as structured links, and the client merges the two before display. A script reading only content sees the sentence with the links missing. origin_server_id HAS EXPLICIT PRESENCE and is only meaningful when present, which happens on the cross-server community channels. Absent means "this server". channel has no explicit presence: absent reads as the zero value, Channel.GLOBAL. When you may send it Requires character_loaded observed Related messages Arrives after ChatChannelMessageRequest Fields #FieldTypeMeaningYou set it 1contentstringThe spoken text, without the rich-link content. The client merges this with the metadata links before displaying the line.never 2sender_prefixstringDecoration shown in front of the speaker's name. Empty for an ordinary player.never 3origin_server_idint32Which server the speaker is on. Explicit presence: absent is not the same as zero. (server id) Only meaningful when present - it appears on the cross-server community channels.never 4sender_account_idint64The speaking character's account id - use it to ignore a person rather than a character. (account id) A person can return on another character; the account id follows them.never 5sender_namestringThe speaker's character name, as displayed.never 6sender_character_idint64The speaking character's id - use it to address or open a menu on the speaker. (character id)never 7from_adminboolWhether this is a staff line. The client passes it to its mute predicate, which is what stops staff lines being muted.never 8datestringWhen the line was said. Observed: 2026-08-26T21:51:44+02:00 An ISO-8601 string with offset. NOT a unix timestamp.never 9channelChannelWhich channel the line was said on. A Channel value. No explicit presence: absent reads as Channel.GLOBAL.never 10metadataMetadataRich content attached to the line. See Metadata. Present but empty for an ordinary line.never Recovered with score 340, confidence 0.89, margin 340 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: 10 of 10.

A character's availability state, plus the player's own optional away message. Kind structArea Game.CommonNamed by beta The shared availability carrier, used everywhere a character's presence is shown - PlayerStatusUpdateRequest, friend, guild and party listings. message IS PLAYER-CONTROLLED TEXT. TREAT IT AS UNTRUSTED. It is whatever another person typed into their status, it is usually absent, and it reaches your script exactly as they wrote it. Never interpolate it into anything that executes, and escape it before display. status is the machine-readable half; see Status. Not sent on its own — it is embedded in a dozen messages and never sent on its own. inferred Used by PlayerStatusUpdateRequest PlayerStatusUpdatedEvent Fields #FieldTypeMeaningYou set it 2statusStatusThe character's availability state. A Status value.required when you set your own status 3messagestringThe player's own away or custom text. Explicit presence: absent is not the same as zero. Usually absent. UNTRUSTED - it is free text another player wrote. Escape it before display.optional 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: 2 of 3.

Whether the selection was accepted, and which character was entered. Kind eventArea Game.Character.ManagementNamed by beta, gamemapping Answers CharacterSelectionRequest with one of two outcomes, carried in a oneof: success with the selected character, or an error with no payload. CHECK WHICH BRANCH IS SET BEFORE READING EITHER. The failure branch is empty, so a client that reads the success branch unconditionally sees a zeroed character rather than an error. When you may send it Requires authenticated observed State it changes Establishes character_selected observed — a successful selection is what makes later character and world messages legal Related messages Arrives after CharacterSelectionRequest Fields #FieldTypeMeaningYou set it 1successSuccessSet when the selection was accepted; carries the character now being played.never 3errorErrorSet when the selection was rejected. Carries no detail - the branch itself is the message.never Recovered with score 95, confidence 0.96, margin 95 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.

The whole appearance of a character - name, class, gender, colours, head - used both to create one and to remodel one. Kind structArea Game.Character.ManagementNamed by beta THIS IS THE PAYLOAD OF CHARACTER CREATION, despite the name. The same type carries a character you are creating, a character you are remodelling, and the alternative branch of Character for someone mid-remodelling. Its name comes from the last of those; its most common use is the first. FILLING IT IN NAME, CLASS, GENDER, COLOURS, HEAD. That is the whole payload for a creation. SEND SIX COLOURS. The real client builds the list to six entries before it will construct the request, and -1 in a slot means "leave this one at the class default". Sending fewer is not something the client ever does. THE CLASS IS AN ID, NOT AN INDEX. The client stores it in its own class enum and writes that value straight out, so it is the class id you would recognise, not a position in a menu. THE HEAD IS YOUR CHOICE; THE OTHER NUMBER IS NOT. Beside the head there is a second small integer the client does not ask the player about - it looks it up from the class and gender and sends it along. It is recovered as a member but deliberately left unnamed here, because no reference build ever named it. If you are replaying a capture, send back what the client sent; if you are building a request from scratch, that value is derived, not chosen. WHAT YOU LEAVE EMPTY THE REMODELLING BLOCK IS NOT YOURS TO FILL. One member describes what an existing character may and must change. The client never populates it on the creation path - the server sends it when it offers a remodelling - so leave it absent. READ AND WRITE BY ROLE, NOT BY NUMBER. Every member of this message has moved field number between builds, and the padding around them changes too: three same-typed integers side by side is normal here. Not sent on its own — it is a payload type, never sent on its own. inferred Used by Character CharacterCreationRequest Fields #FieldTypeMeaningYou set it 1breed_idint32The class. The client sends its own breed enum here, so the value is a class id, not an index.required 2cosmetic_idint32The head you picked. It comes straight from the player's choice, not from the class.required 3genderGenderMale or female. The client holds it as a bool and converts it to this two-valued enum on the way out.required 4colorsrepeated int32The colour choices, in slot order. -1 means "leave this slot at the class default". The client refuses to build the request until the list holds six entries, so send six.required 6namestringThe character's name.required 7character_to_remodel_informationtype not documented yetWhich parts of an existing character a remodelling is allowed, and required, to change. Absent when creating.never on the creation path Recovered with score 346, confidence 0.94, margin 346 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 7.