Protocole Dofus

ColorPalette

ColorPalette

One set of packed RGB colours applied to a character.
Kind struct · Area Game.Cosmetic
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

• summary: One set of packed RGB colours applied to a character.
• area: Game.Cosmetic

• 77 vues

Smooth

Septembre 15Sep 15

CommunityChannelEvent

CommunityChannelEvent

The community channel the server has actually placed this character on.
Kind event · Area Game.Social
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 No fields you may set.

• summary: The community channel the server has actually placed this character on.
• area: Game.Social

• 61 vues

Smooth

Septembre 15Sep 15

ContextRemoveElementEvent

ContextRemoveElementEvent

One element has left the current context. This is the despawn message.
Kind event · Area Game.Context
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

• summary: One element has left the current context. This is the despawn message.
• area: Game.Context

• 68 vues

Smooth

Septembre 15Sep 15

DialogLeaveEvent

DialogLeaveEvent

Announces that a dialog has closed, and which kind it was. Broadcast, not an acknowledgement.
Kind event · Area Game.Dialog
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 State it changes
Invalidates npc_dialog_open inferred — when its type is DialogType.DIALOG_DIALOG: the NPC dialogue is over, and its replies can no longer be sent Related messages
Arrives after DialogLeaveRequest Fields
#FieldTypeMeaningYou set it 1dialog_typeDialogTypeWhich kind of dialog closed.never

• summary: Announces that a dialog has closed, and which kind it was. Broadcast, not an acknowledgement.
• area: Game.Dialog

• 64 vues

Smooth

Septembre 15Sep 15

DialogType

DialogType

Which kind of dialog a dialog-lifecycle message is talking about.
Kind enum · Area Game.Common
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 ExchangeLeaveEvent 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.

• summary: Which kind of dialog a dialog-lifecycle message is talking about.
• area: Game.Common

• 81 vues

Smooth

Septembre 15Sep 15

Direction

Direction

The eight-way compass facing shared by the map, movement and fight message families.
Kind enum · Area Game.Common
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.

• summary: The eight-way compass facing shared by the map, movement and fight message families.
• area: Game.Common

• 86 vues

Smooth

Septembre 15Sep 15

EmotesEvent

EmotesEvent

The complete list of emotes you know. A replacement, not an addition.
Kind event · Area Game.Emote
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: EmoteAddedEvent adds a single emote and EmoteRemovedEvent 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 1emotes_idrepeated int32Every emote you know, by id.never

• summary: The complete list of emotes you know. A replacement, not an addition.
• area: Game.Emote

• 63 vues

Smooth

Septembre 15Sep 15

EntityDisposition

EntityDisposition

Where an entity stands and which way it faces, optionally naming who is carrying it.
Kind struct · Area Game.Common
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 EntitiesDispositionEvent FightPlacementSwapPositionsEvent Fields
#FieldTypeMeaningYou set it 2entity_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 3cell_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 4directionDirectionThe entity's eight-way facing.
A Direction value.
One dumped build declares a second field of the same enum beside this one.never 5carrying_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

• summary: Where an entity stands and which way it faces, optionally naming who is carrying it.
• area: Game.Common

• 62 vues

Smooth

Septembre 15Sep 15

EntityLook

EntityLook

How to draw an entity: its skeleton, layered art, colour overrides, scale and attached sub-entities.
Kind struct · Area Game.Common
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.
idle_id (from 3.5) picks the idle animation the entity plays when standing still: an id into the game's idle data. 0 means the default idle. The client reads it for nothing else.
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
ActorInformation ChangeLook CharacterInformation ContextRefreshEntityLookEvent IndexedEntityLook MonsterInGroupInformation PartyGuest SubEntityInformation SummonContextInformation Fields
#FieldTypeMeaningYou set it 1bones_idint32Which skeleton animates this entity. (bones id)
The cheapest way to tell one kind of entity from another.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 4idle_idint32The idle animation the entity plays when standing still, as an idle id; 0 means the default idle. (idle id (data-center Idles))
The client looks it up in its idle data (IdleData) and plays that entry's animation; a value of 0 or less keeps the default idle.
Not in the beta protocol; sent from 3.3 on (absent or never copied on 3.2.7.15).never 5indexed_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 6scalesrepeated int32Entity scale as a percentage pair; a single entry means uniform. (percent)never

