Aller au contenu
Afficher dans l'application

Une meilleure façon de naviguer. En savoir plus.

Asterobot

Une application plein écran sur votre écran d'accueil avec notifications push, badges et plus encore.

Pour installer cette application sur iOS et iPadOS
  1. Appuyez sur Icône de partage dans Safari
  2. Faites défiler le menu et appuyez sur Ajouter à l'écran d'accueil.
  3. Appuyez sur Ajouter dans le coin supérieur droit.
Pour installer cette application sur Android
  1. Appuyez sur le menu à trois points (⋮) dans le coin supérieur droit du navigateur.
  2. Appuyez sur Ajouter à l'écran d'accueil ou Installer l'application.
  3. Confirmez en appuyant sur Installer.

Protocole Dofus

Le protocole Dofus actuellement pris en charge par Asterobot
One item as it sits in the inventory: the item itself, where it is, whether it is a favourite and, up to 3.6.12.16, how the player tagged it.
Kind struct · Area Game.Inventory
The element type of InventoryContentEvent.objects. It wraps an ObjectItem with the three things that are true of the item HERE rather than of the item in general.
position IS NOT A BAG INDEX. It is the equipment slot when the item is worn, and a bag marker otherwise. Do not treat it as an ordinal you can iterate: two unequipped items can carry the same position, and the value only becomes meaningful once you know whether the item is equipped.
tag_storage_uuids is the player's own tagging, not a server concept. It is a set of opaque strings; compare them, do not parse them. From 3.7.1.0 the member is gone: tags became client-only filtered boxes (by item type) saved in the client's local options, so nothing on the wire replaces it.
Not sent on its own — it is only ever reached as an element of InventoryContentEvent.objects. proven
Used by
ExchangeObjectsAddedEvent InventoryContentEvent ObjectAddedEvent ObjectsAddedEvent StorageInventoryContentEvent StorageObjectUpdateEvent Fields
#FieldTypeMeaningYou set it 1itemObjectItemThe item itself.
The current build declares this type twice in the record and only this copy is ever populated.never 3favoriteboolWhether the player marked this item as a favourite.never 4positionint32The equipment slot when the item is worn, and a bag marker otherwise.
Not an inventory ordinal. Unequipped items share values.never
  • summary: One item as it sits in the inventory: the item itself, where it is, whether it is a favourite and, up to 3.6.12.16, how the player tagged it.
  • area: Game.Inventory
  • 72 vues
Why an inventory stack changed; the client only acts on the quest origin.
Kind enum · Area Game.Common
The origin carried by ObjectQuantityEvent (and by the item-added event).
WHAT THE CLIENT DOES WITH IT. Exactly one thing: when the origin is ORIGIN_QUEST it announces the gained amount in chat. Every other value - ORIGIN_UNDEFINED and the two unnamed ones - is treated identically: the inventory is updated silently.
TWO VALUES HAVE NO NAME. The protocol has grown: two values in the reference build, a third by 3.2, a fourth by 3.4. No dumped client, string table, type table or descriptor names the two newer ones, so they keep their obfuscated names. If you meet one, treat it like ORIGIN_UNDEFINED; that is what the client does.
ORIGIN_UNDEFINED is the default: an update whose origin is absent from the wire arrives as this value.
Not sent on its own — an enum is never sent on its own. inferred
Used by
ObjectAddedEvent ObjectQuantityEvent Values
ValueNumberMeaning ORIGIN_UNDEFINED0No particular origin; the client updates the inventory silently.
Named from beta's numbering, not client behaviour. It is the default when the origin is absent. ORIGIN_QUEST1The stack changed because of a quest; the client announces the gained amount in chat.
  • summary: Why an inventory stack changed; the client only acts on the quest origin.
  • area: Game.Common
  • 60 vues
