Upgrade Requirements for 2014.0.x

This page lists the changes that you must make to your code or pipeline in order to upgrade to the 2014 release.

Bot initialization and path following configuration

This release makes some major changes to the way you initialize your Bots, and the ways in which you can customize the path finding and path following system.

For complete details on the new system, see the topics in the Path Finding and Path Following chapter. Briefly:

Bot configuration parameters

A new BotConfig class gathers all configuration parameters that relate to the way a Bot generates and follows paths. You can set up an instance of this config object and provide it when you initialize your Bot, or you can alter the configuration parameters after initialization by calling accessor methods in the Bot class interface.

This change removes many parameters that used to be set in the BotInitConfig, and adds several new configuration parameters and sub-classes for configuring specific objects used in path following. See also Customizing Path Following.

AStar Customizers and path following predicates

In previous releases, many queries and objects involved in path finding and path following relied on template parameters called either AStarCustomizers or NavTagPredicates, depending on usage. For simplicity, these objects all now take a TraverseLogic class as a template parameter, such as the SimpleTraverseLogic provided with Gameware Navigation. Although the methods expected of this class are similar to the old AStarCustomizer and NavTagPredicate, all methods of the new TraverseLogic are now static.

If you currently use any customizers or predicates, you will have to rewrite your class slightly to match the new TraverseLogic interface.

NavigationProfiles

A new NavigationProfile class acts as a factory for all customizable objects used by the Bot during its path calculation and path following, including path finding queries, trajectory computers, avoidance computers, etc. The NavigationProfile is templated to a particular TraverseLogic, which in turn is used automatically for all objects served by the profile. This ensures that the same traversing logic will be used when calculating a path and when following that path. Retrieving objects from the profile also allows Bots to share object instances wherever possible, reducing memory footprint.

By default, each Bot uses a default instance of NavigationProfile that is maintained by the World. However, if you want to customize any of the objects used in your Bot's path finding and path following, you can set up your Bot with an instance of your own custom class that re-implements the methods in the NavigationProfile interface. See also Customizing Path Following.

PathFollower replaced by PathProgressComputer

The introduction of spline-based path following has also introduced new constraints on path following, and has invalidated some old assumptions. As a result, the PathFollower class used in previous versions has been removed. Its role of keeping the Bot progressing along its path is now handled by a new PathProgressComputer class.

If you previously relied upon the target point computed by the PathFollower class, this target point is now computed by the ShortcutTrajectory (the class formerly called simply Trajectory in previous versions). The new PathProgressComputer instead projects the current position of the Bot onto its original path, resulting in a marker that consistently indicates the Bot's progress along its path even when the Bot moves away from the original path due to shortcuts or dynamic avoidance. You can use this progress marker instead of the target point if you need to monitor whether or not your Bot has arrived at its destination or is making progress along its path. See Monitoring Path Following.

Query initialization

The procedure for initializing a query has changed, to make it easier to re-launch a query with the same configuration parameters but with different input values. As of this release:

You must call a new BindToDatabase() method of the query to associate the query with a Database. This association remains until the query is destroyed, or until you call BindToDatabase() again.
Calls to the Initialize() method no longer reset any configuration parameters for the query; they only reset the input data specified in the call to Initialize().

For details and code examples, see Using the Query System.

Starting the visual debug frame

In previous releases, the visual debugging system considered each frame to be the sum of all messages and display lists that were sent between successive calls to World::Update(). However, because the calls to World::Update() can be placed at different points in the main game loop, this could lead to visual debug data being offset from the corresponding game frame, or could lead to data sent in two successive game frames being combined in the same visual debugging frame.

To avoid this confusion, customers need to explicitly mark the start of each frame in the game by calling the new VisualDebugServer::NewFrame() method. This method sends any pending messages to the Navigation Lab, and increments or resets the index of the current visual debugging frame.