Smooth
Administrateurs
-
Adhésion
-
Dernière visite
Tout ce qui a été publié par Smooth
-
Enters the game with a character for the first time, and asks for the tutorial. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping USE THIS FOR A CHARACTER YOU JUST CREATED, and CharacterSelectionRequest for one you have already played. Both enter the game with a character; this one additionally tells the server to run the tutorial. WHEN TO SEND IT WHEN YOU VALIDATE A CHARACTER THAT HAS NEVER BEEN PLAYED. In the real client both messages come from the same screen action - validating your choice on the character-selection screen - and the screen decides which of them applies from a first-selection flag it raises with the character id. You are choosing between them on the same signal it uses. SENDING THE WRONG ONE IS NOT A NO-OP. Send this for an existing character and you are asking the server to run the tutorial flow for someone who has already played. Send the ordinary one for a fresh character and you skip the tutorial the server would have set up. DO_TUTORIAL IS ALWAYS TRUE IN THE REAL CLIENT. It writes a hardcoded true into that member on every dumped build - it is never a player choice. False is a legal wire value that no client has ever sent, so treat it as untested. THE THIRD BRANCH. The same screen action has one more outcome, CharacterReplayRequest, for a character in a state that needs replaying rather than selecting. If you are implementing the screen, all three come from one place. WHAT COMES BACK The ordinary game-entry sequence, exactly as for CharacterSelectionRequest - there is no dedicated reply to this message. It is uncorrelated, so its envelope uid is -1 and there is nothing to match against. READ THE MEMBERS BY ROLE. Both have moved field number across builds, and some builds pad the message with a second bool beside the real one. When you may send it Requires authenticated observed Raised by: a client-side state change: the player validating their character choice on the selection screen for a character that has not been played yet. The screen raises one intent carrying the character id and a first-selection flag, and the selection dispatcher turns the flag into this message instead of the ordinary one inferred Related messages Reply not yet recovered: the game-entry burst follows, the same as for an ordinary selection. Those messages are recovered but not documented yet. Fields #FieldTypeMeaningYou set it 1character_idint64The character to enter with.required 2do_tutorialboolWhether to run the tutorial. The client always sends true here.required Recovered with score 235, confidence 0.92, margin 235 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 2 of 2.
-
Destroys a character. This is irreversible and there is no further confirmation exchange. Kind requestArea Game.CharacterNamed by beta, gamemapping STEP 3 OF 3, AND THE DESTRUCTIVE ONE. THE CHARACTER IS GONE. There is no undo, no grace period, and no second confirmation on the wire - the moment this is sent the decision is made. If you are writing automation, the honest answer is that THIS MESSAGE HAS NO LEGITIMATE AUTOMATED USE. Deleting a character is a decision a person makes once; put it behind a human, not behind a script. secret_answer_hash IS NEVER THE PLAINTEXT ANSWER. The client sends the lowercase hex MD5 of the UTF-8 bytes of: <character_id>~<secret_answer> with a literal tilde between them. The separator, the digest and the hex casing were all read out of the client rather than assumed. Send the plaintext and it will not match; hash without the id prefix and it will not match either. Whether the hash is required at all comes from CharacterDeletionPrepareEvent.need_secret_answer. Read that first. Two builds declare a second int64 beside character_id; the named one is the one the hashing writer actually stores. When you may send it Requires authenticated observed Related messages Answers CharacterDeletionPrepareEvent Reply not yet recovered: the character list is re-sent afterwards; the deletion's own acknowledgement has no signature here yet. Sequence Step character_deletion.3 inferred — of 3 steps; the flow is a fixed ask / terms / confirm exchange If you get it wrong the hash must be MD5 of <character_id>~<secret_answer>; sending the plaintext answer, or hashing without the id prefix, produces a value that cannot match inferred Fields #FieldTypeMeaningYou set it 1character_idint64The character to destroy. (character id) Also the prefix of the hashed string - the two must agree.required 3secret_answer_hashstringLowercase hex MD5 of the UTF-8 string <character_id>~<secret_answer>. NEVER the plaintext answer. The tilde separator, the digest algorithm and the hex casing were all read out of the client.required when the prepare event asked for it Recovered with score 225, confidence 0.80, margin 225 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 2 of 3.
-
Creates a character on the current server. One wrapper field carrying the whole appearance. Kind requestArea Game.Character.ManagementNamed by beta, gamemapping ONE FIELD, AND EVERYTHING IS INSIDE IT. The request is a thin wrapper: the whole character - name, class, gender, colours, head - travels in CharacterRemodelingInformation. Read that record before building this one; it is where every rule about the payload lives. WHEN TO SEND IT ONCE, WHEN YOU HAVE CHOSEN EVERYTHING. The real client sends it from the creation screen's confirm button and from nowhere else. It is not idempotent in any useful sense: a second identical request is a second character, or a refusal. YOU MUST ALREADY BE ON A SERVER. This is game-server traffic, not connection traffic - you send it after you have picked a server and the game context is up. THE CLIENT VALIDATES BEFORE IT SENDS. It refuses to build the request at all when the name box is empty or the name fails its local check, and it fills the colour list to six entries first. None of that is enforced by the wire format, so a script that skips it simply gets refused by the server instead - see CharacterCreationResultEvent, which distinguishes the two. WHAT COMES BACK CharacterCreationResultEvent, always - success and every kind of refusal use the same message. It is uncorrelated, so its envelope uid is -1 and there is nothing to match against; watch for the event by type. ON SUCCESS the character list is what changes; the client re-reads it rather than being told the new character inline. When you may send it Requires authenticated observed Raised by: a client-side state change: the player confirming character creation on the creation screen. The screen builds one internal notification carrying the name, the class, the chosen head, the gender and the colour list, and the character service turns that notification into this request inferred Related messages You will then receive CharacterCreationResultEvent observed — the server answers with a result code, and a name reason when the name is what it rejected Fields #FieldTypeMeaningYou set it 1modeling_informationCharacterRemodelingInformationThe whole character you are asking for: name, class, gender, colours and head.required Recovered with score 265, confidence 0.88, margin 265 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 1.
-
Answers the server's latency poll with the mean of the client's last 50 round-trip measurements, in milliseconds. Kind requestArea Game.BasicNamed by beta, gamemapping Answers BasicLatencyStatsEvent. One integer: how long your round trips are taking, in milliseconds. WHEN TO SEND IT ONCE PER POLL, IMMEDIATELY, AND FROM NOWHERE ELSE. The client builds this message in exactly one place - inside the handler for the poll - and replies unconditionally. There is no timer, no threshold and no proactive path. If you did not just receive the poll, do not send it. REPLY ON THE SOCKET THE POLL ARRIVED ON. The client answers on the originating connection, which only matters once you hold two at the same time (see IdentificationRequest): the measurement buffer is shared between them, the reply is not. WHAT TO PUT IN IT THE VALUE IS A MEAN, NOT A LAST READING. The client averages the round trips it has stored - at most the last 50 - and rounds to the nearest millisecond, ties going to the even value. It is not the most recent sample, and it is not smoothed or weighted. Those samples come from the PingRequest / PongEvent exchange and from nothing else. WITH NO SAMPLES IT REPORTS 0. There is no guard for an empty buffer: a client that has never completed a ping exchange reports zero. That is faithful, but over a long session it is also a tell - real latency is never exactly and permanently zero. If you are going to answer these polls, ping often enough to have something true to say. KEEP IT IN A PLAUSIBLE RANGE. The client casts its average through a signed 16-bit integer before writing this 32-bit field, so a value above 32767 would go out negative and one above 65535 would wrap. No real latency comes near that ceiling, which is the point: a number outside roughly 0-2000 is not something a real client can produce. IT IS SELF-REPORTED, AND CHECKABLE. The server can compare what you claim against how long you actually took to answer this very poll. THE TWO REPLIES TO ONE FRAME DO NOT LOOK ALIKE This poll arrives in the same frame as SequenceNumberEvent, and the two replies leave with different envelopes. This one travels as a correlated request: the client allocates a uid from a counter that cycles 0-65534 and puts it on the envelope. SequenceNumberRequest does not - it goes out with the uid set to -1. Giving both a normal uid, or neither, is a shape no real client produces. When you may send it Requires authenticated observed Related messages Answers BasicLatencyStatsEvent Fields #FieldTypeMeaningYou set it 1latencyint32The mean of the client's stored round-trip measurements. (ms) Range: 0 upward in practice; the client truncates through a signed 16-bit integer, so anything above 32767 goes out negative Averaged over at most the last 50 samples and rounded to the nearest millisecond, ties to even. Not the latest round trip. A client with no samples yet reports 0 - there is no guard for an empty buffer.required Recovered with score 165, confidence 0.86, margin 165 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 1.
-
Asks for a fresh API token for the in-client shop back end. Empty payload, sent on a timer. Kind requestArea Game.BakNamed by stringtable Refreshes the key for Ankama's in-client shop back end. Carries nothing. THE TRIGGER IS TOKEN LIFECYCLE, NEVER USER ACTION, and the client's state machine has three parts worth reproducing: in-flight latch one request at a time. The send routine sets a latch and will not send a second while one is outstanding. 5,000 ms retry when it cannot send yet - the connection is not up - it re-arms on a 5 second delay and tries again. A real repeating cadence during bring-up. 3,600,000 ms after a successful answer, EXACTLY ONE HOUR before the next refresh. A long session re-sends this hourly, indefinitely. Both constants are read straight out of the client, one in the send routine and one in the receive routine. IT APPEARS DURING BRING-UP ALONGSIDE THE SOCIAL BURST, AND IT IS NOT PART OF IT. A capture shows it in the same handful of milliseconds as ContextCreationRequest and the four-request burst described under FriendListRequest - but it comes from a different service on a different trigger. Do not fold it into that sequence. Nothing in gameplay depends on having the key. When you may send it Requires authenticated observed Raised by: token lifecycle, never a user action: 3,600,000ms after each successful key, and a 5,000ms retry whenever the send cannot proceed; one in flight at a time proven Related messages You will then receive BakApiKeyEvent observed — the server answers with the key; observed in a live session Recovered with score 145, confidence 0.92, margin 145 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 0 of 0.
-
Asks for the whole anomaly board: every subarea, whether an anomaly is there and what it pays. Empty payload. Kind requestArea Game.AnomalyNamed by beta, gamemapping, stringtable Carries nothing. One request returns the entire board - there is no per-subarea form. THIS IS THE MESSAGE A FARMING SCRIPT WANTS. The board says which subareas currently carry an anomaly and what reward bonus each grants, which is exactly the input for deciding where to go. Ask when you need to choose, not on a loop. The board changes when anomalies open and close, and AnomalyOpenedEvent and AnomalyStateEvent tell you about those as they happen - so you can keep your copy current without asking again. Three builds pad this message; no writer in any dumped build populates anything. Send it empty. When you may send it Requires character_loaded observed Raised by: one internal client notification, once per session - not a timer, not per subarea, not per map change. The bus hides what raises it, so send it once the session can render the map and zaap UIs inferred Related messages You will then receive AnomalySubareaInformationEvent inferred — the server answers with the whole board Recovered with score 150, confidence 0.86, margin 150 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 0 of 0.
-
Asks for the players the character has recently met or grouped with, as distinct from added friends. Kind requestArea Game.SocialNamed by beta, gamemapping It is one of a FIXED FOUR-REQUEST BURST the client fires once per entry into the world, straight after asking for the game context. The client's own name for the routine survives obfuscation: SendRequestAfterCharacterLoaded. The order is constant: ContextCreationRequest (the context first) 1. FriendListRequest 2. AcquaintanceListRequest 3. SpouseInformationRequest 4. GuildInformationRequest That order is not guessed from traffic: it is the order the routine allocates the four objects in, and a live capture reproduces it exactly - the first three land inside the same millisecond, the guild request three milliseconds later. SEND IT ONCE, AT THAT POINT. NEVER POLL IT. The trigger is "the character finished loading", not a timer. ACQUAINTANCES ARE NOT FRIENDS. These are players the character has recently met or grouped with; explicitly added friends come from FriendListRequest. The two lists overlap but neither contains the other. Carries nothing. When you may send it Requires character_loaded observed Related messages Reply not yet recovered: the acquaintance list arrives as an event that has no signature here yet. Sequence Step post_character_load.2 observed — of 4 requests, in the order the client's own routine allocates them Recovered with score 215, confidence 0.89, margin 215 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 0 of 0.
-
Claims the reward for a finished achievement, or every claimable reward at once. Kind requestArea Game.AchievementNamed by beta Claims one achievement's reward. achievement_id OF -1 CLAIMS EVERYTHING CLAIMABLE AT ONCE. That is a real value, not a sentinel for "unset": the client sends exactly that when the player accepts all rewards. Be sure you meant it - there is no per-item confirmation. The current build pads the message with a nested four-member message that no dumped build writes. Leave it alone. When you may send it Requires character_loaded observed Raised by: the player accepts a reward in the rewards menu proven Related messages Reply not yet recovered: the reward arrives as items - watch GameActionItemListEvent and your inventory - but the acknowledgement message itself has no signature here yet. Fields #FieldTypeMeaningYou set it 1achievement_idint32Which achievement's reward to claim, or -1 for every claimable reward at once. (achievement id) Range: a real achievement id, or -1 for all -1 IS MEANINGFUL, not a placeholder.required Recovered with score 155, confidence 0.87, margin 155 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 1.
-
Asterobot Asterobot est le programme que vous installez et lancez sur votre machine. C'est lui qui connecte vos bots, les fait jouer, et sert Asteroboard, l'interface web depuis laquelle vous le pilotez. Il n'y a pas d'installateur : l'archive contient un seul programme autonome, que vous lancez là où vous l'avez posé. Votre antivirus signale Asterobot ? C'est un faux positif.Certains antivirus signalent Asterobot comme une menace. C'est un faux positif : Asterobot ne contient ni virus ni logiciel malveillant. Pourquoi? Pour protéger notre travail contre la copie et le piratage, nous obfusquons Asterobot : son code est brouillé pour que personne ne puisse le lire ni le réutiliser. Les logiciels malveillants utilisent la même technique pour se cacher, alors les antivirus se méfient de tout programme obfusqué. Leur verdict est une supposition automatique, fondée sur l'apparence du programme et non sur ce qu'il fait. Ce que nous faisons: Nous signalons chaque nouvelle version aux éditeurs d'antivirus comme un faux positif, et ils la débloquent en général en quelques jours. Nous allons réduire l'obfuscation, ce qui fera plaisir aux antivirus. Ce que vous pouvez faire : Téléchargez Asterobot uniquement sur asterobot.net, et vérifiez votre archive avec le fichier checksums.txt fourni avec chaque version. Si votre antivirus a mis Asterobot en quarantaine, restaurez-le depuis la quarantaine. Ajoutez une exclusion pour le dossier d'Asterobot uniquement. Ne désactivez jamais votre antivirus. Dites-nous sur le forum ou sur Discord quel antivirus l'a signalé et sous quel nom, pour que nous le signalions à son éditeur. Toujours inquiet ? Faites tourner Asterobot à l'écart du reste de votre ordinateur : Avec Docker : notre image officielle, asterobot/asterobot sur Docker Hub, ne voit que le dossier que vous lui donnez. Dans une machine virtuelle : Asterobot tourne dans un ordinateur à part et ne peut pas du tout atteindre vos fichiers personnels. Quel fichier télécharger ? Six versions, une par système et par famille de processeur. Prenez la seule ligne qui correspond à votre machine. Fichier Système d'exploitation Processeur Pour Asterobot_X.Y.Z_windows_amd64.7z 🪟 Windows Intel ou AMD x86-64 C'est le bon fichier pour à peu près tous les PC. Asterobot_X.Y.Z_windows_arm64.7z 🪟 Windows ARM Par exemple un portable Snapdragon X. La version Intel y fonctionne aussi par émulation, mais celle-ci est plus rapide et plus légère. Asterobot_X.Y.Z_darwin_arm64.7z 🍎 macOS Apple Silicon: ARM (M1, M2, M3, M4..) Tous les Mac vendus depuis fin 2020. Asterobot_X.Y.Z_darwin_amd64.7z 🍎 macOS Intel Les Mac de 2020 et avant. Asterobot_X.Y.Z_linux_amd64.7z 🐧 Linux Intel ou AMD x86-64 La plupart des Linux. Asterobot_X.Y.Z_linux_arm64.7z 🐧 Linux ARM Raspberry Pi 4 et 5, serveurs et VPS ARM. Docker 🐧 🍎 🪟 x86-64 et ARM Deux mots de ces noms méritent une traduction. darwin veut dire macOS. amd64 veut dire Intel ou AMD 64 bits, le processeur ordinaire de presque tous les PC, et ce n'est pas réservé à AMD. Comment savoir quel processeur j'ai ? Windows : Paramètres, Système, Informations système. La ligne Type du système indique soit processeur x64, soit processeur ARM. macOS : menu Pomme, À propos de ce Mac. S'il affiche Puce : Apple M..., prenez arm64. S'il affiche Processeur : Intel..., prenez amd64. Linux : lancez uname -m. x86_64 veut dire amd64, aarch64 veut dire arm64. Ouvrir l'archive Les archives sont au format .7z, ce qui garde le téléchargement aussi petit que possible. Windows 11 ouvre les .7z tout seul. Sur les Windows plus anciens, installez 7-Zip. macOS ne sait pas ouvrir un .7z depuis le Finder. Utilisez Keka ou The Unarchiver. Linux : 7z x Asterobot_X.Y.Z_linux_amd64.7z, avec le paquet p7zip. À l'intérieur, un seul fichier : Asterobot ou Asterobot.exe. C'est tout le programme. Ce qui n'est pas dans l'archive Les fichiers du jeu. Asterobot télécharge lui-même les morceaux de DOFUS dont il a besoin, à la première utilisation, et les garde à l'écart de la copie du jeu que vous avez peut-être déjà. Si vous voulez qu'un bot accompagne une partie que vous jouez vous-même, c'est l'installation gérée par votre Ankama Launcher qui sert, et vous la laissez telle quelle. Vérifier votre téléchargement checksums.txt donne l'empreinte SHA-256 de chaque archive. Pour vérifier, placez-le à côté du fichier téléchargé et lancez sha256sum -c checksums.txt. C'est le seul endroit où Asterobot est publié. Une version téléchargée ailleurs n'est pas la nôtre. Ensuite L'installation, le lancement et l'accès à l'interface sont détaillés dans le manuel : https://asterobot.net/helpGratuit
