UT3 BOMBING RUN PATHING

PATH LINES
Just because paths build in the editor doesn't mean paths are ok.
If path lines intersect even a slight part of a mesh
the editor will not complain, but pathing can break in the game.
Generally each path node must have a clean trace (line of sight) to
the next node on the path or pathing can break.

CONSOLE COMMANDS
There are a few good commands for path debugging. 
See ConsoleCommands.txt for more details.
ShowPath shows the internal AI process in the console.
TestPaths tests the map paths and shows the results in the console.

A NOTE ON DEFENSIVE POSITIONS
A defensive positions is a place near to an objective which a bot will
go to in order to attack or defend from. Bots in UT3 BR will use all
path nodes near an objective for this purpose. However, you can turn
off that behavior simply by placing 7 or more UTDefensePoints near to the
objective, and then the bots will only use those places. Another way is
to turn off a particular path node that you never want the bot to use for
this purpose. To do this simply set the node's Tag property to NOTDEFENSIVEPOSITION.
Another way, if the node is a UTBRPathNode, is to set it's property 
NotDefensivePosition to True.


UTBRPATHNODES
There are so many difficult pathing situations that
we have created a new PathNode called UTBRPathNode which you can use
in the editor. It has all the abilities of the regular UT3 PathNode,
plus additional abilities which we have created for BR.

In the node properties you will find a RouteInfo array which you can use
to build routes. A single node can contain many routes. The basic idea
is that you can add as many routes as you want. Set RouteTarget to the
ultimate destination of the route, such as a BR Goal, and set MoveTarget
to the next place you want the bot to go.

There are two main types of paths.

ASSAULT PATH:
This is a prefered path. For example, you may want bots to always go down
a certain hallway when going to the enemy base. The hallway might be a 
longer path, but it has strategic value and you want bots to take it.
You do this by putting an assault path in that hall.

The general rule is that bots will use an assault path node if it's path evaluates as
the shortest path, -and- if the node is horizontally closer to the objective than
the bot is. The distance rule is an important one, as generally you would not want 
a bot going away from the objective to take a path further out. 
There is also the danger of a bot always looping back to the same path and getting
into an infinite loop.
You can add weight to any UT3 path node to make their paths longer,
and you can shorten the weight in any UTBRPathNode to make it's path shorter.

APPROACH PATH:
IMPORTANT: Only use an Approach Path when absolutely needed to resolve a bad pathing
situation close to an objective. Otherwise do not use Approach Paths. Approach
paths should only be used close to an objective, not far away, as bots tend to seek
them out even if it takes them out of their way.

This is a path which should only be used to resolve extreme pathing difficulties
close to an objective. The bot will seek the approach node first before seeking
the objective. There is no distance rule so keep that in mind, even if the bot is
very close to the objective, and an approach node is further out, the bot will
always go to the approach node.

For example, the goal could be in a tunnel which has volumes and other difficulties
inside it which break all pathing inside the tunnel. Outside the tunnel pathing is
fine. So by placing a approach node just outside the tunnel mouth, the bot will path
ok to that node and get to the tunnel mouth, and then the node can direct the bot
to the goal from there. If the bot was on top of the tunnel directly above the goal
and 10 feet away from the goal, but 500 feet away from the tunnel mouth, we still
want the bot to always seek the approach node, so no distance rule applies for
approach nodes. Once the bot reaches that node, it must contain a path which can 
direct the bot to the goal.


BR DYNAMIC PATHING:
When this is used, the bot is forced straight at the target and will 
navigate around any blockages it encounters. This is very useful for
directing the bot over difficult terrain and around obstacles. Very useful
for situations where regular UT3 pathing is breaking down.


USING UTBRPATHNODES TO FORCE A PATH
With our special nodes, you can force the bot to take a certain path.
Each node can direct the bot to any other path node on the map, and
also specify whether or not the bot uses normal pathing or BR 
dynamic pathing. The next node does not have to be nearby or the next
node along a path line. The next node could be on the other side of the
map. Using this method, you can guarantee that a bot will get somewhere.
So in our tunnel example, even if the tunnel is not straight but very
twisty, the approach node can point to another UTBRPathNode
inside the tunnel, and then that node an point to another, and etc until
bot reaches the goal. Since normal UT3 pathing will not work inside the tunnel,
you can use BR dynamic pathing to force the bot from one node to the next.