• summary: How to draw an entity: its skeleton, layered art, colour overrides, scale and attached sub-entities.
• area: Game.Common

• 96 vues

Smooth

Septembre 15Sep 15

ExchangeMoneyMovementLimitEvent

ExchangeMoneyMovementLimitEvent

The ceiling on how much money you may move in one exchange. Sent once, kept for the session.
Kind event · Area Game.Exchange
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

• summary: The ceiling on how much money you may move in one exchange. Sent once, kept for the session.
• area: Game.Exchange

• 66 vues

Smooth

Septembre 15Sep 15

FileCheckEvent

FileCheckEvent

An integrity challenge: the server names a game file and asks the client to measure it.
Kind event · Area Game.Client.Verification
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 1file_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 2check_typeCheckTypeWhich measurement the server wants.
A CheckType value. Echo it back unchanged in the answer.never

• summary: An integrity challenge: the server names a game file and asks the client to measure it.
• area: Game.Client.Verification

• 62 vues

Smooth

Septembre 15Sep 15

GameActionItem

GameActionItem

One captioned group of items inside an action-item announcement.
Kind struct · Area Game.Inventory
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 1itemsrepeated GameActionItemObjectThe items this caption describes.
Element type GameActionItemObject.never 2titlestringThe caption for this group, as a localisation key rather than display text.
Resolve it against the client string table before showing it.never

• summary: One captioned group of items inside an action-item announcement.
• area: Game.Inventory

• 64 vues

Smooth

Septembre 15Sep 15

GameActionItemListEvent

GameActionItemListEvent

Items the server hands the character as the result of an action - a reward, a gift, a craft outcome.
Kind event · Area Game.Inventory
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 GameActionItemObject, 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 GameActionItemObject 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.

• summary: Items the server hands the character as the result of an action - a reward, a gift, a craft outcome.
• area: Game.Inventory

• 64 vues

Smooth

Septembre 15Sep 15

GameRolePlayShowActorsEvent

GameRolePlayShowActorsEvent

One or more actors have become visible on the current map.
Kind event · Area Game.Roleplay
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.
READ ONLY actors. 3.7 builds declare a second list of the same type beside it; the reference build does not, and no client code reads it. It is padding: never take actors from it.
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

• summary: One or more actors have become visible on the current map.
• area: Game.Roleplay

• 67 vues

Smooth

Septembre 15Sep 15

Gender

Gender

