A few words about the navigation system Marine Bot is using

First you need to know that Marine Bot waypointing system is using waypoints and paths. Both are important parts of the whole system. Parts that communicate together and support each other. The waypoints are pretty self-explanatory issue. Basically the waypoints themselves are just points in 3d space. The bot has no eyes. So the waypoints tell him this is walkable space not a solid wall. Some specific waypoint type does tell him there is a ammobox here. Other specific waypoint type tells him there is more than one route here please choose one. And so on. As I said the waypoints are just lone points in the space. They will not tell the bot where does he need to go. They will not tell him where is next waypoint. I'll say it once more, because this is important information. Every single waypoint is just a lone point in the space. Nothing more.

And this is the reason why there are the paths. They allow you to connect the waypoints together. The paths link those separated points in the space together and form routes the bots can then follow. The path will always tell the bot where does he need to go to reach the next waypoint. The path doesn't inform the bot only about the next waypoint. It can tell him what will he be able to do there several waypoints ahead, because paths do take information from some of their waypoints and transmit them to bots. Let me explain it. I already said there is a specific waypoint type telling the bot there is a ammobox there. So if such waypoint is in a path then the whole path transfers this information. Now if the bot is running low on ammunition he will be looking for such path. And whenever he has the chance he will choose a path like that as a path he will follow. You can also put more general information into certain paths. As a sort of a hint telling the bot that this path will lead him to the location where he has to deliver the map object item for example a briefcase. Okay let's move to details.

Waypoint

Each waypoint is build out of many important informations. It is its exact position in the 3d space. Also known as its origin. Next one is its type. Then there is its priority. Its time. And finally its range. All of them have its default value. However all these values can be changed whenever you like. Some changes will have quite a big impact on the waypoint itself. And some values will change automatically as a result of your previous actions. Don't worry everything can be fixed even if you do something big in error.

Waypoint position

Related console commands are: 'wpt add' and 'wpt move'

You can't set this value directly. Everytime you use the command to add a new waypoint in the map the waypoint is added at your actual position. Basically the waypoint takes it from you. The same holds true even when you want to change waypoints' position. Yes there is a command that will allow you to reposition existing waypoint. You move it to a new place if you wish. Yet again at the moment you use this command the waypoint just takes the position from you.

Waypoint type (or tag or flag)

Related console commands are: 'wpt add <argument>' and 'wpt change <argument>' where argument is the type of the waypoint ... no quotes nor brackets

There's quite a variety of different waypoint types. You may have already seen the list of waypoint types in the 'support' section of Marine Bot web. Or you may have already seen them in the game. Let's go through them again. This time we will try to explain them in details.

Waypoint priority

Related console commands are: 'wpt setpriority <number 0-5> <team>' and 'wpt triggerevent setpriority <number 0-5> <team>'

Waypoint priorities help the bots navigate through the map and will determine how the bots 'play' the map. While there are no team specific waypoints you can set waypoint priorities differently for each team. You can safely ignore waypoint priority on most of the waypoints you add to the map with the exception of two specific cases. Waypoint priorities are used by the bots when they reach a 'cross' waypoint. As we already said you can imagine it as sort of a junction. 'Cross' waypoints trigger the bots decision making. When they reach a 'cross' waypoint they will then choose the next waypoint based on waypoint priority. Using waypoint priorities you can force the bots to use certain routes more than others. And the other time where the priority plays a role is on a few special waypoint types such as goback, shoot, aim etc. Where you can set priority to zero to disable them for specific team.

This picture shows an example - yellow dots represent normal waypoints, blue dot is a cross waypoint and the numbers are priority levels for waypoints. Cross waypoint should have the default/lowest priority 5. It is only a signal for the bot to run the 'choice code'.
an example of priority setting around cross waypoint

Let's say the bot comes from the south. It reaches the 'cross' waypoint and because the waypoint on the left has a higher priority than waypoint on the right the bot will decide to go to the left. He will do so most of the time. But there is also chance (small chance) that bot will ignore priority and decide to go to the right. This random behaviour has been done on purpose. We don't want the bot was easily predictable. The next picture shows exactly what was just described. The green dotted line shows how will the bot move through this junction. And you can also see there the exact moment when the bot is making his decision.
the decision making when the bot reaches a cross waypoint