LOOSE ROUTES
By allowing any node on the map to be the next node, this allows you to setup
general paths without forcing the bot into a tight path line.
So, you can setup a string of UTBRPathNodes which direct a bot from one general 
area to the next, such as "go to the building, then to those trees, then over
to that hill". Regular UT3 pathing can be used so that from one area to the 
next, the bot is taking whatever route it wishes.

TRIGGER AREAS
Sometimes you just want a bot to take a certain route once it enters into a 
certain area. For example, you might want to setup spawn areas so that when
a bot spawns it just immediately moves out to a certain place on the map.
Any UTBRPathNode can be setup to have a trigger distance, so that when the bot
is within that distance to the node, it immediately uses that node's route as if
the bot had reached the node. This adds to the "loose route" idea so that you 
can make the bot move around from one area to the next without roping it into
a tight route.

AIR PATHS
The nodes can be laid out even in the air to make a bot travel through the air.
This can be used to guide them when jumping in low gravity, to navigate them
off of a jumping point, to navigate them using an air vehicle, etc.

RANDOM ROUTES
Sometimes you want the bot to take one route, and sometimes you want it to take
another. You don't always want the bot to take the same route. Each route in a
UTBRPathNode can be assigned a chance of use percentage so that the bot won't always
use that route. A node could contain many routes to the same objective, each with
a chance percentage, and also several nodes can be used each of which has one or 
more routes with assigned percentages. Bot will choose the node and the route in
the node based on that chance.

PATH WEIGHTING
This is adding or subtracting length to or from a path.
The ability to add is done using any UT3 path node's ExtraCost property.
The ability to subtract is a feature in UTBRPathNodes.
Sometimes simply placing an assault path on the map is enough to make
a bot use it, and other times you need to adjust path lengths, seeing as how
the bot tends to prefer the shortest route.
There are many ways to adjust path length on a UTBRPathNode. 
You can add or subtract distance to the total path length,
set the total route distance, or set the distance to the next node in the route.
-Be careful- when adjusting path lengths, -especially- when shortening paths.
There is great potential for a bot to get in a looping situation where it keeps
going back to a path and never leaves it because the adjusted path length is so
short. There are many failsafes in BR to prevent this, however, so do feel free
to use this feature within reason.
The great advantage of being able to shorten a path is that you can now make a 
path a priority over other paths without having to adjust any paths but the priority
path. If you could only add weight, it is very difficult, as you would need to adjust 
all the path weights for all paths to get the right balance.


HELPER ROUTES
Sometimes there's a nasty piece of terrain such as a hill that is so difficult to
make the bot get through. For example, an objective could be right up a hill, but
getting a bot to climb that hill can be a pain. You can fix this by laying down
an assault path up the hill to the objective. It's not that this path is a priority
path. You don't actually want the bot to prefer this path, but you do want the bot
to use it when it's at the bottom of the hill so it can just climb up quickly to the
objective. Simply lay down the needed UTBRPathNodes which lay out a good route up
the hill. Use BR dynamic pathing if you need to force the bot from one node to the
next because the terrain is too difficult for normal UT3 pathing to navigate. Make 
sure at least the starting node is marked as an assault path. Do not adjust the 
path lengths. This way, the bot will use the path when it's a the hill bottom, but 
will not use the path when bot's somewhere else, such as near hill top.

MARKING NODES AS ASSAULT OR APPROACH
You do -not- need to mark each node in a route as assault or approach. At least 
mark the first node. Once the bot uses that node, it's on the route and will stay 
on it, even if no other node is marked. Try to only mark the key nodes, because each
marked node adds to the game processing time, as the bot must evaluate each one. 
The processing expense is not that bad, so you can have a good amount of these nodes,
but on the other hand, don't go wild with them, as you don't want to choke a 
map with so many of these marked nodes that you drag the game down.

