When a script doesn't do what you expect, its own output is usually the quickest way to find out why, once you know which of the two consoles it went to.
Two places to write
| Functions | Module | Where the lines appear |
|---|---|---|
botDebug(), botInfo(), botWarn(), botError() |
asterobot:bot |
The bot's Console tab, as Script lines, at every level |
debug(), log(), info(), warn(), error(), also available on the console object |
asterobot:console |
Server > Console, and the terminal Asterobot runs in |
The bot's console
This is the one you want while you write a script. Your lines show at their level, among Asterobot's own lines about the bot and, when Live chat is on, the game chat. In Sources, keep only Script to see your output alone.
Asterobot keeps the last 200 lines of each bot's console, and that's what you see when you open the tab. A script that logs on every message pushes the other lines out quickly, so remove chatty lines once you're done. Console describes the tab.
Asterobot's log
asterobot:console writes to the log of Asterobot itself, where log() is the same as info(). The lines don't say which bot wrote them, so when several bots play the same package, you can't tell their lines apart.
Two settings decide which levels reach each place:
| Where | Setting | Default |
|---|---|---|
| Server > Console | Server level, on that page, which is the logger.webLevel setting |
INFO |
| The terminal | logger.cliLevel |
INFO |
Both leave out debug lines by default. Set Server level to DEBUG and they show from then on, without restarting Asterobot. Status and console describes that page.
How values come out
Each call joins its values with spaces. Asterobot turns the values into text itself, not with JavaScript's String(), so some of them look different from a browser's console:
| You log | The line shows |
|---|---|
"Bouftou" |
Bouftou |
42, 1.5, true |
42, 1.5, true |
123456789012n |
123456789012 |
undefined or null |
<nil> |
[1, 2, 3] |
[1 2 3] |
{ pods: 5, kamas: 10 } |
map[kamas:10 pods:5] |
An Error |
map[] |
So log an error as String(error) or error.message, which give its text. For objects and arrays, JSON.stringify() makes a more readable line, but it throws a TypeError with the message Do not know how to serialize a BigInt as soon as it meets a BigInt, and message payloads often hold some. Convert them on the way:
function toJson(value) {
return JSON.stringify(value, (key, item) => (typeof item === "bigint" ? item.toString() : item));
}
botInfo("Payload:", toJson(traffic.payload)) then prints the payload with its 64-bit numbers written as digits.
Keep the game ticket out of your logs
Caution
Never log session.gameToken. It's the ticket to the bot's game session, and anyone who reads it could take that session over.
The ticket also travels in the ticketKey field of IdentificationRequest. A handler registered with onTraffic() receives the messages your own script sends, so a script that logs every payload writes the ticket to the console when it identifies. Leave that message out whenever you log traffic, as the sample below does.
A debugging routine
- Before running, look at the editor's error badge. A misspelled function or a field a message doesn't have is cheaper to fix there.
- In the editor, pick a MITM bot and click Run. On a MITM bot (man-in-the-middle: the bot relays the game session of the Dofus client you play), you can make things happen in the game yourself and watch the script react.
- If the toast says Couldn't run the package and no alert appears on the bot's page, the code didn't load. Open the bot's Settings tab: Package settings shows the reason.
- Open the bot's Console tab and keep only Script in Sources. Log a line when the script starts, such as
botInfo("Started:", launch.reason), to be sure it runs at all. - If The behavior stopped with an error appears, click Copy and look at how the text starts. Errors says what each beginning means.
- When a handler never seems to run, check what really arrives: log the type of every message for a moment with the sample below, or use the Network tool as React to messages shows.
- When a lookup returns nothing, try it on the game version's Game data tab first. SQL queries shows how to try a query there.
- Fix the code and click Run again: it saves your change and starts it.
This handler writes the direction and the name of every message to the bot's console:
import { session, botDebug } from "asterobot:bot";
import { onTraffic, send } from "asterobot:protocol";
export default async function behavior(launch) {
onTraffic((traffic) => {
// Its payload holds the game ticket, which must never reach a log.
if (traffic.type === "IdentificationRequest") return;
botDebug(traffic.direction, traffic.type || traffic.wireType);
});
// A new game connection starts with this message. MITM bots never launch
// with "initial": the Dofus client has already identified their session.
if (launch.reason === "initial") {
await send("IdentificationRequest", {
ticketKey: session.gameToken,
languageCode: session.language,
});
}
}
traffic.type is empty for a message Asterobot has no readable name for, so the line shows its name on the wire instead. Traffic describes every property. A busy session fills the console within seconds, so run this only while you look.
Next, JavaScript support.
Aucun avis à afficher.