Now if the bot comes from the north. No matter whether he is coming from the right or the left. The situation would be the same. Most of the time the bot will choose the waypoint with the higher priority. If you look at the picture closely you may notice that the bot isn't going toward the cross waypoint at all. The green dotted line goes from the waypoint where the bot does his decision straight to the waypoint he just chose. This shows exactly what was said in the description of the cross waypoint. Feel free to scroll a few paragraphs back and read the description once more if you want.
yet another decision making when the bot reaches a cross waypoint

If all waypoints have the same priority the bot will choose one randomly. It is best to set some priority on all waypoints in the direction you want the bot to move, this will prevent unwanted turn backs. Waypoint priorities and cross waypoints are the first key to successful, intelligent bot navigation. Please read the previous sentence again, because this is very important.

Waypoint time

Related console commands are: 'wpt settime <number> <team>' where number is the time period in seconds

The next thing you can specify is waypoint time. The time (in seconds) that the bot will wait at his current waypoint. It can be used with almost all waypoint types. You can for example use a crouch waypoint behind a corner with a long delay to effectively get a bot to camp. Don't forget to place also one or more aim waypoints in the direction the bot should be watching. There are two time values on the waypoint. One for each team. That allows you to make the bots from one team to guard the waypoint while the bots from the other team won't even stop there. You can also force both teams to wait there and each team will have different wait time.

Waypoint range

Related console commands are: 'wpt setrange <0-400>' and 'check_ranges'

You can imagine waypoint range like a circle around the waypoint. The bot will use this whole space to detect that he reached the waypoint. Actually the bot randomly picks one point from the whole range and he will go there. You will never see two bots that would be moving through waypoint range exactly the same way. The bigger the range is the more visible this behaviour is. This again helps to make the bot less predictable. However you should keep an eye on this value and make sure the waypoint range doesn't interfere with any obstacles. If it does then the bots may get stuck on any objects that lie inside the waypoint range. Any range under 20 units (19 and down) will cause the bot to slow down and proceed 'carefully' so that he doesn't miss the waypoint. This is a valuable tool for getting the bots through very narrow passages, or along dangerous routes like ledges, or the tops of walls. Use the 'check_ranges' command to give you a two line cross section that will show you how large your waypoint ranges are. Next to setting your waypoint priorities, setting your waypoint ranges are the most important factor in determining smooth, intelligent bot navigation. I would recommend that you set the waypoint ranges as you place the waypoints. Returning and resetting all the ranges on all your waypoints after you have placed them all can be a discouraging, time consuming procedure.

Let's see some examples. This is how does the range look like in the game after you used the 'check_ranges' command. Notice those thin white lines that are intersecting the waypoint beam in the middle. They are showing you the waypoint range.
an example of waypoint range in game

Here's the same thing again. I have only edited the picture to highlight the exact waypoint range, because the range isn't just the two lines. It's the whole circle. Each point inside the circle is considered as the waypoint range.
an example of highlighted waypoint range

Let me show you how does the bot work with the range. As we already said he will randomly pick one of the points from inside the circle. I've marked it with the red 'x' on the picture. And will go toward it in order to pass this waypoint. The red dotted line shows the actual trajectory he will follow while passing through this area.
an example of how does the bot work with waypoint range

Last picture still shows the same waypoint, the same range, but this time the bot picked different point from the range so he will follow a different trajectory.
an example of how does another bot work with this waypoint range

I hope you already understand why you should pay close attention to setting a proper waypoint range. If there is a wide open area with no obstacles like crates, trees, sandbags etc. feel free to use big waypoint range. The bots will then move a lot like a real human does. And if there are obstacles on the way or you need to pass through a narrow passage you also need to reduce the waypoint range in order to prevent the bots getting stuck here and there.

Cross waypoint range

Related console commands are: 'wpt setrange <0-400>' and 'check_cross'

Similar to standard waypoint range is the cross waypoint range. The main difference is that the bots don't use this range as space for walking. They will never try to pick one specific point from inside the cross waypoint range like they do on standard waypoints. As we already said this waypoint works only as a marker to start the decision making where will the bot go next. Basically the cross waypoint range tells the bot which waypoints are available to choose from. Every waypoint that is inside the cross waypoint range is taken into the decision. The bot will then choose one of these waypoints in order to get to other parts of the map. Just like standard waypoint range even range on cross waypoints can be displayed. There is a command 'check_cross' that will show a connection between cross waypoint and any waypoint that is inside this cross waypoint range. In other words this command will show you all waypoints that the bot is going to use to make his desicion on this particular cross waypoint. Please look at this sketch which summarises previous description.
cross waypoint summary

