Smooth

The server refused to play your emote. Kind event · Area Game.Emote The answer to an EmotePlayRequest the server will not play: an emote you do not know, or one you cannot play now. No EmotePlayEvent follows. WHAT TO DO WHEN YOU RECEIVE IT 1. Treat your last EmotePlayRequest as refused. Do not resend it as is. 2. If you play emotes from a cached list, check it against EmotesEvent, EmoteAddedEvent and EmoteRemovedEvent. 3. SEND NOTHING BACK. The message names no reason the official client uses: it reads none of its members and only prints the localized line ui.common.cantUseEmote. The members it declares (two int32 and a decoy record; beta carried the emote id) are never read. Ignore them. When you may send it Requires context_ready inferred Related messages Arrives after EmotePlayRequest No fields you may set.

The emote a character is playing right now. Kind struct · Area Game.Common 1. EmoteOption.emote_id: the emote (emoticon id of the game data) to play on the actor. 2. Ignore the other int32: the client never reads it (beta's second member was a start time string). Not sent on its own — a record carried by HumanOption.emote_option, never sent on its own. proven Used by HumanOption Fields #FieldTypeMeaningYou set it 2emote_idint32The emote being played, as an emoticon id of the game data. Observed: 22never

Several actors of your map play the same emote at once. Kind event · Area Game.Emote The many-actors form of EmotePlayEvent: one emote, one animation, for a list of actors. WHAT TO DO WHEN YOU RECEIVE IT 1. For each id in EmoteMassivePlayEvent.actors_id, find that actor on the map; skip ids you do not show. 2. If EmoteMassivePlayEvent.emote_id is 0, the actors stop their emote: return them to their normal animation. 3. Otherwise play EmoteMassivePlayEvent.animation on each of them. The emote id gives the emote's data (whether it is drawn in eight directions, allowed on a mount). 4. SEND NOTHING BACK. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this a group emote broadcast by the server; nothing requests it Fields #FieldTypeMeaningYou set it 1animationstringName of the animation to play on every actor. Name invented from the client parameter it fills (SetAnimationAction's animation), as on EmotePlayEvent.animation; no reference build names this member.never 2emote_idint32The emote played; 0 means the actors stop their emote. (emote id)never 3actors_idrepeated int64The map actors playing it. (actor id)never

You learned one emote: add it to the emotes you know. Kind event · Area Game.Emote One emote was added to the emotes you know. EmotesEvent gave the whole list at load; this message and EmoteRemovedEvent are the changes after it. WHAT TO DO WHEN YOU RECEIVE IT 1. Add EmoteAddedEvent.emote_id to your set of known emotes. If it is already there, do nothing more: the official client ignores a duplicate. 2. From now on you may send EmotePlayRequest with that id. 3. SEND NOTHING BACK. The official client also looks the emote up in its game data (an unknown id is ignored), files an emote that carries an aura as an inventory item, re-enables shortcut-bar slots holding that emote, and, once the initial EmotesEvent has arrived, prints the localized line ui.common.emoteAdded with the emote's name. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this the server sends it when the character gains an emote (an item, a quest reward, a shop purchase); nothing requests it Fields #FieldTypeMeaningYou set it 1emote_idint32The emote learned. (emote id) An id of the emoticons game data, the ids EmotesEvent lists and EmotePlayRequest sends.never

What kind of delayed action a character is performing. Kind enum · Area Game.Roleplay The kind of delayed action. Only DelayedActionType.OBJECT_USE is named: it is the only value the official client acts on. The three other values (beta: DISCONNECT, JOIN_CHARACTER, AGGRESSION_IMMUNE) are ignored by the client, so nothing proves which is which. Not sent on its own — an enum carried by DelayedActionEvent.delayed_action_type and DelayedActionFinishedEvent.delayed_action_type, never sent on its own. inferred Used by DelayedActionEvent DelayedActionFinishedEvent ObjectUseOption Values ValueNumberMeaning OBJECT_USE1The character is using an item; the event carries the item.

A character's delayed action is over: remove its display. Kind event · Area Game.Roleplay A character's delayed action ended. WHAT TO DO WHEN YOU RECEIVE IT 1. Drop what you track for DelayedActionFinishedEvent.character_id's delayed action (the official client removes the tooltip it keyed by that character id). 2. SEND NOTHING BACK. DelayedActionFinishedEvent.delayed_action_type repeats the type; the client does not read it. The declared int32 list is never read either. When you may send it Requires roleplay_context inferred Related messages Arrives after DelayedActionEvent Fields #FieldTypeMeaningYou set it 1character_idint64The character whose action ended. The DelayedActionEvent.character_id it closes.never 2delayed_action_typeDelayedActionTypeWhat kind of action ended. A DelayedActionType; not read by the client.never

A character on your map started an action that takes time, such as using an item. Kind event · Area Game.Roleplay A character started an action that lasts until a given time. The official client shows a tooltip above them for DelayedActionType.OBJECT_USE (using an item), with the item. WHAT TO DO WHEN YOU RECEIVE IT 1. DelayedActionEvent.character_id is the character acting; DelayedActionEvent.delayed_action_type says what they do. 2. For OBJECT_USE, DelayedActionEvent.object_gid is the item used (an item template id) and DelayedActionEvent.delayed_end_time is when it ends, in epoch milliseconds. Other types are ignored by the official client. 3. Wait for DelayedActionFinishedEvent for that character; it may arrive at once. 4. SEND NOTHING BACK. When you may send it Requires roleplay_context inferred Related messages You will then receive DelayedActionFinishedEvent observed — when the action ends; in the same instant in the capture, whose end time was already reached; 1 observation Unsolicited - nothing you send causes this a character on the map started a delayed action Fields #FieldTypeMeaningYou set it 1character_idint64The character performing the action. An actor id of the current map.never 2object_gidint32The item used, for OBJECT_USE. Explicit presence: absent is not the same as zero. An item template id; optional, absent for other types.never 3delayed_end_timeint64When the action ends. Epoch milliseconds; the client shows the time left.never 4delayed_action_typeDelayedActionTypeWhat kind of action. A DelayedActionType.never

Today's date in the game calendar, printed in chat. Kind event · Area Game.Basic The game-calendar date (Dofus months and years, not the real-world date). TO SHOW IT 1. Look DateEvent.month up in the Months game data. It is 0-based: the client's own calendar code asks for month - 1 of a real date. 2. Print day, month name and year in that order: the client fills the ui.time.dateLetters text with DateEvent.day, the month name and DateEvent.year. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this no client code sends DateRequest; the server pushes the date Fields #FieldTypeMeaningYou set it 1monthint32Month of the game calendar, 0-based. (month id) An id of the Months game data; the client prints that month's name.never 2dayint32Day of the month. The first value of the ui.time.dateLetters text, the slot the client's calendar fills with DateTime.Day.never 3yearint32Year of the game calendar. The last value of the ui.time.dateLetters text, the slot the client's calendar fills with the year.never

Outcome of a craft or smithing attempt. Kind enum · Area Game.Exchange Carried by ExchangeCraftResultEvent.result. The values keep their obfuscated names. On 3.7.11.11 the client treats them as: - 0: impossible (invalid recipe, job level too low, nothing to make); - 2: success; - 4: forbidden (for example a legendary item); - 1 and 3: the other outcomes (beta: failed, neutral). In smithing, 1 and 2 change the item, 3 leaves it as it was. Not sent on its own — an enum carried by ExchangeCraftResultEvent, never sent on its own. inferred Used by ExchangeCraftResultEvent No fields you may set.

