Smooth

Your character started regenerating life, at the given rate. Kind eventArea Game.CharacterNamed by beta, gamemapping Regeneration has started. The client starts a local timer from the moment this arrives and keeps the rate, so the life shown between server updates is its own estimate. IT ENDS WITH UpdateLifePointsEvent. That message stops the same timer. IF YOU TRACK LIFE YOURSELF, do what the client does: remember when regeneration started and at what rate, and stop when the update arrives. ONE DECLARED MEMBER IS PADDING. Read the recovered name. When you may send it Requires character_selected inferred Related messages Unsolicited - nothing you send causes this the client reacts to it without having asked for anything Fields #FieldTypeMeaningYou set it 2regen_rateint32The regeneration rate the client starts its life timer with. The client scales it before use; the unit is not documented here.never Recovered with score 240, confidence 0.89, 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 2.

How many kamas you are carrying. Kind eventArea Game.InventoryNamed by beta, gamemapping Your carried kamas. The inventory snapshot in InventoryContentEvent brings the first value; this message keeps it current afterwards. TREAT IT AS THE AMOUNT, NOT A CHANGE. The client hands the number unchanged to every open storage window as the kamas figure to display. Overwrite what you track rather than adding to it. ONLY THE WALLET YOU CARRY. Storage windows such as the bank listen to a different message for the kamas they hold. ONE DECLARED MEMBER IS PADDING. Read the recovered name; the client never reads the other member. When you may send it Requires character_selected inferred Related messages Unsolicited - nothing you send causes this the client handles it without having asked for anything Fields #FieldTypeMeaningYou set it 2quantityint64How many kamas you are carrying. (kamas) An amount to overwrite, not a delta: the client displays it as is.never Recovered with score 260, confidence 0.90, 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.

A display-only item description: its effects, plus integral members that are deliberately left unnamed. Kind structArea Game.InventoryNamed by beta The item description used in announcements rather than in the inventory. ONLY effects IS NAMED HERE, AND THAT IS DELIBERATE. The record carries integral members whose values the client does pass into its item factory, but telling the template id apart from the quantity needs a role proof this signature does not have. Historical field order would answer it and historical field order is wrong on this protocol often enough that guessing is worse than leaving them bare. They stand with their obfuscated names; do not read meaning into their position. If you need the real quantity or template id of something you were just given, read it from the inventory - see InventoryContentEvent - rather than from here. A repeated bool member is likewise untouched: it may be a decoy or protocol state the game has not started using. Not sent on its own — it is only ever reached inside GameActionItem.items. inferred Used by GameActionItem Fields #FieldTypeMeaningYou set it 4effectsrepeated ObjectEffectThe effects the item carries. Element type ObjectEffect - branch on its oneof.never Recovered with score 180, confidence 0.99, 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: 1 of 4.

How full your inventory is, and how full it can get. Both numbers, every time. Kind eventArea Game.InventoryNamed by beta, gamemapping BOTH NUMBERS, EVERY TIME. The server does not send "you gained 12 weight"; it sends the current weight and the ceiling together, so you can overwrite your state rather than accumulate into it. If you are tracking pods, this message IS your state - do not try to keep a running total from item pickups and drops. WHEN IT ARRIVES Whenever what you are carrying changes, and once when the inventory first loads. Treat it as a refresh, not a delta. READ IT BY ROLE, NOT BY NUMBER. The two members swap field numbers between builds - on some the weight is #1 and the ceiling #2, on others the reverse, and on the current build they are #1 and #3 with a decoy between them. The recovered names are what to key on. WHAT THE CLIENT DOES WITH IT It feeds a progress gauge: the current weight becomes the bar's value and the maximum its full extent. That is the whole handling - no thresholds, no warnings in this message. If you want an "overloaded" signal you have to compare the two yourself. ONE DECLARED MEMBER IS PADDING and no dumped client has ever read it. When you may send it Requires context_ready observed Related messages Unsolicited - nothing you send causes this the server sends it whenever what you carry changes; nothing requests it Fields #FieldTypeMeaningYou set it 1inventory_weightint32How much your inventory currently weighs.never 3weight_maxint32The most it can weigh before you are overloaded.never Recovered with score 260, confidence 0.90, 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: 2 of 3.

