Smooth

0.3.0 - 13/10/2026✨ AjoutéPlannings des bots. Choisissez quand chaque bot joue, semaine après semaine, depuis Bot Manager › Schedule… : ajoutez autant de créneaux horaires que vous le souhaitez pour chaque jour, choisissez votre fuseau horaire et visualisez toute la semaine en un coup d'œil grâce à l'aperçu. Lorsqu'un créneau commence, Asterobot connecte le bot et lance son script. Lorsque le créneau se termine, il déconnecte le bot. Les créneaux peuvent se prolonger après minuit. Une fin propre à chaque créneau. L'option Time to finish accorde jusqu'à 30 minutes au script pour terminer son travail. Un script conçu pour cette fonctionnalité peut ainsi terminer son combat ou son trajet avant la déconnexion du bot. Les scripts qui ne la prennent pas en charge s'arrêtent immédiatement. Vos bots se relancent automatiquement. Si un bot est déconnecté ou si son script s'arrête pendant un créneau, Asterobot le relance automatiquement. Visualisez immédiatement la prochaine action. Une nouvelle colonne Schedule dans Bot Manager indique ce que chaque bot fera ensuite : Connects at Tue 08:00, Disconnects at 12:00, Retrying at 10:42 (survolez l'indication pour connaître la raison) ou Paused, avec le motif de la pause. Vous gardez le contrôle. Si vous connectez, déconnectez, lancez ou arrêtez manuellement un bot planifié, son planning se met en retrait. L'indication On hold until 12:00 reste affichée jusqu'au début ou à la fin du prochain créneau. Enregistrez le planning pour le reprendre immédiatement. Un seul planning pour tous vos bots. L'option Copy to… permet de copier les mêmes créneaux horaires, le même fuseau horaire et le même temps de fin vers autant de bots que vous le souhaitez. Chaque bot conserve son propre interrupteur On/Off. Aucune ambiguïté. Lorsqu'un bot ne peut pas encore suivre un planning, la fenêtre de dialogue indique ce qui manque : un compte Ankama, un package chargé ou un choix de serveur autre que Ask me each time. Prise en charge des comptes Ankama Shield. Les comptes protégés par Ankama Shield peuvent désormais se connecter et jouer comme les autres. Après votre connexion, Asteroboard vous demande le code de sécurité envoyé par Ankama par e-mail et le transmet dès que vous saisissez le sixième caractère. Code perdu ou expiré ? Cliquez sur Send a new code. Une fois le code accepté, les bots du compte se connectent comme avec l'Ankama Launcher, sans qu'un nouveau code soit demandé jusqu'à la prochaine reconnexion du compte. Les codes envoyés par e-mail sont pris en charge ; les comptes protégés par Ankama Authenticator ne le sont pas encore. Ne manquez plus aucun code Shield. Où que vous soyez dans Asteroboard, une notification vous informe lorsqu'Ankama envoie un code et indique le domaine de l'adresse e-mail destinataire, même si le code a été demandé par une connexion de bot ou par son planning. Cliquez sur Enter the code pour saisir le code directement depuis la notification. Repérez les comptes qui nécessitent votre intervention. Un statut Shield code needed apparaît dans Account Manager, et l'option Enter Shield code est disponible dans le menu du compte. Choisissez l'ordinateur présenté à Ankama. L'option Shield device, dans le menu du compte, permet de configurer l'appareil présenté à Ankama Shield : son Device ID (un clic sur Generate en crée un nouveau) et son User name. Attribuez le même appareil à plusieurs comptes pour qu'ils apparaissent comme provenant d'un seul ordinateur, ou un appareil différent à chacun pour qu'ils apparaissent comme plusieurs ordinateurs. Toute modification déconnecte le compte ; sa prochaine connexion nécessitera un nouveau code. About › Your data contient désormais des liens vers les conditions d'utilisation et la page de contact. 🔄 ModifiéUne page d'accueil plus claire. Les liens Download Asterobot, Help center et Join the Discord apparaissent désormais juste sous l'introduction, à côté du lien Asterobot not responding? See the checks, qui mène directement à la liste des vérifications de connexion. Le message de bienvenue « Asterobot is connected » ne s'affiche que lorsque la connexion est réellement établie et vous redirige vers Server › Console. La page d'accueil précise désormais les prérequis : Asterobot fonctionne sous Windows, Linux et macOS (Intel/AMD ou ARM), ainsi que sous Docker (amd64 et arm64). Votre navigateur peut demander une autorisation avant de s'y connecter, et vous pouvez installer Asteroboard comme application pour l'utiliser hors ligne. Un compte en attente de son code Shield n'est plus considéré comme connecté. Un bot ajouté avec ce compte attendra le code, et son bouton Connect vous redirigera directement vers la saisie du code. Le bouton Disconnect reste disponible pour annuler l'attente du code. Lorsqu'une connexion échoue après la saisie d'un code copié-collé, le message d'erreur indique désormais pourquoi Ankama l'a refusé. Navigation améliorée avec un lecteur d'écran. Le contenu de la page se trouve désormais dans une région principale dédiée, et le titre de la barre supérieure n'est plus considéré comme un deuxième titre principal. Dépendances mises à jour.