Your chat line was refused; the error says why. Kind event · Area Game.Chat The server refused a chat line you sent, instead of echoing it. WHAT TO DO WHEN YOU RECEIVE IT 1. Read ChatErrorEvent.error (ChatErrorEvent.Error): for example ChatErrorEvent.Error.RECEIVER_NOT_FOUND when the player you whispered to is not found. 2. Do not resend the line unchanged: the same error comes back. 3. SEND NOTHING BACK. The official client prints the localized text ui.chat.error.<value> in the chat. Values 5 and 9, and any value the client does not know (0, 11), print the generic ui.chat.error.0 instead. When you may send it Requires context_ready inferred Related messages Arrives after ChatChannelMessageRequest Arrives after ChatPrivateMessageRequest Fields #FieldTypeMeaningYou set it 1errorErrorWhy the line was refused. A ChatErrorEvent.Error.never

Which guild emblem symbol categories the character may use. Kind event · Area Game.Character Tells the client which guild emblem symbol categories the character may use. WHAT TO DO WHEN YOU RECEIVE IT 1. Keep CharacterCapabilitiesEvent.guild_emblem_symbol_category: it is a bit set of the emblem symbol categories allowed when designing a guild or alliance emblem. 2. SEND NOTHING BACK. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server sends it with the character's login data Fields #FieldTypeMeaningYou set it 1guild_emblem_symbol_categoryint32Bit set of the guild emblem symbol categories the character may use.never

The alliance of a character on the map, and whether it can be attacked. Kind struct · Area Game.Common 1. AllianceOption.alliance_information: the alliance (uid, tag, name, emblem). 2. AllianceOption.attackable_status (AttackableStatus): whether the character can be attacked in alliance PvP. Not sent on its own — a record carried by HumanOption.alliance_information, never sent on its own. proven Used by HumanOption Fields #FieldTypeMeaningYou set it 1attackable_statusAttackableStatusWhether the character can be attacked in alliance PvP. An AttackableStatus.never 2alliance_informationtype not documented yetThe character's alliance: uid, tag, name and emblem. An AllianceInformation record (no signature yet).never

The smiley packs you own besides the default one: your whole smiley set. Kind event · Area Game.Social THE WHOLE LIST, EVERY TIME. AdditionalSmileyEvent.pack_id lists every smiley pack you own on top of the default pack. The official client rebuilds its smiley set from scratch on each message, so overwrite rather than merge. WHAT TO DO WHEN YOU RECEIVE IT 1. Your packs are pack 0 (always there, never listed) plus every listed pack id. 2. The smileys you may send with SmileyRequest are the smileys of those packs (from the smiley-pack game data). 3. SEND NOTHING BACK. A second, single int32 member is declared and never read by the client. Ignore it. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this the server sends it when the character loads or gains a pack; nothing requests it Fields #FieldTypeMeaningYou set it 2pack_idrepeated int32Every smiley pack you own besides the default pack 0. Ids of the smiley-pack game data (SmileyPacksDataRoot.GetSmileyPackById); the client keeps them as bytes.never

