FritzBot ET Intermediate waypointing

From Bots-United Wiki

Jump to: navigation, search

This article forms the third section of the FritzBot ET waypointing tutorial. If you are looking for the RTCW tutorial go Here.

THIS ARTICLE IS UNDER CONSTRUCTION. IF YOU WANT TO HELP FEEL FREE TO USE THE DISCUSSION PAGE. OTHERWISE PLEASE COME BACK LATER

Contents

[hide]

Basic Bot Navigation

Before we talk about node attributes lets discuss the basics of bot navigation. First a bot has to have an objective or action that it has selected (more on actions later). The location of this objective or action is known by the location of its closest navigation node (lets call it Naction). It then calculates a path to that node, starting at the bot's current node position (Call it Nstart). This calculation is a search through the maze of nodes and their connections to find the shortest combination ending in that Naction node. The bot now has a list of all the nodes it needs to visit along this path. The first node it must visit say is N2nd (the number is arbitrary). The bot turns aiming for the center of the next node N2nd and proceeds towards it. This node may also tell the bot how to approach it using node flags. When the bot is less than the node radius away from the center of N2nd, it turns to navigate to the next node (call it N3rd). As long as the bot is not distracted by fighting or a change in status of its chosen action, it continues to navigate node by node to Naction.

Below is an example from ammodepot where bots exiting sewers, move right to left making a couple of turns. If the nodes were flagged to make the bots walk then the bots would turn as soon as they are inside the node cross sectional area (dotted line path). But since the nodes are normal nodes the bots will likely enter the node on the right with some speed. That speed (or bot ballistics) will carry the bot further inside the node before they can turn to face the next node. In that next node the penetration depth of a running bot may be less having lost some speed making the previous turn.

Image:node_rings_ammodepot5.jpg

The point of the diagram is that bots turn inside the nodes with some variability, and do not have to reach the center. The larger the node radii, the easier the latter can be seen. Now since humans run and turn at the same time sharp turns like these may appear a little unnatural. If so additional nodes can be added in between to soften the turn angle.

Now bots only know what to navigate by your waypoints so they do not know how to take shortcuts between unconnected nodes. By calculating the shortest path they will only expect to visit any node once in that path. Touching any other node or any node out of sequence does not bother them. They are focused on navigating to that next node in their path's list.

Node Radius

So the position of a node together with its radius determines where the bot starts focusing on getting to the next node in the chosen path. So is it better to use a large radius or small radius? Well that depends. Small radii may keep a bot to a tighter and more precise direction. Larger radii are easier for bots to reach and can handle multiple bots at the same time. So the answer will be determined by the map, and we will discuss why below. But first lets learn how to set and see the node radius.

When you add a node, by default the display does not show the radii spokes. So it can be hard to judge if the node is the best size for that spot in the map. Open the console and type

/node_drawradius 1

then enter. This switches the in-game display from drawing connections to drawing radii spokes. The connections are still there just invisible now. To return to viewing the connections repeat the command with the value zero instead of one.

The node_drawradius 1 command now allows you to see the cross section of the node at the height of the spokes. From the length of the spokes you can project (or imagine) what the node's logical sphere would be. The nodes are not drawn as spheres to avoid overtaxing ET and your PC. And with the bots moving mainly in a level-manner the cross section is information enough.

Now that you can see the radii, you can judge when a node is too large for tight places. Something that you want to avoid is radii spokes penetrating through walls to the other side. You also want to avoid nodes bigger than the doorways or openings they are in, and avoid ladders having nodes wider than the ladder. Generally avoid letting node radii touch walls etc. that you cannot slide along easily.

Now to change a node's radius, say node 35's radius in our previous section's example of et_slide, open the console and type

/node_radius 35 100

and enter. If you are viewing that node you will see the spokes change length to reflect the new radius.

In general a default radius of 70 is good for open areas, with larger values used for bots falling or flying in the map. Narrower values of 40-50 may be better suited for some interiors and corridors. Narrow doorways and ladders, narrow ledges and such, and health and ammo cabinets take some of the smallest nodes with radii typically between 15 and 35. Radii values are best kept to some multiple of 5 or 10. No radius value smaller than 10 should be used or needed.