Your respawn point is now the zaap on map_id. Kind event · Area Game.Teleportation Your saved zaap - where you respawn - changed to the zaap on map_id. It is the answer to ZaapRespawnSaveRequest. WHAT TO DO WHEN YOU RECEIVE IT 1. Remember map_id as your respawn point. It replaces the spawn_map_id of the last TeleportDestinationsEvent. 2. If a destination list is open, the destination whose map_id matches is now the respawn one; no other is. WHAT THE OFFICIAL CLIENT DOES WITH IT It walks the destinations of the open list, sets each one's respawn flag to (its map id == map_id), stores map_id in the zaap service - the same member TeleportDestinationsEvent.spawn_map_id filled - and refreshes the picker. Builds pad this message with a nested decoy or an unread repeated string. When you may send it Requires roleplay_context inferred Related messages Arrives after ZaapRespawnSaveRequest Fields #FieldTypeMeaningYou set it 1map_idint64The map of your new respawn zaap. (map id) Replaces TeleportDestinationsEvent.spawn_map_id.never

Saves the zaap you are using as your respawn point. No payload - the server knows which zaap you are at. Kind request · Area Game.Teleportation CARRIES NOTHING, AND DOES NOT NEED TO. You are at one zaap, in its picker; the server knows which one you mean. WHEN TO SEND IT While the zaap picker is open (after TeleportDestinationsEvent), when you want THIS zaap to become your respawn point. The official client asks first - "change your saved zaap from A to B?" - and sends it only when the player confirms. From the haven bag's zaap list the same button reads "save in haven bag". WHAT COMES BACK ZaapRespawnUpdatedEvent with the new respawn map. Update your own idea of the respawn point from THAT, not from the request. THE DECLARED MEMBER IS PADDING. Some builds give this message a field. No client has ever written it, and neither should you. When you may send it Requires teleport_dialog_open proven Raised by: the player confirms the "save as respawn" prompt of the zaap picker proven Related messages You will then receive ZaapRespawnUpdatedEvent inferred — the server confirms the new respawn map; the client then moves the respawn mark in the open list. Not captured yet No fields you may set.

Every zaap your character has discovered, as the maps they stand on. Replaces the previous list. Kind event · Area Game.Teleportation The full list of zaaps your character knows, as map ids. Each arrival REPLACES the previous list; it is not a delta. WHAT TO DO WHEN YOU RECEIVE IT 1. Compare it with the list you held: every map id not in the old list is a zaap you just discovered. 2. Replace your list with this one. WHAT THE OFFICIAL CLIENT DOES WITH IT For each map id it checks whether the played character already knew it; for each new one it raises a "zaap discovered" notification, which the world map uses to add that map's zaap icon. Then it stores a copy of the whole list in the played character's state. These are the same map ids as TeleportDestination.map_id for zaap destinations. Builds pad this message with a second repeated int64 or an int64 that the client never reads. When you may send it Requires character_selected inferred Related messages Unsolicited - nothing you send causes this the server pushes the full list when it changes, typically when you discover a zaap; no request asks for it Fields #FieldTypeMeaningYou set it 1destinationsrepeated int64The map ids of every zaap your character knows. (map ids)never

What travelling to one zaap costs, in kamas - the answer to WaypointPriceRequest, shown in the world map's tooltip. Kind response · Area Game.Teleportation The price of the zaap on one map, in answer to WaypointPriceRequest. WHAT TO DO WHEN YOU RECEIVE IT 1. MATCH IT BY map_id, not by order. The official client keeps one price per map and only accepts an answer for a map it asked about. 2. IGNORE A PRICE OF 0 OR LESS. The client only stores a positive price; until then the map stays "price unknown". 3. KEEP THE PRICE. The client asks once per map and reuses the answer for as long as it keeps its cache; nothing in this message tells you it changed. SEND NOTHING BACK. THE OTHER MEMBERS ARE PADDING. This build declares a second int32, a nested record and an enum beside the two real values. The client never reads any of them. When you may send it Requires character_loaded observed Related messages Arrives after WaypointPriceRequest Fields #FieldTypeMeaningYou set it 3map_idint64The map of the zaap this price is for - the map you asked about in WaypointPriceRequest.map_id. (map id)never 4priceint32What travelling to that zaap costs, shown in the world map's tooltip. (kamas) The client ignores a value of 0 or less.never

Asks what travelling to the zaap on one map costs. Answered by WaypointPriceResponse. Kind request · Area Game.Teleportation This name is not Ankama's. It was chosen for this documentation from proven client behaviour, and is a label rather than protocol documentation. Asks the price of the zaap on map_id, from where the character stands. WHEN TO SEND IT Whenever you need a zaap's travel price before choosing it. The official client sends it from the world map: when the tooltip of a map with a zaap opens and the price is not cached yet, it marks the map as pending and asks. It asks ONCE per map and reuses the answer. WHAT COMES BACK WaypointPriceResponse with the same map_id and the price in kamas. Match the answer by map, not by order. THE DECLARED LIST IS PADDING. This build gives the message a repeated int32 beside the map id. No client ever fills it. When you may send it Requires character_loaded observed Raised by: the world map's tooltip shows a map whose zaap price the client does not know yet inferred Related messages You will then receive WaypointPriceResponse observed — the price for the same map arrived right after the request in one capture Fields #FieldTypeMeaningYou set it 1map_idint64The map of the zaap whose travel price you want. (map id) Echoed back in WaypointPriceResponse.map_id.always

