Marine Bot Waypointing Manual
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. It's much like the electric christmas tree lights (fairy lights). The bulbs are waypoints. The wires are paths that allow electric power to visit bulbs one after another and light them up. So in Marine Bot navigation system 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. Whenever is the bot running low on ammunition he will be looking for such path. And if 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 paths. As a sort of a hint telling the bot that this path will lead him to location where to he must deliver map goal object for example a briefcase.
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.
You can't set this value directly. Everytime you use the command to add a new waypoint to the map the waypoint is added to your current position. Basically the waypoint gets your position. 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 can move any waypoint to a new place if you wish to. So at the moment you move to desired place and type in the command the waypoint gets its new position from you.
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.
Before we move to next chapter let me explain one thing. The term 'type' isn't much accurate. There are only five of these that can be used as single type. The first two are 'aim' and 'cross'. Those two are special signals so not true waypoints. Therefore you can't even add them to any path. Then it is only 'normal', 'crouch' and 'prone' waypoints that can be used as single type. All other types will always be used in combination with at least one other type. If for example you add 'ammobox' waypoint next to the ammobox in game using 'wpt add ammobox' command or via the menu. Then such waypoint will automatically become a 'ammobox' + 'normal' waypoint. If you change your mind and decide that the bots should take cover while using this ammobox and you change this waypoint to a crouch using 'wpt change crouch' command or via menu. Then such waypoint will become 'ammobox' + 'crouch' waypoint. 'Normal' will be removed and 'crouch' will be added instead of it. Therefore a term 'tag' is better word to describe these. Because it really is more like a heap of identification tags that you simply put on the waypoint. Or remove from it if you aren't happy with them. Internally on the code level the variable that holds this information is named 'flags'. The plural is meant there. As I said in previous sentences, in many cases there will be more of them on one specific waypoint.
The whole system is done so that it automatically fixes invalid combinations. If for example you created a sniper spot somewhere and the final waypoint was 'sniper' + 'goback' + 'crouch' and you noticed that the bot is just too visible there and it would have been better if the bot went prone there. Then all you need to do is get yourself close to that waypoint and change it to 'prone' waypoint using 'wpt change prone' command or via menu. The system will then just remove 'crouch' tag and replace it with 'prone' tag, because you can't be crouched and prone at the same time. If after that you would have used the same command (i.e. wpt change prone) again. Then the system would remove the 'prone' tag and would have to replace it with standard 'normal' tag, because there always has to be tag telling the bot in what stance he needs to be. So the waypoint would then look like this 'sniper' + 'goback' + 'normal'.
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. Then the priority setting is also being used on a few special waypoint types such as goback, shoot, aim etc. Where for example you can set priority to zero to disable them for specific team.
Waypoint priority values:
This picture shows an example of priority layout around 'cross' waypoint - 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'.
Let's say the bot comes from the south. Imagine this is his 'respawn zone' exit. 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.
Now if the bot comes from the north. No matter whether he is coming from the right or the left. The situation would be almost the same (see the percentage values below). 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.
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.
If you want to know the exact data on priority based decision making then here are the percentage values for each priority level:
To help you understand the priority based decision making you need to know that the bot ignores the waypoint that he used to enter the 'cross' waypoint with. This is basic rule that's applied by default. Next rule is that the bot will always look up the highest priority level on all remaining waypoints around this 'cross' waypoint. There can be multiple waypoints with such priority level. That doesn't matter though. The bot only needs to know what is the highest priority level (for his team) on the remaining waypoints. Once that is known he can finally use the matching percentage value from the list above. Remember this mechanism and you won't have any problems figuring out the correct priorities on any junction that you will build.
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.
Look at the following picture where you can see example of waypoint with different wait times for each team. Actually the picture shows the whole set up. The wait-timed waypoint and also three aim waypoints that are linked to it. If you don't know how does 'aim' waypoint work then please go back to the 'waypoint type' paragraph and read its description again. Red arrow points to the waypoint with wait time. The place where will the bot wait for the exact amount of seconds you've set through the 'wpt settime <time in seconds> <team>' command. Blue arrow points to one of the 3 aim waypoints. If you use more than one aim waypoint around any wait-timed waypoint the bot will divide the whole wait time in parts and will be switching between all aim waypoints. That way the bot will watch all directions you've set up for him. Notice also the thin pink beams connecting waypoint with wait time and all the aim waypoints around it. That is a result of 'check_aims' command. Which is a toggle command (show/hide) that allows you to easily check which aim waypoints are placed in correct distance and so are available for the bot. This feature is useful especially if you have more wait-timed waypoints close together. Each waypoint with wait time will automatically connect with any aim waypoint that is within 100 units radius. So using the 'check_aims' feature to view these connections you can prevent unwanted aim waypoint sharing. You simply move the aim waypoints outside the 100 units radius. The thin pink beam disapears and such aim waypoint is no longer available for the wait-timed waypoint.
On the next picture you can clearly see that the waypoint marked by the red arrow has different wait time for each team. Red bot will wait for 60 seconds and blue bot will wait only for 30 seconds on this waypoint. If you look closely you can also see that 'wpt info' for this waypoint returns that the bot will be laying on ground (the 'prone' tag) when waiting there. The 'sniper' tag means that the bot will not move towards enemy, but he will hold the position on this waypoint. Finally the 'goback' tag means that the bot will return back on the start of his path once the wait time is over. Basically this is pretty common usage of waypoint wait time ... to create a sniper/camper spot.
We will also look at one of aim waypoints a little. The one marked by the blue arrow. As you can see 'wpt info' for this aim waypoint shows that blue team has no priority value there. According to 'aim' waypoint description this means that any blue bot that is going to wait on the wait-timed waypoint will be using just the other two aim waypoints. Simply put blue bot will ignore the aim waypoint marked by the blue arrow. That makes sence, because that direction leads back to blue team respawn area. Thus there's no point to watch there, because members of the red team can't come from that direction. On the other hand red team priority is at its default level. So red bots will be using this aim waypoint to watch for the blue team coming from that direction.
There's one quite specific thing about waypoint time. The bot doesn't always use the exact value you have set on the waypoint, but modifies it based on his behaviour. Let me explain it. Each bot generates his own behaviour type based on the weapon he enters the game with. There are 3 basic types: attacker, defender and a standard behaviour. Bot with standard behaviour will always use the value you set on the waypoint. Bot attacker will always reduce the wait time so such bot will spend less time waiting and will move faster towards enemy. While bot defender will always extend the wait time so he will stay longer on every waypoint with wait time. This brings element of variety, because each game is little different then. However there are cases where you need specific wait time to make things work. Imagine a valve type button where you must keep using it for exact time to open some gate. Or there is this specific objective on obj_bocage where you must stay for exact period of time near each of the guns and the bridge to set the explosives. Therefore there is a tool in form of waypoint priority = 1 that deactivates bot behaviour and forces every bot to use the exact wait time you have set on the waypoint. So in case you want to force bots to use the wait time you have set on the waypoint then you must also set priority to 1 (highest) on such waypoint.
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.
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.
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.
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.
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 large 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.
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.
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 large 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.
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. You can see altered appearance of the path beam on this picture too. There's a path on the left side leading to a sniper spot behind the sandbags. 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.
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 waypoints 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.
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 into path (to path start, to its end or anywhere between its starting and ending waypoints). There's an option to split long path to two shorter ones. 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.
Using the term path type when speaking about Marine Bot paths isn't quite 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.
You may often get to a situation that you've already finished a path, but realized that it needs to lead to another area than where it ends now. Don't worry, you won't have to delete it and recreate it from scratch. There's a command 'pathwpt continue' which is meant exactly for cases like this. Just get yourself close to the waypoint where the path ends now and type that command into console. Or find 'Continue path' in Marine Bot menu. You'll hear typical 'ding' sound that confirms that the action was successful and that you are editing this path now. Then you can work the same way as if you have been creating a brand new path. So get close to new waypoints and use 'pathwpt add' command there. When you have reached desired end and you have all new waypoints on the path, finish it using the 'pathwpt stop' command. There's one thing you need to keep in mind. If the original path did end on 'goback' waypoint then you'd have to remove that tag from the waypoint in order to allow bots passing through and reaching the new end. Let's see following sketch showing such situation.
If you'd forget to do the 1st step then the bots would simply turn and return back to the beginning of this path at the moment when they have reached the middle waypoint ... the original path end. Because that's exactly what goback tag tells them. Please refer to 'Waypoint type (or tag or flag)' and read its description if you don't understand what have I just wrote.
There may be cases when you'd want to add just one waypoint to existing path. In most of the times it would be into the path ... to the middle of it or even right to the beginning of such path. Adding waypoint to path end is easy task and we've already seen that in previous section. But the other parts of path need different approach. Therefore there is special command 'pathwpt insert <new_wpt_index> <path_index> <arg3> <arg4>' that allows you to insert one waypoint to any position on the path. To do so you need to know few things first. You need to know the unique number (aka index) of the waypoint you want to insert. That can be done using 'wpt info' command while standing next to such waypoint. Then you need to get unique number of the path. You will get close to one of its waypoints and type 'pathwpt info' command. Now the next steps depend on where exactly you want to insert the new waypoint. If it it right to the beginning of the path then you're ready. But if you need to insert the waypoint to the middle of the path then you would need to know indexes of two neighbouring waypoints from the path. Since the new waypoint will be inserted right between those two.
Let's start with the more complicated case. Insertion between two path waypoints. Next sketch shows the initial situation. You have a path and newly placed solitary waypoint nearby. Say that there is an ammobox there or perhaps there are bandages. Something you've missed when you have been creating the path before.
Following serie of sketches shows the exact steps you need to do to successfully insert this solitary waypoint into the path. You can of course swap steps number 3 and 4 to remove the double run between those two waypoints. But for the purpose of this example I made it this way ... to make it crystal-clear. Also you can swap their indexes in the final command. The result would be same whether you used 'pathwpt insert 12 8 31 32' or 'pathwpt insert 12 8 32 31'. The order of their indexes doesn't matter, but they must be neighbours on that path. If they weren't, you'd get an error and nothing would have been done.
Next I'll show you the way to insert new waypoint to the beginning of an existing path. You'll again need to know the index of such waypoint as well as the index of the path. While getting the path index you should also check that this path really starts here. If you haven't seen what does 'pathwpt info' command show, look at the next picture. There you can clearly see several things you usually need to know about one or another path. I've merged two pictures to show you both outputs. Path index is highlighted in red color. The index of waypoint where does this example path start is highlighted in yellow color.
Okay let's see new example. This example shows typical scenario where you have bad layout for the cross waypoint on the left side of the picture. The bots are getting stuck there so you've already added new waypoint, changed cross waypoint range and now you want to transfer the beginning of the path onto the new waypoint. I'll use some data from previous picture. So the path unique number (aka index) is 1. It's a five waypoints long path so its length is = 5 and it starts on waypoint number 2.
I'll assume you already know how to get all necessary data. So I'll jump right to the new stuff. If you want to insert waypoint directly to the beginning of the path then you won't be looking for specific path waypoints to set the exact insertion point. There is special keyword instead. So the command then looks like this 'pathwpt insert <new_wpt_index> <path_index> <start>'. The system will read the last argument and will automatically insert the new waypoint to the beginning of path that you've specified in 'path_index' argument. Look at the sketches to see how will that work in our example.
You need to be careful though. If you don't check the situation properly you can create nasty bugs quite easily. Solution to such bug would be removing the waypoint from the path using 'pathwpt remove' command while you're standing next to the waypoint you've just inserted into this path. Then checking the situation again ... thoroughly this time :). And then reworking the path using the right commands for that case.
Now that you've finally noticed the problem, you will only need to use different keyword. You aren't working with the beginning of the path. You are working with its end point. So the keyword is 'end' now. And the whole command looks like this 'pathwpt insert <new_wpt_index> <path_index> <end>'. The system will again check the keyword first and insert the new waypoint to the end of the path this time. This option basically replicates what would have been done if you used commands 'pathwpt continue', 'pathwpt add' and 'pathwpt stop'. The difference is you do that all in one step. So for simple addition of just one waypoint this is probably the better option. However it's up to you which option you'd choose.
As you could have seen on previous sketches you need to learn to always check the situation first. The whole system is done so that most of the bugs can be repaired quite easily. Like I wrote above bug scenario sketches. You'd use just one command to return back to previous state of things. But it's always better to double check the whole situation before doing changes. There's a simple rule, don't rush things. You will never be able to remember how you've built the waypoints. But you should remember that you should always check things first. You'll save yourself lots of time and troubles.
Until now we have been building paths ... adding new waypoints to them. This chapter will show you something little different. We are going to split one path in two. Say that you have a long path leading through a passage and a side way that you haven't waypointed yet. You obviously need to create a new junction there to connect the side way to the whole network. So you will have to split the original path first. You have two options. Depending on the situation you can use either the 'pathwpt split' command or directly change one of path waypoints to a cross waypoint using standard 'wpt change cross' command. I'll show you both of course, because both utilize path splitting feature. But before we move on the examples I'll tell you few facts about splitting any path. First rule is that you can split only path with at least five waypoints. Shorter paths cannot be splitted. And rule number two is that first two waypoints on a path and last two waypoints on the path are excluded from splitting. Reason for both rules is fact that the shortest possible path that is considered a valid path is a path that has two waypoints. The splitting is done so that the waypoint that you picked as the splitting point will be the new end point of the original path. And all other waypoints after that one till the original end of the path will form a new path with new unique number (i.e. new index). This new index is printed into console as a confirmation of successful splitting. Since that moment both paths are completely independent. They are two separate paths. You'll work with each of them the same way as with any other path.
For the purpose of example I've used the shortest possible path that can be splitted. Typical usage would be on longer paths. But I want to show you even the cases when things won't work so five waypoints long path is ideal for that. Also I'm not going to show the steps after the splitting itself, because they have no meaning for this explanation. The first two sketches show how will the splitting look like if the path was built from cross waypoint on the left side. The splitting is pretty simple action. You just position yourself close to the waypoint where you want to end the original path and type 'pathwpt split' into console. The only thing you'll see is that the path beam that was connecting this waypoint with the next waypoint on the path will disappear. You'll also hear typical 'ding' sound and if you open the console, you'll see the index of the new path.
Next two sketches show basically the same. This time the path was built from the cross waypoint on the right side. So even if you are doing the splitting on the exactly same spot (on the same waypoint number 4) the result looks different now. That's due to the fact that the original path had opposite direction of creation. The waypoint you are using to split the path will always stay on that path. So what is left from the original path is on the right side of the picture and the new path is on the left side. While in previous case it is vice versa. I'm showing you this only to remind you that it is important to know where the path you are working on starts.
These two sketches will show you a case when the 'pathwpt split' command failed. It returned error telling you that you can't split the path at that place. And nothing was done with the path of course. Reason why the error occured is rule no. 2. First two or last two waypoints on any path that is long enough, cannot be used for splitting. If I generalize it then there always must be at least two other waypoints on each side of the waypoint you're standing next to. That's not the case here. We have three other waypoints on the left side ... waypoints number 2, 3 and 4. That'd be okay. But on the right side there is just one waypoint ... waypoint number 6. You can't create a valid path on one waypoint, because valid path must have at least two waypoints. In our example you would get this error on any waypoint except for the waypoint number 4 that we used in both previous cases. If you say that it would be possible to create valid path there if the path started on waypoint number 6, because waypoint number 5 would stay on the original path, so that path would have 2 waypoints thus it would be valid. Yes you are right. That would be possible, but there still is one rule that in combination with the other option how path splitting feature is used prevents that. I'll explain it later. As for now you have to accept the fact that no matter where this path starts the only possible place to split it is waypoint number 4.
We're getting to the second option how you can split a path in two parts. We're going to use automatic path splitting as a result of 'wpt change cross' command used on waypoint that already is on this path. Marine Bot waypointing system has many parts including monitoring routines and self-repair routines. Basically the system keeps checking your actions and in some cases it automatically runs fixing routine to prevent serious bugs. One of the cases is if you change waypoint. I've already mentioned it in this guide. Some combinations are considered as serious bug. For example you can't have 'normal' and 'crouch' tags together on one waypoint. That's the case when the system will act and will automatically remove one tag if you're trying to add the other one and vice versa. Exactly same case is if you change waypoint that is on any path to a cross waypoint. The system will check for possibilities to fix that situation right away. It tries to follow common logic. Which means if you are changing any waypoint to a cross waypoint then you most probably want to create a new junction there. So if the path is long enough and the waypoint is far enough from either path end it will split the path and remove this waypoint from the original path. And that's exactly what we can use in our favor. This allows you to do two steps in one go. You have the original path splitted in two and you already have even the cross waypoint at place ... a waypoint that allows you to connect everything to the whole path network.
Last two sketches will show you what happens if you changed waypoint that is too close to one of the path ends. The system will again check for possibilities to repair the serious problem. However path splitting isn't available this time due to reasons I already mentioned before. I promised there I'll explain the problem with splitting the path near its start or end point. This case is exactly the reason why it cannot be done. The system needs to be able to remove one waypoint from the original path. If the path was left with just two waypoints where one of them was a cross waypoint, then the system would create invalid path at the moment of removing this cross waypoint. The system is meant to fix or at least report bugs, not create them :). Back to our example. When the system cannot use path splitting feature the only solution to repair the bug is removing the cross waypoint from the path. The path becomes a four waypoint long path. Waypoints number 2, 3, 4 and 6 create this path. Waypoint number 5 is now a solitary waypoint, but because this waypoint is a cross waypoint now then everything is okay. Truth is that such placement is pretty stupid. But you can't predict every action the user does. The system can only prevent serious bugs. It can't stop people from doing other actions.
Let me show you how you can revert the changes made by splitting the path in parts. In case you've done it in error. I'll use the situation when you did it via 'wpt change cross'. Reverting 'pathwpt split' command is he same. You will only skip the step where you are changing the waypoint back to the normal waypoint.
What we did on last sketch is something you should not do under normal circumstances. It's fatal bug. Sadly it's a common error people do. Therefore I added special code that can repair it. In Marine Bot version 0.94b this code has been updated to be able to check and fix almost all variations of this bug. It's a part of bigger group of self-fixing routines that are available through 'wpt repair' command. As always there are more options there. I'm going to show you one that can be called controlled self-repair. What I mean is that you'll use this command with an argument to point right to a spot you want to get repaired. The command looks like this 'wpt repair <pathmerge> <path_index> where the path index is the unique number of a path you want to let repair. Usually it's the path that you want to keep. Since the other path will be erased in the end. The repair process is such that waypoints from the other path are appended one by one to the end of path you used in the argument. Which leads to invalidating the other path. And invalid paths are being automatically erased. This is basically the opposite process to what is done when the system is splitting the path. If you used the command without the path_index argument then the self-fixing routine would be used in fully automatic mode. The system would then check all paths for the 'invalid merge of paths' bug. Your path would be repaired too, but depending on situation the other path could be used as the main one. Which in our case would mean path no. 11 was erased and replaced by the other path from right side. Here that would be no problem. But in your waypoints you may lose the tags on that path and the bots would then play the map different ... or they won't even be able to pass through such area. So be careful if you let the system take the control.
To summarize it, path splitting feature is designed to be used on long paths. So that you don't have to delete such paths and recreate them any time you need to create a side route. Which means you should have no problems with waypoints near one or the other end of the path. All these examples are there only to show you how can one or the other feature be used and I also try to point out possible problems. Basically to let you know what is available. Whether you decide to use such feature or you avoid it is up to you.
One of the cool things about paths is the fact that you can have multiple paths going over one waypoint. Or in other words one specific waypoint can be part of several paths. So you have quite a big freedom in a way how you can build your paths. The only rule is that you can't add specific waypoint more than once into one path. That would create a loop error. You don't need to worry about it, because the waypointing system is built so that this can't happen. Everytime you finish your path the system does check for this and repairs it if needed be.
So what does this feature mean to you? For example if there is a narrow passage somewhere on the map (trenches, ladders, doorways, etc.) you don't need to add new waypoints there for every path you want to lead through there. You simply use the existing waypoints everytime you are building another path leading through such spot.
The place where this feature is used most often is without a doubt cross waypoint. Well not on the cross waypoint itself, because that one cannot be added to any path, but on waypoints around it. First because Marine Bot does majority of his decisions here. Second it's the place where paths tend to start or end. Since one of their main purposes is to get bot from one junction to another. Knowing these two facts you may have thought that you'd need to add many waypoints around the cross waypoint to be able to begin or end all the paths there. That would have been quite impractical though. And this is where the option to have several paths on one waypoint becomes really useful. There's no limit on how many paths can you start on one waypoints. There's also no limit on how many paths can you stop on the very same waypoint. But the bot will use only a few paths for his final decision. Don't worry. You won't have any problems with that. Because the bot does filter out all unusable paths first. That means all paths that does not match his team will never be taken into his decision. Like if they were not even there. The same is true even for one-way paths that end there. So in the end the bot will really be left with only a few paths to choose from ... even if you created quite a lot of them around this cross waypoint.
Let's see couple sketches to make things clear. This first sketch shows multiple default two-way paths going from/to several directions and a simple 'cross' waypoint junction that connects all these paths. As you can see there are just two waypoints that are connected to this 'cross' waypoint. All 5 paths are default two-way paths. So speaking only about bot navigation it doesn't matter if they start here or end here. Them all are accessible for all boths. Also the priority on both waypoints that are connected to the 'cross' waypoint can be left on it's default setting which is 5. The end result only deppends on from where the bot came. The blue bot who followed path number 1 and so he arrived from north will only choose from 3 paths. Those are paths number 3, 4 and 5. If you wonder why he can't choose path number 2 then the answer is because that path is on the waypoint that he used to enter this junction with. And by default such waypoints are excluded from the decision making. Reason is that we want the bot to move forward. The waypoint the bot is standing at when he started deciding would generally have returned him back to a place where did he just come from. There is one exception, but more about it later. In our case the blue bot will randomly choose between paths number 3, 4 and 5. While red bot who arrived from the south can only choose from two paths and those are paths number 1 and 2. Reason why he can't choose from more is the same as in blue bot case.
Let's see how is the example situation going to change if we'd turned path number 5 into a class restricted path. Say it's a 'sniper only' path now. There's no change at all for the red bot. He will still be able to choose from paths number 1 and 2 only. But the situation for blue bot is different now. There are 3 possible cases. Case a) If the blue bot isn't a sniper he can now choose only between paths number 3 and 4. Such bot doesn't match class restriction on this path so it's like if the path number 5 wasn't there. Case b) There's one exception to this though. Bots automatically generate a behaviour type when they join the game. And there's a 'camper hunter' behaviour which allows the bot to enter a 'snipers only' or 'machinegunners only' paths. Such bot will ignore any wait-time on any waypoint on class specific path. He'll only scout such path and seek for enemy snipers (or gunners in case of 'machinegunner' path) to eliminate them. So if the blue bot was 'camper hunter' he would see even the path number 5 and would be able to choose from all 3 paths again like on the first sketch. Finally case c) If the blue bot was a sniper. He would then almost always pick just the path number 5. There's a small chance blue sniper would ignore sniper path and would randomly choose between paths 3 and 4 only. But they tend to prefer paths that match their class since these paths are specifically meant for them and should get them to a good sniper spot.
Following sketch shows another small modification to our example junction. Now there's a new waypoint added and we have moved the 'snipers only' path on it. With that change we also need to set approriate priorities on all waypoints connected to the 'cross' waypoint. You can see them in team specific colors next to all 3 waypoints. The 'sniper only' path has pretty low priority due to the fact that sniper bots will almost always priorise this path over the other options they have. The way that is designed there makes the situation perfectly equal for both teams. Which means that what was true for blue team on previous sketch holds true even here and even for red bots. The only small difference is that 'camper hunter' bots will visit the 'sniper only' path less often. That's because of its low priority. To make the chance equal as it was before you would have to set priority to 2 for the waypoint with 'sniper only' path.
Now let's return back to original junction and see how will the situation look like if we change some paths into one-way paths. For example path number 1 which the blue bot used to move to this junction is one-way path. Also path number 3 is one-way path that allows traveling only towards this junction, but not away. Both these changes bring quite big limits for both teams. Blue bots can now choose between paths 4 and 5, because as we said the path number 3 is built as inbound one-way only and no bot is ever able to travel through one-way path in the opposite direction. Red bots can only pick path number 2, because path number 1 is also built as inbound one-way path thus unavailable for them now.
I promised I will explain the exception I mentioned in description of the original situation. I said there that the bot is always trying to move forward which is the reason why the waypoint the bot used to enter the junction is excluded from the decision making process. That holds true as long as he is able to find at least one forward direction. But if he fails then he reverts to checking his current waypoint and tries to find different path than his current one. This then often leads to doing turn around and travelling back towards previously visited positions. If you look at the next sketch you can clearly see that all previously available options are now unavailable, because paths number 3, 4 and 5 are now inbound one-way paths. There's no way to move forward. So the blue bot has to check what other options are there on his current waypoint. There are two paths there. His current path number 1 is inbound one-way path thus unavailable for traveling away from here. Then there is path number 2 which is two-way path and so the only available option left that allows leaving this 'cross' waypoint. The bot will pick that path and simply turn around moving away. If you happen to see such junction somewhere in the middle of the map then that is most probably a bug ... or at least not a preferred way of building junctions. However it's pretty clever solution for team respawn area with some sort of protection that would have killed bots of the opposing team.
The final sketch shows a case that you should avoid at all cost. As you can see all the paths are inbound one-way paths. Which means it doesn't matter if the bot came from north or from south he won't be able to leave. Because even after he resets his recent navigation he won't still be able to find any way away. All those paths will return him back to that 'cross' waypoint over and over again. One-way paths are great tool to prevent bots from returning to already visited positions like trying to jump back on the roof or up the cliff. But you must be careful with them. You can create a true trap that will catch bots one by one quite easily. You simply forget to build a path leading away from there and bots won't be able to leave such spot. The same thing is possible with team specific paths as well. You forget to build exit for one team and that team will be stuck there forever.
From all these examples you can see that the bot does filter out really big amount of paths before he does a final decision. So you are free to use quite a lot of paths around one 'cross' waypoint. And because some of these paths may share more than just the first or last waypoint there was added special client command that allows you to check all paths that are present on any waypoint. One of its possible use is done in a way that you can bind it to a free key on your keyboard for easier use. The command is 'pathwpt printall nearby'. Everytime you want to check any waypoint on presence of multiple paths you just use this command while standing next to such waypoint. And a simple list of all paths that are present there will be printed into console.
For those of you who need exact data. Currently there's a limit of 8 waypoints that the bot will choose from when he reaches the cross waypoint. Like I said in above paragraphs the bot will filter out all unavailable first. So in reality you can have more than just 8 waypoints connected to specific cross waypoint. Then there's again limit of 8 paths on a specific waypoit that the bot can include into his decision. He will again filter out unusable paths first. If you need to check how does the bot work with it then there's a toggle command 'debug_cross' that will print details into console at the moment the bot reached cross waypoint. If you combine it with standard 'developer 1' command, you'll get even more details from the routines that control the decision making.
To give you some real world example the following picture shows a pretty complex junction on tc_basrah map. It's the 'Town Center' Territory Control point where the bots are tasked to guard it against the opposing team. There are used both team paths mostly, because both teams can reach this point from multiple directions. So the bots must watch them all. When I was updating these waypoints for MB0.94b release I've added a few team specific paths needed to give the bots an option to move directly to the other TC points. And also to improve blue team defence abilities. There were also added paths into both side houses where the bots can refill ammunition when they are running low on it. So this junction is closing to its full capacity now. As you can see there are actually 10 waypoints connected to this cross waypoint. However due to priority setting combined with the use of various path types both teams can see all possible waypoints. On top of that they can also see all the paths that are on some of the waypoints, because only half of the waypoints on this picture hold just one path. The other half has more than one path. Best thing about this junction is fact that there can still be added more paths to more camping spots, but when there are more bots in the game this place gets pretty crowded so there's no point to make the situation even worse. However if the street was wider and there was more free space then Marine Bot waypointing system would still be able to handle it. Anyway to describe this junction a bit. The waypoints with paths leading to camping spots that are facing directly the opposing team have priority set to 1 (i.e. highest). The waypoints with paths leading to camping spots covering the backs have priority setting at level 2. The one waypoint with paths to the the side houses has priority set to 5, because if the bot is in need of ammunition then this need will temporary override the priority based decision making and the bot will always pick this waypoint. If the bot has enough ammo then we don't want to allow him to leave this area. Finally the 4 waypoints (2 per team) with paths leading directly to the other two TC points have priority set to low level too, because we don't want the bots to leave this area often. These waypoints will be picked only when the bot decides to completely ignore priority based decision making and will do a random pick. Then there's a small chance that he will choose one of these waypoints and will leave this area then.
I've mentioned that you can check how does the bot decide on cross waypoints so that you can tweak the setting to fit the specific needs of that area. On the following picture you can see how was a red team bot deciding while guarding the 'Town Center' Territory Control point that I've shown on previous picture. The decisions made around this cross waypoint are marked with red rectangle. The output above and below it is from the other cross waypoints neighbouring this one. The first line inside the red rectangle clearly shows that red team bots are at maximum limit of waypoints on this cross waypoint (i.e. "Number of found wpts is 8"). If there was more waypoints available for the red team around this cross waypoint then the red bots would ignore them. At least at the moment when they were entering this cross waypoint for the first time. After then when they were moving between specific camping spots they would be able to add one more waypoint to the decision making. The reason why the bot can see only 7 waypoints instead of 8 like when he entered this junction for the first time has already been mentioned above. Just to remind it. The bot always ignores the waypoint he used to enter the junction with. This is the default behaviour and is applied as long as he is able to find any other waypoint at the junction. Feel free to scroll a few paragraphs up and read it again. You can see that on the console output. The waypoint index the bot has picked out at one moment, isn't present on the next list of available waypoints, because the bot is entering the junction with this waypoint then. Anyway the red bot was stricly following the orders and was moving from one camping spot to the other till a moment when he chose not to follow priority based decision. He picked the next waypoint randomly and by a chance it was a waypoint designed to allow the bots exit this area. So the red bot left this area after only a few guarding tasks.
Next picture shows that the blue team bots would be able to handle one more waypoint added to this junction. The last position on the console output is empty for them (i.e. #0|5). Anyway as you can see the blue bot decided to follow highest priority setting most of the time, because there are used only two waypoints with blue priority=1 around this cross waypoint. While the red team has three waypoints with priority set to 1 around this cross waypoint. Once in a while this blue bot decided to ignore just the highest priority and was choosing between waypoints with priority set to level 2 for blue team. So he was covering the backs then. And if you look closely you'll notice that the bot has done also a few subsequent decisions about paths, because there's this additional 'blue team only' path on one of the waypoints. This path actually breaks the overall design a bit. The waypoints with priority set to level 1 should get the bots to camping spots that are directly facing the opposing team, but based on the game tests where the blue team was being slaughtered from backs a lot, I've added this extra path with higher priority to balance this area. Finally this blue bot also had a moment when he decided to ignore priority based decision, but his random pick kept him on the guarding duty this time. So based on from which camping spot he was moving he kept picking out the next camping spot designed for blue team and unlike the red bot on previous picture this bot continued in guarding the area.
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.
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.
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.
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.
Next picture shows what you would have seen if you used standard 'wpt info more' 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.
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.
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.
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.
Getting the bots to climb a ladder can sometimes be pretty tricky task. Every ladder is little different. There are cases where you can use just the standard waypoints with a small range and the bot will climb the ladder just fine. Then there are cases where the bot is getting stuck on the ladder a lot. I'm going to show you such example on tc_basrah map. The blue team has a series of two ladders as one of the exit route from their base area. The bot was usually able to climb the first ladder without problems, but the second ladder has been a tough deal for him. He was often stuck on the ledge on the left side and because of the way how is this map build he was trying to snipe through skybox. His head was in a position out of the map so he was able to see enemies, but the weapon was still inside the map so he was hitting the wall behind the ladder. And if another bot reached this spot too then them both were stuck there for very long time of even forever. The solution isn't all that hard though. I've changed the waypoints that lead to the ladder to a 'crouch' waypoints with a very small range (10 units). Which makes the bot move slow and precise. This allows him use the minimum space that is there to face the ladder correctly. I've also changed both 'ladder' waypoints to 'crouch' waypoints. Now they have tags 'ladder' + 'crouch' instead of 'ladder' + 'normal'. Reason for this is fact that the waypoints leading to the ladder are 'crouch' one too. So the bot won't change his stance just before he touches the ladder itself and won't make him stick to the ladder in strange position. And finally I moved the top 'ladder' waypoint slightly to the right so the bot cannot get stuck on the ledge on the left side. Next picture shows the situation after those changes.
Next thing you should always try to do is moving the bottom 'ladder' waypoint slightly above the ground level. I mean that you should enter on the ladder and move on it a little up then finally place the 'ladder' waypoint. The bot is always facing his next waypoint. So when the waypoint is above the bot then he will aim up. That's exactly what you need to do when you want to climb the ladder up. Let's look at the following picture to see how it should look. It's a side view of the same spot we have seen before.
Now let's move onto the top part of the ladder. The situation here isn't much easier than how it was at the bottom. Still the same narrow area with very little space to maneuver. On top of that the bot must exit the ladder to the side which is much worse scenario than if the bot could move straight forward to exit it. However it is still doable and not that hard. As I've said before the 'ladder' waypoint is also a 'crouch' waypoint. This helps with the fact that there isn't free space above the ladder. Also the exit maneuver will be smoother that way. If there was enough free space we wouldn't need the 'crouch' tag, but that isn't our case. Therefore we also must change the next waypoint to a 'crouch' one too. And set very small range on it, because the ledge is really small. This is basically the same thing as we have done at the bottom. It will force the bot to make slow and precise movement. If you look at the next picture you'll see that we are using the same mechanism with the waypoint position as we have used at the bottom. The 'ladder' waypoint isn't on the same level as the next waypoint. This will again work in our favour. Once the bot reaches this 'ladder' waypoint he will turn to the side in order to face the next waypoint. But because the next waypoint is above current bot position he will keep aiming upwards which is exactly what he must to do to be able to continue climbing the ladder. Finally the combined effect of facing to the side and aiming upwards will allow him to exit the ladder smoothly. He will then reach the next waypoint still in a crouched stance where he will target the next waypoint. As you can see that waypoint is a 'normal' waypoint so the bot will finally stand up and leave this whole area.
Let me show you one more ladder on tc_basrah. I'm showing it just to make it clear that you don't always need to use the 'crouch' tag to get the bots climb the ladders. On the following picture you can see entrance to City Sewers. It's the entry point on the blue team side. The waypoint that leads to the ladder has again a small range setting to force the bot to slow down and proceed carefully. Reason why this waypoint is a bit to the side is that we must ensure that the bot will enter on the ladder at the top point. If the path to the ladder was straight then after the bot had slow down before entering the ladder he may not be able to touch the ladder at the top point, but he may fall down through the hole. He would then enter on the ladder at the bottom and climb it up to reach the top 'ladder' waypoint, because the navigation routine forces him to do it. Then he would look down and go down the ladder again to reach the bottom 'ladder' waypoint and then exit it. Not only that this would look stupid, but if there was another bot then them both would get stuck there.
This picture shows the bottom of this ladder. We are again using the standard mechanism where the 'ladder' waypoint is on different level than the next waypoint. The next waypoint is below the 'ladder' waypoint and quite far away from it. So once the bot reaches this 'ladder' waypoint he will turn to side to face the next waypoint, but he'll keep aiming down, because he's above that waypoint. Which will allow him to exit the ladder successfully. This layout works well because the path is only one-way. If we wanted to make the bots move through this spot in opposite direction (i.e. to leave the sewers) we would have to use another one-way path and add new waypoint. Because the way how is this area build wouldn't allow using two-way path to waypoint this ladder. The bots would be getting stuck here a lot on a two-way path, because this is simply too narrow area to give the bot enough space to align himself right.
To wrap this up. You've seen two places where the ladder was causing problems, but using available tools we've managed to make the bots pass through them with ease. Most of the ladders will allow you use the default two-way both teams path. However even there you should place the 'ladder' waypoint on a different level than the entry/exit waypoint to make the bots pass through without any problem. Also do NOT add another waypoint between those two 'ladder' waypoints. There should be just one 'ladder' waypoint at the bottom and one 'ladder' waypoint at the top. Nothing else. Finally do NOT change the range setting on 'ladder' waypoints. The bot works with 'ladder' waypoint in a different way than with other waypoints. He will always slow down and will always head towards to the 'ladder' waypoint directly.
The pushpoint (a.k.a. flag) waypoint type was specifically designed to improve bots behaviour on Territorial push maps like ps_crash for example. Every map with prefix ps_ usually has at least 3 push points (also known as check points or flags). Each push point is a special zone that reacts on every player who enters into it and causes specific game event. The 'pushpoint' waypoint is designed to detect such events inside these zones and hand them over to all paths that include this waypoint. The paths then transmit these data so the bots can see the real-time situation. The 'pushpoint' works on similar basis like the system of 'Triggers' (above). But because territorial push is standardized feature in Firearms mod, the 'pushpoint' waypoint is much easier for the waypointers. All you have to do is that you place this waypoint inside the area where you can activate (capture) the specific check point. And use a path to connect this waypoint to the whole network.
Look at the picture of first push point for the red team (or the last one for the blues if you want) on ps_upham map. I've erased couple waypoints and paths from the official waypoints to show you only the important things on this spot. The way that it has been done here will cause that once the red team captured this push point the red bots will start to ignore it and they will move towards the other two push points on this map. If you would have used just standard priority setting to waypoint this area then red bots would have to follow it every time they were passing through this cross waypoint. Which means they would have to visit the push point every time even if it was already under their control. Important thing is to use high/higher priorities on waypoints on the main routes and keep the priority low on the waypoint on the path leading to the push point area. The navigation is done so, that bots that decide to reach map goals will ignore standard priority setting and will always visit push points that aren't yet under control of their team.
Next picture shows 'wpt info' for the 'pushpoint' waypoint. You can see all the tags on this waypoint. The 'flag' is the most important tag here. That's the pushpoint marker that does all the magic there. Without it everything would revert to standard priority based navigation. As you already know the 'goback' tag tells the bot to turn around and use the same path back to its start to leave this area. It must be used here, because the path ends on this waypoint. If there was a reason to continue the path beyond this waypoint then 'goback' tag would have not been there of course.
The last picture shows console output for a command that lists all paths on nearby waypoint. This command also prints all tags each path currently holds. I've used it on the waypoint at the start of the path leading to the push point area. As you can see on the line above the red rectangle our path holds the standard tags - 'both teams', 'two-way' and 'all classes'. Which means this is a default path. However the optional forth factor (titled 'misc' in the console output) holds 3 other tags - 'RedGoal', 'BlueGoal' and 'AvoidEnemy'. We have already explained the 'AvoidEnemy' tag in chapter named 'Path type'. The 'RedGoal' and 'BlueGoal' tags are two tags that are set automatically by the waypointing system. And they are dynamic tags. The bots that decide to reach map goals do look for these tags. Let me explain it. The 'pushpoint' waypoint that lies inside the push zone keeps checking the zone ownership. If the zone belongs to neither team (at the start of the map or after map restart) the 'pushpoint' waypoint assigns 'RedGoal' & 'BlueGoal' to all paths that lead through this waypoint. Now each red bot who decided to reach map goals and entered this cross waypoint will look for 'RedGoal' tag and will see it there, because this push zone isn't held by any team yet. Such bot will ignore standard priority setting and will select the path leading into the push zone to accomplish his mission. Once he does that the 'pushpoint' waypoint will detect the change in zone ownership and will stop assigning 'RedGoal' to all its paths. It will continue assigning just the 'BlueGoal' to all its paths. So now each red bot who will enter this cross waypoint won't be able to find the 'RedGoal' tag anymore and will have to use the standard priority setting. Thus he will stay on the main route and will head towards the other push points. That is exactly what you can see on the picture. The first call of 'pathwpt printall nearby' shows the situation before I captured this push point. Then the red rectangle shows the moment when I did that. And finally the second 'pathwpt printall nearby' call shows that the path lost the 'RedGoal' tag and it will not attract red bots attention.
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.
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.
And this picture shows changing any path to a path for snipers by using the menu.
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 ...
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!
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.
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.
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. Next you need to 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 generally called path ending in a void. However all the checking & fixing routines that are part of Marine Bot waypointing system report this as 'invalid path end'. Anyway this is a pretty common bug.
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.
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.
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.
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.
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.
If you look at the next picture everything seems to be alright.
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 merge of paths'. 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.
Next picture shows just the same. Another example of 'invalid merge of paths'. 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.
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).
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.
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.
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.
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.
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.
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.
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.
Honestly I'm not fan of auto waypointing. That's the reason why its description is almost at the end of this guide. I'll always prefer precise manually created waypoints over the auto waypointed ones. However I do understand that if you want to play some custom map that doesn't have any waypoints then you would probably not want to spend hours or even days creating proper waypoints. You would just want to jump in the game and have some fun killing bots. Well then there's auto waypointing feature to help you with that.
There are four commands for auto waypointing. Most of the time you'll need just one command. And that is 'autowpt start' which is a toggle command. It'll start auto waypointing if it is turned off. And if the auto waypointing is active it will stop it. So it's an ideal command for binding to a free key on your keyboard. Next command 'autowpt distance' allows you set exact distance in units between any two waypoints. Currently its default value is 200 units which is good value for most cases so you don't need to change it. If you happen to run into problems somewhere (eg. inside buildings) you can lower this value and the waypoints will be placed closer together. But keep in mind that the distance really means between any two waypoints. So not only waypoints you are currently placing, but also any waypoints you already have around you. That means that if you move too close to already placed waypoints there won't be added any new waypoint. Last two commands are 'autowpt on' and 'autowpt off'. You probably know what do they do. First one will turn the auto waypointing on ... will activate it. Second one will turn it off ... deactivate it. If you don't like toggle command then you have the option to use these two instead of 'autowpt start'.
Now I'll show you how does the auto waypointing work. There are two ways. One is going is small steps. Second is doing a long run from one end of the map to the other and then splitting the whole path into pieces where needed be. Let's start with the first case. We will be doing short paths. You position yourself to a place where you want to start ... usually the respawn area of your team. Use the command 'autowpt start' and start moving forward. Auto waypointing feature will be adding waypoints as you go and it will also build a path. Once you reach a place on which you want to split the path into multiple directions, you stop and use command 'wpt add cross' (or use the menu: waypoint menu -> placing -> cross). The system will deactivate the auto waypointing, finish the path and place the 'cross' waypoint on your position. You move a little away from it, use the 'autowpt start' command again and continue moving towards next area. Repeat this untill you reach respawn zone of the opposing team. You don't need to worry about any range setting on 'cross' waypoint. The system will repair it itself. If you aren't happy with the way how you're building the path then stop auto waypointing. Then go back and use 'wpt delete' command to erase all waypoints till the place that you like. Once you are done with that. Get yourself to the last waypoint and start auto waypointing again. You will create a bug called invalid merge of paths, but the system will fix it next time you deactivate (stop) auto waypointing. It's done so that every time you deactivate the auto waypointing feature the system checks for most common errors and tries to fix them as best as possible. If you see there's a gap somewhere then stop auto waypointing. Go there, get yourself close to the waypoint where the gap starts and start auto waypointing. You need to touch that waypoint to hear the typical 'ding' sound. Then go to the other end, touch the other waypoint same way as you did before (to hear the 'ding' sound confirmation) and stop auto waypointing there. The system sees that there are two invalid merge of paths and repairs them. Then you can return to your previous work. You will most probably create another bug 'invalid merge of paths' in order to resume your work, but the system will fix it later on. Following series of pictures will show you what has just been described here ... repairing a gap.
Let's look in the console again. The first 3 lines say that there were two separate paths with a gap between them. Just what you can see on first picture. Then I started auto waypointing as what does the 2nd picture show. And because there already was a waypoint there the system only started a new path ... 3rd path in our case ... that's the console output just above red rectangle. What is inside the rectangle is exactly what has happened when I stopped auto waypointing. The system checked waypoints, found 2 bugs ... two invalid merge of paths and repaired them. This isn't normally shown in console, you can see a 'developer 1' console output there. Finally the last 3 lines show the result ... one long path without any gap. Basically I just wanted to show what I was describing in previous paragraph.
Now the second case. The long run from one team zone to the other. You will basically do the same as what is written in the first case. Find the best place in your respawn, start the auto waypointing and go towards the respawn zone of the other team. The difference is that you won't stop on places where the route can split to different directions. You'll choose one route and continue on it untill you reach the respawn zone of the opposing team. Then you'll finally stop auto waypointing. If you are happy with the whole path, you'll follow it and whenever you feel like you would like to build a junction, you get close to the waypoint that you think has the best position for it, you'll change that waypoint to 'cross' waypoint. You can do it through client command 'wpt change cross' or via the menu: waypoint menu -> changing -> cross. The system will then split the whole path in two parts (two paths) exactly on that cross waypoint. This cross waypont will be removed from the path of course. You can then continue to another suitable spot for building a junction and simply repeat the same action. Just make sure you don't do this near any end of the original path since the system won't allow the split if the remaining paths are too short. That means there has to be at least 2 waypoints left on each side of the 'cross' waypoint. Once you are done with splitting the original path in parts, you should return to each new junction and start auto waypointing near the 'cross' waypoint. Now you'll follow the other (side) routes and you'll stop auto waypointing near another 'cross' waypoint. That way you will build the whole network. Let's look at a few pictures with these actions.
The last picture shows that now there are 4 separate paths instead of the original one path. You can also see that if you move around ammobox then auto waypointing will change the waypoint to ammobox right at the moment it places it. That is the short red waypoint in front of ammobox that I'm standing on. And this is basically the end of description of auto waypointing feature. Once you're done with your waypoints you should use 'wpt repair masterrepair' command. This command is meant to do several checks and repairs in exact order to fix converted old waypoints or waypoints created by auto waypointing. The last step you need to do is to save your waypoints typing 'wpt save' into console or if you prefer the menu then it is: service menu -> save wpts&paths. That's it. Now you should be able to play your custom map with Marine Bot.
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.
Note: You can use sniper and mgunner tags together. That means that one specific path can be sniper and mgunner path. It can hold both tags at the same time. So both snipers as well as machine gunners will be allowed to use this path.
Other useful commands that help you when you are testing your waypoints.
by Frank McNeil 2005-2020
end of file