Debugging Aiscripts

From Bots-United Wiki

Jump to: navigation, search

Or How can you be certain that code in your aiscript is being executed.

Contents

[hide]

Preamble

Like other scripting languages it is possible for an error in the FritzBot aiscript file to short circuit the code that follows it. A simple typo can wreck havoc on otherwise good code and confuse you. It is a good idea to make use of Hobbits waypoint tool's aiscript editor which may underline/find many of these errors. You can also search through a console /condump or a log file in the hope that a meaningful error message can be found. The list of console error messages are in the Topic Error_Messages_When_Fritzbot-ET_Reads_The_Aiscript.

But what would be really useful is classic break-inspect-stepthrough debugging. However the way to trigger the actions is to walk through the map building, dynamiting and stealing. So checking the actions means doing a walkthrough of the map, inspecting/testing in the console, taking actions, checking the bot messages by unpausing/pausing the bots.

Here are a few methods to use to check on whether your aiscript code is working;

Ways to Check If An Action Test is Executed

Console Checks

Verifying Node_connect or Node_disconnect Statements

  • open the console
  • pause the bots /bot_pause 1
  • inspect the node that is the first node in the node_connect or node_disconnect statement in the action test.
    • /g_node_info <first_node_number>
  • Look at the output to see if the second node number appears in one of the output lines beginning "Connected to Node Num:"

G_action_info

The console command /g_action_info can be used to debug actions. The command is used as follows;

/g_action_info <action_num> 

where <action_num> is the action ID number.

This command is similar to /action_info <action_number> with 2 important differences;

First, any waypointing changes to the selected action since the last /map_restart are not reflected in g_action_info because they are not current to the game in progress. The waypoint editor's action HUD and /action_info reflect the static .nav file in memory (saved or unsaved). G_action_info on the other hand follows the game state variable's copy, initialized at map startup.

The second difference is that there are 2 values returned for goal num. The g_action_info generated console output has values for "Goal Num" and for "Original GoalNum". The latter "Original GoalNum" is the value at startup programmed in the .nav file (/action_goal <action_number> <goal_num>). The former "Goal Num" is the value of the game's goal number (/goal_num) at the time that the action was (or will be) activated. This "Goal Num" is set when the /goal_num matches the "Original GoalNum" and updated if action_active=1 (see Fritzbot_Goal_Tracker). Additionally, the "Goal Num' is modified by any aiscript keywords that affect the current availability of the action.

Using G_action_info

Actions are either on or off, so checking the current Goal Tracker value with /goal_num and using g_action_info to display the actions current goal number ("Goal Num") tells you whether or not the action is active. It's useful to use this when testing action tests in the aiscript:

Usage Example 1: in this example, an action is activated after a certain event occurs

 action 0 //some action
 {
     activateAction 1 //another actions
 }

The test would be to use /g_action_info 1 before and after action 0 is completed to ensure that it is not active beforehand and is active afterwards.

Troubleshooting this example:

Symptom: action 1 was active before action 0 was completed

probable cause: action 1's original goal number was not set to -1

potential cause: the aiscript hasn't been fully loaded

potential cause: action 1 was already activated somewhere else in the aiscript


Symptom: action 1 was not active after action 0 was completed

probable cause: the aiscript hasn't been fully loaded

potential cause: action 0's entity number wasn't set correctly


Usage Example 2: in this example, an action is activated in an action test if a conditional is met

 action 0 //some action
 {
    if_obj_home_false 0
         activateAction 1
 }

The test would be to use /g_action_info 1 before and after action 0 is completed to ensure that it is not active beforehand and is active afterwards.

Troubleshooting this example:

Symptom: action 1 was active before action 0 was completed

probable cause: action 1's original goal number was not set to -1

potential cause: the aiscript hasn't been fully loaded

potential cause: action 1 was already activated somewhere else in the aiscript


Symptom: action 1 was not active after action 0 was completed

probable cause: the aiscript hasn't been fully loaded

potential cause: action 0's entity number wasn't set correctly


Usage Example 3: in this example, an action is activated in an action test if two conditionals are met

 action 0 //some action
 {
    if_obj_home_false 0 AND if_action_true 2
         activateAction 1
 }

The test would be to use /g_action_info 1 before and after action 0 and action 2 are completed to ensure that it is not active beforehand and is active afterwards.

Troubleshooting this example:

Symptom: action 1 was active before action 0 and action 2 were completed

probable cause: action 1's original goal number was not set to -1

potential cause: the aiscript hasn't been fully loaded

potential cause: action 1 was already activated somewhere else in the aiscript

potential cause: action 2 was set to goal -1 and not activated in the script early enough


Symptom: action 1 was not active after action 0 and action 2 were completed

probable cause: the aiscript hasn't been fully loaded

potential cause: action 0's entity number wasn't set correctly

potential cause: action 2's entity number wasn't set correctly


Adding Test Nodes For Debugging

If you need to test whether an Action block or even a specific conditional statement is working consider adding a couple of unused nodes in a free area of the map. Then in the aiscript add the node_connect and/or node_disconnect statements. For example suppose the following action block is in the aiscript;

action 14 //spawn flag
{
	//...
	if_fda_owner_allies 14 AND if_axis_cp_built_true 3
		activateAction_Group 10 //engrcamp at flag
	//...
}

then suppose nodes 101 and 102 were added to the map with no connections. The aiscript could be modified thus;

action 14 //spawn flag
{
	node_connect 101 102 false //DEBUG ONLY 
	//...
	if_fda_owner_allies 14 AND if_axis_cp_built_true 3
		activateAction_Group 10 //engrcamp at flag
	if_fda_owner_allies 14 AND if_axis_cp_built_true 3
		 node_connect 102 101 false //DEBUG ONLY
	//...
}

Then in the console use /g_node_info 101 if "Connected to Node Num: 102" appears then the action block for action 14 was opened. And in the console type; /g_node_info 102 And if "Connected to Node Num: 101" appears the the conditional statement if_fda_owner_allies 14 AND if_axis_cp_built_true 3 was true (at least one time).

More Complex Testing with Test Nodes

This method can be extended to more than just 2 nodes and in such a case you may want to use a cfg file that can be exec'ed to do all the /g_node_info checks (the results can be then /condump'ed to file for later analysis).

G_action_info Vs. Test Node Method

If you have designed your waypoint actions for strict control by the aiscript then /goal_num will likely remain value zero during the entire game. If you have only one or two dynamite/build/flag actions triggered by the goal_tracker and included them in goal 0 then /goal_num will remain in the range of 0..1 or 0..2.note 1 In either case the point is that the "Goal Num" returned from g_action_info may not give enough info to lead backwards to a prior action test. G_action_info is best used to review the current state of an action to verify expectations, or to check action_tests before-and-after when doing a single-step walk-through of the map. In complex cases you may want to try the test node method if presented with rarely observed problems since you can set it up for full backwards analysis.

note 1If using the script conditionals if_action_true/false for dynamite actions use goal of 999 instead of -1 when triggering them by the .aiscript. But be careful since they will affect the goal tracker /goal_num and could affect other actions that are not set /action_active 1.

How to Count Aiscript Events

Aiscripts do not provide accumulators (counting variables) so it is not possible to directly count in the aiscript how many times an action or condition occurs. However 2 types of accumulators are available in script files and a means to print their value to the console. So if you need to know how many times an objective type action occurred then use the script file to do it. For this and other script debugging ideas see Debugging_Script_files. Also see the example using a user defined cvar in Unattended_Testing_Methods#Scripting_Counters.

Permanent link to this page

Retrieved from "Debugging_Aiscripts"