One answer an NPC dialog offers: the reply_id to send back, and what choosing it does. Kind struct · Area Game.Npc One answer the NPC dialog offers, inside NpcDialogQuestionEvent.visible_replies. reply_id the id you send back in NpcDialogReplyRequest to choose this answer; it also names the reply's text in the NPC's game data. actions what choosing it does (ActionInformation): start a quest, validate a quest step, start a fight... The official client only uses them to pick the reply's icon; the server performs them when you choose the reply. Choose by reply_id, never by position. Not sent on its own — it only travels inside NpcDialogQuestionEvent.visible_replies. inferred Used by NpcDialogQuestionEvent Fields #FieldTypeMeaningYou set it 1reply_idint32The id to send back in NpcDialogReplyRequest to choose this answer. (NPC reply id) Also names the reply's text in the NPC's game data. Your capture: 36979.never 2actionsrepeated ActionInformationWhat choosing this answer does. The client only derives the reply's icon from them.never

A gathering skill: how long one use takes and how many resources it yields. Kind struct · Area Game.Job The gathering branch of SkillAction: Timed.time, the duration of one use, and Timed.collect, the range of resources one use yields. The client stores the duration as a 32-bit value; its unit is not established by client code. Not sent on its own — it is the timed branch of SkillAction, never sent on its own. inferred Used by SkillAction Fields #FieldTypeMeaningYou set it 1collectCollectHow many resources one use yields. A Collect.never 2timeint32How long one use of the skill takes.never

A kind of teleporter or destination: zaap, zaapi (subway), prism, haven bag or anomaly. Kind enum · Area Game.Teleportation The kind of a teleporter (which picker opened) or of a destination: TELEPORTER_ZAAP 0 a zaap. Absent on the wire. TELEPORTER_SUBWAY 1 a zaapi, the in-town subway. TELEPORTER_PRISM 2 an alliance prism. TELEPORTER_HAVEN_BAG 3 the zaap list opened from your haven bag. TELEPORTER_ANOMALY 4 an anomaly destination; it carries TeleportDestination.anomaly. WHERE IT APPEARS - TeleportDestinationsEvent.type: which picker opened. - TeleportDestination.type: what each destination is. - TeleportRequest: source_type is the picker's kind, sent back unchanged; destination_type is the chosen destination's kind. Builds from 3.5 declare a sixth value, 5. No client code tests for it; another client feature builds teleport choices with source 5 and destination ZAAP, but what it stands for is not proven, so it is left unnamed. Treat any other value as a protocol change. Not sent on its own — an enum is never sent on its own; it is a member of TeleportDestinationsEvent, TeleportDestination and TeleportRequest. inferred Used by TeleportDestination TeleportDestinationsEvent TeleportRequest Values ValueNumberMeaning TELEPORTER_ZAAP0A zaap. The default, absent on the wire. The client titles the picker ui.zaap.zaap. TELEPORTER_SUBWAY1A zaapi, the in-town subway. The client titles the picker ui.zaap.zaapi and shows district hints. TELEPORTER_PRISM2An alliance prism. The client titles the picker ui.zaap.prism. TELEPORTER_HAVEN_BAG3The zaap list opened from your haven bag. The save button then saves into the haven bag (ui.zaap.saveInHavenbag). TELEPORTER_ANOMALY4An anomaly destination; it carries the anomaly details. The client requires your level to reach the destination's level.

Asks to teleport to one destination of the open zaap, zaapi or prism list. Costs the destination's kamas. Kind request · Area Game.Teleportation Takes you to one destination of the list the server sent in TeleportDestinationsEvent. Send it while that picker is open. HOW TO BUILD IT 1. map_id = the chosen TeleportDestination.map_id. 2. destination_type = that destination's own TeleportDestination.type. 3. source_type = the list's kind, TeleportDestinationsEvent.type, unchanged - the teleporter you are using, not the one you go to. BEFORE YOU SEND IT - Make sure you have at least the destination's cost in kamas. The official client checks this itself and, when you are short, prints a "not enough kamas" line and sends nothing. - For an anomaly destination, make sure your level is at least the destination's level; the client disables Validate otherwise. Send one request per choice. The picker does not resend on its own. Builds pad this message with an int32, a string or a third Teleporter member that no client ever writes. Leave them unset. When you may send it Requires teleport_dialog_open proven Raised by: the player validates a destination in the teleporter picker proven Related messages Reply not yet recovered: T Reply not yet recovered: h Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: v Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: Reply not yet recovered: m Reply not yet recovered: o Reply not yet recovered: v Reply not yet recovered: e Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: y Reply not yet recovered: o Reply not yet recovered: u Reply not yet recovered: : Reply not yet recovered: Reply not yet recovered: e Reply not yet recovered: x Reply not yet recovered: p Reply not yet recovered: e Reply not yet recovered: c Reply not yet recovered: t Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: Reply not yet recovered: m Reply not yet recovered: a Reply not yet recovered: p Reply not yet recovered: Reply not yet recovered: c Reply not yet recovered: h Reply not yet recovered: a Reply not yet recovered: n Reply not yet recovered: g Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: n Reply not yet recovered: d Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: h Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: e Reply not yet recovered: l Reply not yet recovered: e Reply not yet recovered: p Reply not yet recovered: o Reply not yet recovered: r Reply not yet recovered: t Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: Reply not yet recovered: d Reply not yet recovered: i Reply not yet recovered: a Reply not yet recovered: l Reply not yet recovered: o Reply not yet recovered: g Reply not yet recovered: Reply not yet recovered: c Reply not yet recovered: l Reply not yet recovered: o Reply not yet recovered: s Reply not yet recovered: i Reply not yet recovered: n Reply not yet recovered: g Reply not yet recovered: . Reply not yet recovered: Reply not yet recovered: N Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: r Reply not yet recovered: e Reply not yet recovered: p Reply not yet recovered: l Reply not yet recovered: y Reply not yet recovered: Reply not yet recovered: h Reply not yet recovered: a Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: b Reply not yet recovered: e Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: Reply not yet recovered: c Reply not yet recovered: a Reply not yet recovered: p Reply not yet recovered: t Reply not yet recovered: u Reply not yet recovered: r Reply not yet recovered: e Reply not yet recovered: d Reply not yet recovered: Reply not yet recovered: y Reply not yet recovered: e Reply not yet recovered: t Reply not yet recovered: , Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: n Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: r Reply not yet recovered: e Reply not yet recovered: p Reply not yet recovered: l Reply not yet recovered: y Reply not yet recovered: Reply not yet recovered: m Reply not yet recovered: e Reply not yet recovered: s Reply not yet recovered: s Reply not yet recovered: a Reply not yet recovered: g Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: i Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: i Reply not yet recovered: e Reply not yet recovered: d Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: i Reply not yet recovered: t Reply not yet recovered: . Fields #FieldTypeMeaningYou set it 1map_idint64The map you want to go to: the chosen TeleportDestination.map_id. (map id) Echoes TeleportDestination.map_id.always 2source_typeTeleporterThe kind of the teleporter you are using: echo TeleportDestinationsEvent.type unchanged. Echoes TeleportDestinationsEvent.type.always 4destination_typeTeleporterThe kind of the destination you chose: its TeleportDestination.type. Echoes TeleportDestination.type.always

