Smooth

@asterobot:baseRead in English · Changelog @asterobot:base est la bibliothèque standard dont se sert chaque paquet. D’abord, il fait tout ce que le client Dofus officiel fait de lui-même, pour qu’aucun autre paquet n’ait jamais à le faire. Il donne à un bot un personnage connecté, dans le monde, prêt à tout sur sa carte, et l’y maintient : il identifie la connexion de jeu avec le ticket qu’Asterobot a obtenu à la connexion ; il choisit un personnage et attend qu’il soit chargé ; il entre dans le monde et suit le personnage de carte en carte ; tant que le script tourne, il garde la connexion en vie comme le fait le client. Il répond à la preuve d’identité du serveur et à ses relances, et il envoie des pings. Ensuite, il donne à chaque paquet ce qui vient après : se déplacer : marcher, changer de carte, les portes et les zaaps, les voyages vers n’importe quelle carte, et les fonctions qui choisissent où aller ; les plans : il joue les plans dessinés dans le Studio d’Asteroboard, en une ligne, await run(plan) (voir Plans) ; l’état du personnage : niveau, kamas, vie, sacs, combats, objets, métiers et carte, sous forme de conditions qu’un plan ou un script pose (voir Conditions sur l’état du jeu) ; le gameplay : récolter, combattre avec le module de combat d’Asterobot, se reposer et manger, l’équipement, vendre et acheter à l’hôtel des ventes du jeu, et la banque, sous forme d’étapes qu’un plan joue ou qu’un script appelle (voir Récolter, Combattre, Se reposer et manger, L’équipement, L’hôtel des ventes et La banque) ; des profils de combat : 24 façons de combattre toutes prêtes, pour n’importe quelle classe, que chaque bot peut jouer (voir Les profils de combat). D’autre gameplay arrivera dans base avec de nouvelles captures, pour qu’un plan nomme @asterobot:base pour tout cela. Il est pensé pour être la seule dépendance de chaque paquet. Un paquet importe base et oublie la connexion : base démarre tout seul, sur les deux sortes de bots, qu’il soit joué seul ou tiré par d’autres paquets. C’est du JavaScript simple au-dessus des modules intégrés d’Asterobot, et il ne fait lui-même aucune cryptographie : la preuve d’identité est calculée dans Asterobot, en Go (voir La preuve d’identité). Tout ce qu’il envoie, et quand, vient de captures « homme du milieu » du vrai client, et base s’améliore à chaque nouvelle capture (voir Améliorer base à partir d’une nouvelle capture). SommaireDémarrage rapide Comment base fonctionne dans tous les cas Ce qui se passe, étape par étape API Réglages Plans Le format des plans Conditions sur l’état du jeu Récolter Combattre Se reposer et manger L’équipement L’hôtel des ventes La banque Les profils de combat La preuve d’identité Garder la connexion en vie Entrer dans le monde Suivre les cartes Mémoire, et reprise en cours de route Réagir à ce que base répond Sur un bot MITM Tous les messages que base envoie Tous les messages que base lit Lignes de console et erreurs Délais et bruit Ce qu’il faut à base dans Asterobot Différences connues avec le vrai client Améliorer base à partir d’une nouvelle capture Fichiers Démarrage rapideL’installerDepuis ce dépôt, dans la bibliothèque d’Asterobot : asterobot library install --path ./base --name @asterobot:base --version 0.0.1 Réinstallez-le après chaque modification, sous la même version tant que vous travaillez dessus : chaque démarrage lit les fichiers installés à ce moment-là. Le jouer seulChoisissez @asterobot:base comme paquet d’un bot et cliquez sur Lancer. La Console du bot affiche alors base: playing <name> une fois le personnage sélectionné, et base: in the world, on map <id> une fois qu’il se trouve sur sa carte. Le bot reste dans le monde jusqu’à ce que vous l’arrêtiez. L’utiliser depuis votre propre paquetDéclarez-le dans le asterobot.json de votre paquet : { "dependencies": { "@asterobot:base": { "version": "0.0.1" } } } L’importer suffit. Attendez le monde là où votre code en a besoin : import { connect } from "@asterobot:base"; import { botInfo } from "asterobot:bot"; export default async function behavior() { // Pas attendu ici, pour que Lancer rende la main tout de suite. void main(); } async function main() { const map = await connect(); botInfo("On map", map.mapId, "cell", map.cellId); // ... votre script } connect() se résout avec la carte sur laquelle se trouve le personnage, tout de suite s’il y est déjà, et se rejette si le personnage ne peut pas y arriver (voir Lignes de console et erreurs). Elle renvoie la même promesse à chaque appel pendant une exécution du script, donc chaque paquet du bot peut l’appeler. Comment base fonctionne dans tous les casUn paquet qui utilise base doit se comporter de la même façon sur un bot Full socket, où Asterobot est le client, et sur un bot MITM, où une personne joue avec le client officiel et où Asterobot relaie la session. Il doit aussi fonctionner que base soit le paquet joué par le bot, ou une dépendance plusieurs niveaux plus bas. Base gère lui-même ces quatre cas. Les quatre cas Bot Full socket Bot MITM Base joué seul S’identifie, sélectionne, entre dans le monde, puis répond à tout ce que le serveur demande N’envoie rien. Attend que le personnage de la personne soit sur une carte. Base en dépendance, à n’importe quelle profondeur Pareil, dès que le script charge base Pareil Base décide lui-même de la colonne qui s’applique, d’après session.shared : Asterobot le définit sur un bot MITM. Il n’y a rien à configurer, et un paquet qui utilise base est le même code dans les quatre cas. Sur un bot Full socket, personne d’autre n’est là pour répondre au serveur, donc base fait tout ce que ferait le client officiel. Sur un bot MITM, le client officiel répond déjà. Une seconde réponse de base mettrait deux réponses sur le réseau là où le serveur en attend une, donc base n’envoie absolument rien. Il suit quand même la session, si bien que connect() se résout dès que le personnage de la personne se trouve sur une carte. Il démarre tout seulLe index.js de base appelle connect() à son niveau le plus haut, pendant le chargement du module. Assez tôt. Les modules se chargent avant le code qui les importe, donc les gestionnaires de base sont en place avant que le code de tout autre paquet ne tourne, et avant que le serveur ne puisse parler. La première vérification du serveur arrive juste après qu’il a accepté le ticket. À n’importe quelle profondeur. Dans une chaîne comme my-bot → @alice:harvest → base, l’auteur de my-bot ne sait peut-être même pas que base est là, et il tourne quand même. Un paquet charge base quand l’un de ses fichiers l’importe ; le lister dans dependencies sans l’importer ne charge rien. Jamais pendant la lecture des réglages. Asterobot exécute aussi le niveau le plus haut de chaque module quand il lit les réglages d’un paquet, sans bot ni session de jeu. Base reconnaît ce moment, où session.connectionId vaut 0n (ce qui n’arrive jamais pendant une vraie exécution), et ne démarre pas. C’est le seul endroit où base fait quelque chose que le guide du développeur déconseille, un effet de bord au niveau le plus haut d’un module. C’est voulu : c’est ce qui permet à chaque paquet d’oublier base. Un seul point d’entréeBase exporte connect() pour attendre le monde, ainsi que latency() et toutes les fonctions d’asterobot:movement : move(), changeMap(), useElement(), les voyages (travel(), route(), stopTravel(), trip()) et les fonctions qui trouvent les cartes. Il exporte aussi ce qui joue les plans, run(), stop() et plan(), les conditions sur l’état du jeu, et les étapes de gameplay avec leurs conditions. Les étapes de la connexion elles-mêmes (l’identification, la sélection, l’entrée dans le monde et les réponses au serveur) sont internes. Base les exécute déjà, et un second point d’entrée vers les mêmes étapes ferait la course avec sa propre exécution : une seconde identification considérerait le ticket comme accepté avant que le serveur ait répondu. Écrire un paquet au-dessus de baseImportez base, et faites await connect() avant d’agir. Elle se résout tout de suite si le personnage est déjà sur sa carte. Ne refaites pas ce que fait base. Les pings, les relances, la preuve d’identité et l’échange de carte ont déjà leur réponse. Les envoyer à nouveau ferait répondre le bot deux fois. Vérifiez session.shared avant d’agir. Sur un bot MITM, la personne qui joue contrôle le même personnage. Un paquet qui marche ou combat devrait y rester passif, ou demander d’abord. Déplacez-vous avec ce que base réexporte. move(), changeMap(), useElement(), travel() et les autres sont celles d’asterobot:movement : le bot fait un déplacement à la fois, et après un changement de carte, base charge la nouvelle carte comme il le fait pour chaque carte. Fixez une seule version de base. Deux versions chargées côte à côte répondraient toutes les deux au serveur. Ce qui se passe, étape par étapeLes attentes sont celles que le vrai client a prises dans la capture, à partir de 100 ms. Base ajoute un peu de bruit autour de chacune, et envoie tout le reste directement, dans l’ordre du client (voir Délais et bruit). Quand Base Serveur Tout de suite IdentificationRequest { ticketKey, languageCode } AuthenticationTicketAcceptedEvent, puis une rafale : TimeEvent, ServerSettingsEvent, informations de compte et de confiance, ServerSessionReadyEvent Tout de suite CharacterListRequest Tout de suite ClientChallengeInitRequest { challengeKey }, avec un uid QueueStatusEvent, tant que dure la file d’attente du serveur, puis CharacterListEvent 1,5 à 3,5 s plus tard, comme une personne qui clique CharacterSelectionRequest { characterId } CharacterSelectionEvent, puis CharacterLoadingCompleteEvent. C’est t0 ci-dessous. Tout de suite, à chaque fois SequenceNumberRequest { number } SequenceNumberEvent t0 + 1085 ms cinq réglages sociaux, tous vides, puis les maisons de guilde, les informations de guilde, la réinitialisation hebdomadaire de guilde t0 + 1349 ms ContextCreationRequest, puis le jeton de boutique, l’avertissement de connexion de guilde désactivé, SetCommunityChannelRequest { community } +231 ms l’étape de chaque quête en cours, les prix moyens (une fois par jour), puis les amis, les connaissances, le conjoint, les maisons de guilde MapCurrentEvent { mapId } 1,2 à 2,4 s plus tard, sur la première carte AnomalySubareaInformationRequest, ContextReadyRequest { mapId }, MapInformationRequest { mapId } MapComplementaryInformationEvent : connect() se résout Ensuite, tant que le script tourne : Tous les Base Serveur 10 s environ en moyenne PingRequest { quiet: true } PongEvent 4 minutes SequenceNumberRequest { number }, puis BasicLatencyStatsRequest { latency } avec un uid, les deux tout de suite SequenceNumberEvent et BasicLatencyStatsEvent, ensemble De temps en temps, à plusieurs minutes d’intervalle ClientIdRequest { id }, puis ClientChallengeProofRequest { proof }, chacun tout de suite, les deux avec un uid ServerVerificationEvent, puis ServerChallengeEvent { value }, la valeur étant parfois absente Nouvelle carte ContextReadyRequest + MapInformationRequest, 0,4 à 1,2 s plus tard MapCurrentEvent ou MapCurrentInstanceEvent Une heure après chaque clé BakApiTokenRequest BakApiKeyEvent APIimport { connect, latency, move, changeMap, useElement, travel, route, stopTravel, trip, findMaps, mapAt, mapInfo, nearest, nearestWith, mapsWithin, reachable } from "@asterobot:base"; import { run, stop, plan, conditions, levelAtLeast, kamasAtLeast, lifeBelow, bagsAbove, inFight, hasItem, jobLevelAtLeast, onMap, inSubarea, inArea } from "@asterobot:base"; import { steps, gather, harvestsAtLeast, fightMonsters, fightSettings, diedInLastFight, fightsAtLeast } from "@asterobot:base"; import { rest, eat, equip, unequip, wears, sell, buy, deposit, withdraw } from "@asterobot:base"; Export Renvoie Ce qu’il fait connect() Promesse de la carte Attend que le personnage soit sur sa carte. Base l’exécute déjà pendant son chargement. latency() nombre La latence que le bot déclare au serveur, en millisecondes. move() Promesse de la cellule d’arrivée Fait marcher le personnage vers une cellule de sa carte : celle d’asterobot:movement, réexportée. Sa référence est dans le guide du développeur d’Asterobot. changeMap() Promesse de la carte et de la cellule Emmène le personnage sur la carte suivante par un côté : celle d’asterobot:movement, réexportée. Base demande le contenu de la nouvelle carte, comme pour chaque carte. useElement() Promesse de ce qu’a fait l’utilisation Utilise une porte, un zaap, une ressource ou une sortie de la carte : celle d’asterobot:movement, réexportée. travel() Promesse de la carte et de la cellule Emmène le personnage sur n’importe quelle carte, aussi loin soit-elle, carte après carte : celle d’asterobot:movement, réexportée. Base demande le contenu de chaque nouvelle carte, comme pour chaque carte. route(), stopTravel(), trip() Le chemin que prendrait travel(), l’arrêt d’un voyage, et le voyage où il en est : celles d’asterobot:movement, réexportées. findMaps(), mapAt(), mapInfo(), nearest(), nearestWith(), mapsWithin(), reachable() Les fonctions qui trouvent les cartes où voyager : celles d’asterobot:movement, réexportées. run(), stop(), plan() Jouer un plan dessiné dans le Studio d’Asteroboard, l’arrêter, et ce qu’appelle un fichier de plan pendant son import : voir Plans. levelAtLeast(), kamasAtLeast(), lifeBelow(), bagsAbove(), inFight(), hasItem(), jobLevelAtLeast(), onMap(), inSubarea(), inArea() booléen, ou promesse d’un booléen L’état du personnage, sous forme de questions oui/non. conditions les déclare pour le Studio : voir Conditions sur l’état du jeu. gather(), harvestsAtLeast() Une promesse, un booléen Récolter les ressources de la carte, et combien de récoltes ont été faites. steps et conditions les déclarent pour le Studio : voir Récolter. fightMonsters(), fightSettings(), diedInLastFight(), fightsAtLeast() Une promesse, rien, des booléens Combattre : attaquer les groupes de monstres de la carte, régler le module de combat, et ce qu’ont donné les combats. steps et conditions les déclarent pour le Studio : voir Combattre. rest(), eat() Une promesse Récupérer de la vie, en s’asseyant et en mangeant ce que contiennent les sacs. steps les déclare pour le Studio : voir Se reposer et manger. equip(), unequip(), wears() Une promesse, une promesse, un booléen Mettre des objets, les retirer, et savoir si le personnage en porte un. steps et conditions les déclarent pour le Studio : voir L’équipement. sell(), buy() Une promesse Vendre ce que contiennent les sacs et acheter à l’hôtel des ventes du jeu. steps les déclare pour le Studio : voir L’hôtel des ventes. deposit(), withdraw() Une promesse Mettre en banque ce que contiennent les sacs, et en retirer des objets et des kamas. steps les déclare pour le Studio : voir La banque. steps, conditions des objets Les déclarations de toutes les étapes et conditions ci-dessus, que le Studio propose dans chaque paquet qui dépend de base. Tout le reste de la connexion se fait tout seul, donc base n’en exporte rien de plus. Un second point d’entrée vers les mêmes étapes ferait la course avec sa propre exécution. connect()const map = await connect(); Le premier appel, que base fait pendant son chargement, fait ceci dans l’ordre : Il enregistre les étapes clés de la session dans la mémoire du bot (voir Mémoire). Sur un bot Full socket, il commence à répondre au serveur : la preuve d’identité, les deux relances et les pings, et chaque carte (voir La preuve d’identité, Garder la connexion en vie et Suivre les cartes). Il identifie la connexion, sélectionne un personnage et entre dans le monde (voir les étapes). Elle se résout avec ce que renvoie currentMap() d’asterobot:bot une fois le personnage placé : { mapId, characterId, cellId, actors, elements }, elements étant les éléments interactifs de la carte et ce que chacun propose à cet instant. La même promesse à chaque fois pendant une exécution du script : chaque appel suivant l’attend simplement. Un échec est journalisé. La raison va dans la Console du bot sous forme de ligne d’erreur, et la promesse se rejette avec elle. S’arrêter n’est pas un échec. Une promesse rejetée parce que le script s’arrête ou que la connexion s’est fermée n’écrit rien dans la Console. Les étapesL’identification. Base envoie IdentificationRequest avec session.gameToken et session.language, puis attend jusqu’à 30 s la réponse du serveur. Il n’envoie jamais un second IdentificationRequest sur une même connexion. Un ticket refusé arrête tout : le ticket est consommé, et seule une nouvelle connexion au compte en apporte un autre. La sélection d’un personnage. Base joue le personnage que nomme le réglage character, ou le premier de la liste. Quand un combat attend l’un des personnages du compte, après une déconnexion en plein combat, le serveur choisit lui-même ce personnage, juste après la liste (CharacterForceSelectionEvent). Base répond alors aussitôt, comme le client (CharacterForceSelectionReadyRequest), joue ce personnage, et prévient dans la Console du bot quand le réglage character en nomme un autre. L’attente de la liste n’a pas de limite : elle arrive après la file d’attente du serveur, quelle que soit sa longueur. La réponse à la sélection est attendue jusqu’à 30 s, et le chargement jusqu’à 60 s. Elle échoue quand : le compte n’a aucun personnage sur le serveur ; aucun personnage ne porte le nom donné par le réglage (le message liste ceux qui existent) ; le serveur refuse la sélection. L’entrée dans le monde. Base envoie ce que le client envoie après le chargement (voir Entrer dans le monde), puis attend jusqu’à 60 s que le personnage soit placé sur sa carte. Les réponses au serveur tournent dès le départ, et tant que le script tourne. latency()La moyenne des 50 derniers allers-retours de ping du bot, en millisecondes, ou 0 avant le premier : arrondie au pair le plus proche, comme le fait le Math.Round du client ; puis ramenée à un entier signé sur 16 bits, comme le fait la conversion du client. Les allers-retours sont gardés dans la mémoire du bot, donc ils survivent à un redémarrage du script et à une reconnexion, comme dans un client qui reste ouvert. RéglagesBase a sa propre carte dans l’onglet Réglages du bot, quel que soit le paquet qui l’utilise. Réglage Valeurs Par défaut Ce qu’il change character Le nom d’un personnage Vide Le personnage à jouer, quelles que soient ses majuscules. Vide joue le premier de la liste, comme le fait la sélection automatique du client. community server, french, english, spanish, portuguese, german server La communauté de discussion que rejoint SetCommunityChannelRequest : 0 à 4 dans cet ordre. server envoie la community de ServerSettingsEvent, ou 0 s’il n’en a pas. ping active, idle active active envoie des pings comme une personne qui utilise le client, ce qui donne au serveur une vraie latence. idle n’en envoie jamais, comme un client que personne ne touche. Il continue de déclarer la dernière latence mesurée, ou 0 s’il n’a jamais envoyé de ping. bringUp faithful, minimal faithful faithful envoie tout ce que le client envoie après le chargement. minimal n’envoie que ContextCreationRequest, le seul message nécessaire pour atteindre la carte, et aucun jeton de boutique horaire. Les réglages sont lus au moment où ils servent, donc un changement s’applique à partir de la prochaine exécution de l’étape. Un changement de ping s’applique dès le battement suivant. PlansUn plan est un fichier d’un paquet, dessiné dans le Studio d’Asteroboard : des lieux sur la carte du monde, l’ordre dans lequel le bot en fait le tour, et ce qu’il fait à chacun, avec les fonctions d’un paquet ou la logique propre au Studio (attendre, attendre que, seulement si, réessayer…). Base le joue. Le format des plans décrit ce que contient le fichier. Jouer un planimport { run } from "@asterobot:base"; import main from "./plans/main.js"; // Les réglages du plan, dans l'onglet Réglages du bot. export { parameters } from "./plans/main.js"; export default async function behavior() { // Pas attendu ici, pour que Lancer rende la main tout de suite. void run(main); } C’est l’index.js qu’écrit le Studio quand il crée un paquet. Un script écrit à la main peut appeler run() n’importe où, autant de fois qu’il veut, un plan à la fois. Export Renvoie Ce qu’il fait run(plan, options?) Promesse Joue un plan : l’export par défaut d’un fichier de plan. Se résout quand le circuit se termine ou est arrêté, se rejette quand le plan échoue (voir Échecs). options est réservé : rien ne le lit encore. stop() booléen Demande au plan en cours de s’arrêter proprement. Dit s’il y en avait un. plan(data, refs) Le plan Appelée par un fichier de plan pendant son import, jamais à la main. Elle garde le plan et ce à quoi il fait référence, et ne lève jamais d’erreur : elle s’exécute pendant qu’Asterobot lit les déclarations du paquet sans bot, et une erreur à ce moment empêcherait le Studio de lire sa propre palette. run(plan) : Attend le monde, avec connect(). Vérifie tout le plan, et chaque plan qu’il joue par ses interruptions et ses étapes plan : le format, chaque sorte et chaque champ, chaque lieu choisi et chaque requête qui restreint la recherche (voir Les lieux), chaque paquet et chaque fonction qu’un appel nomme, chaque argument selon les règles des réglages, chaque argument omis qui n’a rien avec quoi jouer (sa valeur par défaut, sinon le zéro de son type, enfreint ses propres règles, ou il a un ref sans valeur par défaut), le nom et la valeur par défaut de chaque réglage, chaque $setting et la valeur par défaut du réglage qu’il nomme, chaque plan auquel il fait référence, au moins un arrêt. Au moindre problème, elle se rejette tout de suite en listant tous les problèmes, chacun avec le libellé et l’identifiant de son bloc, avant que le bot ne fasse un seul pas. Parcourt le circuit, tour après tour, jusqu’à sa fin. Un plan à la fois. run() pendant qu’un autre plan est joué se rejette tout de suite avec base: a plan is already running. Les plans qu’un plan joue lui-même, pour une interruption ou une étape plan, ne comptent pas. S’arrêter proprement. Un arrêt vient de stop(), d’une étape stop, ou d’Asterobot qui demande au script de s’arrêter, par exemple à la fin d’une plage du planning. L’étape en cours se termine alors (une étape longue voit context.stopping passer à vrai et peut finir plus tôt), un wait ou un waitUntil se termine tout de suite, un voyage s’arrête à la fin de son tronçon, et run() se résout, même s’il attendait encore le monde. Asterobot attend cela avant d’arrêter le script, dans le temps que le planning laisse pour finir. Un échec rejette run(). Rien n’attrape un void run(main), donc un plan qui échoue arrête le script, et la page du bot dit pourquoi. Attrapez-le pour faire autre chose. Un tourL’arrêt suivant : le suivant dans l’ordre où ils ont été dessinés (drawn), ou le plus proche qui a encore du travail (nearest). Si son when est faux, il est sauté pour ce tour. Son lieu donne ses cartes, visitées de la plus proche à la plus lointaine depuis l’endroit où se trouve le bot. Une carte qu’aucun voyage n’atteint est sautée, avec une ligne de console ; l’arrêt échoue quand aucune ne peut être atteinte. Sur chaque carte : travel() jusqu’à elle, sauf si le bot y est déjà, puis les interruptions, qui sont aussi la vérification avant la première étape ; puis chaque étape à son tour : son when, l’étape, son onFailure si elle échoue, et les interruptions de nouveau avant l’étape suivante. Quand une étape a emmené le bot ailleurs, comme une étape plan, il revient sur la carte avant l’étape suivante ; après la dernière, il continue directement. Après chaque arrêt, repeat.until, s’il y en a un. Le dernier arrêt d’un tour compte d’abord le tour, donc « jusqu’à 3 tours » se termine juste à la fin du troisième. À la fin d’un tour, once termine le circuit, et forever et until commencent le suivant. Un tour dure au moins une seconde : un circuit sans rien à rejoindre et sans rien qui attende, un seul arrêt sur la carte du bot, tournerait sinon sans jamais laisser le bot faire autre chose. Les cartes en attente. Une étape qui se résout avec { nothingToDo: true, retryAfter } laisse la carte de cet arrêt de côté pendant retryAfter secondes, ou jusqu’au tour suivant sans valeur. Les deux ordres sautent une carte en attente. nearest choisit la carte la plus proche d’un arrêt qui n’est pas en attente, et un tour se termine une fois que chaque arrêt a été joué ou est en attente. Quand toutes les cartes restantes sont en attente, le runner attend que la première ait de nouveau du travail plutôt que de tourner à vide. Les interruptions sont vérifiées dans l’ordre à l’arrivée sur chaque carte et avant chaque étape, jamais pendant une étape ou un voyage. C’est la vérification à l’arrivée qui permet d’interrompre aussi un circuit fait uniquement de points de passage. La première dont la condition est vraie joue son plan, imbriqué. Pendant que ce plan tourne, la même interruption n’est plus vérifiée, même depuis l’intérieur de ce plan, donc « sacs pleins : banque » ne peut pas relancer le trajet vers la banque depuis ce même trajet ; les interruptions propres au plan imbriqué s’appliquent bien. Ensuite : resume revient sur la carte où était le circuit, et reprend avec l’étape qu’il allait jouer ; stop termine le plan auquel appartient l’interruption. Avec resume, le plan de l’interruption doit rendre sa condition fausse : le trajet de banque vide les sacs. Quand la condition est encore vraie juste après le plan, le plan s’arrête avec une erreur qui nomme l’interruption, plutôt que de le rejouer environ une fois par seconde tant que le plan tourne. Un chance dans la condition ne compte pas contre elle, puisque la vérification suivante tire à nouveau. Les réglages d’un planUn plan peut déclarer des réglages, exactement sous la forme des réglages d’un paquet, et n’importe quel argument d’une fonction qu’il appelle peut prendre la valeur d’un réglage au lieu d’une valeur fixe : { "$setting": "monsters" }. Le réglage doit exister et avoir le type de l’argument. Le nom d’un réglage est un nom qu’un script pourrait écrire : des lettres, des chiffres et _, sans chiffre au début. Jamais __proto__, que l’objet littéral du fichier du plan lirait autrement, si bien que le réglage disparaîtrait. Un réglage déclare une valeur par défaut quand le zéro de son type enfreint ses propres règles (un int d’au moins 1 commencerait à 0), ou quand c’est une valeur seule avec un ref (0 serait un identifiant que personne n’a choisi) : la page du bot le fait commencer à cette valeur. Un argument lié convient à la valeur par défaut de son réglage. Tant que personne n’a réglé une autre valeur sur la page du bot, l’argument prend la valeur par défaut du réglage, sinon le zéro de son type, donc cette valeur doit passer les règles de l’argument lui-même : un réglage qui vaut 150 par défaut ne peut pas tenir lieu de pourcentage. Ils deviennent des réglages du paquet, dans l’onglet Réglages du bot, dès que l’entrée du paquet les réexporte. Le Studio propose d’écrire la ligne : export { parameters } from "./plans/main.js"; // un seul plan, rien d'autre à déclarer // ou, fusionnés avec ceux de l'entrée : import { parameters as mainSettings } from "./plans/main.js"; export const parameters = { ...mainSettings, myOwnSetting: { type: "int", default: 3 } }; Lus en direct. Le runner lit un réglage chaque fois qu’un argument s’en sert, donc une valeur changée sur la page du bot s’applique dès l’étape suivante. Sans réexport, le plan utilise la valeur par défaut de chaque réglage, et la Console le dit en une ligne avant que le bot ne bouge, en les nommant tous. Plusieurs plans d’un même paquet partagent les valeurs du bot : deux plans qui déclarent le même nom utilisent la même valeur, et doivent le déclarer avec le même type. Une valeur qui enfreint les règles de l’argument lui-même, comme 150 pour un pourcentage, fait échouer le bloc qui s’en sert. ÉchecsUne seule règle pour tout : un voyage, une étape ou une condition qui échoue arrête le plan, sauf si le plan dit autre chose. Les étapes et les arrêts ont chacun un onFailure : onFailure Alors absent, ou { "kind": "stop" } Le plan s’arrête avec l’erreur { "kind": "skip" } Une ligne de console, puis l’étape suivante (pour une étape) ou l’arrêt suivant (pour un arrêt) { "kind": "retry", "times": n, "wait": s, "then": "stop" \| "skip" } Réessayé jusqu’à n fois (1 à 10), à s secondes d’intervalle (5 par défaut). S’il échoue encore, then (stop par défaut). Un arrêt est réessayé en entier : sa condition, son lieu et toutes ses cartes. Ce qui fait échouer quoi : Ce qui arrive Ce qui échoue L’étape d’un paquet lève une erreur ou se rejette, un waitUntil dépasse son délai, le plan d’une étape plan échoue L’étape Le when d’une étape, ou la condition d’un waitUntil, échoue L’étape Le lieu d’un arrêt est introuvable, ou aucune de ses cartes n’est atteignable, un voyage vers l’une de ses cartes échoue, ou son when échoue L’arrêt. Une étape qui échoue ne regarde qu’elle-même, jamais son arrêt. La condition d’une interruption échoue, ou le plan qu’elle joue, ou avec resume sa condition est encore vraie après ce plan, ou repeat.until échoue Le plan, qui s’arrête Une condition échoue quand elle lève une erreur ou se rejette, comme le fait une condition sur l’état du jeu à propos d’un fait que le jeu n’a pas encore dit, ou quand elle répond autre chose que true ou false. Un when simplement faux saute son étape ou son arrêt, ce qui n’est pas un échec. Quand le plan s’arrête, le runner écrit l’erreur dans la Console, et run() se rejette avec elle. L’erreur nomme le bloc, par son libellé et son identifiant, puis la cause : base: Astrub farm › 2 Astrub fields (k3f9) › Fight (p2x1) failed 3 times: no monster to fight base: Astrub farm › 3 map 191105026 (m8q2) failed: travel: no known way leads to map 191105026 base: Astrub farm › interrupt Bank when full (i7w0) failed: condition Bags above (c0b2): the bags' weight isn't known yet base: Astrub farm › interrupt Bank when full (i7w0) is still true after its plan plans/bank.js ran: that plan must make it false, or it would run again and again Les lignes de console d’un planElles restent en anglais, telles que base les écrit : Niveau Ligne Quand info base: <plan> › <n> <stop> Un arrêt arrive : son numéro sur le circuit, puis son libellé, ou son lieu s’il n’en a pas info base: <plan> › <n> <stop> › <step> Une étape commence : une fonction par son libellé, une étape logique par ce qu’elle fait (wait 5–15 s, wait until, play plans/bank.js, stop) info base: <plan> › <n> <stop> › <message> Une étape log info base: <plan> › interrupt <label>: playing <path> La condition d’une interruption est vraie warn base: <block> failed, trying again in <s> s (<i> of <n>): <cause> Une étape ou un arrêt est réessayé warn base: <block> failed, skipped: <cause> Une étape ou un arrêt est sauté, avec <n> times après failed quand il a d’abord été réessayé warn base: <plan> › <n> <stop> (<id>): no trip reaches map <id>, skipped Les cartes d’un lieu qu’aucun voyage n’atteint, toutes sur une ligne warn base: <plan>: settings <name>, <name> aren't among the package's settings, so their defaults are used: re-export the plan's settings from the package's entry Une fois, avant de bouger, en nommant chaque réglage que l’entrée ne réexporte pas, de tous les plans que l’exécution peut jouer (setting <name> isn't one of the package's settings, so its default is used pour un seul) error base: <block> failed: <cause> Le plan s’arrête error base: <plan> can't be run: puis - <problème>, une ligne chacun La vérification a trouvé des problèmes <plan> est le libellé du plan, sinon son chemin dans le paquet, sinon plan quand son fichier ne donne pas son chemin. <block> est l’endroit où se trouve le bloc, avec les identifiants : <plan> › <n> <stop> (<id>) › <step> (<id>). Où en est le runnerPendant qu’un plan est joué, le runner garde l’endroit où il en est dans la mémoire du bot, sous @asterobot:base/plan : { plan: "plans/bank.js", stop: "k3f9", step: "p2x1", map: 191105026, lap: 2, connectionId: 7n } plan est le chemin du plan joué dans son paquet, null quand son fichier ne le donne pas. stop et step sont des identifiants de blocs ; step vaut null à l’arrivée sur une carte, avant sa première étape. Elle est écrite à l’arrivée sur chaque carte, au début de chaque étape, et quand un plan joué depuis là (celui d’une interruption, d’une étape plan) se termine, et retirée une fois que run() s’est terminée. Le Studio en direct d’Asteroboard la lira pour montrer où est le bot. Rien ne la lit encore. Le format des plansLe format 1 : ce que le Studio écrit, et ce que le runner lit. Le Studio écrit tout le fichier. Il est documenté ici pour qu’un runner et un Studio s’accordent dessus, et pour qu’un plan puisse se lire sans le Studio. Le fichierUn plan est un module .js, où qu’il soit dans le paquet. C’est sa première ligne qui en fait un plan : // asterobot-studio-plan v1 // Made in Asteroboard's Studio. Edit it there: changes made by hand are lost the next time the Studio saves it. import * as runner from "@asterobot:base"; import { values } from "asterobot:parameters"; import * as p0 from "@asterobot:farm"; import * as q0 from "./bank.js"; const data = /* studio:plan */ { "format": 1, "runner": "@asterobot:base", … } /* studio:end */; export const parameters = data.settings ?? {}; export default runner.plan(data, { path: "plans/astrub.js", packages: { "@asterobot:base": runner, "@asterobot:farm": p0 }, plans: { "plans/bank.js": () => q0.default }, settings: values, }); Le JSON entre /* studio:plan */ et /* studio:end */ est le plan. Tout le reste est généré à partir de lui. path : le chemin du fichier lui-même dans le paquet, qui nomme le plan dans les lignes de console quand il n’a pas de libellé, et dans où en est le runner. Un fichier sans lui reste un plan, dont le chemin est inconnu. packages : un import d’espace de noms par paquet qu’un call nomme, celui du runner compris. plans : un import par autre plan que le plan joue. Ils sont lus au dernier moment, () => q0.default, pour que deux plans qui se jouent l’un l’autre (ferme → banque → ferme) puissent s’importer mutuellement. Dans le JSON, les chemins sont relatifs au paquet (plans/bank.js) ; l’import est relatif au fichier (./bank.js). settings : values d’asterobot:parameters, qui dans ce fichier sont les réglages du paquet lui-même, pour que le runner lise les réglages du plan dans le bon paquet. parameters : les réglages du plan, déclarés comme ceux d’un paquet, pour que l’entrée les réexporte (voir Les réglages d’un plan). Le plan{ "format": 1, "runner": "@asterobot:base", "label": "Astrub farm", "settings": { "monsters": { "type": "array", "of": "int", "ref": "monsters", "label": "Monsters to fight", "default": [31, 34] } }, "circuit": { "order": "drawn", "repeat": { "kind": "forever" }, "stops": [ { "id": "k3f9", "label": "Astrub fields", "place": { "kind": "subarea", "id": 95 }, "steps": [ { "id": "p2x1", "kind": "call", "package": "@asterobot:farm", "step": "fight", "args": { "monsters": { "$setting": "monsters" } }, "when": { "id": "t5h2", "kind": "time", "from": "08:00", "to": "20:00" }, "onFailure": { "kind": "retry", "times": 2, "then": "skip" } }, { "id": "w4t6", "kind": "wait", "seconds": 5, "upTo": 15 } ] }, { "id": "m8q2", "place": { "kind": "map", "mapId": 191105026 }, "when": { "id": "n1t3", "kind": "not", "of": { "kind": "call", "id": "c5r1", "package": "@asterobot:base", "condition": "levelAtLeast", "args": { "level": 50 } } }, "steps": [] } ] }, "interrupts": [ { "id": "i7w0", "label": "Bank when full", "when": { "kind": "call", "id": "c0b2", "package": "@asterobot:base", "condition": "bagsAbove", "args": { "percent": 90 } }, "run": { "plan": "plans/bank.js" }, "then": "resume" } ] } Champ Signification format 1. Un runner refuse un format qu’il ne connaît pas runner Le paquet dont plan() et run() jouent le plan : @asterobot:base label Facultatif. Affiché dans le Studio et dans les lignes de console settings Facultatif. Les réglages du plan, par nom, chacun sous la forme d’un réglage de paquet (voir Les réglages d’un plan) circuit.order drawn : les arrêts dans leur ordre. nearest : l’arrêt le plus proche qui a encore du travail circuit.repeat { "kind": "once" }, { "kind": "forever" }, ou { "kind": "until", "until": <condition> } circuit.stops Les arrêts, dans l’ordre où ils ont été dessinés. Au moins un interrupts Facultatif. Vérifiées dans cet ordre Les quatre circuits du Studio sont des préréglages d’order et de repeat, et toute autre combinaison est valable aussi, comme un balayage jusqu’au niveau 50 : Circuit order repeat Boucle drawn forever Aller simple drawn once Balayage nearest forever Jusqu’à drawn until Les identifiants. Chaque bloc qu’une personne peut sélectionner (un arrêt, une étape, une condition, une interruption) a un id : 4 caractères parmi a-z et 0-9, unique dans le plan, donné par le Studio et jamais réutilisé. Les erreurs et la position du runner nomment les blocs par lui. Les arrêtsChamp Signification id, label Le libellé est facultatif place Où est l’arrêt (voir Les lieux) go Comment le bot s’y rend. Absent vaut { "kind": "travel" }, la seule sorte du format 1 when Condition facultative. Fausse quand l’arrêt arrive : l’arrêt est sauté pour ce tour onFailure Ce qui se passe quand l’arrêt échoue (voir Échecs) steps Jouées dans l’ordre, sur chaque carte du lieu. Vide pour un arrêt qui n’est qu’un point de passage Les lieuxkind Champs Cartes map mapId Cette carte maps mapIds, au moins une Ces cartes : une zone peinte dans le Studio subarea id findMaps({ subArea: id }), quand l’arrêt arrive area id findMaps({ area: id }), quand l’arrêt arrive query query : les champs de la requête de findMaps() (subArea, area, monster, resource, zaap, x, y, worldMap) findMaps(query), quand l’arrêt arrive Un lieu est choisi. Un map nomme son mapId, un subarea ou un area son id : un lieu que le Studio a passé à l’une de ces sortes n’a pas d’identifiant tant qu’on n’en a pas choisi un, et le runner refuse le plan plutôt que de deviner. 0 est un identifiant comme un autre : la zone 0 est Amakna. Une requête restreint la recherche : elle nomme au moins l’un de subArea, area, monster, resource, x, y, worldMap. Un zaap seul, ou rien du tout, prendrait toutes les cartes du jeu. Les identifiants tiennent dans ce que lit Asterobot. Les nombres d’une requête et l’id d’un subarea ou d’un area sont des nombres entiers qui tiennent sur 32 bits : de 0 à 2147483647, et à partir de -2147483648 pour x et y. Les identifiants de carte sont des nombres JSON, entiers et au-dessus de 0 : ceux de Dofus y tiennent largement. Un lieu subarea, area ou query suit les données de jeu de la version que joue le bot. Les étapesChaque étape a un id et un kind, et peut avoir un when, une condition vérifiée juste avant elle (fausse, elle saute l’étape, ce qui n’est pas un échec), et un onFailure. kind Champs Fait Échoue quand call package, step, args Joue une étape que donne un paquet. Un argument absent prend sa valeur par défaut déclarée ; un argument peut valoir { "$setting": "<nom>" } La fonction lève une erreur ou se rejette wait seconds (0 ou plus), upTo (facultatif, au moins seconds) Attend seconds, ou un temps tiré au hasard entre seconds et upTo Jamais waitUntil until (une condition), timeout (en secondes, facultatif) Vérifie la condition tout de suite, puis chaque seconde, jusqu’à ce qu’elle soit vraie Le délai passe avant, ou la condition échoue plan plan (un chemin dans le paquet) Joue ce plan ici, puis continue Le plan échoue log message Écrit le message dans la Console Jamais stop Termine tout le run(), plans imbriqués compris, comme une fin normale Jamais L’étape d’un paquet est une fonction run(args, context), éventuellement asynchrone, qui se résout avec rien (fait sur cette carte) ou avec { nothingToDo: true, retryAfter } (rien à faire sur cette carte, peut-être de nouveau dans retryAfter secondes). context vaut { map, stop, lap, stopping } : la carte où se trouve le bot, l’arrêt joué (son JSON), les tours faits à partir de 0, et si un arrêt est demandé. Le guide du développeur d’Asterobot explique comment un paquet déclare ses étapes et ses conditions pour le Studio. Le runner lit les déclarations d’un paquet comme Asterobot les lit : un default à null n’est pas une valeur par défaut (le zéro du type, ou le premier choix), un ref à null ou "" n’est pas un ref, un min ou un max qui n’est pas un nombre n’est pas une borne, un label qui n’est pas du texte n’en est pas un. Une déclaration veut donc dire la même chose pour Asterobot, le Studio et le runner. Les conditionskind Champs Vraie quand call id, package, condition, args La condition du paquet le dit. Les arguments comme pour une étape call all of : des conditions, au moins une Chacune l’est any of : des conditions, au moins une Au moins une l’est not of : une condition Elle ne l’est pas elapsed minutes (0 ou plus) Ce temps s’est écoulé depuis le début du run() de plus haut niveau laps count (1 ou plus) Le circuit a été fait au moins ce nombre de fois time from, to ("HH:MM") L’horloge de la machine qui fait tourner Asterobot indique de from, compris, à to, exclu. Un from après son to passe minuit chance percent (0 à 100) Un tirage au hasard, nouveau à chaque vérification, tombe sous percent Les conditions gardent un arrêt (when), une étape (when, un waitUntil), le circuit (repeat.until) et une interruption (when). La condition d’un paquet est une fonction run(args, context) qui renvoie un booléen ou une promesse d’un booléen. Les interruptionsChamp Signification id, label Comme pour un arrêt when Une condition run { "plan": "<chemin dans le paquet>" } : le plan à jouer then resume : retour là où en était le circuit. stop : le plan se termine Ce que ce runner ne connaît pasUn kind, un order, un repeat.kind, un then ou un champ que ce runner ne connaît pas, ou un paquet, une étape ou une condition que le fichier de plan ne lui donne pas : le runner refuse le plan avant de bouger, en nommant le bloc, et en disant que le plan demande un @asterobot:base plus récent ou un paquet manquant. Le format ne grandit que par des ajouts qui ne changent pas la lecture des plans existants ; tout le reste est un nouveau format. Conditions sur l’état du jeuL’état du personnage, sous forme de questions oui/non. Chacune est une fonction que base exporte, utilisable depuis le code, et déclarée dans les conditions de base, donc le Studio la propose dans chaque paquet qui dépend de base : Condition Arguments Vraie quand levelAtLeast level (int, 1 ou plus) Le niveau du personnage vaut au moins level kamasAtLeast kamas (int, 0 ou plus) Il porte au moins kamas kamas lifeBelow percent (int, 1 à 100) Sa vie est sous percent de son maximum bagsAbove percent (int, 1 à 100) Ses sacs sont remplis à plus de percent de ce qu’ils peuvent porter inFight Un combat est en cours hasItem item (int, un objet), count (int, 1 ou plus, 1 par défaut) Il porte au moins count exemplaires de item, équipés ou non jobLevelAtLeast job (int, un métier), level (int, 1 ou plus) Ce métier vaut au moins level. Un métier qu’il n’a pas est au niveau 0 onMap map (int, une carte) Il se trouve sur cette carte inSubarea subarea (int, une sous-zone) Il se trouve dans cette sous-zone inArea area (int, une zone) Il se trouve dans cette zone Le contraire de chacune est un not autour d’elle. Un objet, un métier, une carte, une sous-zone et une zone sont demandés avec un ref vers leur table de données de jeu (items, jobs, maps, sub_areas, areas), donc le Studio propose une recherche par nom. Elles lisent ce qu’Asterobot suit du personnage, asterobot:character, et de sa carte, currentMap() et mapInfo(). Un fait que le jeu n’a pas encore dit n’est jamais deviné : la condition lève une erreur qui le nomme, comme the level isn't known yet ou the jobs aren't known yet. Dans un plan, c’est l’échec du bloc que la condition garde, que son onFailure traite. Quand connect() se résout, le jeu a déjà envoyé le personnage, ses caractéristiques et son inventaire, donc cela concerne surtout un plan lancé plus tôt, ou une liste de métiers que le jeu n’a pas encore envoyée. Depuis le code, chacune prend ses arguments en un seul objet, comme le Studio les passe : import { bagsAbove, levelAtLeast } from "@asterobot:base"; if (levelAtLeast({ level: 50 }) && bagsAbove({ percent: 90 })) { // … } inSubarea() et inArea() renvoient une promesse, puisqu’elles cherchent la carte dans les données de jeu. RécolterRécolter, pour les plans comme pour les scripts : récolter les ressources de la carte avec l’action du métier, comme le client de jeu quand le joueur en clique une. Base déclare l’étape dans son export steps et la condition dans ses conditions, donc le Studio les propose dans chaque paquet qui dépend de base. Depuis le code, elles prennent leurs arguments en un seul objet, comme le Studio les passe : import { gather } from "@asterobot:base"; // 303, c'est le Bois de Frêne. await gather({ resources: [303], bagsAbove: 90 }); gatherRécolte les ressources de la carte qui conviennent, l’une après l’autre : Un combat en cours, comme l’agression d’un monstre de la carte, est attendu d’abord, joué par le module de combat, comme fightMonsters en attend un. La récolte continue ensuite. Elle choisit la ressource suivante que ses arguments laissent passer : la plus proche d’abord, à la distance en cellules depuis le personnage, ou celle du plus haut niveau d’abord. Elle utilise l’élément avec la compétence qui la récolte, comme le fait useElement() : le personnage marche jusqu’à portée de l’élément et le serveur commence la récolte. Elle attend ensuite la fin de la récolte, jusqu’à 5 s après la durée donnée par le serveur. Un élément dont l’utilisation échoue, pris par quelqu’un d’autre entre-temps ou hors de portée, est essayé une fois de plus, puis abandonné. Elle s’arrête quand plus rien ne convient, après maxHarvests récoltes, ou dès que les sacs sont plus remplis que bagsAbove. Quand rien ne convenait, il n’y avait rien à faire sur cette carte, et le plan n’y revient pas avant 60 s, le temps que les ressources repoussent. Elle échoue quand le personnage meurt dans un combat, avec the character died in the fight, et, sans jamais deviner, quand le jeu n’a pas encore dit les niveaux de métier ou le poids des sacs dont elle a besoin. Argument Type Par défaut Récolte resources array d’int, des objets aucun Ce qui donne ces objets, comme 289, le Blé. Avec jobs, ce que l’un ou l’autre demande jobs array d’int, des métiers aucun Chaque ressource de ces métiers. Ni resources ni jobs : chaque ressource de la carte avoid array d’int, des objets aucun Jamais ce qui donne ces objets myLevel bool true Seulement ce que le niveau du personnage dans le métier permet. Le serveur refuserait le reste order nearest, level nearest La plus proche d’abord, ou la ressource du plus haut niveau d’abord, la plus proche à égalité maxHarvests int, 0 ou plus 0 Termine l’étape après ce nombre de récoltes sur la carte. 0 : tout ce qui convient bagsAbove int, 0 à 100 0 Termine l’étape dès que les sacs sont plus remplis que cette part de ce qu’ils peuvent porter. 0 : jamais Ce qu’offre une carte, c’est ce qu’Asterobot en suit : les éléments de currentMap() et les compétences que chacun offre en ce moment, un élément récolté n’offrant plus rien jusqu’à ce qu’il repousse. La table skills des données du jeu dit quel objet chaque compétence récolte, pour quel métier, à partir de quel niveau, et maps__interactive_elements où se trouve chaque élément. La condition de récolteCondition Arguments Vraie quand harvestsAtLeast count (int, 1 ou plus) Le personnage a fait au moins count récoltes avec gather depuis le démarrage du script CombattreCombattre, pour les plans comme pour les scripts : attaquer les groupes de monstres de la carte, que le module de combat d’Asterobot joue, régler la façon dont le module joue tant que le plan tourne, et ce qu’ont donné les combats. Base déclare les deux étapes dans son export steps et les deux conditions dans ses conditions, donc le Studio les propose dans chaque paquet qui dépend de base. Depuis le code, chacune prend ses arguments en un seul objet, comme le Studio les passe : import { fightMonsters, fightSettings } from "@asterobot:base"; fightSettings({ profile: "Prudent" }); await fightMonsters({ monsters: [4109], maxLevel: 30 }); fightMonstersAttaque les groupes de monstres de la carte qui conviennent, le plus proche d’abord, l’un après l’autre, et attend la fin de chaque combat : Un combat en cours, celui de l’étape ou un autre venu autrement, comme une agression, est attendu d’abord. Elle choisit le groupe le plus proche que ses arguments laissent passer, à la distance en cellules depuis le personnage. Sur un bot Full socket, elle active le module de combat, tant que le script tourne, quand il est désactivé : un combat ne peut pas avancer sans lui. Sur un bot MITM, l’interrupteur reste celui de la personne, et module désactivé, elle joue le combat elle-même. Elle marche jusqu’à la cellule du groupe et envoie AttackMonsterRequest avec l’identifiant du groupe, comme le client de jeu. Quand le serveur ne lance aucun combat dans les 5 s, le groupe s’est déplacé ou n’est plus là : base marche de nouveau et attaque depuis sa nouvelle cellule, et renonce à un groupe après trois attaques. Une fois le combat fini, elle attend jusqu’à 10 s le contenu de la carte, qui revient avec les groupes, et passe au suivant. Elle s’arrête quand plus aucun groupe ne convient, ou après maxFights combats. Quand aucun groupe ne convenait, il n’y avait rien à faire sur cette carte, et le plan n’y revient pas avant 60 s, le temps que des groupes reviennent. Elle échoue quand le personnage meurt dans un combat, avec the character died in the fight : il n’est plus sur la carte, et le onFailure de l’étape décide de la suite. Argument Type Par défaut Garde les groupes monsters array d’int, des monstres aucun Avec au moins un de ces monstres. Aucun : n’importe quel groupe avoid array d’int, des monstres aucun Sans aucun de ces monstres races array d’int, des races de monstres aucune Avec un monstre de l’une de ces races. Aucune : n’importe quelle race minLevel int, 0 ou plus 0 Dont le niveau, la somme des niveaux de ses monstres comme le jeu l’affiche, vaut au moins celui-ci maxLevel int, 0 ou plus 0 Dont le niveau vaut au plus celui-ci. 0 : sans limite maxMonsters int, 0 à 8 0 Avec au plus ce nombre de monstres. 0 : sans limite maxMonsterLevel int, 0 ou plus 0 Sans monstre au-dessus de ce niveau. 0 : sans limite archmonsters avoid, allow, only avoid Sans archimonstre, avec ou sans, ou seulement avec un. Un archimonstre est un monstre que les données du jeu marquent ainsi, le isMiniBoss du client maxFights int, 0 ou plus 0 Termine l’étape après ce nombre de combats sur la carte. 0 : chaque groupe qui convient Les groupes et leurs monstres sont ce qu’Asterobot suit de la carte : les acteurs de currentMap() et leurs monsters. Les races et les archimonstres viennent de la table monsters des données du jeu. fightSettingsRègle la façon dont le module de combat joue tant que le script tourne, comme le fait asterobot:fight. Ce qu’elle laisse à keep, ou un profil vide, reste comme le disent les réglages du bot, et ce qu’elle règle dure jusqu’à l’arrêt du script. Argument Valeurs Par défaut Règle module keep, on, off keep L’interrupteur du module. Sur un bot MITM, l’interrupteur reste celui de la personne profile Le nom d’un profil de combat vide Le profil que le bot joue, par son nom sur la page Profils de combat. Vide garde celui en vigueur speed keep, slow, normal, turbo keep La vitesse Les conditions de combatCondition Arguments Vraie quand diedInLastFight Le personnage est mort dans son dernier combat. Fausse avant le premier fightsAtLeast count (int, 1 ou plus) Le personnage a livré au moins count combats depuis le démarrage du script Toutes deux suivent chaque combat du bot à partir des événements du module de combat (onFight), dès que base démarre, quel que soit celui qui a lancé le combat. Se reposer et mangerRécupérer de la vie, pour les plans comme pour les scripts : s’asseoir, comme un joueur avec l’émote assis, et manger ce que contiennent les sacs. Base déclare les deux étapes dans son export steps, donc le Studio les propose dans chaque paquet qui dépend de base. Depuis le code, chacune prend ses arguments en un seul objet, comme le Studio les passe : import { rest } from "@asterobot:base"; // Manger ce que contiennent les sacs, puis s'asseoir pour le reste, jusqu'à 90 % de la vie. await rest({ upTo: 90, eat: true }); La vie est ce qu’Asterobot suit du personnage, character().life, qui compte la régénération que le serveur lance entre deux caractéristiques, plus rapide assis. Les objets sont ses piles, items(). restS’assoit jusqu’à ce que la vie revienne à une part de son maximum : Rien à faire quand la vie y est déjà. Avec eat, il mange d’abord, comme eat. Il s’assoit avec l’émote du client de jeu, EmotePlayRequest { emoteId: 1 }, l’émote 1 des données de jeu, S’asseoir, que le serveur confirme avec EmotePlayEvent. Une émote que le serveur ne confirme pas dans les 5 s n’est pas renvoyée, puisque la même émote relève le personnage : la vie revient tout de même debout, plus lentement. Une fois la vie à upTo, il se relève avec la même émote, au moins 1,2 s après s’être assis, le temps de recharge de l’émote. Le serveur confirme avec l’émote 0. Un combat qui survient entre-temps, et qui relève le personnage, est attendu comme fightMonsters en attend un, puis il se rassoit. Elle échoue quand le personnage meurt dans un combat, avec the character died in the fight ; quand la vie ne change plus pendant une minute, avec the character's life isn't coming back ; et, sans jamais deviner, tant que le jeu n’a pas dit la vie, avec the character's life isn't known yet. Argument Type Par défaut Ce qu’il fait upTo int, de 1 à 100 100 Se relève dès que la vie atteint cette part de son maximum eat bool false Mange d’abord ce que contiennent les sacs, ce qui est plus rapide food array de int, des objets aucun Ne mange que ces objets. Aucun : toute nourriture qui rend de la vie eatMange ce que contiennent les sacs jusqu’à ce que la vie revienne à une part de son maximum : Il choisit la nourriture : une pile des sacs dont les effets dans les données de jeu rendent de la vie (action 110 : pains, potions, viandes, poissons, boissons), seulement les objets de food quand ils sont donnés. Celle qui soigne le plus sans dépasser ce qui manque passe d’abord, sinon celle qui soigne le moins. Il en utilise une, comme le client de jeu pour un objet sans cible : ObjectUseRequest { objectUid }. Il attend que la pile diminue, puis que la vie monte avec les caractéristiques suivantes. Une nourriture que le serveur ne prend pas dans les 5 s est abandonnée pour le reste de l’étape. Il attend de 0,6 à 1,2 s entre deux, au rythme d’une personne. Rien à faire quand la vie y est déjà, ou quand les sacs n’ont rien à manger. Un combat entre-temps est attendu, comme dans rest. Elle prend upTo et food, comme rest. L’équipementMettre et retirer des objets, pour les plans comme pour les scripts, comme le joueur les glisse dans un emplacement ou de nouveau dans les sacs. Base déclare les deux étapes dans son export steps et la condition dans ses conditions : import { equip, unequip, wears } from "@asterobot:base"; // 1439 et 852 : Mauvaise Pioche et Petit Anneau Magique. if (!wears({ item: 1439 })) await equip({ items: [1439, 852] }); Les emplacements où un objet peut aller viennent de ses données de jeu : les possible_positions du super-type de son type, donc un anneau va à l’une ou l’autre main et un Dofus dans l’un des six emplacements de Dofus. La requête est celle du client de jeu, ObjectSetPositionRequest { objectUid, position, quantity: 1 }, que le serveur confirme avec ObjectMovementEvent ; un objet déjà dans l’emplacement retourne dans les sacs avec le sien. equipMet les items, l’un après l’autre au rythme d’une personne, chacun dans un emplacement libre où il peut aller, sinon dans son premier emplacement, ce qui renvoie l’objet qui s’y trouvait dans les sacs. Un objet déjà porté reste comme il est. Elle échoue pour un objet qui n’est pas dans les sacs, avec item 1439 isn't in the bags, un objet qui ne se porte pas, avec item 1439 can't be worn, et un objet que le serveur n’a pas déplacé dans les 5 s, avec the game didn't move item 1439. Rien à faire quand chacun est déjà porté. unequipRetire les items, de nouveau dans les sacs, l’un après l’autre au rythme d’une personne, ou tout ce que porte le personnage si aucun n’est donné. Elle échoue pour un objet que le serveur n’a pas déplacé dans les 5 s, comme equip. Rien à faire quand aucun n’est porté. La condition d’équipementCondition Arguments Vraie quand wears item (int, un objet) Le personnage porte cet objet L’hôtel des ventesVendre ce que contiennent les sacs et acheter, à l’hôtel des ventes du jeu, pour les plans comme pour les scripts, comme le fait un joueur dans la fenêtre d’hôtel des ventes du client de jeu. Base déclare les deux étapes dans son export steps : import { buy, sell } from "@asterobot:base"; // 289 est le Blé, 468 le Pain d'Incarnam. await sell({ items: [289], under: 1, floor: 70 }); await buy({ items: [468], upTo: 20, maxPrice: 50 }); Les deux utilisent l’hôtel des ventes de la carte où se tient le personnage : son comptoir, l’élément interactif qui offre la compétence 355, que le client utilise de n’importe où sur la carte. Sa range vaut 63 dans les données de jeu, donc useElement() ne marche pas jusqu’à lui. Un plan va d’abord sur la carte de l’hôtel des ventes, comme pour n’importe quel autre lieu. Les deux échouent avec there's no marketplace on this map quand aucun élément n’offre la compétence, et avec the marketplace's window didn't open quand le serveur ne l’ouvre pas dans les 5 s. Elles ferment la fenêtre en finissant, même sur un échec, avec DialogLeaveRequest, dont le client envoie l’unique champ à sa valeur zéro, KIO_EUZF. Ce que dit la fenêtre en s’ouvrant, ExchangeBidBuyerStartedEvent.sellingConditions, décide de ce que chaque étape y fait : les types d’objets que l’hôtel des ventes prend, son maxItemLevel, ses tailles de lot quantities (1, 10, 100 et 1000 dans chaque hôtel des ventes de la table auction_houses des données de jeu), sa taxPercentage (2), et npcContextualId (-1), l’identifiant de PNJ du comptoir. sellMet en vente les objets demandés, depuis les sacs : Rien à faire quand les sacs n’en contiennent aucun : la fenêtre n’est pas ouverte. Elle ouvre la fenêtre, qui s’ouvre sur son onglet Achat, puis passe à l’onglet Vente comme une personne le clique, 0,7 à 1,1 s plus tard : InventoryUpdateMergedInventoryTypeRequest { mergedInventoryType: MERGED_INVENTORY_TYPE_BID_HOUSE }, puis NpcGenericActionRequest { npcActionId: 5, npcId: -1, npcMapId }, dans la même frame. Le serveur ferme l’onglet Achat, ExchangeLeaveEvent, et ouvre ExchangeBidSellerStartedEvent, avec les lots du compte en vente. Pour chaque pile, elle passe un objet d’un type que l’hôtel des ventes ne prend pas, ou au-dessus de son niveau maximum. Elle choisit l’objet comme le client, dans une seule frame : elle cesse de suivre l’objet suivi avant, ExchangeBidHouseSearchRequest { objectGid, follow: false }, suit celui-ci, { follow: true }, et demande ses prix, ExchangeBidHousePriceRequest { objectGid }. ExchangeBidPriceEvent répond avec le lot le moins cher de chaque taille, minimalPrices, le prix moyen d’un objet, averagePrice, et allIdentical. Un objet dont les lots ne sont pas tous identiques, comme un équipement qui a ses propres caractéristiques, reste dans les sacs : ses caractéristiques font son prix. Elle fixe le prix de chaque taille une fois pour la pile, comme ci-dessous, et met les lots en vente l’un après l’autre : ExchangeObjectMovePricedRequest { objectUid, quantity, price }, avec l’uid de la pile, la taille du lot et le prix du lot entier. Le serveur prend sa taxe et confirme avec ExchangeBidHouseItemAddedEvent. Une personne tape le prix d’un lot, 2 à 5 s, puis clique de nouveau pour le lot suivant de la même taille, 0,6 à 1 s ; l’objet suivant vient 0,7 à 1,1 s après le dernier lot d’une pile. Elle ferme la fenêtre 1,5 à 5 s après le dernier lot. Les lots sont les plus gros que chaque pile remplit, 1000, puis 100, 10 et 1, ou autant d’une seule taille que lot en demande : ce qui n’en remplit pas un reste dans les sacs. Le prix d’un lot est : under kamas sous le lot le moins cher de sa taille en vente. Un lot du compte qui est déjà le moins cher, listé par ExchangeBidSellerStartedEvent ou mis en vente par cette étape, garde son prix : base ne se coupe jamais l’herbe sous le pied. Sans lot de cette taille en vente, le prix moyen pour autant d’objets. Jamais sous floor pour cent du prix moyen pour autant d’objets, aussi bas que vendent les autres. Elle arrête de mettre des lots en vente quand le personnage ne peut pas payer la taxe, la taxPercentage du prix arrondie, avec base: not enough kamas for the marketplace's tax on <item> (<tax> kamas), et quand le serveur ne confirme pas un lot dans les 5 s, avec base: the marketplace took no more lots of <item>: it may be full, or the account may have as many lots on sale as it can. Aucune capture n’a encore ce refus. Elle écrit ce qu’elle a mis en vente de chaque objet, comme base: put on sale Bakélélite: 1 × 10 at 129993, 2 × 1 at 13871 kamas, et se résout en { nothingToDo: true } quand elle n’a rien mis en vente. Argument Type Par défaut Ce qu’il fait items array de int, des objets aucun Vend ces objets. Avec jobs, ce que l’un ou l’autre demande jobs array de int, des métiers aucun Vend chaque ressource que récoltent ces métiers, d’après la table skills des données de jeu. Ni items ni jobs : rien n’est vendu lot int : 0, 1, 10, 100 ou 1000 0 0 : les plus gros lots que chaque pile remplit. Sinon, des lots de cette taille seulement under int, 0 ou plus, kamas 1 De combien sous le lot le moins cher de la même taille. 0 : le même prix floor int, de 0 à 100 70 Jamais sous cette part du prix moyen. 0 : pas de plancher buyAchète les objets demandés jusqu’à ce que le personnage ait upTo de chacun, portés ou dans les sacs, comme itemCount() les compte : Rien à faire quand il en a assez de chacun : la fenêtre n’est pas ouverte. Elle échoue sans maxPrice, avec buying needs the most to pay per item, maxPrice : base n’achète jamais à n’importe quel prix. Elle ouvre la fenêtre, sur son onglet Achat. Pour chaque objet, elle passe un objet d’un type que l’hôtel des ventes ne prend pas. Elle choisit le type de l’objet comme une personne, 1,5 à 4 s plus tard, ExchangeBidHouseTypeRequest { typeId, follow: true }, auquel ExchangeTypesExchangerDescriptionForUserEvent répond avec les objets de ce type en vente. Puis l’objet, 1,2 à 2,5 s plus tard : elle cesse de suivre l’objet suivi avant et suit celui-ci, auquel ExchangeTypesItemsExchangerDescriptionForUserEvent répond avec ses annonces. Une ressource a une seule annonce, avec le prix du lot le moins cher de chaque taille. Un objet qui a ses propres caractéristiques en a une par objet, et n’est pas acheté. Elle achète des lots l’un après l’autre, à 1,5 à 3 s d’intervalle : le lot qui coûte le moins par objet parmi ceux qui n’achètent pas plus que ce qui manque et coûtent au plus maxPrice par objet, le plus gros à égalité. ExchangeBidHouseBuyRequest { objectUid, price, quantity } nomme l’uid de l’annonce, le prix du lot entier tel qu’affiché et sa taille, et ExchangeBidHouseBuyResultEvent répond avec bought. Les prix de l’annonce suivent ExchangeBidHouseInListUpdatedEvent, qui arrive à mesure que les lots se vendent, ses propres achats compris. Une fois un objet fini, elle cesse de le suivre deux fois, 0,1 à 0,3 s plus tard, comme le client. Elle ferme la fenêtre 0,3 à 1 s après le dernier objet. Elle arrête d’acheter un objet quand aucun lot ne convient, avec base: no lot of <item> at <maxPrice> kamas each or less fits the <n> missing, et quand le serveur ne vend pas le lot, avec base: the marketplace didn't sell the lot of <size> <item>: someone may have bought it first. Elle arrête tout quand le personnage ne peut pas payer un lot. Elle écrit ce qu’elle a acheté de chaque objet, comme base: bought Incarnam Bread: 2 × 10 at 450 kamas, et se résout en { nothingToDo: true } quand elle n’a rien acheté. Argument Type Par défaut Ce qu’il fait items array de int, des objets aucun Achète ces objets upTo int, 1 ou plus 1 Combien de chacun le personnage doit avoir. Elle achète ce qui manque maxPrice int, 1 ou plus, kamas aucun Le plus qu’elle paie pour un objet. Obligatoire : la vérification d’un plan le demande La capture de l’hôtel des ventesUne capture du client 3.7.12.12 du 2026-10-29, heures en UTC : deux lots de 1 et un de 10 de Bakélélite (749) à l’hôtel des ventes des ressources, 1261, sur la carte 212601350 ; un objet qui a ses propres caractéristiques (6716) à l’hôtel des ventes 1265, sur la carte 212601345 ; et deux lots de 10 achetés à 1265, sur la carte 73532928. Heure Message Ce qu’il portait 13:07:42.652 → InteractiveUseRequest élément 522694, le comptoir, instance de compétence 8731 13:07:42.682 ← ExchangeBidBuyerStartedEvent hôtel des ventes 1261, tailles 1, 10, 100, 1000, taxe 2 %, niveau maximum 200 13:07:43.442 → InventoryUpdateMergedInventoryTypeRequest, NpcGenericActionRequest MERGED_INVENTORY_TYPE_BID_HOUSE ; action 5, PNJ -1, carte 212601350 13:07:43.474 ← ExchangeLeaveEvent, ExchangeBidSellerStartedEvent l’onglet Achat se ferme ; les lots du compte en vente 13:07:43.479 → ExchangeBidHouseSearchRequest ×2, ExchangeBidHousePriceRequest 749 plus suivi, suivi ; ses prix 13:07:43.509 ← ExchangeBidPriceEvent moins cher 13872, 129994, 1399999, aucun ; moyenne 13010 ; identiques 13:07:47.215 → ExchangeObjectMovePricedRequest pile 2003241, 1 à 13871 13:07:47.245 ← KamasUpdateEvent, ExchangeBidHouseItemAddedEvent, ObjectQuantityEvent 277 kamas de taxe ; le lot ; 11 restants 13:07:48.010 → ExchangeObjectMovePricedRequest pile 2003241, 1 à 13871 13:07:59.409 → ExchangeObjectMovePricedRequest pile 2003241, 10 à 129993, son dernier : ObjectDeletedEvent 13:08:04.526 → DialogLeaveRequest 13:08:56.395 ← ExchangeBidPriceEvent objet 6716 : moins cher 99998, moyenne 1172559, pas identiques 13:12:34.888 → ExchangeBidHouseTypeRequest type 326 13:12:36.659 → ExchangeBidHouseSearchRequest 33326 suivi 13:12:36.690 ← ExchangeTypesItemsExchangerDescriptionForUserEvent annonce 73541 : 500, 4500, 49896, aucun 13:12:38.939 → ExchangeBidHouseBuyRequest annonce 73541, 10 à 4500 13:12:38.970 ← ExchangeBidHouseInListUpdatedEvent, KamasUpdateEvent, ObjectAddedEvent, ExchangeBidHouseBuyResultEvent les nouveaux prix de l’annonce ; les kamas ; la pile ; acheté 13:12:39.256 → ExchangeBidHouseSearchRequest ×2 33326 plus suivi, deux fois 13:12:42.440 → DialogLeaveRequest La taxe est la taxPercentage du prix, arrondie : 277 kamas pour 13871, 2600 pour 129993, 2400 pour 119999. Chaque fois que la fenêtre s’ouvre ou se ferme, le serveur renvoie tout l’inventaire, InventoryContentEvent. La banqueMettre en banque ce que contiennent les sacs et en retirer des objets et des kamas, pour les plans comme pour les scripts, comme le fait un joueur dans la fenêtre de banque du client de jeu. Base déclare les deux étapes dans son export steps : import { deposit, withdraw } from "@asterobot:base"; // Tout sauf le pain, puis 20 pains pour se reposer. 468 est le Pain d'Incarnam. await deposit({ keep: [468] }); await withdraw({ items: [468], upTo: 20 }); Les deux utilisent le banquier de la carte où se tient le personnage : le plus proche des acteurs de currentMap() qui ont npc: true. Un plan va d’abord sur la carte de la banque, comme pour n’importe quel autre lieu. Pour ouvrir la banque : Une personne clique le banquier une fois la carte affichée, 0,6 à 1 s plus tard : NpcGenericActionRequest { npcActionId: 3, npcId, npcMapId }, l’action générique qui parle. Le serveur répond avec la première réplique du dialogue, NpcDialogQuestionEvent, et ses réponses. La réponse de la banque est celle dont les actions comptent l’action 196. Ses dialogParams portent le prix de la banque. Base la choisit 0,6 à 0,9 s plus tard, comme une personne lit la réplique : NpcDialogReplyRequest { replyId }. Le serveur termine le dialogue, prend le prix, et ouvre la banque : ExchangeStartedWithStorageEvent, puis StorageInventoryContentEvent avec les piles et les kamas de la banque, que base suit avec StorageObjectUpdateEvent, StorageObjectRemovedEvent et StorageKamasUpdateEvent tant que la fenêtre est ouverte. Les deux échouent avec there's no banker on this map quand aucun acteur n’est un PNJ, avec the banker didn't answer et the bank didn't open quand le serveur ne répond pas dans les 5 s, et avec the NPC on this map doesn't offer the bank quand le dialogue du PNJ le plus proche n’a pas de réponse de banque. Ce dialogue reste ouvert : quitter le dialogue d’un PNJ n’est pas encore dans une capture. Elles déplacent une pile à la fois, comme une personne les glisse, 1,2 à 3 s après l’ouverture de la banque, puis à 0,5 à 1,5 s d’intervalle : ExchangeObjectMoveRequest { objectUid, quantity }, avec l’uid des sacs et une quantité positive pour mettre une pile en banque, l’uid de la banque et une quantité négative pour en retirer une. Asterobot voit chaque pile arriver et partir, donc items() et Bags above restent justes. Elles ferment la fenêtre 0,4 à 1,2 s après le dernier déplacement, avec DialogLeaveRequest, comme l’hôtel des ventes. Chacune écrit ce qui a bougé, comme base: put in the bank: 37 Manganese, 395 Iron, 700 kamas. depositMet en banque chaque pile des sacs sauf les objets à garder, keep, ou seulement les items et ce que récoltent les jobs quand ils sont donnés. Les objets portés restent portés. Le serveur confirme une pile avec ObjectDeletedEvent, ou ObjectQuantityEvent pour une partie. Une pile qu’il ne confirme pas dans les 5 s reste, avec base: the bank didn't take <item>, et les autres continuent. Avec kamas, elle met en banque les kamas que le personnage porte au-delà de keepKamas une fois le prix de la banque payé, avec ExchangeMoveKamaRequest { quantity }, que StorageKamasUpdateEvent confirme. Rien à faire quand il n’y a rien à mettre en banque : le banquier n’est pas sollicité. Argument Type Par défaut Ce qu’il fait items array de int, des objets aucun Ne met en banque que ces objets. Avec jobs, ce que l’un ou l’autre demande. Ni l’un ni l’autre : tout ce que contiennent les sacs jobs array de int, des métiers aucun Ne met en banque que ce que récoltent ces métiers keep array de int, des objets aucun Ces objets restent dans les sacs, comme la nourriture, les potions ou un équipement de rechange kamas bool false Met aussi des kamas en banque keepKamas int, 0 ou plus 0 Les kamas laissés sur le personnage, pour les zaaps et le prix de la banque withdrawRetire de la banque les items jusqu’à ce que le personnage en ait upTo de chacun, portés ou dans les sacs, comme itemCount() les compte, dans autant de piles de la banque qu’il le faut. Le serveur confirme avec StorageObjectRemovedEvent, ou StorageObjectUpdateEvent pour une partie d’une pile, et les sacs reçoivent la pile avec ObjectAddedEvent. Un objet que la banque n’a pas est écrit base: no <item> in the bank. Avec kamasUpTo, elle retire des kamas jusqu’à ce que le personnage en porte autant une fois le prix payé, dans la limite de ceux de la banque, avec un ExchangeMoveKamaRequest négatif. Rien à faire quand le personnage a déjà assez de tout. Argument Type Par défaut Ce qu’il fait items array de int, des objets aucun Retire ces objets upTo int, 1 ou plus 1 Combien de chacun le personnage doit avoir. Elle retire ce qui manque kamasUpTo int, 0 ou plus 0 Retire des kamas jusqu’à ce que le personnage en porte autant. 0 : aucun Les captures de la banqueDeux captures du client 3.7.12.12 du 2026-10-29, heures en UTC. La première est la visite à la banque de la capture de l’hôtel des ventes, sur la carte 217059328 : Heure Message Ce qu’il portait 13:08:16.497 ← MapComplementaryInformationEvent le banquier, acteur -20000 sur la cellule 289, un PNJ 13:08:17.227 → NpcGenericActionRequest action 3, PNJ -20000, carte 217059328 13:08:17.259 ← NpcDialogCreationEvent, NpcDialogQuestionEvent réplique 47810, prix 468 ; réponses 63535, avec l’action 196, et 63536 13:08:17.894 → NpcDialogReplyRequest réponse 63535 13:08:17.925 ← DialogLeaveEvent, TextInformationEvent, KamasUpdateEvent, ExchangeStartedWithStorageEvent, StorageInventoryContentEvent le dialogue se termine ; 468 kamas payés ; la banque s’ouvre avec ses piles et ses kamas 13:08:19.498 → ExchangeMoveKamaRequest -249819, tous les kamas de la banque 13:08:21.274 → ExchangeObjectMoveRequest pile 386568, 12 en banque 13:08:21.304 ← StorageObjectUpdateEvent, ObjectDeletedEvent la pile de la banque pour cet objet, désormais 18 ; la pile des sacs disparue 13:08:36.356 → ExchangeObjectMoveRequest pile de la banque 386564, -1 retiré 13:08:36.386 ← ObjectAddedEvent, StorageObjectRemovedEvent l’objet dans les sacs ; la pile de la banque disparue 13:08:45.519 → DialogLeaveRequest Six autres objets sont sortis à 0,5 à 0,65 s d’intervalle, puis deux à 2,6 et 3,2 s. La deuxième capture, une visite à la banque à part, a des piles mises en banque entières et en partie : Heure Message Ce qu’il portait 13:58:55.296 → ExchangeObjectMoveRequest 1 en banque, d’une pile de 37 13:58:55.326 ← ObjectQuantityEvent, InventoryWeightEvent 36 restants 13:58:56.794 → ExchangeObjectMoveRequest les 36 restants en banque 13:58:56.825 ← ObjectDeletedEvent la pile des sacs disparue 13:59:05.001 → ExchangeObjectMoveRequest une pile de 395 en banque 13:59:07.008 → ExchangeObjectMoveRequest 20 retirés 13:59:07.038 ← ObjectAddedEvent une pile de 20 dans les sacs 13:59:08.240 → ExchangeObjectMoveRequest les 20 de nouveau en banque La fenêtre de la banque a aussi des boutons qui déplacent plusieurs piles à la fois. En retirer plusieurs envoie ExchangeObjectTransferListToInventoryRequest { objectsUid } (13:58:52.773 dans la deuxième capture), et le serveur répond avec un message qu’Asterobot ne lit pas encore, isl. En mettre plusieurs en banque a ses propres requêtes, comme ExchangeObjectTransferListFromInventoryRequest, dont les réponses ne sont pas lues non plus. Base déplace une pile à la fois à la place, pour qu’Asterobot voie chaque pile. Les profils de combatBase fournit 24 profils de combat pour le module de combat d’Asterobot, prêts à jouer. Une fois base installé, ils sont sur la page Profils de combat avec la source Paquet, et dans la liste Profil de chaque bot, sous le nom @asterobot:base/<clé> : @asterobot:base/careful, @asterobot:base/ranged-kite… Un bot en joue un qu’il joue base lui-même ou non, et chaque bot le joue dans la version de base la plus récente installée : mettre base à jour les met à jour dès le combat suivant. Chacun est indépendant de la classe : aucun ne nomme de sort, donc chacun joue n’importe quelle classe à n’importe quel niveau, avec les sorts et l’arme du personnage. Quand son but n’est pas un rôle, un profil ne donne pas de rôle, donc chaque classe garde celui que le jeu lui donne en premier (un Féca soutient, un Eniripsa soigne), ni de portée, donc il combat à la portée que font ses sorts. Ce qu’un profil ne donne pas est la valeur du profil par défaut. Clé Ce qu’il fait Ce qu’il règle careful Prudent : ne finit jamais un tour là où les ennemis peuvent le blesser gravement, et se cache dès que sa vie est basse risk 15, poids safety 2 ; sous 35 % de vie, se replie à couvert all-in Tout pour l’attaque : inflige le plus de dégâts possible et ignore le danger, mort comprise risk 100 ; poids damage 1,2, kill 1,5, safety 0,25 melee-charge Se place près, fonce sur l’ennemi le plus proche et frappe au contact range melee, placement close, positioning charge ranged-kite Se place loin, frappe à distance, puis sort de la portée des ennemis range ranged, placement far, positioning kite, risk 40 ranged-hide Se place loin, frappe à distance, puis finit son tour hors de la vue des ennemis range ranged, placement far, positioning hide, risk 30 hold-position Ne bouge que pour atteindre un lancer, pour garder taclés les ennemis à côté de lui positioning hold, risk 60 finish-the-weakest Achève d’abord l’ennemi qui a le moins de vie focus lowestLife, poids kill 2 kill-the-most-dangerous Tue d’abord l’ennemi qui peut le blesser le plus là où il se tient focus mostDangerous, poids kill 1,5 healer Soigneur : soigne d’abord l’allié le plus faible, puis lui-même, et frappe quand personne n’a besoin de soin role healer, allies protect ; un allié sous 60 % est soigné d’abord, puis lui-même sous 40 % bodyguard Garde du corps : protège ses alliés, boucliers et boosts pour le plus faible, et se place pour les abriter allies protect, risk 70, poids buff 1,5 ; un allié sous 50 % est boosté d’abord support Affaiblit les ennemis et booste ses alliés avant de frapper role support, allies help, risk 40 tank Passe devant, encaisse les coups pour l’équipe et tacle les ennemis au contact role tank, range melee, placement close, positioning charge, allies protect, risk 85, poids control 2 crowd-control Contrôle : pousse les ennemis, leur retire PA et PM et leur donne des états avant de les frapper risk 50, poids control 3 summoner Invocateur : invoque dès qu’il peut et reste derrière ses invocations, hors de la vue des ennemis positioning hide, risk 35, poids summon 2,5 trapper Poseur de pièges : pose pièges et glyphes là où les ennemis vont passer, puis reste hors de leur portée range mid, positioning kite, risk 40, poids mark 2,5 earth-strength Préfère ses sorts de terre, pour un personnage force elements earth fire-intelligence Préfère ses sorts de feu, pour un personnage intelligence elements fire water-chance Préfère ses sorts d’eau, pour un personnage chance elements water air-agility Préfère ses sorts d’air, pour un personnage agilité elements air weapon-fighter Frappe avec son arme dès qu’il peut, au contact weapon.use prefer, range melee, placement close, positioning charge spells-only Ne frappe jamais avec l’arme ni à mains nues : ses PA vont à ses sorts weapon.use never team-player Joueur d’équipe : ne blesse jamais un allié avec ses zones, et soigne et booste ses alliés dès que ça aide allies protect ; poids allyHarm 10, heal 1,5, buff 1,5 carried Un bas niveau dans un groupe fort : se place loin, reste hors de danger et de vue, et ne frappe que sans risque placement far, positioning hide, risk 0, poids safety 3 ; sous 50 % de vie, se replie à couvert boss-fight Pour les boss et les donjons : prudent, tue d’abord l’ennemi le plus dangereux et garde le groupe à l’abri focus mostDangerous, allies protect, risk 25 ; sous 40 % de vie, se replie à couvert Ce que fait chaque réglage est dans le guide d’Asterobot, Combats > Réglages du profil, et le format dans son guide du développeur, Fight profile format. Pour en jouer un, choisissez-le dans la liste Profil d’un bot, dans son onglet Combat ; depuis un plan, avec l’étape Fight settings et son nom (@asterobot:base/careful) ; depuis un script, avec setProfile("@asterobot:base/careful") d’asterobot:fight. Pour l’adapter, sur la page Profils de combat, copiez-le avec Copier dans vos propres profils pour le modifier, ou faites un profil qui l’extends et ne donne que ce qui change : { "version": 1, "name": "Cra prudent", "extends": "@asterobot:base/careful", "elements": ["air"] }. Celui qui l’étend suit les mises à jour de base. Leurs clés ne changent pas. Un bot réglé sur l’un d’eux le garde d’une mise à jour de base à l’autre. Pour en garder un exactement tel quel, copiez-le dans vos propres profils. Ce sont les fichiers JSON de fightprofiles/, un par profil, chacun nommé d’après sa clé et tel que la page Profils de combat exporte un profil : c’est ainsi qu’un paquet fournit des profils. Ce sont des données, jamais exécutées. La preuve d’identitéUne fois la session ouverte, le serveur de jeu demande au client de prouver qu’il détient une clé secrète. C’est une preuve d’identité de Schnorr en trois échanges : ServerSessionReadyEvent -> ClientChallengeInitRequest challengeKey = G^x mod P ServerVerificationEvent -> ClientIdRequest id = G^k mod P ServerChallengeEvent { c } -> ClientChallengeProofRequest proof = (k + c*x) mod Q P est le nombre premier de 768 bits de la RFC 2409, section 6.1, « Oakley group 1 ». G = 2, et Q = (P - 1) / 2. x est le secret du client, tiré une fois par processus client. k est un nonce, tiré à nouveau pour chaque ServerVerificationEvent. Le serveur vérifie que G^proof = id × challengeKey^c (mod P). Base ne fait aucun de ces calculs. Il appelle publicKey(), commitment() et proof(value) d’asterobot:verification, qui s’adressent au code Go d’Asterobot (ankama/game/network/verification), et envoie les chaînes qu’elles renvoient. Les secrets n’entrent jamais dans JavaScript. x et k restent en Go. Un script ne voit que ce qui part sur le réseau. x appartient au bot. Il est tiré une fois à la création du bot et gardé toute sa vie, d’un script à l’autre et d’une reconnexion à l’autre, comme un processus client le garde. La même clé publique est publiée à chaque connexion. k est remplacé à chaque engagement. Un second ServerVerificationEvent avant le défi remplace le nonce, et la preuve répond au plus récent, comme le fait le client. Un défi absent reçoit aussi une réponse. Quand ServerChallengeEvent ne porte aucune valeur, proof(undefined) calcule le défi lui-même, comme le fait le client : le SHA-256 de G, de la clé publique, de l’engagement et de l’empreinte de l’appareil envoyée à la connexion du bot. Les deux cas arrivent : le défi d’une capture portait une valeur, celui d’une autre était vide. La part de base, c’est l’enveloppe et l’ordre : Chaque réponse part dès que son événement arrive. Le client répond à sa trame suivante, 6 à 55 ms plus tard selon sa charge, ce qui reste du bruit sous celui du réseau. Le serveur attend chaque réponse avant son étape suivante, donc les trois ne peuvent pas se croiser. Extrait d’une capture : 00:14:08.961 IN ServerVerificationEvent 00:14:08.968 OUT ClientIdRequest #10 00:14:08.997 IN ServerChallengeEvent (no value) 00:14:09.003 OUT ClientChallengeProofRequest #11 Les trois réponses portent un uid, comme celles du client, envoyées avec send(..., { correlated: true }). Rien n’y répond jamais. Les calculs sont couverts par les tests de ankama/game/network/verification dans Asterobot. Ils vérifient le groupe d’après le texte de la RFC, et l’équation du serveur sur chaque branche. Ils vérifient aussi deux vrais contrôles auxquels le client Dofus a répondu, tirés de captures d’un même lancement du jeu : Contrôle Connexion Défi uids La preuve du client 1 c3 aucun : le client le calcule #10, #11 se vérifie avec le défi qu’Asterobot calcule 2 c7 une valeur de 255 bits venue du serveur #12, #13 se vérifie avec cette valeur Le groupe, la preuve et les deux branches sont donc confirmés face au vrai client, pas seulement lus dans son code. Les deux contrôles se vérifient avec la même clé, envoyée sur c3 : le client garde son secret pendant tout le lancement, d’une connexion à l’autre, comme Asterobot en garde un par bot d’une reconnexion à l’autre. Garder la connexion en vieLe serveur relance le client avec deux événements à la fois, dans la même milliseconde et tous deux vides : SequenceNumberEvent et BasicLatencyStatsEvent. Extrait d’une capture du client : 23:57:26.192 IN SequenceNumberEvent 23:57:26.192 IN BasicLatencyStatsEvent 23:57:26.192 OUT SequenceNumberRequest { number: 3 } no uid 23:57:26.200 OUT BasicLatencyStatsRequest { latency: 44 } #5 SequenceNumberEventLe client répond tout de suite avec SequenceNumberRequest { number }, envoyé sans uid : number est le nombre de relances que cette connexion a reçues, celle à laquelle il répond comprise, donc la première réponse vaut 1 ; le compte est gardé dans la mémoire du bot, par connexion. Un script relancé sur la même connexion continue de compter. Le serveur a envoyé chaque relance, il peut donc vérifier le nombre exactement. BasicLatencyStatsEventLe client répond avec BasicLatencyStatsRequest { latency } une trame après la séquence, 8 à 30 ms dans les captures. Il porte un uid, et rien n’y répond. Base envoie latency() juste après le SequenceNumberRequest de la même relance, dans l’ordre du client. Les paires arrivent toutes les 4 minutes, selon l’horloge du serveur plutôt qu’à partir de la connexion : à la seconde 26 d’une minute dont le reste de la division par 4 vaut 1, dans deux sessions. La première arrive 0 à 4 minutes après le chargement du personnage. Un SequenceNumberEvent de plus arrive seul, sans question de latence, pendant le chargement du personnage ; il compte comme la première relance, donc 7 paires plus tard la réponse est number: 8. Chaque paire consomme un uid, un contrôle en consomme deux, et les requêtes numérotées du jeu les leurs : chaque requête numérotée prend l’uid suivant. Dans une session, ClientChallengeInitRequest était #2, puis : Relance Heure Réponse de latence 3 23:57:26 #5 (contrôle) 00:14:08 ClientIdRequest #10, ClientChallengeProofRequest #11 9 00:21:26 #13 Les relances 2 et 3 seules donneraient #3 et #4 : une autre requête numérotée est partie avant la relance 3 dans cette session. Base puise dans le même compteur, donc les mêmes requêtes reçoivent les mêmes numéros. PingsUn vrai client n’envoie de pings que lorsqu’une personne l’utilise : toutes les 5 secondes avec son option de ping rapide, sur les battements où il y a eu une action. Avec ping sur active, base reproduit cela : un battement de 5 secondes qui envoie PingRequest { quiet: true } environ une fois sur deux ; seulement une fois le personnage chargé ; chaque PongEvent qui répond à un ping en cours ajoute son aller-retour aux échantillons dont latency() fait la moyenne, et un pong sans ping en cours est ignoré. Entrer dans le mondeCe que le client envoie après CharacterLoadingCompleteEvent, dans l’ordre. Le client espace certains de ces messages d’une trame ou deux, 10 à 90 ms ; base envoie chaque groupe d’un seul tenant et ne garde que les attentes de 100 ms et plus : Quand Messages Avec minimal t0 + 1085 ms ContactWarnOnAchievementCompleteSetRequest, FriendSetWarnOnConnectionRequest, FriendSetWarnOnLevelGainRequest, ContactWarnOnPermanentDeathSetRequest, FriendSetStatusShareRequest, tous vides : le client rejoue ses options sociales, et un bot n’en a aucune Attend pareil, n’envoie rien ensuite GuildInformationRequest { informationType: INFO_HOUSES }, GuildInformationRequest { informationType: INFO_GENERAL }, GuildWeeklyNextResetRequest Sauté t0 + 1349 ms ContextCreationRequest Envoyé ensuite BakApiTokenRequest, GuildMemberWarnOnConnectionStopRequest, SetCommunityChannelRequest { community } Sauté +231 ms QuestStepInformationRequest { questId } pour chaque quête en cours, deux fois : un passage par identifiant, puis le même passage à nouveau Sauté ensuite ObjectAveragePricesRequest, seulement s’il n’a pas encore été demandé aujourd’hui (UTC) Sauté ensuite FriendListRequest, AcquaintanceListRequest, SpouseInformationRequest, GuildInformationRequest { informationType: INFO_HOUSES } Sauté Les étapes de quête suivent le journal. Le serveur envoie QuestsEvent, le journal de quêtes du personnage, pendant son chargement. Une fois dans le monde, le client demande l’étape de chaque quête en cours, chaque quête deux fois. Dans les captures : 1631, 1631 avec une quête en cours, et 1631, 1637, 1631, 1637 avec deux. Seul ContextCreationRequest est nécessaire pour atteindre la carte. Le reste est ce qui fait ressembler le bot à un client. Le premier écart se mesure à partir du chargement lui-même. Un script relancé en retard n’attend pas une seconde fois la seconde entière. Le jeton de boutique reste frais. Avec faithful, base envoie de nouveau BakApiTokenRequest une heure après chaque BakApiKeyEvent, comme le fait le client. Suivre les cartesChaque MapCurrentEvent { mapId } nomme la carte sur laquelle le serveur a mis le personnage. Pour une carte instanciée, le serveur envoie MapCurrentInstanceEvent { mapId, instantiateMapId } à la place, et base le traite de la même façon avec son mapId : instantiateMapId ne sert à rien, comme dans le client. Il arrive avec un TimeEvent, l’horloge du serveur, auquel rien ne répond. Le client charge l’asset de la carte depuis ses propres fichiers, puis dit qu’il est prêt : Il attend un temps aléatoire entre 1,2 et 2,4 s pour la première carte de la session, et entre 0,4 et 1,2 s ensuite. Dans les captures, une première carte a pris 2,4 s une fois et 1,197 s une autre, et les cartes suivantes 1,19 s et 407 ms, une carte déjà chargée auparavant allant plus vite. Sur la première carte seulement, il envoie AnomalySubareaInformationRequest. Il envoie ContextReadyRequest { mapId }, puis MapInformationRequest { mapId }, l’un après l’autre, avec l’identifiant qu’a donné MapCurrentEvent ou MapCurrentInstanceEvent. Le serveur répond avec MapComplementaryInformationEvent, un aller-retour plus tard, et le suivi de carte d’Asterobot place le personnage : currentMap() a son cellId. Le serveur n’envoie rien de la nouvelle carte avant l’arrivée de ces deux requêtes. Dans une capture, les 1,19 s entre MapCurrentEvent et les requêtes ne portaient aucun message entrant : 21:19:44.838 IN MapChangeOrientationEvent, MapCurrentEvent, TimeEvent 21:19:46.028 OUT ContextReadyRequest + MapInformationRequest same map id 21:19:46.058 IN MapComplementaryInformationEvent Le client déclenche les deux requêtes à partir d’un même événement interne, son moteur de rendu qui démarre sur la carte chargée, donc il n’envoie jamais l’une sans l’autre. Base non plus. Quand un MapCurrentEvent ou un MapCurrentInstanceEvent plus récent arrive alors qu’une carte est encore en chargement, seule la carte la plus récente est annoncée. La carte d’un combat n’est pas touchée. Quand un combat commence, le serveur nomme la carte où il se déroule, et le client y répond autrement (FightPingsRequest, puis ContextReadyRequest). Le module de combat d’Asterobot y répond tant qu’il est activé, et rien ne doit le faire quand il est désactivé : base n’annonce donc jamais une carte nommée pendant un combat. La carte nommée une fois le combat fini est annoncée comme les autres. Avec changeMap() et useElement(). Elles se résolvent une fois le contenu de la nouvelle carte arrivé, donc elles attendent que base le demande. Base le dit à Asterobot avec answerMapLoads(), et Asterobot n’envoie alors jamais lui-même les deux requêtes, quel que soit le temps que prend base : sur un bot qui utilise base, elles partent une seule fois, de base, au rythme du client, même sur un PC lent. Sur un bot dont aucun script ne charge les cartes, Asterobot les envoie lui-même, au rythme du client lui aussi. Mémoire, et reprise en cours de routeLes variables propres d’un script disparaissent après Arrêter, un rechargement ou Lancer depuis l’éditeur, alors que le bot et sa connexion de jeu continuent. Un script relancé sur la même connexion ne doit pas tout recommencer : le serveur n’accepte pas un second IdentificationRequest ; le personnage est déjà sélectionné ; le serveur a compté chaque relance. Base garde donc ce qu’il sait dans la mémoire du bot, que tous les scripts du bot partagent et qui survit à chacun d’eux. Clé Ce qu’elle contient @asterobot:base/connection L’état de la connexion de jeu actuelle, à côté de session.connectionId. Une valeur enregistrée pour une autre connexion, d’avant une reconnexion du bot, est ignorée. @asterobot:base/latency { samples } : les 50 derniers allers-retours de ping, en millisecondes. @asterobot:base/prices { day } : le jour UTC du dernier ObjectAveragePricesRequest. @asterobot:base/plan Où en est le plan joué, tant qu’il l’est : voir Où en est le runner. L’état de la connexion a ces champs. Chacun est absent tant que son étape n’a pas eu lieu. Champ Défini quand id Toujours : le session.connectionId auquel il appartient identified IdentificationRequest va être envoyé. Il est défini avant l’envoi, donc un script arrêté entre les deux n’en envoie jamais un second. accepted, refused Le serveur a répondu au ticket serverCommunity ServerSettingsEvent est arrivé characterId Le serveur a sélectionné un personnage activeQuests QuestsEvent est arrivé : les identifiants des quêtes en cours loadedAt CharacterLoadingCompleteEvent est arrivé (Date.now()) bringUp Les requêtes d’après le chargement ont commencé à partir contextCreated ContextCreationRequest va être envoyé anomalyAsked AnomalySubareaInformationRequest va être envoyé pendingMapId La dernière carte nommée par MapCurrentEvent ou MapCurrentInstanceEvent readyMapId La dernière carte pour laquelle ContextReadyRequest est parti sequence Le nombre de SequenceNumberEvent arrivés bakKeyAt Le dernier BakApiKeyEvent est arrivé Ce que fait un script relancé sur la même connexion, selon l’endroit où le précédent s’est arrêté : Le script précédent s’est arrêté Le nouveau Avant d’envoyer IdentificationRequest S’identifie Après l’avoir envoyé, avant la réponse Ne le renvoie pas. Il considère le ticket comme accepté, puisque la connexion est toujours ouverte, et avertit dans la Console. Avant qu’un personnage soit sélectionné Demande la liste et sélectionne Après la sélection, avant la fin du chargement Attend le chargement Après le chargement, avant que les réglages sociaux partent Envoie tout ce qui suit le chargement Après le début de l’envoi des réglages sociaux, avant ContextCreationRequest Saute les groupes sociaux et de guilde, puis envoie ContextCreationRequest et tout ce qui suit Après ContextCreationRequest N’envoie plus rien de ce qui suit le chargement. Les groupes que le script précédent n’a pas atteints sont sautés, pas envoyés en retard. Pendant le chargement d’une carte Annonce cette carte N’importe où après Se résout tout de suite avec la carte actuelle Après une reconnexion, session.connectionId est nouveau, l’état de connexion enregistré est ignoré, et tout recommence. La page du bot affiche ces clés dans Outils > Mémoire. Réagir à ce que base répondUn message va à chaque gestionnaire qui l’écoute, donc le fait que base réponde à un message ne le retire pas à votre paquet. Vos propres on() et wait() reçoivent chaque message auquel base répond, MapCurrentEvent compris, sur les deux sortes de bots. Ce script note chaque changement de carte, puis la cellule où arrive le personnage : import "@asterobot:base"; import { currentMap, botInfo, botWarn } from "asterobot:bot"; import { on, wait } from "asterobot:protocol"; export default async function behavior(launch) { on("MapCurrentEvent", async (traffic) => { const mapId = traffic.payload?.mapId; if (mapId === undefined) return; botInfo("Heading to map", mapId); try { // Son contenu arrive une fois la carte chargée, un instant après ceci. await wait( (next) => next.type === "MapComplementaryInformationEvent" && next.payload?.mapId === mapId, { timeout: 10000 }, ); botInfo("On map", mapId, "cell", currentMap()?.cellId); } catch (error) { // Une erreur qui s'échappe d'un gestionnaire arrête tout le script. botWarn("Never arrived on map", mapId, String(error)); } }); } Ne répondez pas à ce à quoi base répond. Sur un bot Full socket, envoyer vous-même ContextReadyRequest, MapInformationRequest, ou les réponses à la preuve d’identité et aux relances atteindrait le serveur deux fois. Tout le reste vous appartient : noter, enregistrer, consulter, planifier. Quand MapCurrentEvent arrive, la nouvelle carte n’est pas encore chargée. Base dit qu’il est prêt 0,4 à 2,4 s plus tard, et c’est seulement alors que le serveur envoie son contenu. D’ici là, currentMap() nomme déjà la nouvelle carte, mais sans acteurs ni cellId. Pour agir dessus, attendez son MapComplementaryInformationEvent, comme ci-dessus. Les identifiants sont des BigInt. Comparez-les avec des BigInt, comme mapId === 153879301n. findPath() prend un identifiant de carte en BigInt, et record() d’asterobot:gamedata non : passez-lui Number(mapId). Les cartes instanciées sont annoncées avec MapCurrentInstanceEvent au lieu de MapCurrentEvent. Écoutez les deux pour voir chaque changement de carte. Les gestionnaires de base passent avant les vôtres, parce que base se charge avant votre code. Rien n’en dépend. Sur un bot MITMSur un bot MITM, une personne joue le personnage avec son propre client Dofus, qui fait lui-même tout ce qui précède. Base n’envoie alors absolument rien : il ne répond ni à la preuve d’identité, ni aux relances, ni aux cartes, et n’envoie jamais de ping : le client s’en charge ; il ne s’identifie pas, puisque le client l’a déjà fait ; il prend le personnage déjà sélectionné, ou attend que la personne en sélectionne un ; connect() se résout dès que le personnage se trouve sur une carte, sans limite de temps. Il suit quand même la session, donc un paquet construit sur base lit les mêmes choses sur les deux sortes de bots et attend le monde de la même façon. Un paquet qui agit, qui marche ou qui combat, devrait vérifier lui-même session.shared, puisque la personne qui joue contrôle le même personnage. La personne qui joue est aussi protégée : le signalement de mod loader du client Dofus n’arrive jamais chez Ankama. Le client envoie un message, YoshiRequest, quand il trouve un mod loader dans son dossier d’installation (MelonLoader, BepInEx, dotnet, ou les DLL qu’un mod loader génère). Sur un bot MITM, Asterobot empêche ce message d’atteindre le serveur de jeu dès le début de la session, avant Play, avec ou sans base, et la Console du bot affiche Kept the game client's mod-loader report from the game server à chaque fois. Base n’a rien à faire pour cela, et un bot Full socket n’envoie jamais ce message. Tous les messages que base envoieMessage Quand uid Réglage IdentificationRequest Une fois par connexion aucun CharacterListRequest Après l’acceptation du ticket aucun CharacterSelectionRequest Après la liste aucun character CharacterForceSelectionReadyRequest CharacterForceSelectionEvent : un combat attend l’un des personnages du compte aucun ClientChallengeInitRequest ServerSessionReadyEvent oui ClientIdRequest ServerVerificationEvent oui ClientChallengeProofRequest ServerChallengeEvent oui SequenceNumberRequest SequenceNumberEvent aucun BasicLatencyStatsRequest BasicLatencyStatsEvent oui PingRequest Le battement de ping aucun ping Les cinq réglages sociaux Après le chargement aucun bringUp GuildInformationRequest ×3, GuildWeeklyNextResetRequest Après le chargement aucun bringUp ContextCreationRequest Après le chargement aucun BakApiTokenRequest Après le chargement, puis toutes les heures aucun bringUp GuildMemberWarnOnConnectionStopRequest Après le chargement aucun bringUp SetCommunityChannelRequest Après le chargement aucun bringUp, community QuestStepInformationRequest Après le chargement, deux fois pour chaque quête en cours aucun bringUp ObjectAveragePricesRequest Après le chargement, une fois par jour aucun bringUp AttackMonsterRequest L’étape fightMonsters, une fois sur la cellule du groupe aucun EmotePlayRequest L’étape rest : pour s’asseoir, puis pour se relever aucun ObjectUseRequest L’étape eat, et rest avec eat : une fois par nourriture mangée aucun ObjectSetPositionRequest Les étapes equip et unequip : une fois par objet déplacé aucun InventoryUpdateMergedInventoryTypeRequest, NpcGenericActionRequest L’étape sell : passer à l’onglet Vente de l’hôtel des ventes aucun ExchangeBidHouseSearchRequest Les étapes sell et buy : cesser de suivre et suivre chaque objet aucun ExchangeBidHousePriceRequest L’étape sell : les prix de chaque objet aucun ExchangeObjectMovePricedRequest L’étape sell : une fois par lot mis en vente aucun ExchangeBidHouseTypeRequest L’étape buy : le type de chaque objet aucun ExchangeBidHouseBuyRequest L’étape buy : une fois par lot acheté aucun NpcGenericActionRequest, NpcDialogReplyRequest Les étapes deposit et withdraw : parler au banquier, et choisir la réponse de la banque aucun ExchangeObjectMoveRequest Les étapes deposit et withdraw : une fois par pile déplacée aucun ExchangeMoveKamaRequest Les étapes deposit et withdraw : une fois, quand des kamas bougent aucun DialogLeaveRequest Les étapes sell, buy, deposit et withdraw : fermer la fenêtre aucun FriendListRequest, AcquaintanceListRequest, SpouseInformationRequest Après le chargement aucun bringUp AnomalySubareaInformationRequest Première carte de la connexion aucun ContextReadyRequest, MapInformationRequest Chaque MapCurrentEvent et MapCurrentInstanceEvent aucun « oui » signifie un uid qui lui est propre, comme le client l’envoie. GuildWeeklyNextResetRequest n’en a pas, bien que le serveur y réponde avec une Response : cette réponse revient elle aussi avec l’uid -1. Tous les messages que base litMessage Ce que base en fait AuthenticationTicketAcceptedEvent, AuthenticationTicketRefusedEvent Termine l’identification ServerSettingsEvent Garde community pour le réglage server ServerSessionReadyEvent, ServerVerificationEvent, ServerChallengeEvent Répond à la preuve d’identité QueueStatusEvent Écrit la position dans la file d’attente dans la Console CharacterListEvent Choisit le personnage CharacterForceSelectionEvent Le serveur a choisi le personnage qu’un combat attend : base lui répond et joue ce personnage QuestsEvent Garde les identifiants des quêtes en cours, dans activeQuests. Le serveur l’envoie pendant le chargement du personnage, sans qu’on le demande. CharacterSelectionEvent, CharacterLoadingCompleteEvent Terminent la sélection du personnage SequenceNumberEvent, BasicLatencyStatsEvent, PongEvent Maintien de la connexion BakApiKeyEvent Planifie le prochain jeton de boutique MapCurrentEvent Annonce la carte MapCurrentInstanceEvent Annonce une carte instanciée MapComplementaryInformationEvent Résout connect() ; après un combat, l’étape fightMonsters continue une fois qu’il est arrivé ContextCreationEvent L’étape fightMonsters : le combat que son attaque a lancé InteractiveUseEndedEvent L’étape gather : la fin d’une récolte EmotePlayEvent L’étape rest : la réponse du serveur quand le personnage s’assoit et se relève ExchangeBidBuyerStartedEvent Les étapes sell et buy : la fenêtre de l’hôtel des ventes s’est ouverte, avec ses conditions de vente ExchangeBidSellerStartedEvent L’étape sell : l’onglet Vente, avec les lots du compte en vente ExchangeBidPriceEvent L’étape sell : les prix d’un objet ExchangeBidHouseItemAddedEvent L’étape sell : un lot en vente ExchangeTypesExchangerDescriptionForUserEvent, ExchangeTypesItemsExchangerDescriptionForUserEvent L’étape buy : les objets d’un type en vente, et les annonces d’un objet ExchangeBidHouseInListUpdatedEvent, ExchangeBidHouseBuyResultEvent L’étape buy : les prix d’une annonce à mesure que les lots se vendent, et si un lot a été acheté NpcDialogQuestionEvent Les étapes deposit et withdraw : la réplique du banquier et ses réponses StorageInventoryContentEvent, StorageObjectUpdateEvent, StorageObjectRemovedEvent, StorageKamasUpdateEvent Les étapes deposit et withdraw : ce que contient la banque tant qu’elle est ouverte, et une pile ou des kamas déplacés ObjectDeletedEvent, ObjectQuantityEvent L’étape deposit : une pile mise en banque ExchangeLeaveEvent Les étapes sell, buy, deposit et withdraw : la fenêtre s’est fermée TrustStatusEvent Avertit quand la session n’est pas certifiée SystemMessageDisplayEvent Avertit quand le serveur met fin à la session FileCheckEvent Avertit : base n’y répond pas Lignes de console et erreursLes lignes que base écrit dans la Console du bot à propos de la connexion. Elles restent en anglais, telles que base les écrit. Les lignes propres à un plan sont dans Les lignes de console d’un plan. Niveau Ligne Signification info base: playing <name> Le serveur a sélectionné le personnage info base: in the world, on map <id> connect() s’est résolue info base: waiting in the server's queue, position <n> of <total> Le serveur est plein warn base: resuming after an identification whose answer was not seen Un script s’est arrêté entre le ticket et sa réponse. Voir Mémoire. warn base: the server does not certify this session (TrustStatusEvent) Bon à savoir ; base continue warn base: the server is ending the session (system message <id>) Le serveur s’apprête à déconnecter le bot warn base: the server asked to check <file>, which base does not answer FileCheckEvent. Il n’a jamais été vu dans une capture. warn base: couldn't send <type>: <reason> Un envoi a échoué. Base continue. warn base: <message> failed: <reason> Un gestionnaire a échoué. Base continue. error La raison avec laquelle connect() s’est rejetée Voir ci-dessous Ce avec quoi connect() et les étapes se rejettent : Erreur Cause base: the server refused this connection's ticket; sign the bot in again for a new one AuthenticationTicketRefusedEvent base: this account has no character on this server La liste est vide base: no character is called "<name>" on this server (there are: ...) Le réglage character ne nomme aucun d’entre eux base: the server refused to select <name> CharacterSelectionEvent portait une erreur base: the character's map never arrived within a minute of entering the world Aucun MapComplementaryInformationEvent dans les 60 s qui suivent les requêtes d’après le chargement protocol wait timed out Le serveur n’a pas répondu au ticket en 30 s, à la sélection en 30 s, ou au chargement en 60 s Délais et bruitDeux sortes de délais se trouvent dans une capture, et base les traite à part : Moins de 100 ms : les trames du client. Le client répond à sa trame suivante, donc une réponse arrive 6 à 55 ms après son événement, selon la charge du client. Le serveur le voit à travers l’aller-retour du réseau, 44 ms dans ces captures et plus variable que cela. Base les envoie directement et ne les imite pas. 100 ms et plus : le client qui charge, ou une personne. La seconde qui suit le chargement du personnage, le chargement de la carte, la pause avant de choisir un personnage. Ceux-là sont gardés. Ceux qui ont été mesurés reçoivent un bruit de ±15 % autour de leur valeur, puisqu’un client ne prend jamais deux fois le même temps. Ceux qu’une personne décide, comme regarder la liste des personnages, sont tirés uniformément entre deux bornes. Ce que le serveur voit exactement, c’est l’ordre des messages, puisque TCP le conserve. Base envoie donc dans l’ordre du client, qu’Asterobot conserve : il écrit les trames d’un script dans l’ordre où elles ont été envoyées. Toutes les attentes passent par sleep() d’asterobot:timers, et chacune est annulée quand le script s’arrête. Ce qu’il faut à base dans AsterobotLa mémoire du bot, memory d’asterobot:bot, et session.connectionId. send(..., { correlated: true }), pour les quatre requêtes qui portent un uid et ne reçoivent pas de réponse. asterobot:verification, pour la preuve d’identité. asterobot:movement avec changeMap(), useElement(), les voyages et les fonctions qui trouvent les cartes, que base réexporte à côté de move(). Un Asterobot qui ne les a pas ne peut pas charger base du tout, puisque l’import échoue. asterobot:character, l’état du personnage, pour les conditions sur l’état du jeu. Un Asterobot qui ne l’a pas ne peut pas non plus charger base. onStopRequest() d’asterobot:bot, pour qu’un plan se termine proprement quand une plage du planning se termine. asterobot:fight, les monsters des groupes de monstres dans currentMap(), record() d’asterobot:gamedata et distance() d’asterobot:pathfinding, pour combattre. Un Asterobot qui n’a pas asterobot:fight ne peut pas charger base. find() d’asterobot:gamedata, et les tables skills et maps__interactive_elements des données du jeu, pour récolter. items() d’asterobot:character, pour manger et l’équipement, et la vie qui suit la régénération, pour se reposer. Un Asterobot sans items() ne peut pas charger base. itemCount() d’asterobot:character, text() d’asterobot:gamedata et off() d’asterobot:protocol, pour l’hôtel des ventes, avec la compétence 355 du comptoir dans currentMap().elements. npc: true sur les acteurs de currentMap(), pour le banquier. Un Asterobot plus ancien ne les marque pas, et les étapes de la banque échouent avec there's no banker on this map. Les fichiers fightprofiles/ d’un paquet, pour les profils de combat. Un Asterobot plus ancien laisse ce dossier de côté et n’en liste aucun. Base n’a pas de asterobot.json, donc pas encore de compatibleVersion : une version de développement d’Asterobot se déclare en 0.0.0 et refuserait toute plage. Une fois qu’une version publiée aura ces fonctionnalités, le paquet publié la nommera. Différences connues avec le vrai clientLes canaux de discussion ne sont pas réglés. Un client dont les canaux ont été modifiés dans ses options envoie SubscribeMultipleChannelRequest après SetCommunityChannelRequest, avec l’ensemble complet : dans une capture, Ventes, Recherche, Arène, Communauté et Événement coupés, tous les autres canaux actifs. Une autre capture, d’un client laissé tel quel, n’en a aucun. Les options d’un bot sont celles par défaut, donc base n’en envoie aucun. Les étapes de quête ne sont demandées qu’à l’entrée dans le monde. Le client les redemande aussi quand l’étape d’une quête change. Base ne suit plus les quêtes ensuite. Les prix moyens sont demandés une fois par jour UTC, et Asterobot oublie qu’il les a demandés quand il redémarre. Le client s’en souvient d’un redémarrage à l’autre. FileCheckEvent ne reçoit pas de réponse. Il n’a jamais été vu dans une capture. Le rythme des pings est statistique : environ la moitié des battements de 5 secondes, là où un client envoie un ping sur les battements où une personne l’a vraiment touché. La fenêtre de l’hôtel des ventes se répète moins. Le client choisit un objet dès que l’onglet Vente s’ouvre, puis encore une demi-seconde plus tard, en cessant de suivre puis en suivant le même objet à chaque fois. Base le choisit une fois, et ne cesse jamais de suivre l’objet qu’elle va suivre. En ouvrant un hôtel des ventes qu’il a déjà parcouru, le client redemande le dernier type qu’il montrait, avec deux ExchangeBidHouseTypeRequest ; base commence sans type. La banque déplace une pile à la fois. Les boutons du client qui déplacent plusieurs piles à la fois ne servent pas : Asterobot ne lit pas encore la réponse du serveur. Le dialogue d’un PNJ sans banque reste ouvert. Quitter le dialogue d’un PNJ n’est pas encore dans une capture, donc quand le PNJ le plus proche n’est pas un banquier, les étapes de la banque échouent et laissent son dialogue ouvert. Une seule version de base par script. Deux paquets qui fixent des versions différentes de base les chargent toutes les deux, et les deux répondent au serveur. Fixez la même version partout. Améliorer base à partir d’une nouvelle captureLe premier rôle de base est tout ce que le client Dofus fait de lui-même, pour qu’aucun script qui l’utilise n’ait jamais à penser aux pings, aux contrôles, aux relances ou aux cartes. Chaque nouvelle capture peut l’enrichir, en suivant les mêmes règles : Seulement ce que le client fait toujours : une réponse qu’il envoie à chaque fois à un message du serveur, ou un message qu’il envoie de lui-même à un moment fixe. Ce qu’une personne décide, comme marcher, combattre ou discuter, n’en fait pas partie : c’est le rôle des plans et des fonctions de gameplay. Seulement sur un bot Full socket. Sur un bot MITM, le client Dofus le fait déjà, donc chaque gestionnaire rend la main tout de suite quand session.shared est vrai. Enregistré dans connect(), avant l’identification, puisque le serveur peut parler juste après avoir accepté le ticket. L’ordre du client, pas ses trames. Sous 100 ms, un délai est la fréquence de trame du client : envoyez directement. Envoyez dans l’ordre du client : Asterobot écrit les trames d’un script dans l’ordre où elles ont été envoyées. À partir de 100 ms, un délai est le client qui charge ou une personne qui décide : gardez-le. Utilisez une valeur mesurée avec ±15 % de bruit, ou un tirage uniforme entre deux bornes quand les captures montrent une plage. Ce qui doit survivre à un redémarrage va dans l’état de la connexion (lib/state.js). Quand envoyer deux fois serait une erreur, enregistrez le fait avant d’envoyer. Rien ne s’échappe d’un gestionnaire. Utilisez guarded() et sendQuietly() : une erreur qui s’échappe d’un gestionnaire arrête tout le script, celui de base comme celui qui l’utilise. La preuve va dans ce README, à côté du comportement qu’elle prouve : l’extrait de capture, avec ses heures et ses uids. Fichiersbase/ ├── README.md le README, en anglais ├── README.fr.md ce fichier ├── changelog.md ce qui a changé à chaque version ├── index.js exports, réglages, les primitives du runner, démarrage automatique et fonction d'entrée ├── fightprofiles/ les profils de combat que base fournit, un fichier JSON chacun └── lib/ ├── connect.js connect() : tout, dans l'ordre ├── identify.js l'identification ├── character.js la sélection du personnage ├── world.js l'entrée dans le monde, le suivi des cartes, le jeton de boutique ├── verification.js la preuve d'identité ├── keepalive.js les deux relances, latency(), les pings ├── watch.js enregistre les étapes clés de la session, avertissements de console ├── state.js l'état de la connexion dans la mémoire du bot ├── send.js envoyer depuis les gestionnaires sans arrêter le script ├── timing.js délais mesurés avec bruit ├── conditions.js les conditions sur l'état du jeu ├── fight.js combattre : les étapes et les conditions de combat ├── gather.js récolter : l'étape et la condition de récolte ├── recover.js se reposer et manger : les deux étapes ├── equip.js l'équipement : les deux étapes et la condition ├── market.js l'hôtel des ventes : vendre et acheter, les deux étapes ├── bank.js la banque : mettre en banque et retirer, les deux étapes ├── items.js ce que l'hôtel des ventes et la banque partagent sur les objets └── studio/ le runner, qui joue les plans ├── runner.js run() et stop(), avec les primitives que lui passe index.js ├── plan.js plan(), et la façon dont les lignes nomment les blocs ├── check.js la vérification d'un plan avant de bouger ├── args.js les règles des arguments ├── call.js l'étape ou la condition d'un paquet : arguments, réglages, contexte ├── circuit.js tours, arrêts, cartes, étapes et interruptions ├── steps.js les étapes ├── conditions.js les conditions ├── places.js les cartes d'un arrêt, de la plus proche à la plus lointaine ├── waiting.js les cartes où il n'y a rien à faire pour l'instant └── failures.js onFailure Le runner reçoit tout ce qu’il lui faut d’Asterobot en arguments, donc ses tests, dans test/base à côté de ce dossier, le font tourner sous Node avec des imitations : node --test test/base. Ils sont en dehors du paquet parce qu’Asterobot installe chacun de ses fichiers .js.