-
Notifications
You must be signed in to change notification settings - Fork 2
Debugging
The debugLog
function was added in version 0.2.21 (see changelog). It’s currently located in Snippets → Advanced and looks like this:
The function simply logs text to your browser’s console (in the exact same way that console.log
does from JavaScript).
There are several caveats to using this function:
-
This does not work in the mobile versions of the game, only in the browser or Steam versions.
-
This only works in Test Mode (via Edit Defense) or Campaign Mode. This means that you do not have to remove
debugLog
calls from your script before saving it; the information can’t be seen by other players just like how your overall script can’t be seen by other players. -
The argument type is closely checked, so something like
debugLog(x > 0 && y > 0)
will not work, but this will:debugLog('' + (x > 0 && y > 0))
. In general, define the argument todebugLog
on its own line, e.g.
message = x > 0 && y > 0;
debugLog(message);
-
The output from
debugLog
prints all at once, and it prints before anything has started animating in the Arena. The flow of actions is this:- You press the Start battle button to see what will happen with your bots/scripts.
- Your device simulates the entire match ahead of time and produces a step-by-step replay that won’t actually play back yet.
- In producing the above, your
debugLog
calls get hit. - The replay commences, meaning you’ll finally start to see movements, attacks, etc.
-
The only way to see the output of the function is to go to your browser’s console. This means that it’s likely very difficult to see the output on a mobile device. For help on how to open your specific browser’s console, look at this link.
- Each message contains the text
[debugLog]
, so if using something like Chrome, you can filter messages so that you’re only seeing your own debugLog messages.
- Each message contains the text
-
When concatenating strings, each string is capped to a maximum length of 250 characters. After 250 characters, you’ll see some kind of truncation message in the string itself if you log it. Example code below:
stringA = 'This is a 35-character-long string.';
stringB = 'This is a 35-character-long string.';
stringC = stringA + stringB;
debugLog(stringC); // [debugLog] This is a 35-character-long string.This is a 35-ch(truncated: max length is 250 chars)
- All bots that have a script with
debugLog
will print in exactly the same way. For example, if Bot A and Bot B both have a script withdebugLog
in them that log their coordinates, it will be very tough to tell them apart when you get the resulting logs. To work around this, you could do something like this:
If you’re comfortable using JavaScript, you should essentially just treat debugLog
as a proxy for console.log
(since that’s what it is). This means it’s much easier to interact with than it looks like from Blockly since something like this will work: debugLog(‘Hello’, someObject, x, y, 5);
- Finally, it's possible that having your browser's console open will cause your bots to hit the code execution timeout, which is currently a limit per turn during which a bot is allowed to execute its script. I hope to find a way to fix this in the future so that logging doesn't change the overall outcome of your scripts. If you think this is happening, you can search for
CODE_TIMEOUT_HIT
in the console. If you see that, then perhaps try testing the game with the console closed to see if that has an effect. Sorry for how terrible this particular bullet point is. 😒