I find that I first place the nodes with a rough value for the radii and rather than change all the node radii individually, I set the rough value as the default radii before node_add (see node_defaultRadius below). Then much later on, after getting the map objectives working, I return to tweak the node_radii to improve bot movement and give the waypoints their polish.

BTW Nodes should not need to overlap other nodes, and doing so might make the bots look confused.

Changing the Default Radius

When you add a node, FritzBot assigns a default value for the radius (typically 70). The value of the default can be changed so that all subsequent nodes added are of a new radius value. This is faster than manually changing each node added. For instance to set the new default value to 50 open the console and type;

/node_defaultRadius 50

and enter. Now all new modes added without a radius parameter will be radius of 50.

You could also use a waypointer's config file to bind a key to cycle the default node radii between common values. This can save you typing the long node_defaultRadius command over and over.

Waypointing to Match the Map Environment

This may seem obvious but where you place the nodes, their radii and behavior flags are determined by the paths you chose and most importantly by the environment the paths go through. As bots on the path encounters things like doors, crawl spaces, obstacles, ladders, etc. they need the nodes to be well setup to ensure the bots are as efficient as humans in getting around. The important things to manage with proper node settings are;

  • Ensure the bot approaches from a good angle to pass efficiently through doors, or to enter ducts or narrow corridors. and to ensure bots climb up the center of any ladder.
  • Make some node radii sufficiently small to prevent bots getting stuck on corners etc. (For example the nodes in the center of narrow doors should be small enough to discourage the bot getting stuck on the door frame.)
  • Make some nodes radii sufficiently large to prevent bots missing them due to varying bot ballistics. (For example where bots jump down, hop or even run down a steep slope they may chance to land over an area larger than a typical node radius.)
  • Add a behavior flag when needed to keep the bot on the path. (For example a narrow walkway with edges to fall off may need to be flagged for walking to prevent the bots falling off the edge at things like outside corners.)
TO DO show some obstacle paths, jump downs etc.

Setting Team Specific Nodes

Earlier we learned how to disable nodes so they are unavailable to both teams. Here we will learn how to set nodes so only one specific team can use them.

By default any node added is set to Team number 0 meaning either team may use it. You can add a node and see the team number in the node HUD (mentioned in the previous section), or by getting node info in the console. Now suppose we just added node 1 to the map but we wanted only the allies to use that node. Then, open the console and type /node_team 1 2 then press enter. If the node HUD is on and node 1 is the closest node then the HUD will show the newly changed value. A team value of 2 means the node can only be accessed by the Allies, a value of 1 means only Axis can access that node ( and as mentioned earlier in this tutorial a value of -1 means the node is unavailable to either team).

The team value can seal off certain parts of a map from one team while still letting the other team use that area. However the most common usage will be single nodes at team barriers like team doors. Now unlike the RTCW version, ET has the covert ops class of bots that can use the other team's nodes when the covert op has stolen that team's uniform. This allows them to pass through most team doors for either team. NOTE: Some ET maps do have a few doors or barriers that forbid uniformed covert ops, but these cases are very rare. If you have such a case you will need to do more than just put a team restricted node. You may have to remove anything that would make the covert ops try to pass that point

Now you might want to use team specific nodes to encourage bot movement in an area to keep teams to certain areas say where there is better cover. That is a possible use, but as we will see in later sections there are other ways to influence where bots navigate. And unless great care is taken you could trap a bot at a spot where it can't navigate to its next action because the only paths are blocked by team settings or because the closenode of the action conflicts with the action. Because of the bots combat behavior if they end up in a place too far from any nodes that support his team they may get stuck there until killed, as you can guess this isn't a good thing, so just use the node team settings with caution.

Team node properties can be used in conjunction with grouping nodes and making them available at certain times in the match, but we'll get into that more later.

Node Flags

Node Flag Values