The new quantity of one stack you already hold, and where the change came from.
Kind event · Area Game.Inventory
The singular form of ObjectsQuantityEvent: one stack, its new quantity, and an origin.
THE QUANTITY IS THE NEW TOTAL, NOT A DELTA. The client looks the stack up by ObjectUidWithQuantity.object_uid and SETS its size to ObjectUidWithQuantity.quantity. If you want "how many did I just get", subtract what you held before - which is exactly what the client does for its quest message.
IT NEVER INTRODUCES A STACK. It updates one you already hold; an unknown uid means you missed an earlier add.
THE ORIGIN SAYS WHY. When it is ObjectOrigin.ORIGIN_QUEST and the stack grew, the client also posts the "item obtained" chat line with the gained amount. With any other origin the update is silent.
TWO DECLARED MEMBERS ARE PADDING the client never reads.
When you may send it
Requires character_selected inferred Related messages
Unsolicited - nothing you send causes this the server pushes it whenever one stack's size changes; no request asks for it Fields
#FieldTypeMeaningYou set it 1originObjectOriginWhy the quantity changed.
ObjectOrigin.ORIGIN_QUEST makes the client announce the gained amount in chat; other values change nothing visible.never 3objectObjectUidWithQuantityThe stack being updated and its new quantity.
An ObjectUidWithQuantity whose quantity is the stack's NEW TOTAL, not a delta.never
  • summary: The new quantity of one stack you already hold, and where the change came from.
  • area: Game.Inventory
  • 72 vues
Which of the character's storages a per-item count belongs to: bag, bank, or haven bag.
Kind enum · Area Game.Common
This name is not Ankama's. It was chosen for this documentation from proven client behaviour, and is a label rather than protocol documentation.
THE TYPE NAME AND ALL FOUR VALUE NAMES ARE OURS. Nothing here is attested by any naming oracle. THE NUMBERS ARE THE REAL CONTRACT and are what this signature pins; the labels are descriptions of what each number provably does.
Each value was proven by following the count into the tooltip slot the client renders it in, so the meanings are solid even though the spellings are not.
Switch on this, never on position. An unrecognised value should be ignored the way the client ignores the unspecified one, not folded into a default bucket.
Not sent on its own — an enum is never sent on its own. inferred
Used by
InventoryQuantity InventoryUpdateMergedInventoryTypeRequest Values
ValueNumberMeaning STORAGE_UNSPECIFIED0The proto3 zero value. The client assigns nothing for it and the entry is silently dropped.
WE CHOSE THIS NAME. STORAGE_INVENTORY1The character's own bag.
WE CHOSE THIS NAME. Proven: this count feeds the tooltip slot captioned 'ui.item.inventoryQuantity'. STORAGE_BANK2The account bank.
WE CHOSE THIS NAME. Proven: this count feeds the slot captioned 'ui.item.bankQuantity'. STORAGE_HAVEN_BAG3The haven bag's storage.
WE CHOSE THIS NAME. Proven: this count feeds the slot captioned 'ui.item.havenBagQuantity'.
  • summary: Which of the character's storages a per-item count belongs to: bag, bank, or haven bag.
  • area: Game.Common
  • 59 vues
A quantity of one item stack, addressed by its unique handle. Reused wherever the protocol acts on part of a stack.
Kind struct · Area Game.Common
Names a stack and an amount. Ankama reuses this one record across the inventory protocol - destroying, dropping, and the server's own quantity-changed event all wrap it - so the record itself carries no intent. THE MEANING IS ENTIRELY IN THE MESSAGE THAT CONTAINS IT. See ObjectDeleteRequest for the destructive one.
The uid is ObjectItem.uid, the per-stack handle - never the template gid.
The two members are proven to exist and carry these roles, but this signature does not yet name them individually, so they stand with their obfuscated names. Match them by reading the stack you are acting on out of InventoryContentEvent first.
Not sent on its own — it is only ever reached as the payload of a request or event. proven
Used by
ObjectDeleteRequest ObjectQuantityEvent ObjectsQuantityEvent Fields
#FieldTypeMeaningYou set it 1quantityint32How many units of that stack the record applies to.
On a request this is how many units to act on; on a quantity event it is the stack's new total.required 3object_uidint32Unique id of the stack this record is about.
Identifies one existing stack in the inventory, not the item template. The client uses it as the lookup key when applying the record.required
  • summary: A quantity of one item stack, addressed by its unique handle. Reused wherever the protocol acts on part of a stack.
  • area: Game.Common
  • 71 vues