The destinations a zaap, zaapi or prism offers you, sent when you use one. Pick one and send TeleportRequest. Kind event · Area Game.Teleportation The server's list of where the teleporter you just used can take you. It arrives when you use a zaap, a zaapi (subway) or a prism with InteractiveUseRequest, right after InteractiveUsedEvent accepts the use. From then on you are IN THE TELEPORTER DIALOG until it closes. WHAT TO DO WHEN YOU RECEIVE IT 1. NOTE THE LIST KIND. type says which picker the server opened - ZAAP, SUBWAY or PRISM (see Teleporter). Keep it: it is the source_type you send back in TeleportRequest. 2. READ THE DESTINATIONS. Each TeleportDestination gives a map_id, its subarea_id, a cost in kamas, a level, its own type, and for an anomaly the anomaly details. 3. FIND YOUR RESPAWN POINT. The destination whose map_id equals spawn_map_id is the zaap you saved as respawn. The client marks it. 4. ACT, THEN LEAVE. Teleport with TeleportRequest, save the current zaap as respawn with ZaapRespawnSaveRequest, or close with DialogLeaveRequest. WHAT THE OFFICIAL CLIENT DOES WITH IT - It builds one entry per destination, in list order, and shows them in the zaap window, titled by the list kind (ui.zaap.zaap / ui.zaap.zaapi / ui.zaap.prism). - It compares every destination's map_id with spawn_map_id and flags the match as your respawn point. It also remembers spawn_map_id in the zaap service, the same member ZaapRespawnUpdatedEvent later updates. - For a SUBWAY list it also looks up the map hints of each destination, to show the district names. - For an ANOMALY destination it reads the anomaly details (bonus, time left) and shows them in the entry's tooltip. The list includes the teleporter you are standing at: in the capture below the first destination is your own map, with no cost. LIVE CAPTURE (3.7.4.4): InteractiveUseRequest {element_id 538794, skill_instance_uid 17447} on a zaap, then InteractiveUsedEvent (skill 114) and this event in the same millisecond: no type (ZAAP), spawn_map_id 192416776, six destinations - two zaaps (one is the current map, cost absent; the other costs 7 kamas) and four anomalies costing 1300 to 1850 kamas, each with a 120% bonus and 12 to 77 minutes left. Builds pad this message with an unread second repeated TeleportDestination, a second int64, a string, a bool or a nested decoy; the client reads only the three members above. When you may send it Requires roleplay_context inferred State it changes Establishes teleport_dialog_open inferred — the client opens its destination picker; choosing, saving and closing all happen while it is open Related messages Arrives after InteractiveUseRequest Fields #FieldTypeMeaningYou set it 1spawn_map_idint64The map of the zaap you saved as respawn point; the destination with this map_id is your respawn. Explicit presence: absent is not the same as zero. (map id) proto3 optional: may be absent. The same state ZaapRespawnUpdatedEvent.map_id updates.never 2typeTeleporterWhich teleporter you used: ZAAP, SUBWAY or PRISM. Echo it as source_type in TeleportRequest. Absent on the wire for ZAAP (value 0). Echoed as TeleportRequest.source_type; the client copies it into the picker and sends it back unchanged.never 4destinationsrepeated TeleportDestinationEvery place this teleporter can send you, one TeleportDestination each. Includes the teleporter you stand at (cost absent).never