The character's entire inventory and kamas balance, pushed by the server as a full snapshot. Kind eventArea Game.InventoryNamed by beta The whole inventory in one message: every item the character holds, plus the kamas balance. IT IS A SNAPSHOT, NOT A DELTA - REPLACE YOUR MODEL, DO NOT MERGE. An item that is absent from this message is an item the character no longer has. A script that merges keeps phantom stacks forever, most visibly after a trade, a bank withdrawal, or any server-side resynchronisation. Each element is an ObjectItemInventory: the item itself plus where it sits and how the player tagged it. The item is an ObjectItem, whose ObjectItem.uid is the handle every later request needs - destroy, drop, move, exchange. Index your model by that uid and nothing else. KAMAS IS A 64-BIT VALUE and a wealthy character exceeds 2^31. A 32-bit accumulator overflows. Do not assume you see this exactly once. It arrives at login and can arrive again unprompted at any time. When you may send it Requires character_selected observed Related messages Unsolicited - nothing you send causes this the server pushes it during the login burst and again whenever it resynchronises; no request asks for it Fields #FieldTypeMeaningYou set it 1kamasint64The character's kamas balance at the moment of the snapshot. (kamas) 64-bit; do not narrow it.never 2objectsrepeated ObjectItemInventoryEvery item the character holds, each wrapped with its inventory position and tags. Element type is ObjectItemInventory, not ObjectItem - the item is one level down.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 2.

An entity has started using an interactive element: the element, the skill, how long it takes, and whether it can still move. Kind eventArea Game.InteractiveNamed by beta, gamemapping Announces the BEGINNING of an interaction - chopping a tree, mining an ore, opening a door, taking a zaap - not its result. Nothing here says whether the harvest succeeded or what it yielded. THE INTERACTION IS NOT INSTANT AND THIS IS WHERE YOU LEARN HOW LONG IT TAKES. duration is the run time the client scales into its animation clock. A script that fires its next action immediately is acting during an interaction the server still considers in progress. CHECK entity_id AGAINST YOUR OWN. It is broadcast for characters, monsters and NPCs alike, so most arrivals are other people harvesting. can_move FALSE LOCKS THE ACTOR IN PLACE for the duration. Sending a movement request during that window is not something the real client does. element_id joins this to InteractiveElement and to StatedElement, so it is how you tell WHICH node someone just started on. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this it is broadcast for every actor that starts an interaction, yourself included Fields #FieldTypeMeaningYou set it 1durationint32How long the interaction will run. The client scales this into its animation clock; the exact unit is not proven here, so measure it against a capture before timing on it.never 2element_idint32The interactive element being used. (interactive element id) The same id as InteractiveElement.element_id and StatedElement.element_id.never 3entity_idint64The entity that started the interaction: a character, a monster or an NPC. (entity id) Compare against your own id before treating the interaction as yours.never 4skill_idint32Which action is being performed - what distinguishes cutting from mining from opening. (skill id) The same id space as InteractiveElementSkill.skill_id.never 5can_moveboolWhether the actor may still move while the interaction runs. False locks the actor in place for the duration.never Recovered with score 379, confidence 0.94, margin 379 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.

Every interactive element on the map, sent when the character arrives. The snapshot a harvest plan is built from. Kind eventArea Game.InteractiveNamed by beta The map's interactive snapshot. Build your model of what is harvestable here, then keep it current by applying InteractiveElementUpdatedEvent on top. IT IS A SNAPSHOT, NOT A DELTA - REPLACE THE MAP'S ELEMENTS, DO NOT MERGE. It arrives once per map arrival, so treat each arrival as a fresh world. Drop any element whose InteractiveElement.on_current_map is false, exactly as the client does. The current build pads this message with one member no dumped build reads; it stands with its obfuscated name. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server sends the snapshot on map arrival; no request asks for it directly Fields #FieldTypeMeaningYou set it 2interactive_elementsrepeated InteractiveElementEvery interactive element on the map. Element type InteractiveElement.never Recovered with score 130, confidence 0.85, 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.