Basic rule of thumb is general strategic points should be marked which you want to
bot to consider as an assault path. Remember the node's distance from the objective
is part of that consideration, so mark them accordingly. If node A is an assault path
node but bot is closer to the objective, then bot will generally not use A.

You do -not- need to mark the nodes you want the bot to enter the path at.
For example, if a path had A > B > C > D > E nodes in it, and A was the only node
marked as an assault node, and bot decides to use A's path, but is closest to node
C, then the bot -will- go directly to node C as the path entry point, even though
C is not marked as an assault node. C is part of A's assault path and is treated
accordingly.

So, every node in an assault or approach path does not have to be marked
as Assault or Approach, and indeed should not be marked,
but every node is a possible path entry point.

On the other hand, every node in the route must have a RouteTarget and MoveTarget
set so that the bot can follow the route every step of the way.

So a common example is a route A > B > C, where only A is marked as an Assault Path,
has B as it's MoveTarget, and B has C as it's MoveTarget, and all nodes have
RouteTarget set to the same objective. Bot will only use this path when A's path
is the shortest route to the RouteTarget, and node A is closer to RouteTarget than
the bot is. If you did want bot to use the path even if B was closer to RouteTarget,
then B or C ought to be marked as an Assault Path also.

Plain paths are possible too, which are not marked as assault or approach at all.
When the bot reaches any UTBRPathNode, it will follow the route instructions
contained in that node, regardless of how it's marked or how it got to that node.


UTBRPATHNODE ROUTEINFO PROPERTIES

Here are the RouteInfo properties copied straight out of the code.
In the editor when you hover your mouse over the properties,
the help text will appear.

    /** The final destination of this pathnode's route */
    var() NavigationPoint RouteTarget;
    
    /** Specifies the next node in the route */
    var() NavigationPoint MoveTarget;

    /** Description of path. Set by mapper. */
    var() string Description;
    
    /** 
    *Bot seeks this instead of RouteTarget. Useful for broken or difficult paths 
    *close to RouteTarget. Once reached, bot proceeds to RouteTarget. Bot uses nearest 
    *approach node. Path length is not checked.
    *Useful for when bot can't direcly seek RouteTarget and should rather go to some
    *other place from where it can reach it.         
    */    
    var() bool ApproachPath;
    
    /** 
    *Bot takes special consideration of this as a path. Bot takes nearest AssaultPath 
    *if it's horizontally closer to RouteTarget than bot, and is a shorter route.
    *Path should be weighted accordingly.    
    */    
    var() bool AssaultPath;

    /** Extra distance added to or subtracted from path length */
    var() float ExtraDistance;
        
    /** If specified, is absolute distance to MoveTarget (overrides calculated distance) */
    var() float DistanceToMoveTarget;
    
    /** If specified, is absolute distance to RouteTarget (overrides calculated distance) */
    var() float DistanceToRouteTarget;
    
    /** 
    *Percentage chance this route is used at all. 100% if unspecified.
    *Routes with ChanceOfUse set will be preferred over routes with ChanceOfUse not set.
    *One route with ChanceOfUse not set can be used as a default route, if desired.
    */
    var() float ChanceOfUse;
    
    /** If true, dynamic pathing is used to force bot to MoveTarget, otherwise normal pathing is used */
    var() bool ForceToMoveTarget;
       
    /** 
    *If true, bot can use this assault node even if bot is horizontally closer to RouteTarget.
    *Very useful for solving difficult pathing problems close to objectives which
    *require bot to use an assault path further away.
    *Be careful with this, as misusing it can make the bot keep looping back to
    *this assault path. This should never be a shortened path, and may need lengthening
    *to stop bot from using it unless needed.    
    */
    var() bool CanUseIfBotCloserToRouteTarget;     
    
    /** 
    *If set, bot considers this approach/assault node reached when within this radius and moves on to next node.
    *Great for adding pathing variety without pegging bot into one tight location.
    */
    var() float ReachedRadius;