New absolute quantities for stacks the character already holds, several at once.
Kind event · Area Game.Inventory
Quantity updates for stacks that are ALREADY in your inventory, batched.
EACH ENTRY IS AN ABSOLUTE TOTAL, NOT A DELTA. The client looks the stack up by ObjectUidWithQuantity.object_uid and SETS its size to ObjectUidWithQuantity.quantity; it never adds. Treating it as a delta double-counts every update.
THIS MESSAGE NEVER INTRODUCES A STACK. If the uid is not already known the client logs an error and drops the entry -- so a uid you have not seen means you missed an earlier add, not that a new item appeared. Recover by asking for a fresh snapshot rather than inventing the stack.
A quantity of zero is a real value here; the stack is emptied but the server still announces removal separately.
The singular counterpart carries one entry plus an origin; this one is the bulk form and carries no origin at all.
When you may send it
Requires character_selected inferred Related messages
Unsolicited - nothing you send causes this the server pushes it whenever stack sizes change; no request asks for it Fields
#FieldTypeMeaningYou set it 1objectrepeated ObjectUidWithQuantityThe (uid, new quantity) pairs being applied.
Ankama names it in the singular although it is repeated.
Each element is an ObjectUidWithQuantity whose quantity is the stack's NEW TOTAL.never
  • summary: New absolute quantities for stacks the character already holds, several at once.
  • area: Game.Inventory
  • 64 vues
The set of optional features the server has enabled, replacing any held set.
Kind event · Area Game.Connection
Pushed in the burst after a successful IdentificationRequest.
THIS REPLACES, IT DOES NOT MERGE. The client swaps its whole enabled-feature set for this list and re-evaluates what is available; keeping stale ids from an earlier connection would enable features the server has since turned off.
When you may send it
Requires authenticated observed Related messages
Arrives after IdentificationRequest Fields
#FieldTypeMeaningYou set it 1featuresrepeated int32Identifiers of the optional features currently enabled. (feature id)never
  • summary: The set of optional features the server has enabled, replacing any held set.
  • area: Game.Connection
  • 61 vues
Somebody's availability changed - a contact's, or your own echoed back.
Kind event · Area Game.Social
Broadcast for any player whose status you can see - friends, guild and alliance members, party members - and for your own character, as the echo of PlayerStatusUpdateRequest.
TWO IDS, AND THEY ARE DIFFERENT WIDTHS. player_id is the CHARACTER (int64); account_id is the ACCOUNT behind it (int32). Use the account id to track a person across their characters and the player id to address one character. The differing widths are the only thing separating them on the wire.
status carries the state and the player's own free text, which is untrusted input - see CharacterStatus.message.
When you may send it
Requires character_loaded observed Related messages
Arrives after PlayerStatusUpdateRequest Fields
#FieldTypeMeaningYou set it 1account_idint32The account behind that character. (account id)
32-bit, where the character id is 64-bit - that width difference is what separates them.never 2statusCharacterStatusThe new availability state plus its optional free text.
A CharacterStatus. Its message is untrusted player text.never 3player_idint64The character whose status changed. (character id)never
  • summary: Somebody's availability changed - a contact's, or your own echoed back.
  • area: Game.Social
  • 61 vues
Server reply to a ping; the client turns it into a round-trip latency sample.
Kind event · Area Game.Connection
Answers PingRequest. On receipt the real client takes the clock again, enqueues the round-trip delta into a bounded sample queue, and exposes average, maximum and sample count from it.
THOSE SAMPLES ARE NOT SELF-CONTAINED. They are the source of the value reported when the server polls with BasicLatencyStatsEvent, so skipping the ping exchange leaves you with nothing honest to report in BasicLatencyStatsRequest - a self-reported number the server can compare against how long you actually took to answer.
Nothing else consumes this exchange, and no protocol decision depends on it. Two of its declared members are never read by any dumped build.
When you may send it
Requires authenticated observed Related messages
Arrives after PingRequest Fields
#FieldTypeMeaningYou set it 1quietboolThe quiet flag echoed back from the originating request.never; inbound only
  • summary: Server reply to a ping; the client turns it into a round-trip latency sample.
  • area: Game.Connection
  • 71 vues