Moins de choses à gérer, plus de temps pour le botting : chaque créneau horaire d’un planning peut exécuter son propre package, les combats se déroulent exactement au rythme que vous définissez et peuvent être encore plus rapides, vos métiers sont suivis automatiquement, base s’installe et se met à jour tout seul, les scripts peuvent jouer en groupe, lire les résultats des combats et enchaîner les fabrications, la connexion résiste aux coupures réseau et vos bots continuent de fonctionner pendant la maintenance de asterobot.net. ✨ AjoutsPlanifiez toute la semaine de votre bot : chaque créneau horaire d’un planning peut désormais exécuter son propre package et sa propre version. Par exemple, un package de récolte le matin et un package de farm le soir. Un créneau sans package spécifique continue d’utiliser celui du bot. Lorsqu’un créneau passe le relais au suivant, qui utilise un autre package, le bot reste en jeu : le script en cours doit terminer son travail dans le délai de fin prévu par le planning, puis le package suivant prend le relais. Chaque package utilise les paramètres que le bot conserve pour lui. Vous pouvez désormais consulter et modifier les paramètres de n’importe quel package, et pas uniquement ceux du package configuré pour être exécuté. Lors de l’enregistrement, deux créneaux qui se chevauchent et utilisent des packages différents sont refusés, afin que le package exécuté soit toujours clairement défini. Combattez à votre rythme grâce à la nouvelle vitesse personnalisée Custom : choisissez le temps d’attente du module de combat avant chaque action, de zéro à une minute, avec un délai fixe ou aléatoire entre deux valeurs. Vous pouvez définir un délai spécifique pour le placement, la préparation, les déplacements, les sorts ou la fin du tour. Vous pouvez ainsi enchaîner les tours sans pause tout en conservant un délai avant chaque sort ou avant la fin du tour. C’est vous qui choisissez également si le bot répond au jeu au rythme du client Dofus ou immédiatement. Quelle que soit la vitesse choisie, le module prend exactement les mêmes décisions, et aucun délai ne vous fait perdre un tour. Les scripts bénéficient aussi de cette fonctionnalité : setSpeed() accepte désormais des paramètres temporels, par exemple setSpeed({ actions: { min: 0 }, endTurn: { min: 1000 } }), et speed() renvoie ces paramètres. Accélérez les combats, avec ou sans le module de combat : trois nouveaux interrupteurs dans l’onglet Fight fonctionnent pour tous les combats du bot, que le module les gère, que vous jouiez vous-même dans Dofus ou qu’un script s’en charge. Suivi automatique de vos métiers : Asterobot conserve le niveau et l’expérience de chaque métier pendant toute la session de jeu. Asteroboard et les assistants IA peuvent ainsi consulter ces informations à tout moment. Lorsqu’un nouveau niveau permet de récolter une nouvelle ressource, la console du bot l’indique, par exemple : Lumberjack reached level 60: it can now harvest Oak Wood. Chaque version du jeu inclut désormais également les icônes des métiers. Pour les obtenir dans une version déjà téléchargée, téléchargez à nouveau cette version. @asterobot:base est toujours disponible et à jour : Asterobot le télécharge automatiquement et recherche les nouvelles versions au démarrage, toutes les heures et après chaque connexion. Tous les packages qui utilisent base, tous les bots qui exécutent directement base et les blocs du Studio utilisent automatiquement sa version la plus récente. Aucune mise à jour manuelle n’est nécessaire. Les anciennes versions qui ne sont plus utilisées sont supprimées automatiquement pour garder votre bibliothèque propre. Si base est supprimé par erreur, il est automatiquement téléchargé à nouveau. Un package qui doit conserver une version précise de base peut toujours l’importer explicitement, par exemple @asterobot:base@0.1.0. Cette version est alors conservée. Notification de maintenance dans Asteroboard : lorsqu’asterobot.net est en maintenance, une bannière indique que la connexion, la bibliothèque et les mises à jour sont temporairement suspendues, tandis que vos bots continuent de fonctionner normalement. La bannière disparaît automatiquement quelques minutes après le rétablissement du site. Si une mise à jour d’Asterobot est publiée pendant la maintenance, elle sera signalée dès le retour du site. Suivi en temps réel de votre abonnement : Asteroboard actualise automatiquement le statut de votre abonnement. Les connexions, les déconnexions ainsi que les activations et expirations d’abonnement sont prises en compte sans recharger la page : immédiatement après une connexion et dans un délai maximal de cinq minutes dans les autres cas. Titres pour les messages de l’équipe Asterobot : les messages de l’équipe peuvent désormais comporter un titre, affiché au-dessus du texte dans Asteroboard et dans la console. Les scripts peuvent jouer en groupe : invitez un joueur avec PartyInvitationRequest, acceptez une invitation avec PartyInvitationAcceptRequest ou refusez-la avec PartyInvitationRefuseRequest. Annulez une invitation avec PartyInvitationCancelRequest et quittez le groupe avec PartyLeaveRequest. Le chef de groupe peut exclure un membre avec PartyKickRequest et transmettre son rôle avec PartyAbdicateThroneRequest. Les requêtes PartyFollowMemberRequest et PartyStopFollowMemberRequest permettent respectivement de suivre un membre sur la boussole et d’arrêter de le suivre. Enfin, PartyPledgeLoyaltyRequest permet de refuser les invitations des autres groupes. Les scripts peuvent suivre les changements au sein de leur groupe : ils peuvent désormais recevoir les événements PartyJoinEvent avec chaque PartyGuest, PartyNewMemberEvent, PartyNewGuestEvent, PartyMemberUpdateEvent, PartyMemberRemoveEvent, PartyLeaderUpdateEvent, PartyNameUpdateEvent, PartyRestrictedEvent, PartyLoyaltyStatusEvent, PartyInvitationRefusedEvent, PartyInvitationCancelledEvent, PartyInvitationCancelledForGuestEvent, PartyJoinErrorEvent, PartyNameSetErrorEvent, PartyKickedByEvent, PartyLeaveEvent et PartyDeletedEvent. Les scripts peuvent lire les résultats d’un combat : FightEndEvent fournit désormais une entrée FightResultListEntry pour chaque combattant. Celle-ci indique son identité (FighterListEntry, puis PlayerListEntry, TaxCollectorListEntry ou MutantListEntry), l’expérience gagnée (FightResultAdditionalData avec ExperienceData) ou sa ligue d’arène (PvpData), ainsi que ses récompenses FightReward. Ces dernières comprennent les kamas et le butin de chaque monstre vaincu, via FightLoot, avec le détail des objets dans Loot. Les données NamedPartyTeam et NamedPartyTeamWithOutcome indiquent également quelle équipe a remporté le combat. Les scripts peuvent enchaîner les fabrications : ExchangeCraftCountRequest permet de définir le nombre de fabrications d’une recette ou de continuer jusqu’à épuisement des ressources. ExchangeCraftCountModifiedEvent confirme la modification et ExchangeItemAutoCraftStoppedEvent indique la raison de l’arrêt de la série. ExchangeCrafterJobLevelUpEvent fournit le nouveau niveau d’un métier atteint pendant une fabrication. Enfin, ExchangeObjectUseInWorkshopRequest permet de placer un objet dans un atelier de forgemagie coopérative ou de l’en retirer. Les scripts peuvent rechercher des artisans : JobMultiCraftStateEvent, avec chaque PlayerSkills, indique lorsqu’un joueur présent sur la carte commence ou arrête de proposer ses services de fabrication aux autres. JobCrafterDirectorySettingsEvent, avec chaque JobCrafterDirectorySettings, fournit également les paramètres des métiers dans l’annuaire des artisans. Les scripts peuvent modifier le prix d’un lot déjà en vente : ExchangeObjectModifyPricedRequest permet de changer le prix d’un lot dans l’hôtel de vente sans devoir le retirer puis le remettre en vente. Les scripts peuvent afficher des émoticônes et changer d’humeur : SmileyRequest affiche une émoticône au-dessus du personnage, tandis que SmileyEvent fournit celles des personnages à proximité. SetMoodRequest définit l’émoticône d’humeur du personnage, SetMoodEvent confirme l’action et MoodUpdateEvent fournit les changements d’humeur d’un ami ou d’un conjoint. Les scripts disposent de davantage d’informations sur les entités présentes sur la carte : pour les joueurs, ils peuvent accéder à NamedActor et Humanoid, ainsi qu’à leurs HumanOption : TitleOption, OrnamentOption, AllianceOption, EmoteOption, ObjectUseOption, SkillUseOption et FollowingCharactersOption, qui contient le IndexedEntityLook de chaque suiveur. En cas de transformation, ils peuvent également consulter MutantInformation. Pour les percepteurs, ils disposent de TaxCollectorActor, pour les portails dimensionnels de PortalInformation, et pour les chasses au trésor des PNJ concernés. Les événements DelayedActionEvent et DelayedActionFinishedEvent permettent de suivre une action qui prend du temps, comme l’utilisation d’un objet. RemoveChallengeEvent indique lorsqu’un combat affiché sur la carte disparaît. Autres informations accessibles aux scripts : ChatErrorEvent signale qu’un message de chat a été refusé. CharacterCapabilitiesEvent fournit les symboles d’emblème de guilde que le personnage peut utiliser. HavenBagPackListEvent indique les packs de thèmes de havre-sac possédés par le compte. Enfin, PlayerSearch permet d’accéder aux recherches de joueurs lorsqu’un message en mentionne un. 🔄 ModificationsGestion des changements de package dans les plannings : session.scheduleEndsAt et onStopRequest() prennent désormais également en compte le passage d’un package à un autre entre deux créneaux horaires. Le script peut ainsi terminer proprement son travail avant que le package suivant ne prenne le relais. Asterobotbots ne dépends plus d’asterobot.net. Connexion plus fiable : Une coupure réseau ou une page d’erreur pendant la confirmation du code ne fait plus échouer la connexion. Asterobot continue d’attendre avec le même code jusqu’à son expiration. Refuser l’accès sur asterobot.net équivaut désormais à une déconnexion : Asterobot cesse de demander un nouveau code, même après un redémarrage, jusqu’à ce que vous cliquiez vous-même sur Sign in. Moins de tentatives de connexion inutiles : lorsqu’asterobot.net ne répond pas, Asterobot attend désormais cinq minutes avant de demander automatiquement un nouveau code de connexion, au lieu de réessayer à chaque appel. En revanche, un clic sur Sign in déclenche toujours la tentative immédiatement. Documentation du protocole enrichie : la référence du protocole explique désormais les résultats de fabrication et de forgemagie, notamment Craft Result (échec impossible, réussite, action interdite et autres résultats) et Magic Pool Status (gain ou perte). Nom du champ de quantité d’objets harmonisé : la quantité d’un objet dans chacun des espaces de stockage du personnage, dans ObjectItem et ObjectQuantityEvent, est désormais désignée par InventoryQuantity, le nom utilisé par le jeu, au lieu de ObjectStorageQuantity. Composants mis à jour : les composants logiciels ont été actualisés, notamment le moteur JavaScript utilisé pour exécuter les scripts et le moteur de base de données SQLite. 🐛 CorrectionsConnexion simultanée corrigée : se connecter alors qu’une ancienne requête était encore en cours ne provoque plus l’annulation de la nouvelle connexion ni une seconde demande de connexion. Déconnexion pendant l’attente d’un code corrigée : si vous vous déconnectez alors qu’un code de connexion est encore en attente, celui-ci est désormais invalidé. Confirmer cet ancien code dans un onglet toujours ouvert ne permet plus de se reconnecter. Blocage de la connexion corrigé : une connexion bloquée à asterobot.net ne fige plus le processus de connexion. Chaque requête de connexion expire désormais après quinze secondes, et la tentative suivante repart de zéro. Reprise du module de combat après redémarrage corrigée : le module de combat ne cesse plus de fonctionner après le redémarrage d’Asterobot. Auparavant, un bot dont le paramètre Fights it plays n’avait jamais été modifié revenait en ne jouant plus aucun combat. Il reprend désormais les combats contre les monstres, et les types de combats que vous aviez sélectionnés restent inchangés. Si vous aviez volontairement décoché tous les types de combats, vous devez les décocher à nouveau une fois. Déplacements sur plusieurs cartes corrigés pour les bots joués dans Dofus (MITM) : les déplacements ne s’interrompent plus après une ou deux cartes avec l’erreur the server didn't acknowledge the end of the walk in time. Le bot laisse désormais au jeu le temps d’afficher votre personnage sur chaque nouvelle carte et termine automatiquement un déplacement que le jeu avait interrompu.

