![]() |
|
This chapter will deal with errors that are easy to make and thus occur quite frequently. Of course you will rarely get a totally error-free
waypoint set in the first attempt. Many errors cannot be seen when looking at the waypoints alone. In order to spot them, you need to start
a game and watch your bots. |
I. Waypoint-related errors Unwaypointed areas Many waypointers are too lazy or too sloppy to waypoint the entire map. Or maybe they think that with PODBot MM, bots are limited to
a few key routes anyway, with more waypoints only causing confusion. This is wrong! A harmless case... still, there is no reason to leave so much space unwaypointed. Note: Unnecessary waypoints In the following example screenshot you can see some totally superfluous waypoints. While waypointing this area, the waypointer totally ignored the fact that there is already a connection from the waypoint in the foreground to the one that's located furthest in the background. This connection makes the two waypoints in the middle obsolete. In this area of the map, you can only go through the door or back. Placing more waypoints there doesn't give the bots more alternatives. Only the waypoint in the far background is needed, the other two are superfluous. As you see, there is just one passage anyway, so connections from point to point would have been sufficient. Having connections overlap
makes bot navigation more complicated and increases the risk of bots getting stuck in each other, when they think that they are taking different
paths. But if these paths overlap so heavily, there won't be any real difference. Waypoints too close to each other Apart from the fact that two waypoints at such a close distance from each other are unnecessary, they can cause problems by messing up the bots navigation. This is due to the fact that there's a certain radius hardcoded into the bot dll (this radius has nothing to do with the waypoint radius you can set!). For example, a bot considers normal waypoints to be reached when it is inside a radius of 50 Units from the center of the waypoint. Now what happens if two waypoints are so close to each other that their hardcoded "reached" radii overlap? Let's take the following picture as an example: Never place waypoints that closely together! As soon as a bot has reached one of the depicted waypoints, it automatically thinks (in the same frame) it has reached the other one as well
- without moving! This is obviously bad for precise movement. Bad use of crouched waypoints In order to use crouched waypoints correctly, it is important to know how bots react to these waypoints. Let's have a look at the following picture - the waypointer obviously wanted to get his bots through this half-closed door: At a first glance, everything looks perfect here... but it isn't. Now what's wrong here? Well, bots will crouch as soon as they approach a crouched waypoint, but not when they leave one. To stay with
the example picture, a bot that approaches this door from the left side of the screen will crouch down as soon as it has reached the standing
waypoint on the left. The bot will know that by following the connection towards the middle waypoint, it will reach a crouched waypoint. Thus,
it crouches and crouch-walks until it has reached the middle waypoint. Once the bot has reached the middle waypoint, it will know that the next
waypoint in the line is a standing waypoint, so the bot will stand up- and run head first into the door. Badly placed important waypoints Those Team Specific Important waypoints sure are a nice feature, but many waypointers obviously don't know how to take advantage of this feature. Look at the following screen: Both the CT Important waypoints and the T Important waypoint are badly placed. This "masterpiece" is actually an ideal example to show all relevant errors about team-specific important waypoints in one single picture. Let's have a look at a few facts:
On a side note: Those stupid connections you can see in the picture really take the cake... at least this way you see how much you can do wrong in one lousy room. |
II. Connection-related errors Missing Connections At Ladders Or On Stairs Although the editor checks for unconnected waypoints whenever you save your work, it will only find those points that cannot be reached at all.
However, you might have a spot in your map where one connection is missing, but there's another way to reach the point in question. This error
can easily occur at ladders or on stairs. Pretty much the same applies to staircases: If you do not (or cannot) place waypoints right in the middle of individual stairs, but rather insert them over the edge between two stairs, so that they end up hovering in the air, chances are that there will only be a 1-way connection down to the next waypoint on the stairs, but no connection up. Obviously, the consequences will be the same as with badly waypointed ladders. However, with stairs you can easily overlook a missing connection because under the blue radius bars, the yellow lines for two-way connections appear white anyway. Thus, it can be hard to tell if the line just appears white, but is a perfectly working 2-way connection or if it actually is white, meaning that it's a 1-way connection only. When waypointing stairs, get into the habit of strafing around each freshly placed waypoint a bit to see if everything is in order. Wrong Connections Especially when waypointing ledges and drawing jump connections, you may experience totally undesired connections being drawn automatically. In the example pic you can see a one-way connection up to the wall. Ouch! This connection will cause bots to get stuck forever. This is one of the worst errors that can appear!! When bots try to follow this connection, they will get stuck in the wall forever. So take
care to remove such connections or even better to prevent them in the first place. Sloppy Connections Through Doors And Around Corners This must be one of the most common errors in the whole waypointing world. Even in absolutely simple passages you are likely to encounter connections that cut a corner so closely that bots are bound to bump into the corner. Or you can see a doorway that is waypointed so badly that bots will bump into walls all the time before they finally manage to struggle through the door! See this example picture: If you want your bots to have problems with doorways, follow this example... You can try such a connection by walking exactly on the yellow line: If you bump into something, the connection is bad. With the depicted
connection, you would bump into both sides of the doorway. Overlapping Connections Check out the following example screen, the normal waypoint in front of the vent access is connected with all crouched waypoints inside the vent. A lot of unnecessary connections Now there was a similar pic in the section "unnecessary waypoints". Isn't this really the same and could be solved by deleting the first two crouched waypoints? One thing is for sure,it will cause the same problem that I described in "Unnecessary waypoints". But in the end, this case here is still a bit different, because the waypoints themselves are placed perfectly. It's good to have small distances between crouched waypoints, and that crouched waypoint directly in front of the vent access will ensure that bots going out of the vent will stay crouched until they have left the vent behind. That's why in this case the solution is not deleting waypoints, but removing the overlapping connections. Make sure that in such waypoint setups, the first waypoint in the row is only connected to the second one and the second one with the third etc. This is quite easy to do if you just lower APMD to an appropriate distance. No Use Of Jump Connections This is another quite frequently appearing error. In many places, you will find normal 2-way connections leading on top of an object (a crate, a barrel or whatever), just like in this screenshot: A jump connection would be ideal here. Now it is true that bots will get up that stack of crates eventually by following these connections. However, they will first bump into
the crate. Then, after realizing that they cannot reach the next waypoint by simply walking towards it, they will eventually try jumping up.
The same procedure will repeat for the next crate, and all in all your bots will look very clumsy. In fact, they might even fall down while
trying to get to the topmost crate. In their struggle to get up, they may well try walking a few steps left and right to get around what's blocking
them. Doing this, they could take a step too far and land on the ground. |
III. Radius related errors As you know, the radius of a waypoint (also called "wayzone") indicates how precisely a bot will navigate around that point. Now PODBot
calculates all radii automatically, and many waypointers think they can rely on that calculation and restrict their work to placing waypoints. Too big radius, bots can fall down Another place where you often find too big radii is around narrow doorways, breaches in a wall or other not-so-spacious passages. Imagine you have a wall and a narrow breach in it (24 units wide or something). Now if the waypoints on both sides of the wall are far away from high obstacles (such as the wall itself), their radii will automatically be set to a value much higher than the width of the breach. Now if bots want to go through that passage, they will think that they can use those huge wayzones assigned to the two waypoints in front of the wall and behind of it. As a result, they are very likely to run head first into the wall left or right of the breach. Similar to what would happen in this picture below: Too big radius, bots will bump into the wall Get into the habit of monitoring waypoint radii and lowering them manually whenever necessary. |
IV. Flag-related errors NoHostage Flag Missing (cs-type maps only) On CS_ type maps, it's very annoying when a CT bot activates the hostages and then loses them on its way to the rescue zone. That's why it's
so important to show bots where hostages won't be able to follow them, thus forcing CT bots with hostages to choose passages where the hostages
won't get stuck. Remember to block ladders, vents, windows and jumps. I prefer to block all camp waypoints as well because I don't want to see
a CT bot with hostages have a sitout in some dark corner while the last seconds are ticking away... Bad use of button flags A button flag doesn't have to be placed wherever there is a button. Bots check for obstacles and buttons automatically. If you have a door
that stays open once it is opened by using a button, you won't need a button flag. The first bot to approch the door will detect that it's closed
and push the button. All it takes is a connection setup that will force the bot to pass by near the button before going through the door. Once
the door is open, the next bot will know that there is no obstacle, ignore the button and just walk through. NOTE: These rules apply to buttons that need to be pushed (by pointing at them and hitting the "use" key). If the "button" is actually a small area you just have to enter in order to activate a door or whatever, all it takes is setting up connections in a way that bots go through this area. You can think of such areas like invisible little touchplates in the floor - obviously, you must make your bots walk over them to make them take effect... Waypoints around a button-triggered door; connections shown as arrows. This picture is meant to show the principle; I added some arrows to make the connections visible because correct connections are very important
here. As you probably guessed already, those yellow, two-headed arrows represent bi-directional connections, whereas the single-headed white arrow
represents a one-way connection that leads into the direction indicated by the arrowhead. Here you can see that it was made it impossible for bots
to come climbing up that shaft and go right through the door - because they would get stuck! Instead, they have been forced to pass by the button
first, and they have been forced also to keep them as far away from the door as possible before they reach the button. What's the result? The bot code is not yet perfect when it comes to buttons, so this might not work perfectly. However, if the first bot fails to push the button,
a second one coming after it might help its colleague out...
Phew... that was a huge amount of theory! To put all this into practice, you will need... practice! So click on 'Waypoints - Useful keys binding' and get into it! |