Smooth

Your NPC action was refused. It carries no reason. Kind eventArea Game.NpcNamed by gamemapping THE NEGATIVE ANSWER TO NpcGenericActionRequest, AND IT IS EMPTY. It tells you THAT the action was refused and never why. There is no code, no reason string and no echo of what you asked for - so if you have more than one NPC action outstanding you cannot tell which one this refers to. SEND THEM ONE AT A TIME and treat this as the answer to the outstanding request. WHY IT MATTERS THAT IT IS EMPTY The success path does not answer this message at all: it answers with the action itself - a dialogue's own messages, a shop's own messages. So this event is your ONLY negative signal. Without it a refused action is indistinguishable from a slow one, which is why you should arm a timeout on the request and treat this event as the early, definitive failure. Common causes, none of them reported: the NPC is not on your current map, the action is not one that NPC offers, or the map id you sent is stale. When you may send it Requires character_loaded inferred Related messages Arrives after NpcGenericActionRequest 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: 0 of 0.

The player's complete set of notification flags - the markers behind the interface's "new" badges. Kind eventArea Game.NotificationNamed by beta, gamemapping The persisted markers behind the little "new" badges on menus, tabs and features. IT IS THE COMPLETE SET, NOT AN ADDITION - REPLACE, DO NOT MERGE. A flag missing from this message is a flag the player no longer has. There is a separate canonical sibling that REMOVES notifications and it carries an identical payload shape, so if you are matching messages by shape rather than by type you will confuse the two and accumulate badges forever. The flag values are opaque identifiers into the client's own notification data; the protocol says nothing about what each one means. Low value for most scripts - it drives interface decoration, and nothing depends on it. When you may send it Requires character_loaded observed Related messages Unsolicited - nothing you send causes this sent in the connection burst and again whenever the server resynchronises the whole set Fields #FieldTypeMeaningYou set it 1flagsrepeated int32The player's complete set of notification flags. Opaque identifiers into the client's notification data. COMPLETE, not additive.never Recovered with score 265, confidence 0.91, 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 2.

Why a character name was refused. Kind enumArea Game.Character.ManagementNamed by beta WHY THE NAME WAS REFUSED, when CharacterCreationResult says the name was the problem. NAME_OK means the name itself is fine - so seeing it here does NOT mean the creation succeeded; read the result first and only consult this when the result blames the name. Most of these are client-checkable before you ever send: length, alphabet, forbidden characters, dash placement, capitalisation, runs of identical letters. Checking locally saves a round trip. Two are not checkable and must come from the server - the name is already taken, and the name is reserved - and one, SERVICE_UNAVAILABLE, means name validation itself is down and the same name may work later. Not sent on its own — it is a member type of CharacterCreationResultEvent, never sent alone. proven Used by CharacterCreationResultEvent Values ValueNumberMeaning NAME_OK0The name is acceptable. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_SERVICE_UNAVAILABLE1Name checking is down; the server could not validate it. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_ALREADY_EXISTS2Another character already has this name. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_BAD_ALPHABET3The name uses characters from a disallowed alphabet. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_BAD_LENGTH4The name is too short or too long. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_BAD_CHAR5The name contains a character that is not allowed. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_INVALID_DASH_POSITION6A dash is in a position the rules forbid - leading, trailing or doubled. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_NAME_WITH_BAD_CASE7The name's capitalisation is wrong. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_TOO_MANY_CONSECUTIVE_IDENTICAL8Too many identical characters in a row. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_TOO_MANY_SPECIAL9Too many special characters. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_FORBIDDEN10The name is on the forbidden list. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. NAME_ERROR_RESERVED11The name is reserved and cannot be taken. The name is the reference build's, matched by NUMBER. Beta 2.73.7.7 and every dumped build from 3.2.7.15 to 3.6.10.11 declare exactly twelve values, so the set has not moved in four years - but no dumped client distinguishes one value from another, so only the NUMBER is proven here. Recovered with score 235, confidence 0.85, 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: 12 of 12.

One monster inside a group: what it is, its grade, an optional level override, and its appearance. Kind structArea Game.CommonNamed by beta The compact per-monster entry inside a monster group - the record a script reads to decide whether a group on the map is worth fighting. grade IS ONE-BASED. The client subtracts one before indexing its grade list, so grade 1 is the first grade, not the second. Off-by-one here silently reads the wrong difficulty. level IS AN OVERRIDE, NOT ALWAYS THE LEVEL. The client tests it for a positive value and only then uses it in its experience calculation; a non-positive value means "use the monster's own level from the data centre" rather than "level zero". gid identifies WHAT the monster is; resolve it against your own monster data. look is a full EntityLook. Not sent on its own — it is only ever an element of a monster-group payload. inferred Fields #FieldTypeMeaningYou set it 1gradeint32The monster's grade. ONE-BASED. The client subtracts one before indexing its grade list.never 2gidint32Which monster this is. (monster id)never 3levelint32A level override for this monster. Only used when positive; otherwise the monster's own level applies.never 4lookEntityLookThe monster's appearance. An EntityLook.never Recovered with score 190, confidence 0.96, margin 190 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 4 of 4.

