ABL Debugger Overview

From ABL
Revision as of 09:00, 31 July 2006 by Sooraj (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

As with all types of programming, debugging is an important part of the process in creating an ABL agent. If you are using just a text editor and the Wargus environment to test an agent, you may come across problems in identifying mistakes in the code. If your agent is supposed to be building farms and instead is doing nothing, it could be next to impossible to trace the code in order to discern where the string of behaviors went wrong.

There is a tool included with ABL that is intended to support this debugging process. To run the program with an agent, compile your .abl file with the "-g" option.

Within the program there are three panes: Working Memory, Active Behavior Tree, and Behavior Trace.

Working Memory Pane

The Working Memory pane reveals what information is contained in each of the agent’s WMEs at the point when the program breaks (you can break manually in the debugger, or write a break into the code). There is a list of all WMEs being used, and a right click gives the options to modify or delete. Modifying allows you to manually change the information inside the WME – for example, coordinates or a Boolean state. Deleting disposes of the WME altogether.

Active Behavior Tree Pane

The Active Behavior Tree frame provides a trace of the agent’s ABT. It updates whenever the program breaks. There is an option for continuous update, but this causes problems with lag so it is advisable not to use it. The tree expands and collapses so that you can focus in on a particular branch; branches will end with the actual behavior that the agent is performing.

Behavior Trace Pane

The Behavior Trace pane provides options for detailed traces of the agent’s behaviors. You have the option to trace to the screen, or to a buffer. If you trace to the screen, you will be able to see the trace in real time as the agent runs. If you trace to the buffer, you will have to wait until it is completed to paste the entire contents of the trace. However, the buffer gives you an advantage; If you still have a trace in the buffer, you can filter it by different behavior selections. If you had all of the behaviors selected and ran a trace to a buffer, you can look at it and then change the selections to only one or two behaviors – if you paste the buffer again then it will only contain the information from those couple of behaviors.

The ability to trace individual behavior allows you to be able to focus in on what may be causing a problem in your code. You can look at the ABT and work your way up or down the branches in order to find the specific behavior that may be a result of faulty code. Something to be on the lookout for are precondition tests; failed behaviors are listed in the trace.

Setting Manual Breakpoints

You have the option of manually breaking the agent’s run using the debugger, but you can also write a break into the code. This could be particularly useful if you want to know exactly what behaviors have occurred when a piece of code has been executed. This mental act will cause a break:

mental_act {BehavingEntity.getBehavingEntity().breakNextDecisionCycle();}