One interactive element re-published because its state changed - harvested, unlocked, become usable. Kind eventArea Game.InteractiveNamed by beta The delta counterpart of InteractiveMapUpdateEvent: the server re-sending ONE element because something about it changed. RE-READ BOTH SKILL LISTS AND REPLACE THE ELEMENT WHOLESALE. The change is usually a skill MOVING between the enabled and disabled lists - a resource harvested, a door unlocking - so a script that only looks at InteractiveElement.enabled_skills and merges will keep a stale skill it should have dropped. Match the incoming record to your model by InteractiveElement.element_id. The current build pads this message with two members the payload never carries; they stand with their obfuscated names. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server publishes state changes as they happen Fields #FieldTypeMeaningYou set it 1interactive_elementInteractiveElementThe element whose state changed. A whole InteractiveElement - replace your copy rather than patching it.never Recovered with score 130, confidence 0.85, margin 130 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 1.

One action an interactive element offers: the harvest gesture on a field, open on a door, use on a zaap. Kind structArea Game.CommonNamed by beta An action offered by an interactive object. THE TWO IDS ARE SWAPPED ON THE CURRENT BUILD relative to the reference one - skill_instance_uid is declared at 1 and skill_id at 2. Read by name, and be careful which one you send: they are both int32 and they mean completely different things. skill_id WHAT the action is, as a data-centre skill id. Shared by every element offering the same action. skill_instance_uid WHICH offer this is on THIS element. Unique among that element's actions. name_id is an optional label override. When present the client resolves it through its skill-name data and displays that instead of the skill's own name; its absence is normal and means "use the skill's own name". Whether an action is available is NOT expressed here - it is expressed by which of InteractiveElement's two lists this record appears in. Not sent on its own — it is only ever an element of one of InteractiveElement's two skill lists. proven Used by InteractiveElement Fields #FieldTypeMeaningYou set it 1name_idint32An optional label override for this action. Explicit presence: absent is not the same as zero. (skill name id) Absent is the normal case and means the skill's own name is used.never 2skill_instance_uidint32Per-element handle for this particular offer, unique among the element's actions. (skill instance id) Declared at number 1 on this build, the reverse of the reference build.never 3skill_idint32Which action this is, as a data-centre skill id. (skill id) Shared by every element that offers the same action. Declared at number 2 on this build, the reverse of the reference build.never Recovered with score 180, confidence 0.87, 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: 3 of 3.

One interactive map object - a resource node, door, zaap or workshop machine - and the actions it currently offers. Kind structArea Game.CommonNamed by beta Everything the client knows about one interactive object. This is the record a harvesting script actually reasons over. DO NOT TRUST FIELD NUMBERS FOR THE TWO SKILL LISTS. The current build declares disabled_skills at 3 and enabled_skills at 4 - THE EXACT REVERSE of the reference build. A script that carried the old numbering across shows harvested nodes as harvestable and vice versa. Read by name. enabled_skills IS THE ONLY LIST YOU MAY ACT ON. It is what the element will accept right now. disabled_skills is what it exposes but currently refuses - a harvested resource keeps its gather skill there until it regrows, which is exactly the state that makes a naive bot loop forever on an empty node. on_current_map FALSE MEANS DROP IT. The client's own interactive service discards those records rather than displaying them; keeping them leaves you believing in objects that are on a neighbouring map. element_id is the join key. The same id identifies this object in InteractiveUsedEvent and in the stated-element events, so it is how you correlate "someone started harvesting" with "this node changed state". age_bonus is the harvest bonus a resource has accrued since it last regrew. It has explicit presence: absent means the element has no such notion, which is different from a bonus of zero. Not sent on its own — it travels inside the interactive snapshot or update events. inferred Used by InteractiveElementUpdatedEvent InteractiveMapUpdateEvent MapComplementaryInformationEvent Fields #FieldTypeMeaningYou set it 1age_bonusint32Harvest bonus the resource has accrued since it last regrew. Explicit presence: absent is not the same as zero. (percent) Shown in the client tooltip as ageBonus.never 2element_type_idint32What kind of element this is, resolved against the client's interactives data. (interactive type id)never 3on_current_mapboolWhether the element belongs to the map the character is standing on. The client's interactive service DROPS records where this is false.never 4element_idint32Identity of this element on the map, and the key that joins it to every other event about it. (interactive element id) The client uses it as its element-dictionary key. The same id appears in InteractiveUsedEvent.element_id and in StatedElement.element_id.never 5enabled_skillsrepeated InteractiveElementSkillThe actions currently available on this element - the only ones worth requesting. Element type InteractiveElementSkill. DECLARED AT NUMBER 4 ON THIS BUILD, the reverse of the reference build. Never read it by number.never 6disabled_skillsrepeated InteractiveElementSkillThe actions this element exposes but currently refuses. Element type InteractiveElementSkill. A harvested resource keeps its gather skill HERE until it regrows. DECLARED AT NUMBER 3 ON THIS BUILD, the reverse of the reference build.never Recovered with score 125, confidence 0.90, 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: 6 of 6.