One place a teleporter can send you: map, sub-area, kamas cost, level, kind, and anomaly details for an anomaly. Kind struct · Area Game.Teleportation One entry of TeleportDestinationsEvent. It is never sent on its own. HOW TO USE AN ENTRY 1. TO GO THERE, send TeleportRequest with this entry's map_id as map_id and its type as destination_type. 2. CHECK THE PRICE FIRST. cost is in kamas. The official client greys out Validate when you have fewer kamas, and refuses locally (a "not enough kamas" chat line) without sending anything. 3. FOR AN ANOMALY (type TELEPORTER_ANOMALY), the client also requires your level to be at least level, and shows the anomaly bonus and time left. subarea_id names the area: the client looks the sub-area up in its data to show where the destination is. Builds pad this record with an unread int64, a bool, an int32, a second anomaly-typed member or a nested decoy; the client reads only the members above. Not sent on its own — it is only ever a row of TeleportDestinationsEvent.destinations. proven Used by TeleportDestinationsEvent Fields #FieldTypeMeaningYou set it 1typeTeleporterWhat kind of destination this is (zaap, subway, prism, haven bag, anomaly). Send it as destination_type. Echoed as TeleportRequest.destination_type.never 2costint32What the trip costs, in kamas. Absent (0) for the teleporter you stand at. (kamas) The official client does not send the request when you have fewer kamas.never 4map_idint64The destination map. Send it as map_id in TeleportRequest to go there. (map id) Compared with TeleportDestinationsEvent.spawn_map_id to find your respawn zaap.never 5levelint32The destination's level. For an anomaly, your level must be at least this to go.never 6subarea_idint32The sub-area the destination is in; the client looks it up to name the place. (sub-area id)never 7anomalyAnomalyAnomaly details (bonus, time left); set only for an anomaly destination.never

What a fight team is made of: players, monsters, a tax collector, a prism and so on. Kind enum · Area Game.Fight The kind of team a FightTeamInformation describes. THE VALUES ARE NOT NAMED HERE. Beta declares six: player, monster, mutant, tax collector, bad player and prism, but no client behaviour in the dumps ties a wire number to one of them, so the numbers keep their obfuscated names. Treat the value as an opaque team kind and compare it only with values you have seen. OBSERVED (one capture, 3.7.8.7, attacking a monster group): the monster team carried 1, the player team the default 0 - which matches beta's player = 0, monster = 1, but that is one observation, not a proof. Not sent on its own — an enum carried by FightTeamInformation.type. proven Used by FightTeamInformation No fields you may set.

Which team of a fight a member belongs to: challengers, defenders or spectators. The type is named; its values are not. Kind enum · Area Game.Common The team side of a fight, as used by FightTeamRemoveMemberEvent.team and by the team member of FightPlacementPossiblePositionsEvent. Keep it as a key: the client selects a fight's team by this value. THE VALUES ARE NOT NAMED HERE. Beta declares TEAM_CHALLENGER = 0, TEAM_DEFENDER = 1 and TEAM_SPECTATOR = 2, but enum numbers are not trusted across builds, and nothing read so far in the client separates the values by behaviour. Current builds declare a fourth value. When you need challengers versus defenders, compare with the team of a fighter you know (your own character after you attacked is a challenger). Not sent on its own — an enum is never sent on its own. inferred Used by FightOptionUpdateEvent FightPlacementPossiblePositionsEvent FightTeamInformation FightTeamRemoveMemberEvent No fields you may set.

One item of the open storage (such as the bank) was added or changed. Store it under its uid, replacing what you had: the quantity is the new total. Kind event · Area Game.Inventory One item of the storage you have open changed: it was put in, or part of its stack was taken out. WHAT TO DO WHEN YOU RECEIVE IT 1. FIND THE ITEM BY UID in the storage content you loaded from StorageInventoryContentEvent: the key is the uid inside StorageObjectUpdateEvent.object (ObjectItem.uid). 2. ADD OR REPLACE IT. If the uid is unknown, add the item; if it is known, replace the whole entry with this one. The quantity in it is the NEW TOTAL of that stack in the storage, not the amount that moved. The client does exactly this (copy over the known item, or add a new one). 3. SEND NOTHING BACK. THE STORAGE UID IS ITS OWN. An item put into the storage can get a uid that differs from the one it had in your inventory; to take it back out, send ExchangeObjectMoveRequest with THIS uid and a negative quantity. NOT YOUR INVENTORY. ObjectAddedEvent and ObjectQuantityEvent describe the carried inventory; they arrive beside this one when an item moves between the two. OBSERVED (one capture, a trash bin): putting 2 of a stack in produced this event with a new uid and quantity 2; taking 1 back produced it again, same uid, quantity 1. Taking the last one out produces StorageObjectRemovedEvent instead. When you may send it Requires exchange_open inferred Related messages Arrives after ExchangeObjectMoveRequest Fields #FieldTypeMeaningYou set it 1objectObjectItemInventoryThe storage item as it is now: its uid, its template, its effects and its new total quantity in the storage. Replace the whole entry with the same uid; the quantity is a total, not a delta.never

One item left the open storage (such as the bank) entirely. Drop the item with this uid, whatever quantity you had for it. Kind event · Area Game.Inventory A whole stack left the storage you have open. WHAT TO DO WHEN YOU RECEIVE IT 1. REMOVE THE ITEM whose uid is StorageObjectRemovedEvent.object_uid from the storage content you track, WHATEVER ITS QUANTITY. The client removes the entry outright (no quantity is involved). 2. SEND NOTHING BACK. It is the storage uid, the one StorageInventoryContentEvent and StorageObjectUpdateEvent gave you, not the uid the item gets back in your inventory: that one arrives in ObjectAddedEvent (or as a quantity change in ObjectQuantityEvent when it joins an existing stack). OBSERVED (captures, bank and trash bin): taking the last unit of a stored item out with ExchangeObjectMoveRequest produced this event with that item's storage uid. PADDING. Builds add an unread member (a string on 3.7). The client reads only the recovered uid. When you may send it Requires exchange_open inferred Related messages Arrives after ExchangeObjectMoveRequest Fields #FieldTypeMeaningYou set it 1object_uidint32The storage uid of the item that left the storage. (item uid) The uid the storage knows the item by, not the uid it gets in your inventory.never

