Common errors

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.
However, there are also lots of stupid errors that can be avoided right from the start - if you know them. The most important ones will be listed in the following paragraphs (in no particular order). Read this section carefully and do all bot players a favour: Don't repeat what so many others have done wrong already!

Leaving out areas of the map

Many waypointers are too lazy or too sloppy to waypoint the entire map. Or maybe they think that with PODBot 2.6mm, bots are limited to a few key routes anyway, with more waypoints only causing confusion.
This is wrong! Bots can take advantage of the entire map, and it's much more fun if you know they can be anywhere where players can go. Besides, unwaypointed areas can cause bots to get stuck! During regular waypoint navigation, bots will indeed stick to the waypoints and just ignore unwaypointed areas. But please remember that in some situations (mainly in combat), bots will switch to unwaypointed movement! Thus, a bot engaged in a firefight might move into an unwaypointed area while following the enemy or retreating from combat. As soon as the bot switches back to waypointed navigation (because he has killed the enemy or the enemy has fled), he might find himself in an area without any waypoints to navigate! Or a bot might fall down from a ledge and into an unwaypointed area. In such situations, the bot is very likely to get stuck.
NOTE: There are situations that make leaving out a certain area acceptable. For example, if a passage is just not passable for bots, it can of course better not to waypoint that passage at all. In any case, the more secluded and difficult to reach the unwaypointed area is, the less risk of bots getting stuck you'll have to face. If you leave out a balcony that can only be reached by climbing up a ladder, you ought to be quite safe if you don't waypoint the ladder and the balcony. Still, you should never do this as long as you think that it might be nice to see a bot up there once in a while. Don't leave out areas just because you are plainly too lazy.

Bad use of the autowaypointing feature

In the example screenshot you can see what happens when a waypointer just fully trusts the autowaypointing feature and doesen't take matters into his own hands. I can almost see how he ran to the building and back a few times in autowaypointing mode and thought that this was sufficient. The result is an insane accumulation of waypoins on one narrow path, 80% of these waypoints being totally unnecessary (see below) and large areas of the map remaining unwaypointed (see above).
Other negative aspects of the autowaypointing feature are that you cannot control waypoint placement at important spots like corners etc. This increases the risk of having bots bump into walls and navigating rather clumsily.
If you must use this autowaypointing feature (and a good waypointer doesn't), at least restrict its use to passages where it makes sense and cannot spoil much: long, straight corridors without doors, for example. But when it comes to covering large open areas and waypointing corners, doors, ladders, narrow furnitured rooms, ledges etc., don't use autowaypointing.

Placing unnecessary waypoints

The example above already showed many unnecessary waypoints. Waypoints are unnecessary when they are located between two other waypoints that could be connected directly (without using insanely long connections, of course!!). A connection pattern like A<=>B<=>C makes sense. But if A and C are also directly connected with each other (overlapping connections), B is completely superfluous. Such a connection pattern will only clutter up bot navigation: It encreases the number of waypoints to choose from in order to get from one point on the map to another, but it doesn't offer more alternative passages if all those waypoints are concentrated in one area.
In the screenshot below you can see an example of extremely useless overlapping connections. 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.
Avoid this by not using autowaypointing, by carefully choosing the optimal apmd setting for each area of the map or at least by deleting unnecessary waypoints or connections.

Unconnected waypoints

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.
The example pic shows one mistake that's very easy to make: When waypointing a ladder, a one-way connection from the first normal waypoint near the top of the ladder to the upper ladder waypoint is drawn automatically. However, the upper ladder waypoint by default remains unconnected with the nearest normal waypoint around; you must add this connection manually. [this woul be a place to refer to the basic waypointing document, "how to waypoint ladders"] If you forgot to do so, bots will only be able to climb down the ladder, but they won't be able to get up. Now if there's a longer way to reach that raised area the ladder leads up to, the bots can still go there (and the editor won't report an error!). However it might take them ages and spoil the overall gameplay on that map. So keep an eye on those connections!