Exécutez une activité différente à chaque créneau horaire de la journée et gardez toujours une vue d’ensemble : un package par créneau dans vos plannings, des combats à votre rythme ou plus rapides que jamais, vos métiers visibles en un coup d’œil, Asteroboard disponible en allemand, un avis clair lorsque asterobot.net est en maintenance, et un Studio qui propose toujours les blocs les plus récents de base et vous mène directement aux éléments à corriger. ✨ AjoutsChoisissez ce qui s’exécute à chaque créneau horaire : chaque créneau de Schedule… dispose désormais d’un sélecteur de package, réglé par défaut sur The bot’s package. Il signale toute version qui n’est pas installée ou que votre Asterobot ne peut pas exécuter, avant même le début du créneau. Survolez l’aperçu Week pour voir ce qui s’exécute à chaque moment. La colonne Schedule indique quand le bot passe au package suivant, par exemple Plays my-farm at 18:00. Survolez cette indication pour voir quel package est en cours d’exécution. Un bot qui ne possède pas son propre package peut désormais avoir un planning, à condition que chaque créneau horaire en spécifie un. Combattez à votre propre rythme : sélectionnez Custom dans Speed, sur l’onglet Fight d’un bot, pour définir le paramètre Wait before every action en millisecondes : 0 pour aucune attente, une valeur fixe ou une valeur Random comprise entre deux limites. Dans Wait per action, définissez un délai spécifique pour Placement, Ready, Move, Spell ou End of turn, et choisissez si le bot doit Answer the server at once. Un avertissement apparaît lorsque le bot répond plus rapidement que n’importe quel client de jeu. La liste des vitesses précise désormais le délai associé à chaque option. Accélérez tous les combats, avec ou sans le module de combat : les trois interrupteurs de la section Faster fights, dans l’onglet Fight d’un bot, fonctionnent que le module gère le combat, que vous jouiez vous-même dans Dofus ou qu’un script s’en charge. Hurry the server indique immédiatement au serveur que chaque action a été exécutée, réduisant ainsi les attentes entre les actions et les tours. Lorsque vous jouez dans Dofus, Fewer animations lance tous les sorts sans animation et ignore les cinématiques de combat. Skip walking in fights (experimental) déplace chaque combattant directement à la fin de son déplacement. Ces trois options sont désactivées par défaut et restent inactives tant que vous ne les activez pas. Consultez vos métiers sans ouvrir le jeu : une carte Jobs, dans l’onglet Character d’un bot, affiche chaque métier avec son icône du jeu, son niveau, l’expérience nécessaire pour atteindre le niveau suivant, la ressource qu’il récolte actuellement et la prochaine ressource qu’il débloquera, avec le niveau requis. Ces informations sont disponibles dès que le personnage entre en jeu, même si le personnage en direct est désactivé, et restent affichées sous la mention Last known après la déconnexion du bot. Une notification vous avertit lorsqu’un métier atteint un niveau permettant de débloquer de nouvelles ressources, avec un bouton See the jobs pour ouvrir la carte. Planifiez en tenant compte des niveaux requis : dans le Studio, la section Resources grise les ressources que le bot sélectionné à côté de Run ne peut pas encore récolter, en indiquant le niveau de métier nécessaire. Vous pouvez tout de même les sélectionner pour une utilisation ultérieure. La section Jobs affiche désormais l’icône de chaque métier. Repérez les erreurs dans un plan sans tout déplier : une étape repliée dans le Studio affiche 2 problems inside lorsqu’elle contient des éléments à corriger. Une condition repliée indique également le nombre de problèmes qu’elle contient. Un clic permet de l’ouvrir. Configurez tous les packages utilisés par votre bot depuis un seul endroit : lorsque son planning exécute plusieurs packages, l’onglet Settings du bot vous permet de choisir les paramètres de quel package vous souhaitez modifier, sans changer le package propre au bot. Un avis de maintenance en haut de chaque page : lorsque asterobot.net est en maintenance, un message vous informe de la situation. Vos bots continuent de fonctionner normalement. La connexion, la bibliothèque et les mises à jour seront de nouveau disponibles lorsque le site sera rétabli. L’avis disparaît automatiquement. Asteroboard est désormais disponible en allemand : sélectionnez Deutsch dans Preferences › Language, ou laissez l’application utiliser automatiquement la langue allemande de votre navigateur. Les pages du jeu affichent alors également les noms des objets, des monstres et des cartes en allemand, sauf si vous avez choisi une autre langue dans leurs paramètres. 🔄 ModificationsMessages de l’équipe Asterobot améliorés : les messages affichent désormais leur propre titre et conservent leurs sauts de ligne. Ils restent visibles jusqu’à ce que vous les fermiez, afin que vous ne passiez jamais à côté d’un message. Le Studio propose toujours les derniers blocs de base : sa palette contient désormais systématiquement les blocs de la version la plus récente de base, celle que votre package utilise réellement, quelle que soit la version de base indiquée dans son manifeste. Même un package créé plusieurs mois auparavant bénéficie ainsi de toutes les nouvelles étapes et conditions. Lorsque vous ajoutez base à un package, la version proposée est la plus récente que votre Asterobot peut exécuter. Accès direct aux problèmes dans le Studio : cliquer sur un problème dans l’onglet Problems vous y conduit directement. L’onglet approprié s’ouvre, toutes les cartes repliées sur le chemin sont dépliées, et l’arrêt, l’étape, la condition, l’interruption ou le paramètre concerné défile jusqu’à devenir visible. L’élément est temporairement encadré pour le repérer facilement. Ouverture des plans sur la bonne carte : un plan s’ouvre désormais sur la carte du monde correspondant à son premier arrêt, avec un centrage et un zoom adaptés. Un plan créé sur Incarnam ou Frigost ne s’ouvre donc plus sur une carte vide. Valeur initiale harmonisée pour les blocs d’attente et de condition : les nouveaux blocs Wait until, All of, Any of et Not commencent désormais avec la valeur After 60 min of play, comme les nouvelles interruptions et les répétitions Until, au lieu de 10 minutes. Le même réglage initial est ainsi utilisé partout, et reste modifiable. Téléchargement de base facilité : lorsqu’un package destiné à créer des plans ne possède pas encore de base, le champ de téléchargement du Studio est désormais prérempli avec le fichier de base disponible sur asterobot.net. Il ne reste plus qu’à l’installer en un clic. 🐛 CorrectionsBouton de compte corrigé : le bouton du compte ne propose plus une connexion qui a déjà expiré. Il se met automatiquement à jour lorsqu’un code expire sans être utilisé, lorsque vous refusez la connexion sur asterobot.net ou lorsque vous vous déconnectez depuis un autre onglet ou la ligne de commande. Sélection des emplacements sur la carte du monde corrigée : dans le Studio, la sélection d’un emplacement n’est plus annulée lorsque vous appuyez sur Échap pour fermer un menu ou une boîte de dialogue. La croix ✕ de la liste Maps at termine désormais la sélection au lieu de laisser le champ en attente d’un clic. Textes et libellés corrigés : formulation plus claire et corrections dans les interfaces française, espagnole et portugaise brésilienne, ainsi que dans certains libellés anglais, notamment Shut down server. Une requête SQL sur les données du jeu qui renvoie une seule ligne l’indique désormais correctement, au lieu d’afficher « 1 rows ».