A moderator's warning: who sent it and what it says, shown to the player.
Kind event · Area Game.Moderation
A MODERATOR IS TALKING TO YOU. The server pushes this unprompted and the client renders the moderator's name and their message.
If you are running anything automated, this arriving means a human has looked at your account and acted. Treat it as a stop signal, not as chat.
WHAT IT CARRIES
author the moderator's displayed name content the warning text itself lock_duration an int32 NO CLIENT READS - see below
DO NOT BUILD ANYTHING ON lock_duration. The name is Ankama's, but it is carried across from the reference build by elimination: it is the message's only int32 there and its only int32 here. NO DUMPED CLIENT READS IT - not this build, not any 3.x build, and not the unobfuscated reference build either, whose five handlers touch author_ and content_ and nothing else. Whatever the server puts in it, the game ignores it, so a value of zero is entirely normal and no client behaviour depends on it. It is named because the name is real, not because the field does anything observable.
WHAT THE CLIENT ACTUALLY DOES
It reads the two strings and hands them to the popup service. That is all.
WHAT FOLLOWS
The family completes with an acknowledgement round trip, and this part IS verified in the dumps: the client builds and sends a close request when the popup is dismissed, and consumes a closed event in return. On 3.2.7.15 both were empty; by 3.6.10.10 the close request carries a four-value enum - presumably how the popup was dismissed - while the closed event is still empty. Neither is recovered yet.
So the server can tell whether the warning was actually seen and closed. Failing to acknowledge is itself a signal.
When you may send it
Requires character_loaded inferred Related messages
Unsolicited - nothing you send causes this no client code builds it; it is pushed by the server Fields
#FieldTypeMeaningYou set it 2lock_durationint32An int32 no dumped client reads. Name carried from the reference build.
NOT VERIFIED AT RUNTIME. The name is the reference build's and is assigned by type-elimination - one int32 there, one int32 here. No client in any dumped build reads this member, including the unobfuscated reference build, so nothing confirms it is a duration or that it has any effect. Expect zero and do not depend on it.never 3authorstringThe moderator's displayed name.never 4contentstringThe warning text shown to the player.never
  • summary: A moderator's warning: who sent it and what it says, shown to the player.
  • area: Game.Moderation
  • 63 vues
One quest the character has under way, with the detail of the step it is currently on.
Kind struct · Area Game.Quest
One quest under way: which quest (QuestActive.quest_id) and the step it is on, with that step's objectives (QuestActive.details, a Details).
A shared carrier, not a message anyone sends: the journal (QuestsEvent) embeds a list of these, and QuestStepInformationEvent embeds exactly one when the client asks for a single quest's step.
HOW TO USE IT. Key it by quest id. Each one you receive is the CURRENT state of that quest: replace the step and the objectives you held for it, do not merge. The quest id alone tells you nothing about progress - the step and objectives live in the details.
Several builds declare a SECOND int32 or a SECOND message member beside the real ones. A member is named when it is the only one of its shape, or the only one of its shape the client reads; where neither holds it stands obfuscated rather than being guessed at from position.
Not sent on its own — it is embedded in the quest journal and in QuestStepInformationEvent. inferred
Used by
QuestStepInformationEvent QuestsEvent QuestsFollowedEvent Fields
#FieldTypeMeaningYou set it 1quest_idint32Which quest is under way. (quest id)never 3detailsDetailsThe step the quest is currently on, and its objectives.never
  • summary: One quest the character has under way, with the detail of the step it is currently on.
  • area: Game.Quest
  • 69 vues
The current step of one quest and its objectives.
Kind event · Area Game.Quest
The answer to QuestStepInformationRequest. The real content is information - a QuestActive carrying the quest and the step it is on.
player_id is USUALLY ABSENT, because the answer goes to the character who asked. Do not require it to be present, and do not use it as the key to match the reply against your request - use the quest id inside information.
When you may send it
Requires character_loaded observed Related messages
Arrives after QuestStepInformationRequest Fields
#FieldTypeMeaningYou set it 1informationQuestActiveThe quest and the step it is currently on.
A QuestActive. This is the actual answer.never
  • summary: The current step of one quest and its objectives.
  • area: Game.Quest
  • 63 vues
Your position in the login queue while the server is full.
Kind event · Area Game.Character.Management
Arrives repeatedly while the account waits in the login queue, and stops once you are through. In a capture of an uncongested sign-in it still appears a few times in quick succession with a shrinking payload.
WAIT, DO NOT RETRY. Receiving this means the server has your connection and is holding it; re-sending CharacterListRequest or reconnecting only puts you back at the end.
When you may send it
Requires authenticated observed Related messages
Unsolicited - nothing you send causes this the server pushes queue progress on its own; nothing you send asks for it Fields
#FieldTypeMeaningYou set it 1positionint32Your place in the queue.never 2totalint32How many accounts are queued in total.never
  • summary: Your position in the login queue while the server is full.
  • area: Game.Character.Management
  • 61 vues