Leaving undesired 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 two-way connection: down from the waypoint on top of the crate (which is fine) and up to the crate (which will cause bots to run into the crate and get stuck forever). Originally there was only a one-way connection down from the crate. But as the waypointer took the waypoint on top of the crate as a starting point for a jump, an additional connection up to the crate was drawn automatically. You may also encounter this problem when waypointing narrow ledges: Sometimes the waypoints on the ledge will be located slightly over the edge, and wrong connections up to the ledge may be drawn. Another error also occurs with jump start and end points quite frequently: Wrong connections leading down somewhere. Take the example picture; I just said that the connection down from the crate was fine, and in this case, that's true. But can you imagine what would happen if the crate were higher? Bots might follow the connection(s) leading down and get hurt - they may eventually kill themselves if they don't have many HP left anyway!
All of these errors can thoroughly spoil gameplay, so be very careful. When you draw jump connections, better turn auto-connection off. This way you can make sure that only the jump connection will be drawn, nothing else. If you forgot to do so, for example when you were creating a bunch of jump connections to get bots on top of a stack of crates, walk around the stack on ground level and carefully check for wrong connections. Watch for yellow lines!
When you want to waypoint a ledge, wait until you have the area below the ledge waypointed comnpletely; you might need high apmd settings there. Then you can go up the ledge and decrease the apmd setting to a value that makes it technically impossible to have connections between the ledge and the waypoints on the ground below it. Of course, the wayypoints along the ledge will have to be closer together that way, but that's really ok for ledges. If you forgot to follow this procedure (and we all do sometimes), walk along the ledge and look carefully if you see any undesired connections between the ledge and the waypoints on the ground.

Sloppy connections 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. Since this is so easy to avoid, I don't understand why it keeps happening, but it sure does. In most cases I bet that waypointers just didn't pay attention to the connections that were drawn by the editor. They just placed one waypoint in front of the corner, one waypoint right in the corner and finally one behind the corner - and obviously they didn't even look back once in order to see if the waypoints in front of the corner and behind the corner had been connected with each other automatically.
If this happens to you, it means that you didn't select the optimal apmd setting or - viewed from a different perspective - that you didn't place waypoints according to the currently active apmd setting. This is no catastrophe; if it happens, just delete this stupid connection and everything will be fine. But do delete it.

Jumps not properly waypointed

Jump connections can be the icing on the cake - but only if they are properly used. Many waypointers, however, don't place jump connections where they would be just perfect, or they make jumps too complicated. This applies especially to jumps through windows.
As you can see in the example pic, the waypointer just made a 2-way connection up that crate, and it continues like this. When bots see a "normal" connection, they assume that they can reach the next waypoint walking or running. Now if they run into an obstacle, they will try if they can proceed by crouching or jumping. In the example screenshot, an approaching bot would run into the crate, then probably make some stupid movements and finally jump onto the crate. Everything fine, then? NO!
Bots lose much speed that way, and their movements wil look clumsy. Besides, they may try going a bit left and right, and if they are already standing on a small crate and want to get up onto the next one, they may fall down instead. Better place a waypoint in front of the crate, another one on top of it, then turn off auto-connection and make a jump up the crate. Now bots will jump just as you do. They will get up there quickly and easily.
With windows, many waypointers have their bots jump into the window frame first (they place a crouch WP there) and then go down on the other side. Of course this is not really an error. It works, and in some cases it's even the only solution. But before you do it this way, it cannot hurt to try if you can jump through that window in one big leap. It may take several attempts until you finally succeed, but if you get it waypointed that way, your bots will jump right through the window without slowing down - that's really quite neat. You'll like it... ;o)