Which section of guild data a request is asking for. Three of its six values were renumbered in Dofus 3. Kind enumArea Game.GuildNamed by beta THE VALUES WERE RENUMBERED IN DOFUS 3. DO NOT REUSE THE OLD NUMBERS. The reference build declared seven sections: GENERAL=0, MEMBERS=1, BOOSTS=2, PADDOCKS=3, HOUSES=4, RECRUITMENT=5, LOGBOOK=6. The current protocol has DROPPED the paddocks section and packed the rest densely, so everything after BOOSTS shifted down by one: unchanged GENERAL 0 MEMBERS 1 BOOSTS 2 shifted HOUSES 3 (was 4) RECRUITMENT 4 (was 5) LOGBOOK 5 (was 6) A script reusing the old numbering asks for the wrong section on THREE OF THE SIX values, and nothing reports an error - it just gets data it did not ask for. How the renumbering was established: the client keeps its own selector enum, which still carries the OLD numbering and simply omits the paddocks value, leaving a hole at 3. A converter function translates that client enum to the wire enum by strict ordinal compaction, which is what closes the mapping. Not sent on its own — an enum is never sent on its own. inferred Used by GuildInformationRequest Values ValueNumberMeaning GENERAL0Name, level, emblem, experience and the headline counters on the guild window's front tab. MEMBERS1The guild's member list. BOOSTS2Guild boosts - the spent and available boost points. Forced rather than directly proven: no named UI constant reaches this value. HOUSES3Guild houses. WAS 4 IN THE REFERENCE BUILD; it is 3 here. RECRUITMENT4Guild recruitment settings. WAS 5 IN THE REFERENCE BUILD; it is 4 here. LOGBOOK5The guild logbook. WAS 6 IN THE REFERENCE BUILD; it is 5 here. Forced rather than directly proven, like BOOSTS. Recovered with score 100, confidence 0.94, margin 100 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 6 of 7.

The account's role in the staff hierarchy, from ordinary player up to administrator. Kind enumArea Game.AccountNamed by beta Carried by AccountCapabilitiesEvent. On any ordinary account this is the player role and never changes. It is worth reading for one reason: it tells you when you are talking to a staff account, and staff accounts see and can do things ordinary ones cannot. Nothing in the protocol is gated on it from your side. Not sent on its own — an enum is never sent on its own. inferred Used by AccountCapabilitiesEvent Values ValueNumberMeaning ROLE_UNAVAILABLE0The role is not available. ROLE_PLAYER1An ordinary player. This is what a normal account carries. ROLE_MODERATOR2A moderator. ROLE_GAME_MASTER_PADAWAN3A junior game master. ROLE_GAME_MASTER4A game master. ROLE_ADMIN5An administrator. ROLE_UNKNOWN_SPECIAL_USER6A special account whose precise category is not known. Recovered with score 100, confidence 0.97, 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: 7 of 7.