Grants or refuses the token that skips full authentication on the next connection. Check the flag before the token.
Kind event · Area Game.Connection
Answers ReloginRequest, and it is the only thing worth waiting for in that exchange.
CHECK THE FLAG BEFORE YOU READ THE TOKEN
A REFUSAL IS NOT AN ERROR MESSAGE, and it is not silence - the server answers, the flag is simply clear. Read the flag first. If you read the token unconditionally you will carry an empty string into the next connection and fail authentication there, far from the cause and looking nothing like this exchange.
THE REAL CLIENT OVERWRITES ON REFUSAL. It does not keep the token it already had: on the refusal branch it stores an empty string over it, deliberately. Do the same. A stale token from an earlier session is worse than none, because it will be presented and rejected.
WHAT THE TOKEN IS FOR
The next connection presents it instead of a full authentication round. Store it, then proceed with whatever you were doing - the real client stores it and only then replays the menu action that asked for it. If you act first and store second, you can leave the server before the value is in hand.
READ IT BY ROLE, NOT BY NUMBER
The message is padded, and the padding is different in every build - a nested message here, a spare bool there, a map somewhere else - while the two members that matter keep swapping field numbers between builds. Two members are live: one bool that says whether a token was granted, and one string that carries it. Everything else in the declaration is padding no client has ever read.
IT ARRIVES BY TYPE. The request went out uncorrelated, so nothing links this event back to it by uid. There is only ever one of these exchanges in flight, so nothing needs correlating.
When you may send it
Requires authenticated observed Related messages
Arrives after ReloginRequest Fields
#FieldTypeMeaningYou set it 1valid_tokenboolWhether the server granted a token. Gates the token below.never 3tokenstringThe relogin token, empty when refused.never
  • summary: Grants or refuses the token that skips full authentication on the next connection. Check the flag before the token.
  • area: Game.Connection
  • 63 vues
Account permission booleans (five, four from 3.7.1.0) whose individual meanings are not recovered.
Kind struct · Area Game.Account
Five booleans up to 3.6.12.16 and four from 3.7.1.0, which dropped one; we do not know which is which.
THIS IS A DELIBERATE GAP, NOT AN OVERSIGHT. The reference build has no account-level rights type in the game protocol, the early 3.x name map has none, and the client never branches on an individual flag - only on whether the block is present at all. There is nothing to prove a mapping with, so nothing is claimed.
Read them positionally as opaque flags if you must, and expect their order to be meaningless across builds. The safe answer is to ignore this record.
The type name itself is real: it comes from the current build's own protocol type-name table.
Not sent on its own — it is only ever carried by AccountRightsEvent. inferred
Used by
AccountRightsEvent No fields you may set.
  • summary: Account permission booleans (five, four from 3.7.1.0) whose individual meanings are not recovered.
  • area: Game.Account
  • 62 vues
Empty server poll asking the client how many events it has received.
Kind event · Area Game.Basic
Carries no payload - the message IS the question. Answer it with SequenceNumberRequest carrying how many of these polls have reached you on this connection, the one you are answering included.
COUNT THE POLLS, NOT YOUR INBOUND TRAFFIC. The real client keeps one counter per connection that nothing but this poll touches: zeroed when the socket becomes active, incremented once per arrival, so the first reply carries 1 and never 0. See SequenceNumberRequest for the full rule.
In a capture the real client replies in the same millisecond, and this poll arrives in the same frame as BasicLatencyStatsEvent.
When you may send it
Requires authenticated observed Related messages
You must then send SequenceNumberRequest observed — the poll is unanswered until the client reports its counter Unsolicited - nothing you send causes this the server polls on its own schedule; nothing you send asks for it Sequence
Step server_poll.1 observed — the server emits both polls in the same frame; of 2 observations
  • summary: Empty server poll asking the client how many events it has received.
  • area: Game.Basic
  • 64 vues