Previous sketch says that it doesn't matter where you position the cross waypoint. That is only partially true. If there is enough space around the cross waypoint and you have used quite big range then it really doesn't matter if you place the cross waypoint a few units here or there. However if you are working on a crowded area (e.g. stairway, narrow hallway or inside a building in general) then you will have to literally fine-tune not only its position, but also its range. There are two reasons. First you don't want to have some waypoints from this or that direction being disconnected. And second you should never connect more than one waypoint from one specific direction. Let me show you what I mean on another sketch.
cross waypoint summary

Paths

Second part of Marine Bot navigation system are the paths. The basic meaning of a path is to get the bot from one location to another. It doesn't matter how far away the other location is because there is basically no maximum limit on path length. The path can be as long as you wish. Any path is build from waypoints. You can add any waypoint type to a path with the exception of a cross waypoint and an aim waypoint. Typical path creates a connection between two cross waypoints. In other words it gets the bots from one junction to another. Or from junction to important spot like a 'pushpoint' on push maps or any kind of object on obj_ maps or just to some sniper spot. Look at the next picture. The path is the purple horizontal line that runs through the 3 waypoints there in the middle. This is an example of typical path that created a connection between one cross waypoint on the left and another cross waypoint on the right side. The paths can have many colors and they can also alter the look a bit, but they will always look like a thick horizontal beams. Actually you can see that too. There's a path on the left side leading to a sniper spot. That path has a green color which tells you it's a class specific path. Only a bot with sniper rifle will be able to follow this path.
an example of paths

Adding a new path

Related console commands are: 'pathwpt start', 'pathwpt add' and 'pathwpt stop'

Use the 'pathwpt start' command while standing really close to the 1st waypoint (i.e. the waypoint where you want the path will start). Then move close to the 2nd waypoint and use the 'pathwpt add' command there. You've just created the shortest possible path. If you want to continue adding more waypoints you'll have to get close to each of them and use the 'pathwpt add' command there. Whenever you wish to end the path you can just type the 'pathwpt stop' command into the console. Make sure you have all waypoint in the path because 'pathwpt stop' command doesn't add anything. It will finalize the path. Finalizing the path is quite important step. If you didn't do it then the system would still take it so you want to keep working with this path. So any path changing command you would then use would be applied to this path. Actually you can use this feature in your favor. For example if you want to make that path for one team only. You can do so before you finalize the path. Anyway look at this sketch showing you the proccess of creating a new path in exact steps.
how to build a new path sketch

Working with existing paths

Related console commands are: 'pathwpt continue', 'pathwpt insert', 'pathwpt remove', 'pathwpt delete', 'pathwpt setdirection', 'pathwpt setteam', 'pathwpt setclass' and 'pathwpt setmisc'

Now when you already know how to create a new path and you may have already added several paths to your waypoints. You may want to know whether the paths can be changed in any way. Of course you can do it. It would have been insane if you couldn't edit them. There's a whole set of commands allowing you to alter any path you aren't happy with. You can continue adding new waypoints to the end of existing path. You can even insert one or more waypoints inside a path (anywhere between its starting and ending waypoint). You can also remove waypoints from the path. Or delete the whole path. Finally there are also commands allowing you to limit the path for one team only. Limit it for specific class. Alter the way bots can follow this path. These limiting factors are generally referred as path types. Please look up the appropriate commands in the list of valid commands below where you can find all the details.

Path type

Related console commands are: 'pathwpt setdirection <argument>' where argument can be one, two or patrol, 'pathwpt setteam <argument>' where argument can be red, blue or both, 'pathwpt setclass <argument>' where argument can be sniper, mgunner or all and 'pathwpt setmisc <argument>' where argument can be avoid_enemy, ignore_enemy or carry_item ... no quotes nor brackets