The rooms of the player's haven bag and the theme on each, sent either as a full list or as an amendment. Kind eventArea Game.Haven.BagNamed by beta, gamemapping The player's haven bag is a private instanced house whose rooms each carry a theme. This event tells you what those rooms are, and it arrives in two quite different forms distinguished by one field. READ action FIRST - IT CHANGES WHAT THE LIST MEANS action = 0 the list is the COMPLETE set of rooms; replace what you hold action = 1 the list is an AMENDMENT; merge it into what you hold On the amending form the real client does not rebuild anything. It walks the incoming entries, finds the room it already holds with the same id, and overwrites only that room's theme; an id it has never seen is appended. Treating an amendment as a full list will silently drop every room the server did not mention. AN EMPTY LIST IS IGNORED, NOT AN INSTRUCTION TO CLEAR. The client does nothing at all when the list is empty, on either form. THE FIELD NUMBERS MOVE BETWEEN BUILDS, AT BOTH LEVELS. This message has carried its two members at 1 and 2, at 2 and 3, and at 2 and 1 across the builds on record, and the room entry's own two members have taken four different number pairs including a straight swap. Read every number off this page rather than from an older schema, and identify the members by meaning. When you may send it Requires character_loaded inferred Related messages Reply not yet recovered: nothing answers this - it is inbound only. The haven-bag requests that can provoke the amending form (changing a room's theme, editing the bag) have no signatures yet, so an update arriving without an obvious cause is expected rather than surprising. Fields #FieldTypeMeaningYou set it 1previewrepeated HavenBagRoomPreviewThe haven bag's rooms, each carrying its identifier and the theme currently applied to it. What this list means depends on the companion selector: it is either the complete set of rooms or an amendment to the set you already hold. An empty list is ignored by the real client rather than treated as "no rooms".never; inbound only 2actionHavenBagRoomActionWhether the accompanying list replaces the rooms you hold or amends them. Zero means replace; the other declared value means merge by room id and overwrite only the theme. The client branches on exactly this, so getting it wrong loses rooms silently. The two values themselves are not recovered yet and keep their generated names.never; inbound only Recovered with score 430, confidence 0.93, margin 430 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 2 of 2.

One room of the player's haven bag: which room it is, and the theme currently applied to it. Kind structArea Game.Haven.BagNamed by beta A room and its theme. Both members are plain integers and they are easy to swap, so the distinction matters: the room is WHICH ROOM, and the theme is WHAT IT LOOKS LIKE. THE ROOM IS THE IDENTITY, THE THEME IS THE PAYLOAD. When the server amends the list rather than resending it, the real client finds the room it already holds with the matching room id and overwrites only that room's theme. Nothing else about the entry is kept. Treat the room id as a key and the theme as the mutable value, and the amending form works; treat them the other way round and every update lands on the wrong room. Both are opaque ids into the client's own data files - the theme id resolves to a haven bag theme, and the room id numbers the rooms of the bag. Neither is a display value. Not sent on its own — it is only ever an element of HavenBagRoomUpdateEvent.preview. inferred Used by HavenBagRoomUpdateEvent Fields #FieldTypeMeaningYou set it 1theme_idint32The theme currently applied to that room. (haven bag theme id) This is the mutable half: it is the only thing an amendment overwrites on a room you already hold.never; inbound only 2room_idint32Which room of the haven bag this entry is about. (room id) This is the key. On the amending form the client matches on it and leaves everything else alone, so an entry whose room id you do not recognise is a new room rather than a correction.never; inbound only Recovered with score 135, confidence 0.92, 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: 2 of 2.

Whether a haven bag room list is the complete set or an amendment to the set you already hold. Kind enumArea Game.Haven.BagNamed by beta Two states, and reading the wrong one loses rooms silently rather than raising an error. DISPATCH means the accompanying list is everything: replace what you hold with it. UPDATE means the list is a delta: keep what you hold, match each entry by room id, and overwrite only that room's theme, appending any room id you have not seen. The real client implements this as a single test against DISPATCH, so anything that is not DISPATCH is treated as UPDATE. Not sent on its own — it is only ever the selector carried by HavenBagRoomUpdateEvent.action. inferred Used by HavenBagRoomUpdateEvent Values ValueNumberMeaning HAVEN_BAG_ROOM_DISPATCH0The list is the complete set of rooms; replace what you hold. HAVEN_BAG_ROOM_UPDATE1The list amends what you hold; match each entry by room id and overwrite only its theme. Recovered with score 120, confidence 0.93, 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: 2 of 2.

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.

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.