How many kamas are in the character's bank. An absolute amount to overwrite; nothing is sent back. Kind event · Area Game.Inventory WHAT TO DO WHEN YOU RECEIVE IT: overwrite the bank amount you track with StorageKamasUpdateEvent.kamas and recompute total wealth (carried plus bank). SEND NOTHING BACK - no handler of this message builds a request, and a static walk through the notifications it raises reaches none. The kamas held in the bank, as opposed to the kamas the character carries, which arrive in KamasUpdateEvent. TREAT IT AS THE AMOUNT, NOT A CHANGE. The client stores the value as the bank's kamas and hands it unchanged to the bank window. Overwrite what you track rather than adding to it. IT ALSO MOVES THE TOTAL. Right after storing it, the client recomputes the character's total wealth as carried kamas plus this value and raises the same total-kamas notification that KamasUpdateEvent raises. A script that shows total kamas has to follow both messages. ONE DECLARED MEMBER IS REAL. Builds pad this message with an int32, a repeated int32 or a nested decoy message; the client reads only StorageKamasUpdateEvent.kamas. When you may send it Requires character_selected inferred Related messages Arrives after ExchangeMoveKamaRequest Fields #FieldTypeMeaningYou set it 1kamasint64The kamas currently held in the bank. (kamas) An absolute amount, not a delta. The client adds it to the carried kamas to show total wealth.never

Every item and the kamas of the storage that was just opened, such as the bank. A full snapshot: replace what you hold for that storage. Kind event · Area Game.Inventory The complete content of the storage the server just opened, such as your bank. It comes with ExchangeStartedWithStorageEvent, which says WHICH storage it is and how many slots it has. WHAT TO DO WHEN YOU RECEIVE IT 1. REPLACE THE STORAGE'S ITEMS. Empty what you hold for the open storage, then load every element of StorageInventoryContentEvent.objects. The client clears its storage inventory, items and indexes, before adding these items, so an item missing from the list is not in the storage. Key your model by ObjectItem.uid. 2. SET THE STORAGE'S KAMAS to StorageInventoryContentEvent.kamas. It is the amount, not a change. The client writes it into the very same place that StorageKamasUpdateEvent overwrites later, the bank inventory's kamas. 3. SEND NOTHING BACK. The handler only stores the content; it builds no request. NOT YOUR INVENTORY. InventoryContentEvent has the same two members and fills the CARRIED inventory. This one fills the STORAGE inventory. A script that feeds both into one model loses track of what the character actually carries. KAMAS IS A 64-BIT VALUE. A bank holding more than 2^31 kamas is common; a 32-bit field overflows. PADDING. Builds add an unread member: a second int64, a string, a repeated int32 or a nested enum. The client reads only the two recovered members. When you may send it Requires character_loaded inferred Related messages Arrives after ExchangeStartedWithStorageEvent Reply not yet recovered: while the storage stays open, single items change through storage object update and removal events, which have no signature here; the kamas change through StorageKamasUpdateEvent. Fields #FieldTypeMeaningYou set it 1kamasint64The kamas held in the opened storage. (kamas) An absolute amount. StorageKamasUpdateEvent keeps the same value current afterwards.never 2objectsrepeated ObjectItemInventoryEvery item in the opened storage. The list replaces the storage's previous content. Each element is an ObjectItemInventory; an item absent from the list is not in the storage.never

One skill a job grants: a timed gathering action with its yield range, or a craft with its success chance. Kind struct · Area Game.Job One skill of a job (SkillAction.skill_id) and what using it does, as a oneof (SkillAction.action): - SkillAction.timed - a gathering skill: how long one use takes and how many resources it yields (Timed, Collect); - SkillAction.craft - a crafting skill: its success chance (Craft). Exactly one branch is set. Read the oneof case, not the field numbers: both branches are messages and their numbers change between builds. The client keeps the skill id as a 16-bit value. Not sent on its own — it is an entry of JobDescription.skills, never sent on its own. inferred Used by JobDescription Fields #FieldTypeMeaningYou set it 3skill_idint32Which skill this is. (skill id)never 1craftCraftSet for a crafting skill: its success chance. A Craft; a branch of the action oneof.never 2timedTimedSet for a gathering skill: duration and yield range. A Timed; a branch of the action oneof.never