As I already said the term path type isn't correct because there really is nothing like a one type of a path. Every single path is defined by at least three factors. The first factor is the way the bots will follow this path (refered as a direction). Then there is a team restriction that works as a second factor. Weapon restriction is the third factor. The forth factor is optional. You can imagine it as hint for the bot. In some cases it's specified automatically based on the waypoints you add to the path (e.g. ammobox waypoint in a path will automatically set this factor). However there are also three options that you can set for this factor. It may look pretty difficult now, but it's actually quite simple. At the moment you start a new path the system automatically sets the three main factors to default values. Which creates a two-way path used by both teams and all classes. This is a default path. As you can see such path is pretty universal and doesn't create any limits. Every single bot will always be able to use this path. Okay but let's say you have just created a path leading from inside red spawn area. You don't want blue bots to use this path to visit red team spawn area. All you need to do is change the team factor to red team only by using 'pathwpt setteam red' command. That's all. No blue bot will ever be able to use such path. It wasn't that difficult was it? If you want to prevent also red bots from returning back inside their spawn area. You just change this path to one-way path using 'pathwpt setdirection one' command. Now red team bots will be able to use this path only to get out of their spawn zone, because one-way limiting factor doesn't allow the bots to use the path from its end point to its beginning. As you can see the whole magic in paths is to choose the right limiting factor for them ... if there is a need for it of course. It really is as simple as that. Let's see the details.

Just a reminder. Every path you start is by default a 'two-way', 'both teams' and 'all classes' path.

Triggers

Related console commands are: 'wpt triggerevent add', 'wpt triggerevent delete', 'wpt triggerevent setpriority', 'wpt triggerevent settrigger', 'wpt triggerevent removetrigger', 'wpt triggerevent info' and 'wpt triggerevent showall'

Last major addition to the whole Marine Bot waypointing system were the triggers. The simplest description is that they are a dynamic priorities on waypoints. The word dynamic means that they react on actual game events. They have been added to the system to allow bots play maps such as obj_bocage. So a map where there are big changes in the gameplay as a result of progress of either of the teams. If we stay on obj_bocage at the moment one of the guns was disabled the whole area is completely pointless. You don't need to visit it anymore. But there is no way to tell this to bots by using just the standard priority setting. They would keep visiting all the places no matter what happened. And that is stupid. I had to find a way to change that. Thankfully Firearms mod does send these short text messages to all players to inform them what has just happened. That's it. We can use these messages to change priorities on certain waypoints. That's exactly what the triggers do.

There are 8 slots for the game messages. You don't need to rewrite the whole message but you must use unique part of the message. Also you must write it exactly the way it is written in the game. Because everytime the game sends one of these messages the triggers do check them and look for a match with the message that is stored in each of the 8 slots. If they match then appropriate trigger is fired and priority is changed on all linked waypoints. You may have already guessed that the only waypoint type that can be linked is the 'trigger' waypoint. I'll use an example from obj_bocage to explain the whole thing.

First thing you should do is to capture all the messages. And find out the unique part of each message. Look at this picture showing you one of the messages that is being send short after the moment you've destroyed the yard gun.
example of game message on a obj map

Now that you know the unique part of each of the messages. You need to store them to the trigger slots. Use ' wpt triggerevent add trigger1 "yard gun" ' command to store the message 'yard gun' in a slot number one. The slots are named and they use specific names trigger1, trigger2, .... trigger8. You will use these names pretty often, because they create the link between game messages and your waypoints. You also need to store the other messages in the other slots. Each message has its own slot. So for the next message you'd have to use ' wpt triggerevent add trigger2 "warehouse gun" ' command. The double quotes are neccessary there. That's the way Half-Life works with text strings. Follow the same logic and store all messages. When you are done. You can check you've done everyting right by using ' wpt triggerevent showall ' command. This is what you should see.
all trigger messages

When you have filled all the slots with messages you can start changing standard waypoints to the 'trigger' type. There's no limit on how many waypoints can be linked to each trigger slot. It's only up to you to figure out which junctions you want to modify to use dynamic priority setting. Here's example of the most obvious junction that needs the dynamic priority. It's the entrance to the yard gun. The red arrow points to a waypoint that will get the bots there. I've already changed it to 'trigger' waypoint. It's also the waypoint that will be used for the rest of this description.
junction with trigger waypoints