Currently there are 7 discrete node flag values that can be used. Other values are reserved for future use but not currently supported. You cannot combine nor add 2 flags together. Using any value not listed here will have unknown consequences so only use one of these 7 on any node;

  • 0 - Default, used on most nodes, this Normal node flag allows normal bot behavior.
  • 1 - Ladder top flag. Mostly used at the top of dangerously high ladders where no safe jump down is possible.
  • 2 - Ladder bottom flag. Used on most ladders at the bottom node, helps direct bot behavior for better ladder use.
  • 3 - Flag for a Checkpoint/SpawnFlag node. Used at a checkpoint or spawn flag location in combination with a corresponding flag action. (Also see node entity number.)
  • 5 - Simple Jump flag. Tells the bot to jump across to this node. Normally used for horizontal jumps with the nodes on either side being flagged as jump nodes (i.e. a 2-way jump). Typically used for jumping over a gap. Bots do not need to be told to jump up and over a small obstruction like a crate, fence or low ledge. However their normal behavior can't anticipate gaps or other places that can or must be jumped.
  • 6 - Leap-of-danger flag. Tells the bot that this jump (generally a jump down) will likely involve damage. Bots with less than 10% health will consider the node unavailable to them and look for a different path. Can be used generically to restrict a specific path to bots with more than 10% health, leaving the more wounded bots to use a unrestricted normal flag path.
  • 9 - Walk flag. Tells the bot to walk to the node. This is an important flag often used to stop a bot falling or running off a narrow ledge or cliff when navigating (especially at dangerous sharp corners). It can also be used when openings are narrow to prevent bots jumping and pushing each other and clipping on the door frame. I have also found uses for this flag when waypointing anything where the bot has to slow down and take care (cable cars, monorails, assault ramps etc.)

Grouping Together Nodes

You may have noticed that nodes can be set to non-zero groups. This allow for nodes to be enabled at a point in the game by the AI script (which we'll get into more later). This option should be used in conjunction with setting team specific nodes. For example you wanted the Allied bots to have sole access to using nodes 5-27 until some objective is completed. You would then set those nodes' team values to be Allied-only nodes. Next you would change their group number to be a common non-zero value (say 1). Then in the aiscript a command can be added to change the team setting for this group of nodes.

Now you can have many different numbered groups of nodes but it's best not to have too many. By default all nodes added to a map have a group number of zero 0. You can verify this in the in-game node HUD or by calling up that node's node_info in the console.


Now suppose you have set nodes 5 through 17 to group number 1 and you just placed node 18 in the map and need it to be in the same group. In this case open the console and type /node_group 18 1 then press enter. The group number for node 18 will now be set to 1 making it part of the other nodes' group.

The advantage that node groups provide is that they can reduce the number of node connections to be performed in the aiscript. However the limitation is that they can't replace the need or number of scripted node disconnects. We will cover this later in the scripting section.


Normally you will use node groups very little as they can make debugging and understanding you waypoint difficult. They can be good for blocking certain teams or all teams from accessing certain parts of the map until an objective has been completed. Keep in mind that you can't shut off or disable node groups, only activate them. Also keep in mind that most of the time the bots won't travel down nodes and paths if there isn't a currently active action to be reached from that path.

Spawn/Checkpoint Nodes

TO DO

Spawnpads and Bottlenecks

When you spawn, you and the bots do so on "spawn pads". Actually the "pads" are normally invisible points in space a little bit above the floor of the spawn area. These points are generally grouped together but spaced apart a little so your teammates do not bump each other. Now when they are grouped together in a room with limited exits, the bots all go hellbent for the exits and may plug the doorways slowing down everybody. Unfortunately while bots might apologize for team-kills they do not understand waiting their turn. Fortunately careful node placement can be used to control how fast the individual bots get to the exits.

You will need to be able to see the location of your team's spawn pad points to place these nodes. These points can be viewed from the in-game editor after using the console command;

/mal_showSpawns 1.  

Each spawn pad will then be shown by a thin colored vertical line (blue for Allies, red for Axis). These lines are much thinner than those for nodes so you have to look carefully to see them.

Now imagine a loop of nodes inside a room, passing though/beside the spawn pads. Each spawned bot will start at its nearest node and then run for the next node in the loop on the way to the door. If all the bots have to follow the same path nodes then the bots should exit sequentially without much problem. Below is an example for the single door exit in the Axis cabin on Railgun, note the thin red lines that indicate spawn pad points.

Image:Railgun_cabin_spawn_exitloop.jpg

Note how a few bots near the right side of the exit take the longest path so others nearby (e.g. at the far window) can exit out first. This method may slightly change how the bots fight (possibly more single-file like) so you should review the effect afterwards.

Now if there is more than one exit and they are not spaced far apart, I suggest that the loop be split in two before reaching the first exit. That way bots going for one exit should not slow down those going for the other exits. As to getting the bots to use both exits, you could use two disconnected half-loops or two disconnected parallel loops passing through the spawn pads. Alternately you could try routes (which we will discuss in a later section).

Ladders

For more on ladders see the article Waypointing_Ladders

Underwater Pathing

In water FritzBots swim, fight, and go up for air on their own reasonably well but not perfectly. So they need a little help from the navigation nodes in your waypoints. Waypointing underwater is pretty much like regular pathing after considering the need for air and the slower pace when swimming.

Waypointing in and under water is easiest done as a spectator since you won't drown, or float away. Most of the nodes will be placed at the waterline so the bots can breathe air easily when navigating. And try not to place the nodes too high, the bots have to aim at and touch the nodes. If the nodes are too high the bots will bob about doing a poor imitation of a butterfly stroke (and they can't jump out of the water like dolphins can they!).