Vos bots combattent désormais de manière autonome. Activez le nouveau module de combat et Asterobot place votre personnage, joue chaque tour selon les règles du client Dofus et combat jusqu’à la fin, exactement comme le définit votre profil de combat, aussi bien sur les bots en connexion directe (Full socket) que sur les sessions relayées MITM. ✨ AjoutéCombat autonome des bots : activez Jouer les combats de ce bot dans le nouvel onglet Combat du bot. Le module de combat place le personnage, annonce qu’il est prêt et joue chaque tour : déplacement, lancement de sorts, attaques à l’arme et fin de tour, en envoyant les mêmes messages que le client Dofus. Il répond également à toutes les requêtes auxquelles le client répond normalement pendant un combat, du chargement de la carte jusqu’à la confirmation de chaque action. Il joue les combats lancés par vous ou par votre package, du premier au dernier tour. Des actions conformes aux règles du jeu : le module calcule le coût en PA et la portée de chaque sort, la ligne de vue, les lancements en ligne ou en diagonale, les temps de relance, les limites de lancements par tour et par cible, les états requis, les cellules libres nécessaires, la limite d’invocations et le tacle, conformément aux règles du client Dofus. Une compréhension des effets des sorts avant leur lancement : calcul des dégâts à partir des caractéristiques du personnage et des résistances de la cible, coups critiques, érosion, boucliers, soins, poussées et dégâts infligés en frappant un obstacle, retrait de PA et de PM, états, invocations et sorts déclenchés par d’autres effets, selon les règles utilisées par le client Dofus pour prévisualiser les sorts. Des tours complets plutôt que des actions isolées : le module planifie la meilleure séquence de déplacements et de lancements de sorts. Par exemple, il peut appliquer un bonus permettant d’attirer un monstre à portée, puis lancer le sort qui peut désormais l’atteindre. Il évite également de terminer son tour sur une cellule où les monstres pourraient tuer le personnage. Prise en compte de tous les bonus : portée, coût en PA, dégâts, probabilité de coup critique et nombre de lancements supplémentaires accordés aux sorts par des bonus tels que les Œil de taupe et Tir éloigné du Crâ, ainsi que par l’équipement du personnage. Gestion des pièges et des glyphes : le module évite de marcher sur les pièges ou de terminer son tour dans un glyphe susceptible de blesser le personnage. Il pousse les ennemis dans les pièges de son équipe et permet aux Srams et aux Fécas de placer leurs pièges et glyphes là où les ennemis seront pris au piège. Une nouvelle pondération Pièges et glyphes dans les profils permet de définir l’importance de ces éléments. Une ouverture de combat optimisée : le module place le personnage sur la cellule de départ qui lui permettra de jouer au mieux son premier tour. Il peut également attendre que vos autres personnages soient prêts avant d’annoncer qu’il est prêt. Des invocations autonomes : les invocations fournies par le serveur au personnage, comme les fées de l’Eniripsa, jouent leurs propres tours avec leurs propres sorts. Reprise du combat après une déconnexion : une fois le bot reconnecté, le module reprend le combat là où il s’était arrêté, y compris le tour en cours. Une vitesse de combat configurable : choisissez Lent, Normal ou Turbo pour chaque bot. En mode Turbo, le bot répond immédiatement au jeu, plus rapidement qu’un véritable client de jeu. Des profils de combat personnalisables : définissez le rôle du bot (dégâts, tank, soutien ou soigneur), sa portée, ses éléments, sa prise de risque, son placement et son positionnement (charge, maintien de position, harcèlement à distance ou dissimulation), les ennemis à cibler en priorité, son comportement envers ses alliés, son arme, les sorts qu’il privilégie ou évite et les moments où il les utilise, sa séquence d’ouverture ainsi que des règles comme la retraite lorsque ses points de vie deviennent faibles. Aucun profil n’est nécessaire pour commencer : le profil par défaut s’adapte à tous les personnages en tenant compte du rôle principal de leur classe, de la portée de leurs sorts et des sorts qu’ils possèdent réellement. Une nouvelle page Profils de combat dans Asteroboard : créez, copiez, importez, exportez et modifiez vos profils grâce à un éditeur affichant le formulaire et le JSON côte à côte. Un profil peut en étendre un autre et bénéficier automatiquement de ses mises à jour. Le profil Inactif est fourni par défaut : il participe au combat, mais passe simplement chaque tour. Des profils de combat intégrés aux packages : les packages peuvent fournir des profils sous forme de fichiers JSON dans un dossier fightprofiles, placé à côté de leur script. Une fois le package installé, tous les bots peuvent les utiliser et bénéficient toujours de leur version la plus récente. Le package officiel @asterobot:base en fournit 24, compatibles avec toutes les classes, de careful et all-in à healer, tank, summoner et boss-fight. Comprendre les décisions du bot : le Journal des tours, disponible dans l’onglet Combat de chaque bot, explique toutes les décisions prises lors de ses 10 derniers combats : action choisie, score et éléments pris en compte, autres options évaluées, action non exécutée par le serveur, décision prise par le script et sorts du profil que le personnage ne peut pas lancer. Combat en session relayée : le module joue le combat pendant que votre client Dofus continue de l’afficher. Les clics susceptibles d’interférer avec le module sont bloqués, avec une fenêtre dans le jeu expliquant pourquoi. Si vous désactivez le module, vous récupérez le contrôle du combat à partir du tour suivant. Choix des combats pris en charge par chaque bot : monstres, agressions, duels, Kolossium, percepteurs et prismes, avec un profil spécifique pour les combats contre des joueurs. Un bot de farm peut ainsi se défendre contre une agression tout en évitant les duels. Pour les types de combats qu’un bot ne doit pas jouer, le module reste désactivé. Contre les joueurs, les sorts ennemis ne sont pas encore connus : le bot prend donc davantage de risques. Contrôle du combat depuis les scripts grâce au nouveau module asterobot:fight : activez ou désactivez le module de combat, modifiez son profil, sa vitesse ou les types de combats pris en charge pendant l’exécution. Consultez le combat en cours avec state(), suivez chaque combat avec onFight() et prenez vous-même les décisions avec onDecision(), du placement initial jusqu’à la gestion complète des tours. Les décisions fournies par le script sont vérifiées par le module avant leur exécution. Informations détaillées sur les groupes de monstres : currentMap() fournit désormais les monstres de chaque groupe, avec leur identifiant, leur grade et leur niveau, afin qu’un script puisse sélectionner les combats qui valent la peine d’être lancés. Suivi en temps réel des points de vie dans les scripts : character().life reflète désormais la récupération des points de vie du personnage telle qu’elle est calculée par le jeu, sans attendre la prochaine mise à jour de ses caractéristiques. Suivi en temps réel des objets : Asterobot suit chaque objet obtenu, consommé, vendu ou déplacé vers ou depuis l’équipement, sans attendre la prochaine mise à jour complète de l’inventaire. Les scripts peuvent les consulter avec la nouvelle fonction items() de asterobot:character. Chaque pile indique l’identifiant utilisé dans les requêtes ainsi que l’emplacement d’équipement occupé. Le module de combat prend également en compte les changements d’arme effectués pendant la session. Extraction des icônes du jeu : l’extraction d’une version du jeu récupère désormais aussi les icônes des sorts, des états des sorts et des monstres, affichées par Asteroboard dans ses sélecteurs. Gestion des profils de combat via l’API : l’API d’Asterobot et les assistants IA connectés à Asterobot peuvent désormais gérer les profils de combat, modifier les paramètres de combat d’un bot et consulter son journal des tours. Identification précise des erreurs de connexion : lorsqu’un bot est refusé par le jeu, Asterobot affiche la raison exacte dans la langue du bot et avec la formulation du client Dofus. Si la version du jeu doit être mise à jour, la version exigée par le serveur est indiquée. En cas de suspension, la date de fin est affichée. Les bannissements, les certificats Ankama Shield refusés, les comptes verrouillés ou déjà utilisés, les adresses IP masquées et tous les autres refus disposent également de leur propre message. Les serveurs de connexion trop lents ou injoignables sont eux aussi signalés. Le message apparaît dans la Console du bot et dans le motif d’échec de connexion, avec les liens vers les pages d’Ankama. Nouveaux événements de combat accessibles aux scripts : FightJoinRunningEvent, avec FightResume, FighterResumeInfo et FightTurn, lorsqu’un combat reprend après une reconnexion ; FightFighterRefreshEvent lorsqu’un combattant réapparaît ; FightSpellsUpdateEvent lorsque ses sorts changent ; SummonWeightUpdatedEvent avec les points d’invocation d’un combattant ; FightMark et MarkedCell pour les glyphes, pièges et autres marques ; Challenge pour les défis du combat ; et BaseStatistics pour les statistiques cumulées du personnage en combat. Accès aux sorts du personnage depuis les scripts : SpellsEvent fournit chaque SpellItem, tandis que ApplySpellModifierEvent et RemoveSpellModifierEvent signalent respectivement l’activation et la suppression d’un bonus de sort. Les raccourcis de la barre de sorts sont également accessibles via Shortcut et ShortcutSpell. Accès aux effets persistants du personnage : les scripts peuvent consulter les effets durables grâce à AlterationsEvent et à chaque objet Alteration. Fabrication et échanges depuis les scripts : ExchangeSetCraftRecipeRequest sélectionne une recette dans un atelier ouvert. ExchangeReadyRequest lance une fabrication, un recyclage ou une tentative de forgemagie, ou valide un échange. ExchangeCraftResultEvent, accompagné de ExchangeCraftResultWithObjectDescription, fournit le résultat et, en forgemagie, le puits de l’objet. ExchangeObjectsAddedEvent et ExchangeObjectRemovedEvent suivent les objets ajoutés ou retirés de l’échange par l’une ou l’autre des parties. Suivi du poids d’une banque ou d’un coffre ouvert : les scripts peuvent lire son taux de remplissage grâce à ExchangeWeightEvent. Utilisation et équipement des objets depuis les scripts : ObjectUseRequest permet d’utiliser un objet, comme du pain ou une potion. ObjectSetPositionRequest permet d’équiper ou de déséquiper un objet. ObjectMovementEvent suit chaque déplacement d’objet vers ou depuis un emplacement d’équipement, et ObjectsAddedEvent signale l’arrivée simultanée de plusieurs objets dans les sacs. Gestion des émotes depuis les scripts : EmotePlayRequest permet de jouer une émote, par exemple pour s’asseoir et récupérer plus rapidement. EmotePlayEvent signale chaque émote jouée sur la carte. Gestion du Havre-Sac depuis les scripts : HavenBagEnterRequest permet d’entrer dans un Havre-Sac, HavenBagEditStartEvent signale le début du mode édition, et HavenBagFurnitureEvent ainsi que HavenBagFurnitureRequest donnent accès à chaque élément de mobilier sous la forme d’un objet Element. Gestion des quêtes depuis les scripts : QuestStartRequest permet de démarrer une quête, et QuestsFollowedEvent donne accès aux quêtes suivies par le journal de quêtes. 🔄 ModifiéAsterobot est désormais compatible avec Dofus 3.7.12.12. Téléchargez cette version, puis extrayez à nouveau les données du jeu depuis le Gestionnaire de jeu. Cette opération récupère également les nouvelles icônes des sorts, des états et des monstres.