I'll assume you've already went through the whole map and changed certain waypoints to the 'trigger' ones. I'll say it again. There's no limit how many waypoints will be the 'trigger' waypoints. It really depends only on you. You can change all waypoints on all junctions if you wish. Now we will finally link the messages with these waypoints and set the second priority values. These second priority values will be used after the linked message has been displayed. In our case after the yard gun has been destroyed. First we will set the other priorities using 'wpt triggerevent setpriority 0' command. This command works the same as standard 'wpt setpriority' command. It uses two arguments. You can specify different values for each team. But in our case we want all bots to ignore this waypoint after the gun has been destroyed. So I've set zero priority for both teams. Please consult the list of all valid commands below if you don't understand the way this command works. The last step is to create the link. Use 'wpt triggerevent settrigger trigger1 on' command while you're standing near your 'trigger' waypoint. In our case the one marked by the red arrow. By this command you basically told the bot "you must use standard priority setting till the moment the yard gun is destroyed and then you must use the second priority setting". That's all. You can always check any 'trigger' waypoint by using 'wpt triggerevent info' command. It will show you the second priority setting as well as the trigger name that is linked to this waypoint (i.e. which message will fire this waypoint). You may want to bind this command to a free key on your keyboard in order to make your checking a bit easier. Anyway you would have seen this if you used it on the 'trigger' waypoint from our example.
triggerevent info

Next picture shows what you would have seen if you used standard 'wpt info' on the waypoint from our example. Just to show you the difference between those two commands. As you can see you aren't able to find out what all can this waypoint do if you don't use the proper command.
standard waypoint info

If you aren't sure what all is available to you then feel free to check the console help. As you can see on the following picture the triggers have pretty detailed section there. Telling you that you can even delete unwanted message slot. If you look closely the help also says that you are able to set even 'off' event to your 'trigger' waypoint. We have covered only the 'on' event in our example. There is no other option on obj_bocage. But the 'off' event allows you to use different message (different trigger name) to switch the 'trigger' waypoint back to standard priority setting. That allows you to use triggers almost everywhere. So they can be used also on tc_ maps. Say that you set the slot named 'trigger1' to "red team captured the hill" and slot named 'trigger2' to "blue team captured the hill" ... such messages must exist on the map of course. Now you can set trigger 'on' event to 'trigger1' and the 'off' event to 'trigger2' on several 'trigger' waypoints leading to the hill. And vice versa (trigger2 as on and trigger1 as off) on few other 'trigger' waypoints. Which will then open or close paths based on which team is holding the hill.
triggerevent console help

Waypointing corner

Now when we explained the basics let's move on to a few specific issues you may encounter while you are working on your waypoints. One of the most common things you will have to do is getting the bots around corners. It doesn't matter whether it is a corner of a building or corner of a huge container in a warehouse or corner on a junction of two hallways. You should always place one waypoint at the corner in order to make the bots pass through there smoothly without hitting the corner or getting stuck there. Following sketch shows the right way as well as the wrong way.
sketch showing how you should waypoint a corner

Ammobox waypointing

There are many cases when you don't want to have the ammobox waypoint on the main paths. You don't want the bots to slow down and use the ammo box everytime they are passing through that area. Solution in such case is to place a cross waypoint near the ammo box. Add one or more standard waypoint between the cross waypoint and the ammobox waypoint. Finally build a short path on these waypoints. Leave the priority on default level on the path leading to ammo box and keep higher priorities on the main route waypoints. Having it done this way makes things work pretty well. As I said right at the beginning the paths inform bots about certain things. And path with an ammobox waypoint will tell the bot 'use me if you need ammo'. So now only the bots that really need the ammunition will turn to the ammo box and refill their reserves. All the other bots will follow the priority setting and will move forward. Look at the picture showing an example of a short ammobox only path.
ammobox waypointing

Working with the parachute waypoint

You may also get in situation that one of the teams has to parachute on the map. Typically their spawn zone is on board of airplane or helicopter and they have to jump down. Therefore we have the parachute waypoint. As I say in its description this waypoint isn't meant to be used on the parachutes but works as a check gate. It will only open to the bots that have parachute. The bots that have no parachute will not be able to pass through this waypoint. They will have to return back to the beginning of the path. And find a way to get the parachute. So you will usually need just one parachute waypoint. You have to place it near the end of the ramp but you must give the bot enough space he can still turn back in case he doesn't have parachute yet. This also means parachute waypoints should be used on two-way paths. You'll prevent bots from trying to use this path to get back inside the airplane or helicopter by setting zero priority on the end waypoint there on ground. Look at the sketch showing you the best way of waypointing such spawn zone.
sketch showing how you should work with parachute waypoint