A creature family together with a count, as the monster-count branch of an item effect. Kind structArea Game.InventoryNamed by beta Two integers: which creature family, and how many. It is easy to confuse with ObjectEffectMinMaxValue - both are two-integer messages in the same oneof - so branch on which member of ObjectEffect is set rather than on shape. Not sent on its own — it is only ever the monster_count branch of ObjectEffect. inferred Used by ObjectEffect Fields #FieldTypeMeaningYou set it 1countint32How many.never 2creature_familyint32Which creature family the count applies to. (creature family id)never Recovered with score 140, confidence 0.97, margin 140 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 2 of 2.

The structured links attached to a chat line - items and monster groups - as opposed to the line's words. Kind structArea Game.ChatNamed by gamemapping What rides ALONGSIDE a chat line's text. When a player shift-clicks an item or a monster group into chat, the visible words stay in the message's content and the structured link data comes here, so the recipient's client can render the link and show a tooltip on hover. It is referenced by the four chat messages that can carry a link, and it is normally PRESENT BUT EMPTY - an ordinary text line still carries the carrier. Treat an empty one as the common case, not as an anomaly. Its members are not individually recovered and stand with their obfuscated names. If you only need the words, read content and ignore this. Not sent on its own — it is only ever carried by a chat message. proven Used by ChatChannelMessageEvent ChatChannelMessageRequest ChatPrivateMessageRequest No fields you may set. Recovered with score 155, confidence 0.90, 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: 0 of 3.

The path an actor will actually walk, broadcast to everyone on the map. Kind eventArea Game.GamemapNamed by beta, gamemapping The server granting a movement. THIS IS THE AUTHORITATIVE PATH - walk cells, not what you requested. It may be shorter. CHECK character_id AGAINST YOUR OWN BEFORE ACTING ON IT. The event is broadcast for every actor that moves on the map, so most of the ones you receive are other players and monsters. A script that treats every arrival as its own move will walk phantom paths. For an actor that is not you, this is how you keep a live world model: apply the path to that actor's position and facing. When the granted path is YOURS and you have finished walking it, close the handshake with MapMovementConfirmRequest. Until you do, the server considers you still in motion. direction is the facing the walk starts in, as a Direction ordinal. It is the only member of this message with explicit presence on the wire, so absent and zero are genuinely different: absent means unchanged, zero means east. When you may send it Requires context_ready inferred Related messages You must then send MapMovementConfirmRequest inferred — the movement handshake stays open until the client reports that the walk finished Arrives after MapMovementRequest Fields #FieldTypeMeaningYou set it 2cellsrepeated int32The authoritative path the actor will walk, as ordered map cell ids. (map cell ids) May be shorter than the path that was requested. Walk this one.never 3character_idint64Which actor is moving. (actor id) Broadcast for other actors too - compare against your own id first.never 4directionint32The facing the walk starts in. Explicit presence: absent is not the same as zero. A Direction ordinal. Absent means unchanged; 0 means east. Do not conflate them.never 5cautiousboolWhether the actor is walking in cautious mode.never Recovered with score 210, confidence 0.87, 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: 4 of 5.

The server agreeing that the character has stopped moving. Closes the movement handshake. Kind responseArea Game.GamemapNamed by gamemapping Acknowledges MapMovementConfirmRequest. Receiving it means the server has you standing still. READ ITS PAYLOAD DEFENSIVELY. It was empty from the earliest dumped build through to the mid-3.4 ones; the current build declares a six-value enum. Unlike its request - where the client's own writer provably populates nothing - an INBOUND message offers no such proof, so whether that enum is a decoy or a genuine status has NOT been established. Do not assume it is always zero, and do not build logic on a specific value. This is one of the few genuine Responses in the map area: the whole Gamemap file declares thirty-one messages and exactly one of them is a Response, which is a large part of why the identification holds. When you may send it Requires context_ready inferred Related messages Arrives after MapMovementConfirmRequest Recovered with score 210, confidence 0.83, 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.