A character's gender: MALE or FEMALE.
Kind enum · Area Game.Common
The gender of a character. You send it in CharacterRemodelingInformation when you create or remodel a character; the server sends it back in CharacterBaseInformation and in the actor, fighter and party records that describe a character.
HOW TO USE IT
1. To create a female character, send FEMALE. For a male one, send MALE. 2. When you read a character, pick every gendered piece of game data with it. FEMALE takes the title's female name (TitleData.nameFemaleId) and the class's female look and colours (BreedData.femaleLook, femaleColors). MALE takes the male ones. 3. Read it as a yes/no. The client tests for FEMALE and shows anything else as male.
Each class has exactly two portraits, Head_<class id>0 and Head_<class id>1. For the original twelve classes the male look uses skin <class id>0 and the female look <class id>1. To build a portrait name, append 0 for a male and 1 for a female character (the client's own gender numbers, which today equal the wire values).
Not sent on its own — an enum is never sent on its own. inferred
Used by
CharacterBaseInformation CharacterRemodelingInformation FightCharacterInformation Humanoid PartyGuest SocialMember Values
ValueNumberMeaning MALE0A male character.
The client shows the male title names (TitleData.nameMaleId). Character creation sends it for the class's male look (BreedData.maleLook). FEMALE1A female character.
The client converts it to its own EntityGender.Female and shows the female title names (TitleData.nameFemaleId). Character creation sends it for the class's female look (BreedData.femaleLook).

• summary: A character's gender: MALE or FEMALE.
• area: Game.Common

• 65 vues

Smooth

Septembre 15Sep 15

GuildWeeklyNextResetResponse

GuildWeeklyNextResetResponse

When the guild's current mission week ends, as a text date.
Kind response · Area Game.Guild
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.
Name ours: no build names this field (the type-name table names types only).never

• summary: When the guild's current mission week ends, as a text date.
• area: Game.Guild

• 81 vues

Smooth

Septembre 15Sep 15

HaapiAuthenticationErrorEvent

HaapiAuthenticationErrorEvent

Authentication against Ankama's web platform failed. The message carries no payload.
Kind event · Area Game.Haapi
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 No fields you may set.

• summary: Authentication against Ankama's web platform failed. The message carries no payload.
• area: Game.Haapi

• 62 vues

Smooth

Septembre 15Sep 15

HaapiSessionEvent

HaapiSessionEvent

The session identifier for Ankama's account and authentication web platform.
Kind event · Area Game.Haapi
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.
Name ours: no build names this field (the type-name table names types only).never

• summary: The session identifier for Ankama's account and authentication web platform.
• area: Game.Haapi

• 59 vues

Smooth

Septembre 15Sep 15

HavenBagRoomAction

HavenBagRoomAction

Whether a haven bag room list is the complete set or an amendment to the set you already hold.
Kind enum · Area Game.Haven.Bag
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.

• summary: Whether a haven bag room list is the complete set or an amendment to the set you already hold.
• area: Game.Haven.Bag

• 62 vues

Smooth

Septembre 15Sep 15

HavenBagRoomPreview

HavenBagRoomPreview

One room of the player's haven bag: which room it is, and the theme currently applied to it.
Kind struct · Area Game.Haven.Bag
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 1room_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 2theme_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

• summary: One room of the player's haven bag: which room it is, and the theme currently applied to it.
• area: Game.Haven.Bag

• 63 vues

Smooth

Septembre 15Sep 15

HavenBagRoomUpdateEvent

HavenBagRoomUpdateEvent

The rooms of the player's haven bag and the theme on each, sent either as a full list or as an amendment.
Kind event · Area Game.Haven.Bag
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.
ANY OTHER MEMBER IS PADDING. From 3.7 the message also declares an eight-value enum that no client code reads (the client never loads it, never calls its getter and never uses its enum type): ignore it, and leave it at its default if you build this message yourself.
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 1actionHavenBagRoomActionWhether 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 3previewrepeated 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

• summary: The rooms of the player's haven bag and the theme on each, sent either as a full list or as an amendment.
• area: Game.Haven.Bag

• 67 vues

Smooth

Septembre 15Sep 15

Hierarchy

Hierarchy

The account's role in the staff hierarchy, from ordinary player up to administrator.
Kind enum · Area Game.Account
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 Humanoid 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.

• summary: The account's role in the staff hierarchy, from ordinary player up to administrator.
• area: Game.Account

• 63 vues

Smooth

Septembre 15Sep 15

InformationType

InformationType

Which section of guild data a request is asking for. Three of its six values were renumbered in Dofus 3.
Kind enum · Area Game.Guild
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 INFO_GENERAL0Name, level, emblem, experience and the headline counters on the guild window's front tab. INFO_MEMBERS1The guild's member list. INFO_BOOSTS2Guild boosts - the spent and available boost points.
Forced rather than directly proven: no named UI constant reaches this value. INFO_HOUSES3Guild houses.
WAS 4 IN THE REFERENCE BUILD; it is 3 here. INFO_RECRUITMENT4Guild recruitment settings.
WAS 5 IN THE REFERENCE BUILD; it is 4 here. INFO_LOGBOOK5The guild logbook.
WAS 6 IN THE REFERENCE BUILD; it is 5 here.
Forced rather than directly proven, like BOOSTS.

• summary: Which section of guild data a request is asking for. Three of its six values were renumbered in Dofus 3.
• area: Game.Guild

• 70 vues

Smooth

Septembre 15Sep 15

InteractiveElement

InteractiveElement

One interactive map object - a resource node, door, zaap or workshop machine - and the actions it currently offers.
Kind struct · Area Game.Common
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 2on_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 3disabled_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 4element_type_idint32What kind of element this is, resolved against the client's interactives data. (interactive type 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 6element_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

• summary: One interactive map object - a resource node, door, zaap or workshop machine - and the actions it currently offers.
• area: Game.Common

• 74 vues

Smooth

Septembre 15Sep 15

InteractiveElementSkill

InteractiveElementSkill

One action an interactive element offers: the harvest gesture on a field, open on a door, use on a zaap.
Kind struct · Area Game.Common
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 1skill_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 2name_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 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

• summary: One action an interactive element offers: the harvest gesture on a field, open on a door, use on a zaap.
• area: Game.Common

• 65 vues

Smooth

Septembre 15Sep 15