A fight has started on the character's map: its teams, type and sword positions. The client adds it to the map's fights; nothing is sent back. Kind event · Area Game.Roleplay Announces one fight that has just started on the map the character is on, as a FightCommonInformation: the fight id, its FightType, the teams, the cells where each team's swords stand and each team's options. WHAT TO DO WHEN YOU RECEIVE IT 1. Add the fight to the fights you track for the map. It is the same record, and the client turns it into the same client object with the same routine, as each entry of MapComplementaryInformationEvent.fights: a map's fights are known from its contents, and fights that start later arrive one by one in this message. 2. SEND NOTHING BACK. No handler of this message builds a request, and nothing the handling reaches does either. 3. Joining the fight or spectating it are separate player actions with their own requests; this message only makes the fight visible. WHAT THE CLIENT DOES. The map-fights service converts the record and hands it on to the map's fight display. The same service also handles the map's fight count (MapFightCountEvent) and updates to a fight's teams. Adding a fight here does not change that count; on 3.6.12.16 only MapFightCountEvent sets it above zero. YOUR OWN FIGHT IS ANNOUNCED TOO. The fight carries every team member, your character included when it is one of them, so a fight you just started by attacking appears here like any other. ONE DECLARED MEMBER IS REAL. Builds pad this message with an optional int64, a second message member or a nested decoy; the client reads only ShowChallengeEvent.fight_information. When you may send it Requires context_ready inferred Related messages Reply not yet recovered: it follows any fight starting on the map - including one your own character starts by attacking a monster group - and the requests that start fights have no signature here. Fields #FieldTypeMeaningYou set it 1fight_informationFightCommonInformationThe fight that just started on the map. A FightCommonInformation, the same record the map's contents list its running fights with.never

What kind of fight action a sequence plays. The type is named; its values are not. Kind enum · Area Game.Game.Action The kind of a fight action sequence, carried by SequenceStartEvent and SequenceEndEvent. THE VALUES ARE NOT NAMED HERE. The reference build lists nine kinds - spell, weapon, glyph/trap, triggered, move, character death, turn start, turn end, fight start - but the numbers are not proven per build: the client converts the wire value into its own obfuscated enum through a dense switch and nothing readable tells which output is which. Current builds declare more values than the client's converter handles (it maps the first nine and treats anything else as the default), the extra ones are padding. You do not need the kind to play a fight correctly: acknowledge every finished sequence with GameActionAcknowledgementRequest whatever its kind. Not sent on its own — an enum is never sent on its own. inferred Used by SequenceEndEvent SequenceStartEvent No fields you may set.

Opens a fight action sequence: the actions that follow belong together until the matching sequence end. Kind event · Area Game.Game.Action Opens a fight action sequence. Everything the server sends until the matching SequenceEndEvent is the playback of ONE action - a spell cast, a weapon hit, a movement, a death, a turn start or end - and belongs together. WHAT TO DO WHEN YOU RECEIVE IT 1. Open a sequence: remember that you are inside one, and its kind (SequenceStartEvent.sequence_type, see SequenceType). 2. Apply the fight action events that follow as part of it. 3. SEND NOTHING BACK NOW. The answer comes when the sequence ends: the client acknowledges the finished sequence with GameActionAcknowledgementRequest. SEQUENCES NEST. The client keeps a parent link: a start that arrives while another sequence is open opens a child (a trap triggered during a move, a death during a spell). Close them in reverse order. The author of the sequence is also on the wire in the reference schema, but the official client never reads it here; it reads the author from the sequence end. When you may send it Requires context_ready inferred Related messages You will then receive SequenceEndEvent inferred — every sequence is closed by a sequence end carrying the action id to acknowledge; the client's own handler warns when an end arrives without a start Unsolicited - nothing you send causes this the server opens a sequence whenever it plays a fight action (a cast, a move, a death, a turn change), whoever caused it Fields #FieldTypeMeaningYou set it 1sequence_typeSequenceTypeWhat kind of action the sequence plays (spell, weapon, movement, death, turn start/end ...). Proven as the only member the client reads: it is converted into the client's sequence kind and stored in the sequence it opens.never

Closes the current fight action sequence and gives the action id the client acknowledges. Kind event · Area Game.Game.Action Closes the fight action sequence opened by SequenceStartEvent and names the action to acknowledge. WHAT TO DO WHEN YOU RECEIVE IT 1. Close the current sequence. If none is open, the client logs a warning and ignores the end: do the same. 2. Keep SequenceEndEvent.action_id and note whether SequenceEndEvent.author_id is the fighter you play. 3. When you have applied everything the sequence carried, send GameActionAcknowledgementRequest with valid = true and that action_id. ONE ACKNOWLEDGEMENT PER SEQUENCE. Not acknowledging stalls the fight: the client itself delays the end of a turn, and the end of the fight, while a sequence is still open. A FIGHT CAN END INSIDE A SEQUENCE. The official client then closes the open sequence itself, as if this message had arrived ('Fight end but no SequenceEnd was received'). When you may send it Requires context_ready inferred Related messages You must then send GameActionAcknowledgementRequest inferred — the client acknowledges each finished sequence with its action id once it has played it back; the server's fight waits for that acknowledgement Arrives after SequenceStartEvent Fields #FieldTypeMeaningYou set it 2action_idint32The id of the finished action; echo it in the acknowledgement. (action id) Proven as the only int32 the client reads; it is stored in the open sequence and echoed in the acknowledgement.never 4author_idint64The fighter whose action the sequence played. (fighter id) Proven as the only int64 the client reads; it is compared with the fighter the client plays.never