Sniper spot inside spawn zone

You may want to create some sort of protection on maps where the spawns are easily accessible. You would have to use a cross waypoint right inside the spawn area to create two separated zones. One will be for common bots who will simply leave the spawn area. And the other zone will be for the snipers who will then be defending the whole spawn area.

Let's start with adding few standard waypoint there. Try to cover most of the respawn spots. Next you should place a cross waypoint with relatively small range. Purpose is to connect only 3 standard waypoints not all waypoints inside spawn area. You then use two of these three waypoints to make the bots leave this area. I mean you'll start a path on them and build it so that they can leave.

Now you should find one or two spots for the snipers. Ideally behind some cover (e.g. window, small wall or sandbag). Place a 'sniper' waypoint there. Set some 'wait' time and add 'aim' waypoint in a direction the bot needs to watch. Next we need to start a short path on the last of the 3 standard waypoints that are connected to the cross waypoint. This path will get the bots to the sniper spot. So you need to build it that way. When the path is ready we will change it to a sniper only path. You are probably still standing next to the sniper waypoint so make sure you've added a goback tag on it. You can use 'wpt change goback' command or use the menu if you wish. Either way the waypoint will change its appearance. Having it done this way you basically told the bot that this is a dead end. There's no way forward there. Now the bot knows he needs to return back to the beginning of this path once he stops guarding it. Now you have to repeat it for all your sniper spots. Start all the sniper paths on the same waypoint you used before. This way bot will guard only once and then he will leave the spawn area. You should already know that bot doesn't use the same waypoint again so he won't see the other sniper paths when he returns back to the cross waypoint. If you prefer that the bot was guarding there almost all the time. You'd have to add fourth waypoint to the cross waypoint and start the other sniper path on it. The sniper bot will then almost all the time choose waypoint with the sniper path and he will almost always defend one or the other sniper spot.

There's an example of such spawn protection on the following picture. Notice that I left the other sniper position untouched. This way you can really see the short sniper path. If there was even the other path things wouldn't be clear.
sniper spot inside spawn zone

And this picture shows changing any path to a path for snipers by using the menu.
using marine bot menu to make a sniper only path

Before you start with your waypoints

Many years ago when Marine Bot was in active development. One of the members from the former team once wrote a note to waypointing section of our forum boards. He suggested there that people should draw a sketch before they actually start working on waypoints. I fully support that because it's a really good idea. Especially if you are new to Marine Bot waypointing. You should really draw some sort of a sketch before you jump to the game and start to place waypoints all around. It doesn't have to be anything big. Hand drawn sketch on a piece of paper would work just fine. The point is to plan the general waypoint layout. Where you should build all junctions. Where will you create the main paths. You may even add couple notes about important spots so that you don't forget to add them once you start working. Things like "here is a narrow passage I should place a claymore waypoint there" or "here's a danger of death fall I will have to add avoid_enemy tag to all those paths" and so on. You may also mark important priority setting. Something like this ...
sketch of a map overview with couple notes

One of the ways how to waypoint a map

As I said in previous section you should start with the basic map layout. That means you should cover the basic navigation first. You can improve and/or extend it later on. Here's a simple step by step manual. This is not the only way how you can build waypoints for maps, but following these steps keeps things easy. Also you won't create many mistakes so the bots will then move quite well.

As I said this isn't the only way how you can waypoint a map, but it allows you to fix the problems on the fly, extend the waypoints in waves and mainly release the waypoints. Because the bots will be able to play the map once you've done all the main paths. As you continue improving the waypoints the bots will only become clever and they start to play the map better. I hope I didn't scare you too much. Good luck!

Most common errors or bugs (i.e. things you should NOT do)