Prenez le contrôle des combats de vos bots : un onglet « Combat » sur chaque bot vous permet d'activer le mode combat et de comprendre pourquoi chaque coup a été joué, tandis qu'une page « Profils de combat » vous permet de définir précisément leur style de combat. ✨ AjoutéUn onglet Combat sur chaque bot : activez ou désactivez Jouer les combats de ce bot, choisissez le Profil utilisé, cliquez sur Appliquer et définissez sa Vitesse. L’onglet indique lorsque le module joue le combat en cours, ainsi que les éléments remplacés par le script du bot. Choisissez les combats auxquels chaque bot participe avec Combats joués : Monstres, Agressions, Duels, Kolossium et Percepteurs et prismes. Seuls les combats contre les monstres sont activés par défaut. Un Profil pour les combats PvP dédié devient disponible dès qu’un combat contre des joueurs est activé. Comprenez chaque action grâce au Journal des tours, dans l’onglet Combat : toutes les décisions du bot lors de ses 10 derniers combats, de la plus récente à la plus ancienne, avec le tour, l’action, la cellule ou le sort, le score et les éléments pris en compte, les options Également évalués, ainsi que les décisions marquées Sans réponse ou Gérées par le script. En haut de chaque combat, les sorts du profil que le personnage ne peut pas lancer sont affichés. Une nouvelle page Profils de combat, accessible depuis le menu, regroupe tous les profils utilisables par vos bots : Inactif, les vôtres et ceux de vos packages. Chaque profil indique son origine et son état : Prêt, inutilisable ou accompagné d’avertissements. Créez un profil avec Nouveau profil, importez-en un partagé, ou Copiez, Exportez ou Supprimez un profil depuis son menu. La liste se met à jour automatiquement. Configurez un profil dans un éditeur clair, organisé par sections (Général, Archétype, Jeu, Sorts, Ouverture, Monstres, Règles et Pondérations), avec son JSON affiché à côté. Les deux vues restent synchronisées pendant la saisie. Un champ vide affiche sa valeur par défaut ou celle héritée du profil étendu. Lors de l’enregistrement, chaque problème renvoie directement au champ concerné. Trouvez le bon sort en quelques secondes : Choisir un sort affiche les sorts d’une classe et leurs variantes, avec leur coût en PA, leur portée et leur icône, puis les sorts des invocations qu’ils permettent d’invoquer et les sorts que toutes les classes peuvent apprendre. Les monstres, les races et les états peuvent être recherchés par leur nom. Renommez librement un profil : tous les bots qui l’utilisent, ainsi que tous vos profils qui en héritent, adoptent automatiquement son nouveau nom. Suivez les combats en direct : pendant un combat, l’onglet Carte du bot affiche la carte du combat et tous les combattants avec leurs points de vie, au fur et à mesure de leurs déplacements, de leurs poussées et de leurs morts. Les sorts, les états des sorts, les monstres et les objets affichent désormais leur icône à côté de leur nom partout où un champ permet de les sélectionner : dans les paramètres et les actions des packages, dans le Studio et dans l’éditeur de profils de combat. La jauge de vie, située au-dessus des onglets du bot dans le Gestionnaire de bots et dans l’onglet Personnage, augmente désormais à mesure que le personnage récupère des points de vie, comme dans le jeu. L’onglet Inventaire suit désormais en temps réel chaque objet obtenu, consommé, vendu, équipé ou retiré, sans attendre la prochaine mise à jour complète de l’inventaire. L’éditeur de packages ouvre désormais les profils de combat d’un package, c’est-à-dire les fichiers .json du dossier fightprofiles, au format JSON. Le bouton Ajouter un fichier accepte un chemin tel que fightprofiles/careful.json, ce qui permet d’inclure des profils de combat dans votre package. Identifiez immédiatement pourquoi un bot ne peut pas se connecter : le message Impossible de connecter ce bot et la notification de connexion affichent désormais la raison exacte fournie par le jeu, dans la langue du bot et avec la formulation du client Dofus, plutôt qu’un message technique. Si la version du jeu doit être mise à jour, la version exigée par le serveur est indiquée. En cas de suspension, sa date de fin est affichée. Les autres refus de connexion, les serveurs de connexion lents et les serveurs injoignables disposent également de leurs propres messages, avec des liens vers les pages d’Ankama. Le message apparaît aussi dans la Console du bot. 🔄 ModifiéLes données en direct de Personnage incluent désormais la régénération des points de vie du personnage. Celles de l’Inventaire incluent les objets obtenus, retirés et déplacés. Celles de la Carte incluent les combattants présents dans un combat. Pour en bénéficier sur un bot déjà configuré, réactivez Personnage, Inventaire et Carte dans les Paramètres des données en direct, accessibles via le bouton situé à l’extrémité droite de la ligne au-dessus des onglets du bot.