Everything on the map the character just loaded: actors, interactive and stated elements, running fights and the map's complement. Kind eventArea Game.GamemapNamed by beta, gamemapping The contents of the map the character is on: who stands on it, its interactive and stated elements, the fights running on it, and one complement saying what kind of place it is. IT ARRIVES AFTER EVERY MAP LOAD. The client asks for it with MapInformationRequest each time a map finishes loading - teleport, zaap, map change, fight exit - and the map is not usable until it arrives. TREAT IT AS A SNAPSHOT OF THE NEW MAP. It replaces what you knew about the previous one. Changes after that arrive separately: actors who walk in through GameRolePlayShowActorsEvent, element changes through InteractiveElementUpdatedEvent and StatedElementUpdatedEvent. THE CLIENT REPUBLISHES TWO OF ITS LISTS. It copies interactive_elements into an InteractiveMapUpdateEvent and stated_elements into a StatedMapUpdateEvent, so code that already handles those two events can reuse that path for the initial state. map_id IS AN INT64 HERE while MapInformationRequest asks with an int32: same map, different width. specific_complementary_information carries at most one complement saying what kind of place the map is: a haven bag (with its owner), the house you are inside, the map's world coordinates, an open anomaly, or your guild hall. SOME NAMES ARE CONDITIONAL. houses, in_house_information, anomaly_information, coordinates, guild_hall_information and colored_cells are named only while the client code that proves them can be traced; on a client where it cannot, those members keep obfuscated names while the rest of the message is still recovered. guild_hall_information and colored_cells are invented names - no Ankama dump names those two fields. STILL OBFUSCATED ON PURPOSE: the obstacles list (the client hands each obstacle to its cell service through an interface the dumps cannot follow) and a boolean the client never reads. They carry real data; their names cannot be proven. When you may send it Requires context_ready inferred Related messages Arrives after MapInformationRequest Fields #FieldTypeMeaningYou set it 2housesrepeated type not documented yetThe houses standing on this map. Element type is House, not yet recovered; each entry becomes the client's house object, including its door cells on this map. Named only while the client's house UI can be traced; otherwise left obfuscated.never 5colored_cellsrepeated type not documented yetCells of this map the client paints in a colour. NAME INVENTED - no dump names this field. The client's type table calls the element type ColoredCell, with a nested CellColor. Each entry pairs a cell id with a colour the client turns into an RGBA Color32.never 6map_idint64The map these contents describe. (map id) Observed: 153879299 The same map MapInformationRequest asked for, carried here as int64. The client checks it against the haven-bag map table.never 7subarea_idint32The subarea the map belongs to. (subarea id) Observed: 450 The client looks it up in the subarea table, for example for the area level shown with an anomaly.never 8interactive_elementsrepeated InteractiveElementEvery interactive element on the map, with the skills it offers now. Element type InteractiveElement. The client republishes this list as an InteractiveMapUpdateEvent.never 9actorsrepeated ActorPositionInformationEvery actor already standing on the map when it loads. Element type ActorPositionInformation. Actors who arrive later come through GameRolePlayShowActorsEvent instead.never 11fightsrepeated type not documented yetThe fights currently running on the map. Element type is FightCommonInformation, not yet recovered. The client creates a map fight entry per element and lists party members' fights from it.never 15stated_elementsrepeated StatedElementThe current state of every stated element on the map. Element type StatedElement. The client republishes this list as a StatedMapUpdateEvent.never 1coordinatestype not documented yetSet when the server sends the map's world coordinates. The client stores both coordinates with the map id as the current map position. One of the complement branches; named only while the map renderer can be traced.never 3anomaly_informationtype not documented yetSet when the map belongs to an open anomaly. Carries the anomaly's closing time; the client shows the anomaly panel with the subarea's level. One of the complement branches; named only while the client's anomaly UI can be traced.never 4guild_hall_informationtype not documented yetSet when the map is the player's guild hall. NAME INVENTED - no dump names this field. The client's type table calls its theme part MyGuildHall.ThemeSelectionInfo. The client reads the hall's current theme and the themes available to it. One of the complement branches; named only while the client's guild-hall UI can be traced.never 13in_house_informationtype not documented yetSet when the character is inside a house: the house being visited. The client compares the house's account tag with the player's to tell whether it is the player's own house, then opens the house panel. One of the complement branches; named only while the client's house UI can be traced.never 14haven_bag_informationtype not documented yetSet when the map is a haven bag; names the haven bag's owner. The owner is a Character; the client reads the owner's id and name. One of the complement branches; at most one is set.never Recovered with score 448, confidence 0.92, margin 448 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: 13 of 15.

An actor on the current map has turned to face a new direction. Kind eventArea Game.GamemapNamed by beta, gamemapping Broadcast whenever any actor in your current roleplay context changes orientation - including your own character, echoing back your MapChangeOrientationRequest. IT IS A FIRE-AND-FORGET STATE PATCH. No timestamp, no throttling, no correlation. Apply it straight to your entity table: set that actor's facing and move on. There is nothing to acknowledge. Track other actors' facing if you care about line of sight or backstab positioning - that is the whole reason this is broadcast rather than private. The client reads exactly two members off it and passes both, unchanged, into a single call on its own entity service. Nothing else in the message is used. When you may send it Requires context_ready inferred Related messages Arrives after MapChangeOrientationRequest Fields #FieldTypeMeaningYou set it 1directionDirectionThe facing the actor now has. A Direction value.never 2actor_idint64Which actor turned. (actor id) Includes your own character when the server echoes your request back.never Recovered with score 155, confidence 0.94, 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: 2 of 2.

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.