0.5.0 - 13/10/2026
✨ Ajouté
Les bots peuvent suivre un planning hebdomadaire. Vous choisissez leurs créneaux horaires, dans le fuseau horaire de votre choix, et Asterobot connecte chaque bot, lance son package et le déconnecte à la fin du créneau, sans intervention humaine. La configuration s'effectue dans le Bot Manager d'Asteroboard : consultez le changelog d'Asteroboard.
Un bot planifié assure lui-même sa continuité : s'il est déconnecté ou si son script s'arrête pendant un créneau, Asterobot le relance après 1, 2 et 5 minutes, puis toutes les 10 minutes. Une connexion planifiée ne s'interrompt jamais pour vous poser une question : lorsqu'aucun serveur ne peut être sélectionné automatiquement, le bot réessaie plus tard.
À la fin d'un créneau, un script peut terminer son travail en cours pendant un maximum de 30 minutes, une durée configurable pour chaque planning, au lieu d'être interrompu au milieu d'une tâche.
onStopRequest()indique au script qu'il est temps de terminer son travail, etsession.scheduleEndsAtlui indique quand son créneau se termine, afin qu'il ne commence pas une tâche longue juste avant la fin.Vous gardez le contrôle : connecter, déconnecter, lancer ou arrêter manuellement un bot planifié suspend son planning jusqu'au début ou à la fin du prochain créneau.
Un planning peut contenir jusqu'à 200 créneaux horaires. Un planning activé sans aucun créneau ne fait rien. Son activation ne risque donc jamais de déconnecter un bot par surprise. Un planning mis en pause, par exemple après le déchargement du package du bot, reste modifiable.
Lorsque Asterobot démarre pendant un créneau horaire, le bot se connecte et commence immédiatement à jouer.
L'API d'Asterobot et les assistants IA connectés à Asterobot peuvent définir le planning d'un bot.
Le guide utilisateur dispose d'une nouvelle page Schedule, disponible en anglais et en français. La référence des scripts documente désormais
onStopRequest(),offStopRequest()etsession.scheduleEndsAt.Les comptes protégés par Ankama Shield fonctionnent en mode Full socket. Lorsqu'Ankama Shield demande un code de sécurité, Ankama l'envoie par e-mail et vous le saisissez dans Asteroboard : consultez le changelog d'Asteroboard. Dès lors, les bots du compte se connectent comme le ferait l'Ankama Launcher, à l'aide du certificat Shield du compte, sans qu'un nouveau code soit demandé jusqu'à la prochaine reconnexion du compte. Pour le moment, seuls les codes envoyés par e-mail sont pris en charge : un compte protégé par Ankama Authenticator l'indique lors de sa connexion.
Tant qu'Ankama Shield attend un code, les bots du compte attendent également et aucun e-mail supplémentaire n'est envoyé. L'erreur de connexion du bot indique où le code a été envoyé. Vous pouvez demander un nouveau code à tout moment.
Chaque compte possède son propre appareil Shield, c'est-à-dire l'ordinateur qu'il présente à Ankama Shield. Celui-ci est créé lors de l'ajout du compte, comme le HWID d'un bot. Plusieurs comptes peuvent partager un même appareil pour apparaître comme provenant d'un seul ordinateur, ou chacun disposer du sien. Modifier cet appareil déconnecte le compte de Shield : à la prochaine connexion, le compte s'authentifie à nouveau et un nouveau code est demandé.
L'API d'Asterobot et les assistants IA connectés à Asterobot peuvent saisir un code Shield, en demander un nouveau et définir l'appareil Shield d'un compte. Ils sont également informés lorsqu'Ankama envoie un code.
Sur un bot qui relaie la partie à laquelle vous jouez, Asterobot empêche le rapport du mod loader de Dofus d'être transmis à Ankama. Dofus envoie ce rapport lorsqu'il détecte un chargeur de mods, tel que MelonLoader ou BepInEx, dans son dossier. Asterobot bloque ce rapport dès le début de la session, avant même que vous appuyiez sur Play et que le package soit exécuté. La Console du bot consigne chaque rapport bloqué.
82 messages de jeu supplémentaires disposent désormais d'un nom et de toutes leurs données, permettant aux scripts de les lire et de les envoyer sans avoir à deviner leur structure.
Les scripts peuvent suivre un combat dans son intégralité, de l'attaque jusqu'au résultat, ainsi que les équipes décrites par
FightTeamInformationetFightTeamMembersInformation:AttackMonsterRequest,FightJoinRequest,FightJoinEvent,FightStartingEvent,FightStartEvent,FightLeaveEvent,FightEndEvent,FightSpectatePlayerRequest,FightOptionToggleRequest,FightOptionUpdateEvent,FightTeamUpdateEvent,FightTeamRemoveMemberEvent,FightFighterShowEvent,FightSynchronizeEvent,FightRefreshCharacterStatsEvent,FightPingsRequest,FightPingsEvent,AreaFightModifierUpdateEvent,EntitiesDispositionEvent,GameActionAcknowledgementRequest,SequenceStartEventetSequenceEndEvent. Les options de combat utilisentFIGHT_OPTION_SET_SECRET,FIGHT_OPTION_SET_TO_PARTY_ONLY,FIGHT_OPTION_SET_CLOSEDetFIGHT_OPTION_ASK_FOR_HELP.Les scripts peuvent positionner le personnage avant un combat, échanger sa place avec celle d'un coéquipier et signaler qu'il est prêt :
FightPlacementPossiblePositionsEvent,FightPlacementPositionRequest,FightReadyRequest,FightHumanReadyStateEvent,FightPlacementSwapPositionsEvent,FightPlacementSwapPositionsAcceptRequest,FightPlacementSwapPositionsCancelRequest,FightPlacementSwapPositionsCancelledEventetFightPlacementSwapPositionsErrorEvent.Les scripts peuvent jouer leurs tours et lancer des sorts sur une cellule ou sur une cible :
FightNewRoundEvent,FightTurnEvent,FightTurnStartPlayingEvent,FightTurnReadyRequest,FightIsTurnReadyEvent,FightTurnFinishRequest,FightTurnEndEvent,GameActionFightCastRequestetGameActionFightCastOnTargetRequest.Les scripts peuvent relever les défis de combat, depuis leur proposition jusqu'à leur résultat :
ChallengeProposalEvent,ChallengeListEvent,ChallengeAddEvent,ChallengeNumberEvent,ChallengeSelectionRequest,ChallengeSelectedEvent,ChallengeValidateRequest,ChallengeReadyRequest,ChallengeModSelectRequest,ChallengeModSelectedEvent,ChallengeBonusChoiceRequest,ChallengeBonusChoiceSelectedEvent,ChallengeTargetsRequest,ChallengeTargetsEventetChallengeResultEvent.Les scripts peuvent utiliser les zaaps et autres téléporteurs : les destinations proposées et leur coût, chacune représentée par un
TeleportDestinationavec sonAnomalylorsqu'il y en a une, la téléportation elle-même, la liste des zaaps connus du personnage et son point de réapparition :TeleportDestinationsEvent,TeleportRequest,WaypointPriceRequest,WaypointPriceResponse,ZaapKnownListEvent,ZaapRespawnSaveRequestetZaapRespawnUpdatedEvent. Le type de téléporteur est identifié parTELEPORTER_ZAAP,TELEPORTER_SUBWAY,TELEPORTER_PRISM,TELEPORTER_HAVEN_BAGouTELEPORTER_ANOMALY.Les scripts peuvent gérer la banque, ses objets et ses kamas :
ExchangeStartedWithStorageEvent,StorageInventoryContentEvent,ExchangeObjectMoveRequest,ExchangeMoveKamaRequest,StorageObjectUpdateEventetStorageObjectRemovedEvent.Les scripts peuvent également détecter le démarrage ou la validation d'une quête, la réussite d'un succès, l'obtention d'un objet, l'apparition ou la disparition d'un prisme, la dépense ou la réinitialisation des points de caractéristiques, et bien plus encore :
QuestStartedEvent,QuestValidatedEvent,GuideModQuitRequest,AchievementFinishedEvent,ObjectAddedEvent,CharacterCharacteristicUpgradeRequest,ResetCharacterCharacteristicsRequest,JobBookSubscribeRequest,PrismAddOrUpdateEvent,PrismRemoveEvent,ChatPrivateCopyMessageEvent,ContextQuitRequest,ContextRefreshEntityLookEventetAccountSubscriptionElapsedDurationUpdateEvent.Les scripts qui demandent eux-mêmes au jeu le chargement de chaque nouvelle carte peuvent le signaler à l'aide de
answerMapLoads(). Asterobot leur laisse alors gérer ce chargement, évitant ainsi qu'une même carte soit demandée deux fois.
🔄 Modifié
Les scripts s'exécutent de la même manière sur tous les ordinateurs : sur un PC lent ou très sollicité, ils s'exécutent simplement plus tard, jamais différemment. Chaque message du jeu parvient au script dans l'ordre de réception, et le nombre d'opérations qu'un script peut effectuer simultanément dépend uniquement du script lui-même, et non de l'ordinateur ou du réseau.
Les scripts, ainsi que les packages en cours d'installation, peuvent s'exécuter pendant 5 secondes d'affilée au lieu d'un quart de seconde, ce qui permet aux scripts plus lourds de fonctionner également sur des ordinateurs modestes.
Les messages envoyés par un script sont transmis dans l'ordre où il les envoie, même lorsqu'il est arrêté ou rechargé, et avant que le bot ne se déconnecte ou que le personnage ne se déplace à sa demande. Un script qui attend une réponse juste après un envoi la reçoit toujours, quelle que soit la rapidité de réponse du jeu.
send()ignore son optiontimeout, puisqu'il n'a rien à attendre.Un script qui bloque ou modifie les messages du jeu a toujours le dernier mot, même lorsqu'il est très sollicité, dès que vous appuyez sur Play et pendant toute la durée d'un rechargement. Sur un bot qui relaie votre partie, un script de ce type qui s'exécute lentement oblige également votre jeu à attendre.
Les paramètres que vous appliquez et les boutons d'action sur lesquels vous cliquez sont toujours transmis à un script en cours d'exécution, même lorsqu'il est très sollicité. Les messages du jeu qu'un script n'écoute pas ont un coût de traitement presque nul.
Un script ne s'arrête en raison d'un retard que lorsque l'ordinateur ne parvient réellement plus à suivre, avec plus de 8 Mo de messages du jeu en attente. La page du bot indique alors la raison de l'arrêt. Sur un bot qui relaie votre partie, votre jeu continue même dans ce cas.
Lorsque la connexion au jeu se ferme, le script traite d'abord tous les messages reçus auparavant, notamment la raison de la fermeture communiquée par le serveur, puis s'arrête.
Les requêtes de données du jeu provenant de plusieurs bots et onglets SQL sont exécutées à tour de rôle, selon le principe du premier arrivé, premier servi. Le délai de 10 secondes d'une requête ne commence qu'une fois son tour arrivé. Les autres opérations de lecture des données du jeu ne disposent d'aucune limite de temps propre.
Sur un bot qui se connecte automatiquement, Asterobot demande le chargement de chaque nouvelle carte après le délai nécessaire au client Dofus pour la charger, comme le ferait le jeu lui-même, et uniquement lorsqu'aucun script ne s'en charge.
Lorsqu'un serveur de connexion refuse le serveur choisi par un bot pour le motif introduit dans les versions récentes de Dofus, l'erreur de connexion du bot affiche le nom du motif,
NOT_ALLOWED, au lieu d'un simple numéro.Les requêtes d'Asterobot auprès du service de gestion des comptes d'Ankama correspondent encore plus fidèlement à celles de l'Ankama Launcher : mêmes en-têtes et même ordre des paramètres.
Dépendances mises à jour.
🐛 Corrigé
Les paramètres d'un script, configurés dans l'onglet Settings d'un bot, sont conservés lors du redémarrage d'Asterobot et lorsque vous changez le compte ou la version du jeu du bot. Auparavant, ils étaient réinitialisés aux valeurs par défaut du package.
Cliquer sur Connect sur un bot pendant que son compte ou sa version du jeu est en cours de modification ne connecte plus le bot en cours de remplacement, ce qui laissait une session de jeu sans aucun contrôle.
AccountInformationUpdateEventest désormais le message qui fournit la date de fin de l'abonnement. Le message qu'il désignait auparavant indique la durée écoulée depuis le début de l'abonnement du compte et porte désormais le nomAccountSubscriptionElapsedDurationUpdateEvent.