Unappropriate waypoint radii

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.
As you may already have guessed, this is of course wrong. The radius calculation gets influenced by high obstacles near the waypoint, so if there's a wall at 64 units from a waypoint, the radius will automatically be set to a maximum of 64 or even less. However, if there are only low obstacles around the waypoint, the wayzone is likely to go over these obstacles, resulting in bots bumping into them. The worst part, however, is yet to come: If there's an abyss, a ravine, a hole in the ground or whatever, the radius calculation is not affected by it. So the wayzone will go over that abyss, bots will think they can go there and fall down. This is shown in the example screenshot; the wayzone there should be really small, if not zero.
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 thta 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.
Get into the habit of monitoring waypoint radii and lowering them manually whenever necessary.

Badly placed / connected waypoints near doorways

Another very common error to be found around doors and doorways is not only the radius (see above), but also wrong placement of the waypoints themselves. You often see angled connections through doorways (in the worst case, paired with too big radii as mentioned above).
Take a look at the following screenshot, and you will see that bots are bound to bump into the wall several times before they finally make it through the door. If this doorway has a kind of frame that sticks out of the wall, bots might even get stuck there forever.
Therefore, make sure that you place the waypoints on both sides of narrow doorways exactly in the middle of the doorway. If the connection through the doorway (1)goes right through the middle, exactly halfways between each side and (2) crosses the doorway in an angle of exactly 90 degrees, everything should be fine. And of course, remember to set the radii to zero!

Bad approach angles for ladders

Ladders are another map element that requires carefully placed and connected waypoints. Both waypoints from which bots will approach the ladder (the one at the lower end and the one at the upper end, obviously) ought to be placed directly in front of the ladder whenever possible. This way, the connection will go straight to the ladder waypooint and not at an odd angle.
One thing to remember when waypointing ladders is that at the lower end, a two.way connection to the nearest waypoint will be drawn automatically - no matter at which angle to the ladder this waypoint is located! The connection might even go right through the ladder, causing bots to get stuck.
The best way to avoid this is by making sure that there's an ideal approach point in front of the ladder before you waypoint the ladder itself. And if you forgot to do that, at least choose the best approch point manually and delete the automatic connection if it's bad. If you waypointed the ladder first, make sure you delete all angled or otherwise bad connections to the ladder waypoint and only leave the straightest connection up.

Placing waypoints too closely together

[I think we can copy CF's explanations directly in this paragraph]

Bad placement of special & important waypoints

Team-specific waypoint can be a good means to fine-tune gameplay or to get bots to use less obvious routes. However, many waypointers have a strange strategy in this respect...
In short, the most important things to avoid are:
- placing important waypoints for both teams right next to each other (brainless deathmatch may result)
- placing important waypoints for the "defending" team (T on cs-maps, CT on de-maps) on the opposite side of the map. Have the defending team defend the map goal; place important waypoints at strategic positions they need to keep under control in order to defend themselves. Don't make them rush blindly through the map.
- placing important waypoints in isolated areas. Rather stick to crossroads or intersections of any kind. Place them in positions where several passages or areas can be monitored and defended.
- placing too little important waypoints for the defending team and too many for the attacking team. The attacking team will attack anyway, plus they will treat the defending team's important waypoints with priority, too.
- placing too many important waypoints in general. If every 2nd point is marked as "important", the relative importance of each point is minimal.
Moreover, be especially careful with rescue waypoints. When a CT bots leads hostages to the rescue zone, he runs until he has reached the closest rescue waypoint and, having reached it, immediately turns around to run back into battle. Now if your rescue waypoint is too close to the edge of the rescue zone, the bot may turn back before all hostages have reached the rescue zone. In this case, the hostages would follow the bot back into battle, which is just ridiculous and annoying.

Forgetting to place nohostage flags on CS maps

Surely you will recognize the spot of which I took the following screenshot: It's the sewer tunnel in cs_militia. Once the hostages are down there, they can never be taken to the rescue zone. Good news for the terrorist team, bad news for gameplay.
Things like this can happen quite easily - all it takes is one tiny forgotten "nohostage" flag. Make sure that you blocked every passage that's not suitable for hostages with "nohostage" flags. The same applies to camp waypoints, unless you explicitly wish that bots with hostages sit down and camp while their last precious seconds are ticking away...