Drive the fight module from a script: switch it on or off, change its profile and speed, read the fight under way, follow every fight's events, and take its decisions yourself at the placement, ready and each action of a turn, with the rules engine checking every action. asterobot:fight lets your script work with the bot's fight module, which plays its fights as its fight profile says. The guide describes the module for players: The fight module. import { enable, disable, enabled, setProfile, profile, setSpeed, speed, setFights, fights, state, onFight, offFight, onDecision, offDecision, } from "asterobot:fight"; These are the module's only exports. There's no fight object grouping them. Export Returns What it does enable(), disable() Nothing Switch the module on or off while the script runs enabled() A boolean Whether the module is on, all settings considered setProfile() Nothing Play another profile while the script runs profile() An object The profile in effect setSpeed(), speed() Nothing, a string Set or read the speed setFights(), fights() Nothing, an array Set or read the kinds of fight it plays state() An object or undefined The fight under way onFight(), offFight() A handle, nothing Follow every fight's events onDecision(), offDecision() A handle, nothing Take the module's decisions Every function is synchronous: none returns a promise. Overrides enable(), disable(), setProfile(), setSpeed() and setFights() override the settings the person saved on the bot's Fight tab. The tab then says what the script overrides, and the person's settings play again once the script stops. They last while the script runs. A reload starts a new script: its first override replaces the old script's, and until then the old script's stay. A reload that fails to start leaves the running script's. The switch takes effect at the next turn. Switched during a fight, the module starts or stops playing at the next turn's start, so one turn is never played by two. Before the first turn, and for the profile and the speed, the change applies at once. On a relayed session the switch stays the person's. enable() and disable() change nothing there, and enabled() says what's in effect. The profile, the speed and the kinds of fight still apply. A profile the script sets plays every fight, against players too, whatever Profile in PvP fights the tab sets. enable() and disable() enable() switches the module on and disable() off, as the switch on the Fight tab does. enabled() returns true when the module is on, all settings considered: the saved switch, or the script's. import { disable } from "asterobot:fight"; // This package plays its fights itself. disable(); setProfile() setProfile(nameOrProfile) plays another profile while the script runs. Argument Plays A profile's name "Idle", a profile of the person's pool, or a package's, such as "@some-author:fighters/air-cra" "" The default profile An object A profile your script writes, in the fight profile format An object is read as JSON.stringify writes it, then checked as a saved profile is. Its extends is merged in, one level as always. A malformed profile throws a TypeError naming the field, and its warnings go to the bot's console. A name no profile has, or a saved profile that can't be played, throws an Error. import { setProfile } from "asterobot:fight"; setProfile({ version: 1, name: "Careful", extends: "@some-author:fighters/air-cra", risk: 20, rules: [{ when: { "self.life": { below: "30%" } }, do: { retreat: { to: "cover" } } }], }); profile() profile() returns the profile in effect as a plain object in the format, the profile it extends already merged in, so without extends. The weapon is written "weapon". The object is a copy: change it, then set it back. import { profile, setProfile } from "asterobot:fight"; // Keep everything, but walk no more. const current = profile(); setProfile({ ...current, parts: { ...current.parts, movement: false } }); A field this Asterobot doesn't read isn't in the copy. setSpeed() and speed() setSpeed(speed) sets the speed while the script runs: "slow", "normal" or "turbo". Any other value throws a TypeError. speed() returns the speed in effect. Speed says what each one does, and what "turbo" risks. setFights() and fights() setFights(kinds) sets the kinds of fight the module plays while the script runs, as the Fights it plays checkboxes of the Fight tab do. An empty array plays none. In a fight of another kind, or of a type whose meaning isn't known yet, the module is off, as with disable(), from the moment the game says what the fight is, just after its map's load. An unknown kind throws a TypeError. fights() returns the kinds in effect: ["monsters"] unless the person or a script chose others. Kind Fights "monsters" Fights against monsters, and breaches "aggressions" A player attacking another "duels" Duels between players "kolizeum" Kolossium fights "taxCollectorsAndPrisms" Fights for a perceptor (tax collector), a prism or an alliance's territory import { setFights } from "asterobot:fight"; // Defend against aggressions while farming. setFights(["monsters", "aggressions"]); Starting a fight against players is your script's job, as for monsters: accepting a duel, registering for the Kolossium. Against players, the module reckons each enemy hits bare-handed, since it doesn't know their spells yet: it plays, but takes more risks than against monsters. state() state() returns the fight under way, as the module follows it from the server's messages, or undefined outside one. Every call returns a new snapshot. Property Type Value characterId BigInt The bot's character round number The fight's round, 0 before it starts turn BigInt The fighter whose turn it is; absent during the placement fighters array Every fighter, the dead ones included Each fighter: Property Type Value id BigInt Its id in the fight: negative for monsters and summons kind string "character", "sidekick" or "creature" ally boolean Whether it's on the character's side, the character included team number Its team: fighters of one team share it alive boolean Whether it's alive cell number Its cell invisible boolean Whether the server hides it from the other team: cell is then where it was last seen level number Its level life, maxLife, shield number Its life, its most life, its shield points ap, mp number The AP and MP it has left states array of numbers The states it's in, by spell_states id breed number A character's class, by breeds id monsterId, grade number A creature's monster, by monsters id, and its grade summonerId BigInt The fighter that summoned it, for a summon import { state } from "asterobot:fight"; const fight = state(); const mastogob = fight?.fighters.find((f) => f.monsterId === 2854 && f.alive); onFight() onFight(handler) calls handler with each event of every fight the bot is in, whether the module plays it or not, until offFight(handle). It returns the handle. type When Also has "started" The bot entered a fight, or got one back after a reconnection "turnStarted" A fighter's turn started fighter (BigInt), round "actionPlayed" The module played an action: only the module's own fighter, round, action, spell, cell, reasons, scripted "turnEnded" A fighter's turn ended fighter, round "ended" The fight ended, or the session did first round, summary actionPlayed describes what the module sent, as the Turn log keeps it: Property Value fighter The character, or for a turn's action the summon it controls whose turn it is action "placement", "ready", "move", "cast" or "endTurn" spell The spell cast: its id, or "weapon" cell The cell cast on, walked to, or placed on reasons score, the score of the turn this action starts, terms, what the score counted by term, and options, the best options weighed, { spell, cell, score }. Absent for the placement, ready, and an end of turn a rule asked for. scripted true when a decision hook decided it ended's summary has rounds, turns (the character's), actions (the module's), alive (whether the character was alive at the end) and duration, the fight's length in milliseconds as the server gave it, absent when the session ended first. import { onFight } from "asterobot:fight"; import { botInfo } from "asterobot:bot"; onFight((event) => { if (event.type === "ended") botInfo(`Fight over in ${event.summary.rounds} rounds, alive: ${event.summary.alive}`); }); Handlers run in the order they were registered. What a handler returns is ignored, and an async handler is fine. A handler that throws stops the script, as an on() handler does. An event reaches the script at the moment the module follows it: before your protocol handlers hear the message it comes from, on every PC. actionPlayed comes when the module sends the action. onDecision() onDecision(hook) asks hook at each of the module's decisions, until offDecision(handle). It returns the handle. The module decides first, as its profile says, then asks your hooks, and plays your answer instead when the rules engine accepts it. The hook receives { stage, fight, options }: stage When options, best first The hook can answer "placement" Before the fight, when the profile places the character The placement cells, { cell, score } { cell }: one of the options "ready" Before the fight, when the profile says the character is ready None { wait: true } "action" Before each action of a turn the module plays, the character's and those of the summons it controls The best turns the AI found for the rest of the turn, { actions, score, terms } { option: i }, { actions: [...] } or { endTurn: true } fight is what state() returns. The challenges' stage comes with the challenges, which the module doesn't choose yet. Answers { cell } places the character on that cell. It must be one of the options: the character's own cell, or one of its team's placement cells nobody stands on. { wait: true } holds the character's ready. The hooks are asked again each time the fight changes, such as an ally joining, and the placement countdown still starts the fight when it runs out. { option: i } plays the first action of options[i]. Then the module decides again: the AI searches again, and the hooks are asked again. { actions: [...] } plays the actions one after the other, without asking again between them. Return every action and { endTurn: true } to play the whole turn. { endTurn: true } ends the turn. Each action is one of: Action Does { move: cell } Walks to the cell { cast: spell, cell } Casts the spell on the cell: its id, or "weapon" for the weapon or bare hands { cast: spell, target } Casts the spell on a fighter's cell: target is an id of fight.fighters { endTurn: true } Ends the turn Each turn of options lists its actions the same way, ending with { endTurn: true }, so { actions: options[i].actions } plays a whole turn the AI found. undefined, null and a promise are no answer: the next hook is asked, then the AI decides. A hook is never awaited. import { onDecision } from "asterobot:fight"; onDecision(({ stage, fight, options }) => { if (stage !== "action") return; // Open on the Royal Mastogob with Explosive Arrow when it's there. const mastogob = fight.fighters.find((f) => f.monsterId === 2854 && f.alive); if (mastogob && fight.round === 1) return { actions: [{ cast: 32445, target: mastogob.id }] }; // Otherwise prefer the best turn that doesn't move. const still = options.findIndex((o) => !o.actions.some((a) => "move" in a)); return still >= 0 ? { option: still } : undefined; }); What the module checks The rules engine checks each action before it's sent, as it checks the AI's: the AP, the range, the line of sight, the cooldowns, the cells a walk can reach with its tackle. The module also never sends an action the server refused earlier in the turn. When it can't play an answer, or a hook throws, runs past the time limit or answers something of another shape, the AI's decision is played and the bot's console says why. A list of actions stops early, and the module decides again with the AI and the hooks: at an action the rules engine or the server refuses; when the fight isn't what the engine predicted after the action before: a fighter that died or lived otherwise, one on another cell, or the fighter acting with other AP or MP left. Life isn't compared, since the roll is the server's. The console says why, with The fight module stops the script's actions:. Timing The module waits for your answer as long as it takes. The question goes through the script's queue like every message, so on a slow PC it's answered later, never skipped: such a PC may lose a turn, but it never decides otherwise. When no hook is registered, nothing is asked and nothing waits. What a hook decides goes out after your frames. An answer takes its turn among what your script sends, as a movement does: a hook that calls send(X) and then returns a cast puts X on the wire first. What the AI decides alone is sent directly. The speed still applies. Each action goes out after the think time of the speed, as the AI's do. The Turn log marks the decisions your hooks made By the script, and actionPlayed has scripted: true. While Asterobot reads declarations When Asterobot reads a package's settings, steps and conditions, it runs the top level of its modules without a bot (see Declarations). There's no fight then: state() returns undefined, onFight() and onDecision() return a handle that never fires, and offFight() and offDecision() do nothing. The other functions throw, since they read or change a bot's module. Errors Error Type Cause fight.setProfile: fight: malformed profile: <field>: <reason> TypeError The profile object can't be played. The format's errors list each reason. fight.setProfile: fightprofiles: no profile has this name: "<name>" Error No profile has that name. For a package's profile, the reason follows, such as no version of <package> is installed. fight.setProfile: fight: malformed profile: <field>: <reason>, for a name Error The saved profile of that name can't be played fight.setProfile takes a profile's name or a profile object TypeError The argument is neither a string nor an object fight.setSpeed: fight: the speed must be slow, normal or turbo, not "<speed>" TypeError Another speed fight.onFight handler must be callable, fight.onDecision handler must be callable TypeError The handler isn't a function maximum behavior handlers reached TypeError 256 handlers are registered already, protocol handlers included These lines appear on the bot's Console and don't stop the script: Line Cause fight decision hook failed: <error>: the AI decides A hook threw, or ran for more than 5 s fight decision hook answered <stage>: not an answer this stage takes: <shapes>: the AI decides A hook answered an object of another shape fight decision hook returned a Promise, which counts as no answer: a hook answers synchronously, so it can't be async An async hook, or one returning a promise. Said once per script. The script's decision can't be played: the fight module decides instead The rules engine refused the answer, with the reason. Said once a turn. The fight module stops the script's actions: <reason> A list of actions stopped early A hook that fails again and again is reported at the 1st, 10th, 100th failure in a row, ending with (10 times) and so on. Fights explains how scripts and the module share a fight, and what a script sends when it plays fights itself.

The quests the character follows in the quest tracker, each with its current step and objectives. Kind event · Area Game.Quest Tells you which quests the character FOLLOWS, the ones the quest tracker shows. Each entry is a QuestActive: the quest id and its current step with that step's objectives (QuestActive.details). WHAT TO DO WHEN YOU RECEIVE IT 1. For each entry of quests, add QuestActive.quest_id to your list of followed quests. The client appends to the list it already has; it does not clear it first. 2. For each objective in that entry's QuestActiveDetails.objectives whose boolean flag is set, mark the objective as tracked. The client does this through the same tracker toggle the player uses, which can also send QuestObjectiveFollowRequest. A bot that does not show a tracker can skip this step. 3. Send nothing back for the list itself. The full journal (finished quests too) comes with QuestsEvent; this message only covers the tracked subset. When you may send it Requires character_selected inferred Related messages Unsolicited - nothing you send causes this no request of the client's quest frame asks for the followed list; the client only receives it Fields #FieldTypeMeaningYou set it 2questsrepeated QuestActiveThe followed quests, each with its current step and objectives. Repeated QuestActive. The client reads each entry's quest_id and the objectives of its details.never