Take back every capital point spent on the six base characteristics: they return to 0 and the points return to the capital. Sent empty. Kind request · Area Game.Character Undoes the characteristic points the character has spent: the six base characteristics go back to 0 and every point spent on them returns to the capital (StatsPoints). It is the opposite of CharacterCharacteristicUpgradeRequest. HOW TO SEND IT 1. SEND IT EMPTY. It has no member to fill. 2. NO CONFIRMATION, NO CHECK ON SEND. The client's reset button sends it at once: no question to the player, and nothing between the click and the send tests level, fight or points. Treat the server as the judge of whether a reset is allowed. 3. READ THE RESULT in the next CharacterCharacteristicsEvent: strength, vitality, wisdom, chance, agility and intelligence (StatId 10 to 15) with a base of 0, and StatsPoints (characteristic 3) raised by every point that had been spent. 4. ALSO EXPECT an InventoryWeightEvent with the new maximum weight, and a TextInformationEvent (message id 470 in the observed session). OBSERVED (same character, two captures): on 3.7.7.6 it spent 8 points (1 each on strength, vitality, chance, agility and intelligence, 3 on wisdom), leaving 37 StatsPoints and a maximum weight of 1146. On 3.7.8.7 this request was answered by InventoryWeightEvent (maximum weight 1141), CharacterCharacteristicsEvent (all six bases 0, StatsPoints 45 = 37 + 8) and a TextInformationEvent with id 470. PADDING. 3.5.9.11 declares an optional int32 and a six-value enum in it; the client never writes them. Send it empty on every build. When you may send it Requires character_loaded inferred Raised by: the player clicks the reset button of the character sheet's characteristic boost panel (the full panel; the minimized panel's reset does nothing) proven Related messages Nothing answers it - send it and move on no dumped build declares a reset reply; the new characteristics arrive through the unsolicited [[CharacterCharacteristicsEvent]], as observed

The character's whole quest journal: quests under way with their current step, finished quests, and reinitialised ones. A full replacement; nothing is sent back. Kind event · Area Game.Quest WHAT TO DO WHEN YOU RECEIVE IT 1. Throw away the journal you hold and rebuild it from this message - see below. 2. SEND NOTHING BACK. No handler of this message builds a request. The one request a static walk reaches from it is the tutorial's own step query, raised by the tutorial screen for its special quests - not something the journal requires. 3. If you need the step of one quest refreshed later, ask with QuestStepInformationRequest; the journal itself is complete. WHEN IT ARRIVES. The client asks for it - its journal request (QuestsRequest, no signature here) goes out when the quest list or the quest tab opens and when the calendar refreshes. The server's statement of the character's quest journal. One message carries three lists: QuestsEvent.active_quests, QuestsEvent.finished_quests and QuestsEvent.reinitialized_done_quests_id. IT IS A SNAPSHOT, NOT A DELTA. The client does not merge it into what it already holds. On every arrival it throws away its list of active quests, its list of finished quests, its list of reinitialised quests and both of its objective lists, and rebuilds all five from this one message. A journal that omits a quest has dropped that quest. Treat each arrival as the complete truth and replace your own state the same way. WHAT THE CLIENT BUILDS FROM IT, in this order: 1. one journal entry per QuestActive, keyed by its quest id and holding the id of the step the quest is on (Details.step_id); 2. the finished list: the QuestFinished.quest_id of every entry of finished_quests; 3. the reinitialised list: every id of reinitialized_done_quests_id; 4. for each active quest, every QuestObjective of its current step, sorted into still to do and done, with its progress pair and its text parameters when it carries any; 5. for each finished quest, every objective of every step the game data declares for that quest, all marked done; 6. last, the reinitialised ids are APPENDED TO THE FINISHED LIST. Step 6 is the one to remember. A quest id listed in reinitialized_done_quests_id counts as finished for the client even when finished_quests does not list it; the reinitialised list is kept on its own as well, so the two can still be told apart afterwards. QUEST IDS ARE 16-BIT ON THE CLIENT. Every id - active, finished, reinitialised - is narrowed to a signed 16-bit value before it is stored, although the wire declares int32. TWO MEMBERS THE CLIENT NEVER READS: QuestsEvent.player_id and QuestFinished.finished_count. They are part of Ankama's contract and the server may fill them, but nothing in the client depends on either. Do not build logic on a meaning this catalogue cannot observe. Once the journal is rebuilt the client raises its quest-list-updated notification, which is what refreshes the quest window, the calendar and the group-finder tab. The journal only describes the step each quest is currently on; QuestStepInformationRequest asks for one quest's step again. When you may send it Requires character_selected inferred Related messages Reply not yet recovered: the client asks for the journal with QuestsRequest, which has no signature here. On 3.2.7.15 it sends that request whenever the quest list or the quest tab opens and when the calendar refreshes; whether the server also pushes the journal unasked is not established. Fields #FieldTypeMeaningYou set it 2reinitialized_done_quests_idrepeated int32Ids of finished quests that have been reinitialised. (quest id) The client stores these on their own AND appends them to its finished list, so an id listed here counts as finished even when finished_quests does not carry it.never 3player_idint64Whose journal this is. Explicit presence: absent is not the same as zero. (character id) Never read by the client on any dumped build, the unobfuscated beta included, so its meaning rests on Ankama's name alone. Named only on builds that declare a single optional int64; where a second one is declared it stays obfuscated rather than being picked by position.never 5finished_questsrepeated QuestFinishedEvery quest the character has completed. A list of QuestFinished. The client keeps only each entry's quest id, and rebuilds its finished list from scratch on every journal.never 6active_questsrepeated QuestActiveEvery quest the character has under way, each with the step it is on. A list of QuestActive. Some builds declare a second list of the same type beside it; the client never reads that one and it stays unnamed.never