The server's challenge in the proof-of-identity handshake. The one message in that chain whose contents you must read.
Kind event · Area Game.Client.Verification
Arrives because you sent ClientChallengeInitRequest, and must be answered with ClientChallengeProofRequest. THE HANDSHAKE DOES NOT COMPLETE UNTIL YOU DO.
WHEN IT ARRIVES
Shortly after your init request, and only then - the server does not send it on its own schedule. But it is delivered as an ordinary event: the client matches it BY TYPE, not by the envelope id it allocated for the init. There is only ever one of these exchanges in flight, so nothing needs correlating, and you should not sit waiting for a uid to come back.
It is the third of four steps. ClientIdRequest and ClientChallengeInitRequest publish the two values this challenge is checked against; if you have not sent both, there is nothing here you can usefully answer.
READ THE PAYLOAD - THIS IS THE ONE STEP WHERE IT MATTERS
PARSE IT AS AN ARBITRARY-PRECISION INTEGER. The value is a decimal string and the real client parses it as a big integer, multiplies it by its private exponent and reduces the result. It is not bounded by anything you can hold in 64 bits, and truncating or overflowing it produces a proof that is silently wrong rather than an error you can see.
ABSENT IS NOT EMPTY, AND ABSENT DOES NOT MEAN SKIP IT. The field has explicit presence and the client tests for it. When the value is missing the client does NOT stay silent and does not fail - it computes a challenge of its own by hashing its handshake values together with a device fingerprint, and answers with that. Treating a missing value as "nothing to do here" leaves the handshake open, which is exactly the state the exchange exists to detect. ClientChallengeProofRequest gives the full recipe for both branches.
WHERE THE ANSWER GOES
ON THE MAIN GAME CONNECTION, even when a second one is open. While a fight-server transfer is active the client holds two sockets (see IdentificationRequest) and routes outbound traffic between them by message type. All three verification requests are on the short list pinned to the FIRST connection - ordinary gameplay traffic is what goes to the fight server. Answering on the wrong socket is a mistake the real client cannot make.
THE COMPLETE ALGORITHM IS ON ONE PAGE. Constants, both exponents, both branches, what the server checks and the ways an implementation goes wrong are written out in full under ClientChallengeProofRequest. Read that before implementing any part of this exchange.
When you may send it
Requires authenticated observed Related messages
You must then send ClientChallengeProofRequest proven — the client's handler combines this value with its state and returns the proof Arrives after ClientChallengeInitRequest Fields
#FieldTypeMeaningYou set it 2valuestringThe server's challenge, as a decimal string, combined with your handshake state to derive the proof.
Explicit presence: absent is not the same as zero.
Parse it as an arbitrary-precision integer. It is not bounded to 64 bits, and a truncated value yields a wrong proof rather than a visible error.
Absent means "no challenge given" - and that is an instruction, not a rest: the client derives its own challenge and answers anyway. See ClientChallengeProofRequest.never; inbound only
  • summary: The server's challenge in the proof-of-identity handshake. The one message in that chain whose contents you must read.
  • area: Game.Client.Verification
  • 85 vues
The server's experience multipliers and your experience limit, sent early in the session.
Kind event · Area Game.Server
THE SERVER'S EXPERIENCE MULTIPLIERS, sent early in the session. Nothing requests it at login - it arrives unprompted.
IT ALSO CARRIES YOUR EXPERIENCE LIMIT, and the official client learns the limit only from here. After PlayerExperienceSetRequest the client does not store the value it sent, so expect this message again to confirm the new limit.
THE NUMBERS ARE OFFSET BY 100 - MOSTLY
Two of the values are percentages expressed as a multiplier over normal, and the client subtracts 100 from each before storing them. A wire value of 200 becomes a stored 100, i.e. "+100%". A third value is stored exactly as sent: it is the experience limit (0 to 100, 100 = no limit) that the client copies into its own limit option. If you read these raw and show them to a user you will overstate every bonus by 100 points.
WHICH IS WHICH IS NOT SETTLED, AND THIS RECORD DOES NOT PRETEND OTHERWISE. The reference build declares this message with a SINGLE field; the current one carries three the client actually reads. Only one canonical member name exists, so none of the three is named here - they keep their obfuscated names rather than being given a label by guesswork. What IS established is the shape: two offset-by-100 values and one raw one, all three stored into played-character state and read back from there.
A FOURTH DECLARED MEMBER IS PADDING and no dumped client has ever read it.
If you need one of these values specifically, capture it against a server whose rates you know - the transform above tells you how to interpret what you see.
When you may send it
Requires context_ready observed Related messages
Answers PlayerExperienceSetRequest Reply not yet recovered: the message carries three live members and only one canonical member name exists for it; the members are therefore left with their obfuscated names. See the notes. No fields you may set.
  • summary: The server's experience multipliers and your experience limit, sent early in the session.
  • area: Game.Server
  • 65 vues