Okay the following series of pictures show common errors or fatal bugs that the people do when they waypoint a map. Most of the pictures come from former Marine Bot forums (the hidden development team only section). As you can see I sometimes drew a hint as a part of feedback. Some errors are easy to spot if you would run through the map. Many of them would have been caught if the waypoint creator spent more time testing the waypoints. However some errors are basically a general misunderstanding. The waypoints did work, but they just didn't feel right. Anyways let's see what we have here.

Let me remind you a few facts. The white horizontal lines do represent waypoint range. It's the space around the waypoint the bots will use to move/camp or do any other action on this waypoint. The most important thing about ranges is that they shouldn't intersect (or collide with) the game objects like the crates on this picture. This will cause that the bot will get stuck there most of the time. However you can use 'check_ranges' (without the quotes) command to turn the range highlighting on. So that you can always tweak the range to fit the local area. In our case you'll have to reduce the range on this waypoint in order to prevent bots getting stuck here. Moving the waypoint further away from the crates would be even better.
awful waypoint range

This is another example of bad range. This time on a cross waypoint. You can see there are 4 other waypoints that are inside the cross waypoint range. So the bot can choose between these 4 waypoints if he enters the cross waypoint from the same direction as you can see on the picture. By default the bot will never choose the same waypoint on which he entered the junction. In other words the bot will never do a 'U' turn at cross waypoint. He'll do it only if you force him ... using the priority setting or building the paths in a way he can't use them. That isn't the case here. That's the reason why I said the bot has only 4 options although you can see 5 cyan lines going from the cross waypoint. By the way 'check_cross' command will turn this feature on. Also notice the waypoint that's on the broken wall. This waypoint is completely useless. First problem is that we don't want that waypoint be connected to this cross waypoint, because there already is one waypoint connected in that direction (path). This is the reason why I mark this as a bad range. Second problem is that once you start using the path system (which I strongly recommend) you don't need to keep direct visibility between two following waypoints. It is the path that will tell the bot what is his next waypoint and where is located. So in this case the bot would know he has to jump over the broken wall.
bad cross waypoint range

This path has no meaning. First issue is the bot can't reach the window camp spot. And then this path doesn't even have a proper ending. If path doesn't end at junction then there has to be a waypoint that tells the bot to turn and follow the path in opposite direction. There are 3 waypoints that can do that. An ammobox waypoint and use waypoint are the first two waypoints that when they are used at the end of a path will make the bot turn and return the same way that he got to his present location. After getting the ammunition or pushing the button on wall of course. And the 3rd type is the goback waypoint. This waypoint will always turn the bot back no matter if the path ends there or not. Anyways the solution to this situation would be following common sense. You should add waypoint with tags goback and sniper in front of the window. Set some wait time on it. Then add an aim waypoint or two there. Finally make the path end on that new waypoint. By the way what you see on this picture is called path ending in a void. It's a pretty common bug.
bad path end

Following 3 pictures will show us another paths ending in a void ... much like the one on previous picture. The paths would have been okay if they were actually connected to the whole net. This kind of a bug happens when the waypoint creator tries to do everything at once instead of going in waves.
path ending in a void
another path ending in a void
yet another path ending in a void

Making the bots use a ladder is a tricky task. The most common error is if you connect the ladder directly to a cross waypoint. The bot then has little time and space to align himself right. You should always try to help the bot face the ladder when he is still approaching it. Therefore I recommend having a standard waypoint with a small range setting as an entry point. Let's see a few examples.
bad ladder waypointing
yet another ladder problem
ladder setup before

Following picture shows the change that has been marked on previous picture. Notice the range setting. Using values like 10 or 15 will force the bot to slow down and align himself before touching the ladder.
ladder setup after

Last ladder example. We aren't at cross waypoint this time, but we should still help the bot. There is enough space there so adding an additional waypoint isn't a problem. You wouldn't even have to delete the whole path. There is 'pathwpt insert' command that will help with cases like this. Please check the documentation for more info.
final ladder example

What I tried to show on previous pictures holds true even when it comes to buttons. The bot is able to locate and face a button at use waypoint, but if you have the space then place the waypoints so the bot is already facing the button while he's still moving towards it. I guess that the following sketch is clear enough. The yellow dot is a standard waypoint. The red dot represents the 'use' waypoints and the purple line is a path.
button sketch

If you look at the next picture everything seems to be alright.
just 2 ordinary paths