So as a spectator, once you're right on top of the water and can see the waterline edge on, place your nodes like these.

Image: mdbridge_waterpath.jpg

It may be hard to see, but ALL nodes you place in water should be at the top of the water line except where you want the bots to go underwater (say to swim under an obstacle or into a submerged tunnel or opening). This placement encourages bots to swim along the top of the water and are then less likely to be damaged by lack of air. Don't put nodes underwater unless it's necessary. In maps like saberpeak where the water line goes up and down with the ocean tide you may place the nodes along the top of the lower waterline tide and increase the node radii somewhat. Also try to not place too many nodes in the water, your goal is to get the bots out of the water as quick as possible and back to fighting or whatever.

No special node flags or properties are needed for underwater paths. But verify that your node radii aren't intersecting with objects in the water that could trap the bots. Note that bots will only go up for air if there is an accessible waterline immediately above any submerged nodes. In areas such as tunnels where they can't access the top of the water they can still drown.

Frozen water Pathing

Ok so some maps have ice or a combination of ice and water that must be crossed (e.g. Fueldump and V1rocket_b2). The paths in the water are the same as in maps without ice except that the nodes that are at the ice-to-water interface may need larger radii since the bots are sliding about. In fact any nodes on the ice will have larger radii so the bots don't go sliding backwards because they missed touching their next node. In general direct bots away from any ice not necessary to game play. And when they have to cross ice aim them in a straight line if possible so they can just slide right across. (When not distracted by taking fire.) Your aim must be to get them back on "dry" land ASAP. If you cant cross in a single straight line then look for a sequence of straight lines each ending off the ice before starting on the next one. And avoid putting too many nodes on the ice, better that most be at the land-ice interface where possible.

Pathing Hills & Stairs

Another place where care is needed (to avoid having bots backtrack) are slopes like those on hills. Going up the hill or slope is easy to waypoint. Just join the map on whatever team and follow the edge or surfaces on the slope that you would chose as a human. Place enough nodes for the changes in direction you take and if you have to slow down to avoid going over an edge then the bots need to be told by node walk flags to do the same.

But it is going down the slope where the problems arise. Boys run and jump more than most humans, so the nodes you place going down a slope may be closer than those a bot would choose.

MORE TO DO

Testing Bots On Your Nodes

For simple testing of the bot's abilities to successfully navigate a path you have created, you do not need to have an aiscript file nor do you need hardly any actions added to the nav file. Well actually you need exactly 2 actions in the nav file for the start and end points of a bot navigation circuit. The two actions should be roaming actions that are active at the start of the round and available to both teams. One or two bots may then be added to test the navigation. Any class of bot will do but medics are the best since they can heal themselves as may be needed. When no aiscript exists the bot sight distance is undefined. The bots are then practically blind and thereby unlikely to fight which is fine for just testing the pathing.