The game session is ready to complete its cryptographic handshake.
Kind event · Area Game.Connection
Carries no payload. Arrival means the server is ready for the session handshake, and the client answers with ClientChallengeInitRequest.
In a capture it closes the burst that follows acceptance of IdentificationRequest, and the answer goes out a few milliseconds later - notably as one of the rare CORRELATED requests, meaning the client allocates an envelope id for it and expects the reply routed back to that id.
When you may send it
Requires authenticated observed Related messages
You must then send ClientChallengeInitRequest inferred — the client's handler derives the session value and sends the init request Arrives after IdentificationRequest
  • summary: The game session is ready to complete its cryptographic handshake.
  • area: Game.Connection
  • 70 vues
The server's environment: language, community, ruleset and account limits.
Kind event · Area Game.Connection
Pushed once, in the burst that follows a successful IdentificationRequest. Nothing requests it.
Worth storing rather than ignoring: it tells you which ruleset the server runs and whether the account is restricted to one character at a time, both of which change what later requests are legal.
When you may send it
Requires authenticated observed Related messages
Arrives after IdentificationRequest Fields
#FieldTypeMeaningYou set it 1item_max_levelint32Highest item level this server allows.never 2languagestringThe server's language, e.g. fr.never 3has_free_autopilotboolWhether autopilot is available without a subscription here.never 4arena_leave_ban_timeint32How long a player is barred from arena after leaving a match. (minutes)never 5communityint32Community id the server belongs to.never 6game_typeServerTypeThe server's ruleset.never 7is_mono_accountboolWhether the account may only play one character at a time on this server.never
  • summary: The server's environment: language, community, ruleset and account limits.
  • area: Game.Connection
  • 65 vues
Which ruleset family the connected game server runs: classical, arena, tournament, epic or seasonal.
Kind enum · Area Game.Connection
Carried by ServerSettingsEvent. It tells you what KIND of server you are on, and that changes what your script may safely do.
EPIC IS THE ONE THAT MATTERS. Epic servers have permanent death: a character that dies there is gone. A script that treats death as a recoverable state - walk to the phoenix, carry on - is wrong on those servers in a way that cannot be undone. Check this before writing any combat automation.
TEMPORIS servers are seasonal and temporary; anything you build on one has a known expiry.
Not sent on its own — an enum is never sent on its own. inferred
Used by
ServerSettingsEvent Values
ValueNumberMeaning UNDEFINED0No recognised ruleset. CLASSICAL1A standard game server. KOLIZEUM2A dedicated Kolizeum arena server. TOURNAMENT3A tournament ruleset server. EPIC4An Epic ruleset server.
PERMANENT DEATH. A character that dies here is gone for good. TEMPORIS5A temporary seasonal Temporis server.
  • summary: Which ruleset family the connected game server runs: classical, arena, tournament, epic or seasonal.
  • area: Game.Connection
  • 65 vues
Server-initiated challenge that obliges the client to identify itself.
Kind event · Area Game.Client.Verification
YOU MUST ANSWER THIS. The client's own handler ignores the event's contents entirely and replies with ClientIdRequest; nothing in the payload is needed to build the answer.
The answer is not a constant. The real client generates fresh random handshake state, computes a modular exponentiation from it, and sends the result as a decimal string. A replayed or fixed value is not what a real client produces.
When you may send it
Requires transport_established observed Related messages
You must then send ClientIdRequest proven — the client's handler computes the identifier and hands back the request Unsolicited - nothing you send causes this the server opens the verification exchange on its own
  • summary: Server-initiated challenge that obliges the client to identify itself.
  • area: Game.Client.Verification
  • 62 vues
The current state of one equipment set: which of its pieces are worn and which bonuses that grants.
Kind event · Area Game.Inventory
Sent when the character's equipment changes in a way that affects a set bonus.
IT IS THE WHOLE STATE OF ONE SET, NOT A DELTA - REPLACE, DO NOT MERGE. The message names a set and lists every piece currently worn from it together with every bonus currently active. Removing a piece produces a new message with a SHORTER list, not a removal instruction, so a script that merges never sees a bonus expire.
Key your model by set_id. The client does exactly that: it uses the same value as a dictionary key for set state and as the subject of its own notification.
effects are the bonuses granted at the CURRENT number of worn pieces, not the set's full table. They are ObjectEffect values and carry the same branch-on-the-oneof rule.
The record declares additional members no dumped build reads. They stand with their obfuscated names.
When you may send it
Requires character_loaded inferred Related messages
Unsolicited - nothing you send causes this the server pushes it when equipment changes; no request asks for it Fields
#FieldTypeMeaningYou set it 1set_idint32Which equipment set this update is about. (set id)never 2objects_uidrepeated int32The unique handles of the set pieces currently worn. (item instance ids)
These are ObjectItem.uid values, not template gids.never 3effectsrepeated ObjectEffectThe bonuses active at the current number of worn pieces.
Element type ObjectEffect - branch on its oneof.never
  • summary: The current state of one equipment set: which of its pieces are worn and which bonuses that grants.
  • area: Game.Inventory
  • 60 vues
