Skip to content

Debugging

Adam edited this page Jan 28, 2020 · 10 revisions

Table of Contents

debugLog

The debugLog function was added in version 0.2.21 (see changelog). It’s currently located in SnippetsAdvanced and looks like this:

debugLog

The function simply logs text to your browser’s console (in the exact same way that console.log does from JavaScript).

Caveats

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 to debugLog 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.
  • 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 with debugLog 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:

debugLog

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. 😒