TALplanner. The TPVis framework was used to generate the domain images in this article, and provides an animated display consisting of a set of nodes, where each node can be a container or an atomic object. Containers may represent vehicles (which can contain packages), locations (since there can be vehicles, packages or other objects at a location) or other similar concepts, while atomic nodes may be used for **packages, instruments on a**
satellite, or any other type of object which should be displayed. Edges between nodes can indicate any form of relationship between objects, the most **obvious interpretation being that** two location nodes are connected by some transportation route. A built-in layout engine can generate a layout automatically, or you can manually adjust the visual coordinates of each node.

The visualization framework is then used by concrete plugins adapted to specific planning domains. The DriverLog plugin, for example, displays locations as container nodes, linked by paths where drivers can walk and links where trucks **can drive. Trucks are also** containers, contained within a specific location, as shown in Figure 6 on page 366.

As a plan is being generated, TPVis animates the actual movements of objects between locations. This creates a better instinctive feel for the domain, and the two-dimensional graph display gives an overview that is difficult to provide using only text output. In addition to animating a graph, TPVis simultaneously lists the partial plan leading up to the current state and the problem goals that the planner tries to satisfy. TPVis also provides a limited form of interactive planning since it, at any point **in the planning process, allows**
the user to force the planner to backtrack and explore a different search branch.

The development of TPVis was not initiated until after the planning contest. If this graphical visualization had been available during the work **on the contest domains, it would**
have saved a lot of time, and possibly a tree or two.

## 6.2 Automatic Translation From Pddl To Talplanner

Although it was obvious that there should be an automatic translator from PDDL to TALplanner's input format, there were always more urgent features to be implemented, and we instead decided to translate the IPC-2002 domains by hand. In retrospect this was a mistake. The risk of making an error somewhere in the translation becomes imminent when dealing with complex domains such as UMTranslog-2, with 38 operators, some of which had highly complex preconditions. Also, translating long formulas by hand is quite time consuming. A semi-automatic translator was therefore implemented to decrease the amount of work involved in the translation process and reduce the risk of introducing errors in the definition.

## 7. Discussion And Conclusions

The third International Planning Competition was a major step forward in terms of the expressibility required to represent the benchmark domains, and it provided a number of interesting challenges for any planner that wanted to participate in the competition. In this article we have described how these challenges affected TALplanner and shown a number of extensions that were made in order to meet the challenges. **The article also includes a** number of domain-dependent control rules for the competition domains, but rather than presenting an exhaustive list of pre-packaged control rules, we have attempted to place more