The same location, but now I used path highlighting feature to reveal the nasty bug. We have already seen it. Basically a path ending in a void. The only difference here is that the maker of these waypoints thought he can merge two paths. That's forbidden though. This bug is officially called an 'invalid path merge'. Just to remind you a known fact. A path can only end at a junction (a cross waypoint) or there has to be a turn back marker you know the 'ammobox' or 'use' or 'goback' waypoint.
invalid path merge

Next picture shows just the same. Another example of 'invalid path merge'. The path on the left side is okay. The path on the right side isn't. A bot following it will behave strange here due to this error in waypoints. I mean the bot may suddenly turn around and return back north. The reason is simple. When the bot gets stuck because of faulty path he has to throw path navigation away and forget all waypoints and paths. The present ones as well as all previous else he would be stuck there for ever. The bot will then search for the nearest waypoint so it'll be the one he just reached. Next thing the bot has to do is a try to find a path on such waypoint. He has two options in our case. So he will choose one randomly. Now if the path is a two-way path the bot has to figure out if he is closer to the end of the path or to its beginning. Once he knows it he starts moving towards the other end of the path in order to get away from the problem spot. We can see the path ends here so the bot will most probably return back to north from where he just arrived.
another invalid path merge bug

Here we have 3 more examples of this bug. Unlike the previous two cases here you can clearly see it thanks to the team based paths. A fix for this bug is very simple. There is a command 'pathwpt continue'. You use it to finish the faulty path at the next junction (cross waypoint).
invalid path merge bug is visible at first sight
yet another flashy invalid path merge bug the last invalid path merge bug that hits the eyes

The following serie of pictures will show you some crazy things that people sometimes prepare to our bots. I think these two pictures are clear enough.
the more cross waypoints the better ... or not? one cross waypoint can handle it just fine

Two cross waypoints placed this close makes things just too complicated. You have to work with too many priority and range settings and waypoints in general. In the end you only slow things down as the more junctions you create the more computing is needed when the bots play the map. As you could see above just one cross waypoint can handle the whole area as well. You can start more than one path on a single waypoint. The bot will see them all and will pick the one that matches his needs best. For example a sniper bot will choose the 'snipers only' path instead of standard path. He won't do it all the time as we need a bit of randomness in bots' behavior, but most of the time the bot will follow this logic. So you should build the waypoints as simple as possible. When you are checking your waypoints and you find some places being like those you can see on these pictures then you should rebuild them. It will pay off.
cross mania
cross mania continues even on the other side of the bridge
if one cross waypoint isn't enough

This last one is just a pure madness. This is a red team spawn area. It's even covered by the protection system. So what you should do here is make the bots leave this area as fast as possible. Yet we see that the waypoint creator built a true maze here.
cross mania? nah cross madness

Previous pictures showed us excessive use of cross waypoint. The same thing happens with other waypoints as well. The waypointer is trying to plan bots' movement step by step. Well sometimes you need to do it, but there are many cases where you should leave the bot some more space. I mean if there isn't a real need to limit the bot then leave relatively big gaps between the waypoints. See the following pictures.
several useless waypoints

It may have looked like a bad cross waypoint range at first sight, but we should do something else here. We actually make the cross waypoint range even bigger. Then we erase all the waypoints that form the inner circle around the cross waypoint. Finally we set correct priorities and ranges on the waypoints that used to form the outer circle around the cross waypoint. We just gave the bots more space to move through this area. The bots will now move much like a human because they will move straight towards the exit instead of heading to the center of the room, then doing almost 90 degree turn and finally heading to the exit.
we've cut all useless waypoints

Speaking of useless waypoints. Let's see a few examples of waypoints that serve no purpose. This path is short and straight. So this waypoint cannot change anything. It's a useless waypoint. There's no point having it there.
serves no purpose so it's a useless waypoints

It's a narrow corridor so you cannot change range setting in order to make the bot move less predictably. The bot will follow the same route even without the waypoint. Therefore there is no purpose having an additional waypoint there.
useless waypoints

List of all valid waypoint commands (use them without brackets)

While in game you can always use 'help' or '?' (without quotes) commands in console to access Marine Bot help. Where you can find simplified version of this list.

Other useful commands that help you when you are testing your waypoints.

by Frank McNeil 2005-2019


end of file