Referring to the example waypoints of et_slide the nodes on the axis side form a simple loop with a roam action at the spawn and another in the tunnel at the health and ammo stands. Since the slide is a one-way path the bots must use the ladder to return to the roam in the spawn at the top of the slide. They then choose to use the slide as the shorter path to the other roam action. With only 2 actions available the bots must alternate between the two making them repeatedly navigate the same circuit giving you multiple chances to evaluate their success and tweak or correct things.

Miscellaneous Stuff

Unlike the RTCW version FritzBot ET does provide partial support for some script movers (e.g. trucks and tanks) However effective pathing along the vehicle's path can be tricky. This will be discussed in the advanced waypointing section.

Other special pathing cases that can be waypointed with some trial and error include;

  • Teleport pads
  • Jump Pads
  • Some non-objective script movers (monorail cars, cable cars...)
  • Some elevators
  • Some one way trains

However not all of these are practical in all cases. You should spend some time investigating how to handle these in a test waypoint before committing to doing the rest of a map containing such difficult paths. That way if you cannot resolve these special paths you can start over from a blank waypoint and waypoint the bots to avoid these things.


Now that you know how to set the attributes for nodes you should be aware that the vast majority of nodes will be plain nodes. That is they will be used by both teams, have only 2 way connections, default normal behavior flag, no entity value, and one of 2 common radius values (70 in open areas and 40 or so in narrower interior corridors). Use of unnecessary team restrictions, path direction restrictions, and behavior flags (especially leap flags) may make debugging your waypoints more difficult and time consuming, so keep your nodes simple wherever you can.

Console Command Quick Lookup


/node_drawradius 1 = Draws the radius spokes on screen of nodes, actions and routes for the current map (a value of 0 turns this off, a value of 1 turns this on)

/node_radius <node#> <Radius#> = Sets the specified node's radius to the value given (ex. entering /node_radius 1 50 will give node 1 a radius of 50)

/node_defaultRadius <Radius#> = Changes the default radius value for any new node you add to the waypoints (ex. when waypointing doorways and ladders entering /node_defaultRadius 20 will make subsequent nodes placed default to a radius of 20)

/node_team <node#> <Team#> = Sets which team can use the specified node. Team value zero 0 means that any team can use the node. To limit the node to Axis only use Team value 1, and for Allies only use value 2. Nodes can also be disabled with the value of minus one -1 (i.e. neither team can use). (Ex. entering /node_team 1 2 makes node 1 accessible only by the Allied bots)

/node_flag <node#> <flag#> = Sets a bot behavior flag on that specified node. Bots navigating to that node are informed about any special condition. (ex. entering /node_flag 1 3 will tell the bots that a spawn or checkpoint flag is near node 1, a value of 0 indicates it's a normal default node, a value of 6 indicates that it leads to a dangerous jump, and a value of 5 indicates a gap is ahead and the bots must jump across it, a value of 1 indicates it's the top node on a ladder, and a value of 2 indicates it's the bottom node on a ladder.)

/node_group <node#> <group#> = Groups together nodes so they can be turned on (if disabled for one of the teams) in the AI scripting system. (ex. /node_group 3 1 makes node 3 part of node group 1)

/viewent = Is used to print in the console the entity properties of map objectives and other entities pointed at in your crosshairs (such as MG42 nests, dynamite or construct objectives etc.). This command has no parameters.

/node_ent <node#> <entity#> = Sets the specified node's entity number to the value given to alert the bots that an objective is nearby. For nodes it's only used for checkpoint and/or spawn flags. Use in conjunction with the viewent command. (ex. Entering /node_ent 1 543 sets node 1's entity number to 543 which means it's near the team_WOLF_checkpoint entity 543 in the map)

Next Tutorial

There are a few test questions you can try for review Here (I suggest you open it in a new window or tab)

To continue the tutorial go to FritzBot ET Advanced Waypointing. Or skip ahead to the tutorial on FritzBot ET Actions

Further Reading

Credits

Special thanks go to Denny for his RTCW tutorial on which this article is modeled and borrows from.