The full contents of one of the player's shortcut bars: spells, items, presets, emotes and cosmetics.
Kind event · Area Game.Inventory
One bar's worth of slots. It arrives once PER BAR during the connection burst, so expect several of these, distinguished by bar_type.
IT IS ONE WHOLE BAR, NOT A SLOT UPDATE - REPLACE THAT BAR, DO NOT MERGE. A slot missing from the list is an empty slot.
KEY YOUR MODEL BY bar_type, NOT BY ARRIVAL ORDER. Nothing guarantees the bars arrive in a fixed order, and a second message for the same bar replaces the first.
shortcuts lists only the OCCUPIED slots; each carries its own slot index.
Do not read these members by field number: the list and the bar selector are declared in the opposite order to the reference build, and have been since the earliest dumped 3.x build.
When you may send it
Requires character_loaded observed Related messages
Unsolicited - nothing you send causes this sent once per bar during the connection burst, and again whenever the server resends a bar Fields
#FieldTypeMeaningYou set it 1shortcutsrepeated ShortcutEvery occupied slot of the bar.
Only occupied slots appear; each carries its own index.never 2bar_typetype not documented yetWhich of the player's bars this content belongs to.
Key your model by this, not by the order the messages arrive in.never
  • summary: The full contents of one of the player's shortcut bars: spells, items, presets, emotes and cosmetics.
  • area: Game.Inventory
  • 57 vues
One per-spell modifier, mostly from equipment: which spell, which property, how, and the equipment and context amounts.
Kind struct · Area Game.Common
One modifier on one of a character's spells (a range bonus from an item, an AP-cost reduction...). It arrives in CharacterCharacteristics.spell_modifiers (the full set) and in ApplySpellModifierEvent (one change); RemoveSpellModifierEvent removes one.
HOW TO STORE IT
1. Key it by the character, SpellModifier.spell_id and SpellModifier.modifier_type (SpellModifierType: which property of the spell it changes). 2. Under that key keep one entry per SpellModifier.action_type (SpellModifierActionType); a new modifier with the same action REPLACES the entry. 3. The entry's amount is SpellModifier.equipment + SpellModifier.context. Keep both parts if you show them: the client prints them as "equipment" and "context".
HOW TO USE IT
Compute the spell's value as SpellModifierActionType explains: an ACTION_SET entry replaces the spell level's value, otherwise add BOOST and subtract REMOVE_BOOST (reversed for AP_COST and CAST_INTERVAL). Any other declared member is never read by the client: ignore it.
Not sent on its own — a record carried by CharacterCharacteristics.spell_modifiers and ApplySpellModifierEvent, never sent on its own. inferred
Used by
ApplySpellModifierEvent CharacterCharacteristics FightControlEvent Fields
#FieldTypeMeaningYou set it 1spell_idint32The spell the modifier applies to.
The client keys the modifier by it and looks the spell up with SpellData.GetById.never 3contextint32The contextual part of the amount (not from equipment).
The client adds it to equipment for the total and prints it as "context".never 4action_typeSpellModifierActionTypeHow the amounts combine with the spell's value: add, subtract or replace.
A SpellModifierActionType. One entry per action is kept for each spell and modifier type.never 5equipmentint32The part of the amount that comes from equipment.
The client adds it to context for the total and prints it as "equipment".never 6modifier_typeSpellModifierTypeWhich property of the spell is modified (range, AP cost, line of sight...).
A SpellModifierType.never
  • summary: One per-spell modifier, mostly from equipment: which spell, which property, how, and the equipment and context amounts.
  • area: Game.Common
  • 65 vues

Compte

Navigation

Recherche

Recherche

Configurer les notifications push du navigateur

Chrome (Android)
  1. Appuyez sur l'icône de cadenas à côté de la barre d'adresse.
  2. Tap Autorisations → Notifications.
  3. Ajustez vos préférences.
Chrome (Desktop)
  1. Cliquez sur l'icône représentant un cadenas dans la barre d'adresse..
  2. Select Paramètres du site.
  3. Find Notifications et ajustez vos préférences.