A few words about the navigation system Marine Bot is using
First you need to know that Marine Bot waypointing system is using waypoints and paths. Both are important parts of the whole system. Parts that communicate together and support each other. The waypoints are pretty self-explanatory issue. Basically the waypoints themselves are just points in 3d space. The bot has no eyes. So the waypoints tell him this is walkable space not a solid wall. Some specific waypoint type does tell him there is a ammobox here. Other specific waypoint type tells him there is more than one route here please choose one. And so on. As I said the waypoints are just lone points in the space. They will not tell the bot where does he need to go. They will not tell him where is next waypoint. I'll say it once more, because this is important information. Every single waypoint is just a lone point in the space. Nothing more.
And this is the reason why there are the paths. They allow you to connect the waypoints together. The paths link those separated points in the space together and form routes the bots can then follow. The path will always tell the bot where does he need to go to reach the next waypoint. The path doesn't inform the bot only about the next waypoint. It can tell him what will he be able to do there several waypoints ahead, because paths do take information from some of their waypoints and transmit them to bots. Let me explain it. I already said there is a specific waypoint type telling the bot there is a ammobox there. So if such waypoint is in a path then the whole path transfers this information. Now if the bot is running low on ammunition he will be looking for such path. And whenever he has the chance he will choose a path like that as a path he will follow. You can also put more general information into certain paths. As a sort of a hint telling the bot that this path will lead him to the location where he has to deliver the map object item for example a briefcase. Okay let's move to details.
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.
Related console commands are: 'wpt add' and 'wpt move'
You can't set this value directly. Everytime you use the command to add a new waypoint in the map the waypoint is added at your actual position. Basically the waypoint takes it from you. The same holds true even when you want to change waypoints' position. Yes there is a command that will allow you to reposition existing waypoint. You move it to a new place if you wish. Yet again at the moment you use this command the waypoint just takes the position from you.
Waypoint type (or tag or flag)
Related console commands are: 'wpt add <argument>' and 'wpt change <argument>' where argument is the type of the waypoint ... no quotes nor brackets
There's quite a variety of different waypoint types. You may have already seen the list of waypoint types in the 'support' section of Marine Bot web. Or you may have already seen them in the game. Let's go through them again. This time we will try to explain them in details.
- AimThe bot will turn and aim at this waypoint. This waypoint must be within 100 units range of the waypoint that you want the bot to aim from. Also such waypoint must have a 'wait' time on it. You can have up to four 'aim' waypoints associated with a specific timed waypoint. You can use 0 priority setting on any 'aim' waypoint to tell the bot that this aim waypoint isn't for this team and the rest priorities are taken as a mark that this waypoint is usable for that team. Useful when you want to set up a camping spot. You can also use 'aim' waypoint together with the 'claymore' waypoint on sd_ maps to tell the bot which direction he needs to lay the claymore mine in order to destroy the map object (e.g. some crates). Aim waypoint cannot be added to any path.
- AmmoboxIt tells the bot there's an ammobox close. If this waypoint is at the end of a path it automatically works as a turn back marker.
- ClaymoreIf the bot is carrying a claymore mine he may place it at this location. However he can also save the claymore mine for later use. If this waypoint priority is set to 1 the bot will always place it and will blow the mine manually. This is useful for destroying goal objects like the trucks on sdtc_balcome for example. Otherwise the bot will set the claymore mine to trip mode which means that the mine is left at this location and the bot continues on his way. If this waypoint priority is = 0 then the bots from that team will ignore this waypoint.
- CrossThis waypoint serves as a 'crossroad' marker. It is a critical waypoint to control bot movement. When the bots reach 'cross' waypoint they will then chose between the next waypoints to move to. The decision is usually based on waypoint priority, but bots' actual needs (e.g. a need of ammunition) also play a role there. The bot does not ever target the cross waypoint. In other words the bot will never move towards the cross waypoint position. He will proceed directly from the incoming waypoint to the outgoing waypoint in a direct line. Cross waypoint cannot be added to any path.
- CrouchThe bot will crouch/duck at this waypoint. You must use at least two crouch waypoints in sequence to get the bot to move through an area while crouched.
- DoorThe bot will slow down to pass through doors that open automatically. In many cases you won't need to use this waypoint at all. But if the doors do open really slow or you see the bot is often getting stuck there you may want to use this waypoint.
- DuckjumpThe bot will jump and crouch at this waypoint. He will stay in crouch for a while after passing this waypoint to prevent getting stuck on the obstacle.
- GobackThis waypoint serves as a turn back marker. It tells the bot to return back to the beginning of his path. Useful on paths leading to camping spots. The last waypoint in such path must be 'goback' waypoint. If there is a case where you need to use this waypoint in the middle of a path (e.g. spawn zone protection system killing the players from the other team) then use priority '0' on this waypoint to make the bots from a specific team ignore this waypoint. Basically everytime you use priority = 0 on this waypoint then the specific team bots will ignore this waypoint type. They will treat it as a normal waypoint and they will pass through it. You can imagine it as a gate. Priority = 0 means the gate is open and you can pass through. All the other priorities mean the gate is closed, turn back.
- JumpThe bot will try to jump towards to next waypoint.
- LadderPlace this waypoint on a ladder. There should be one ladder waypoint at the bottom and one at the top of the ladder.
- NormalThe bot will just pass through. This is a default waypoint type.
- ParachuteThe bot will check if he has a parachute at the moment he reaches this waypoint. You can imagine this waypoint as a gate. If the bot has the parachute the gate will open and the bot can pass through this waypoint. If the bot doesn't have the parachute the gate will stay closed. The bot will then try to return to the beginning of his path. Where should be a route to a waypoint where the bot can pick up the parachute.
- ProneThe bot will either go prone at this waypoint. Or he will continue in prone stance. Or he will resume from prone. It all deppends on his previous stance. You need to always place at least two prone waypoints in sequence if you want the bot to move through an area prone.
- PushpointIt will allow the bot to ignore flags that are already under control of his team and he will be more interested in flags that aren't controled by his team yet. You need to place this waypoint inside the pushpoint/flag trigger area (i.e. where you can capture the flag).
- ShootThe bot will fire his weapon to break a breakable object (e.g. window or some other obstacle) or Firearms specific search and destroy object (e.g. the crates on sd_durandal). The bot is able to find the proper object in a distance up to 300 units around this waypoint and aim at it even if you don't use an aim waypoint. You'll have to set some 'wait' time to this waypoint otherwise the bot won't do anything. If you want to force the bot to fire at something that is not breakable "just for fun" you'll have to use the aim waypoint and you will also have to set priority = 1 for this waypoint otherwise the bot won't shoot. If there is a time tag on the waypoint the bot will keep shooting for that amount of time. As usual if the priority is set to 0 the bots from specific team will ignore this waypoint. That is useful to limit this waypoint to just one team.
- SniperThis tells the bot not to move when he goes into combat mode. The bot will not move toward the enemy and will stay by this waypoint. This is useful if you want the bot to hold his position behind a sandbag, in a window (i.e. in a sniper position).
- SprintThe bot will start or stop sprinting at this waypoint. There are two ways how you can use this waypoint. The first one is to place only a single sprint waypoint. The bot will sprint until he runs out of stamina. The second option is to place two sprint waypoints. The bot will start sprinting at the first one and stop sprinting at the second sprint waypoint. You can place one or more normal waypoints between those two sprint waypoints to allow the bot to turn corners or sprint around obstacles.
- TriggerThis waypoint will allow the bot to navigate to locations based on actual game situation. This waypoint is specially designed to handle object based maps like obj_bocage, obj_thanatos and such like. By using this waypoint you can open or close some routes based on the progress of either of the teams.
- UseThe bot will 'press' 'use' to activate something near this waypoint (e.g. a button). If you specify also 'wait' time the bot will keep using the object until the time is over. This is useful for valve type buttons. If you place this waypoint near mounted gun the bot try to use it. Don't forget to place also aim waypoint to tell the bot which direction he should aim the mounted gun. If you want that the bot uses the mounted gun all the time instead of only for certain time period don't specify any 'wait' time. The bot will then try to use the gun as long as possible.
- UsedoorThe bot will slow down and 'press' 'use' to open the door.
Related console commands are: 'wpt setpriority <number 0-5> <team>' and 'wpt triggerevent setpriority <number 0-5> <team>'
Waypoint priorities help the bots navigate through the map and will determine how the bots 'play' the map. While there are no team specific waypoints you can set waypoint priorities differently for each team. You can safely ignore waypoint priority on most of the waypoints you add to the map with the exception of two specific cases. Waypoint priorities are used by the bots when they reach a 'cross' waypoint. As we already said you can imagine it as sort of a junction. 'Cross' waypoints trigger the bots decision making. When they reach a 'cross' waypoint they will then choose the next waypoint based on waypoint priority. Using waypoint priorities you can force the bots to use certain routes more than others. And the other time where the priority plays a role is on a few special waypoint types such as goback, shoot, aim etc. Where you can set priority to zero to disable them for specific team.
This picture shows an example - yellow dots represent normal waypoints, blue dot is a cross waypoint and the numbers are priority levels for waypoints. Cross waypoint should have the default/lowest priority 5. It is only a signal for the bot to run the 'choice code'.
Let's say the bot comes from the south. It reaches the 'cross' waypoint and because the waypoint on the left has a higher priority than waypoint on the right the bot will decide to go to the left. He will do so most of the time. But there is also chance (small chance) that bot will ignore priority and decide to go to the right. This random behaviour has been done on purpose. We don't want the bot was easily predictable. The next picture shows exactly what was just described. The green dotted line shows how will the bot move through this junction. And you can also see there the exact moment when the bot is making his decision.
Now if the bot comes from the north. No matter whether he is coming from the right or the left. The situation would be the same. Most of the time the bot will choose the waypoint with the higher priority. If you look at the picture closely you may notice that the bot isn't going toward the cross waypoint at all. The green dotted line goes from the waypoint where the bot does his decision straight to the waypoint he just chose. This shows exactly what was said in the description of the cross waypoint. Feel free to scroll a few paragraphs back and read the description once more if you want.
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.
Related console commands are: 'wpt settime <number> <team>' where number is the time period in seconds
The next thing you can specify is waypoint time. The time (in seconds) that the bot will wait at his current waypoint. It can be used with almost all waypoint types. You can for example use a crouch waypoint behind a corner with a long delay to effectively get a bot to camp. Don't forget to place also one or more aim waypoints in the direction the bot should be watching. There are two time values on the waypoint. One for each team. That allows you to make the bots from one team to guard the waypoint while the bots from the other team won't even stop there. You can also force both teams to wait there and each team will have different wait time.
Related console commands are: 'wpt setrange <0-400>' and 'check_ranges'
You can imagine waypoint range like a circle around the waypoint. The bot will use this whole space to detect that he reached the waypoint. Actually the bot randomly picks one point from the whole range and he will go there. You will never see two bots that would be moving through waypoint range exactly the same way. The bigger the range is the more visible this behaviour is. This again helps to make the bot less predictable. However you should keep an eye on this value and make sure the waypoint range doesn't interfere with any obstacles. If it does then the bots may get stuck on any objects that lie inside the waypoint range. Any range under 20 units (19 and down) will cause the bot to slow down and proceed 'carefully' so that he doesn't miss the waypoint. This is a valuable tool for getting the bots through very narrow passages, or along dangerous routes like ledges, or the tops of walls. Use the 'check_ranges' command to give you a two line cross section that will show you how large your waypoint ranges are. Next to setting your waypoint priorities, setting your waypoint ranges are the most important factor in determining smooth, intelligent bot navigation. I would recommend that you set the waypoint ranges as you place the waypoints. Returning and resetting all the ranges on all your waypoints after you have placed them all can be a discouraging, time consuming procedure.
Let's see some examples. This is how does the range look like in the game after you used the 'check_ranges' command. Notice those thin white lines that are intersecting the waypoint beam in the middle. They are showing you the waypoint range.
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 big waypoint range. The bots will then move a lot like a real human does. And if there are obstacles on the way or you need to pass through a narrow passage you also need to reduce the waypoint range in order to prevent the bots getting stuck here and there.
Cross waypoint range
Related console commands are: 'wpt setrange <0-400>' and 'check_cross'
Similar to standard waypoint range is the cross waypoint range. The main difference is that the bots don't use this range as space for walking. They will never try to pick one specific point from inside the cross waypoint range like they do on standard waypoints. As we already said this waypoint works only as a marker to start the decision making where will the bot go next. Basically the cross waypoint range tells the bot which waypoints are available to choose from. Every waypoint that is inside the cross waypoint range is taken into the decision. The bot will then choose one of these waypoints in order to get to other parts of the map. Just like standard waypoint range even range on cross waypoints can be displayed. There is a command 'check_cross' that will show a connection between cross waypoint and any waypoint that is inside this cross waypoint range. In other words this command will show you all waypoints that the bot is going to use to make his desicion on this particular cross waypoint. Please look at this sketch which summarises previous description.
Previous sketch says that it doesn't matter where you position the cross waypoint. That is only partially true. If there is enough space around the cross waypoint and you have used quite big range then it really doesn't matter if you place the cross waypoint a few units here or there. However if you are working on a crowded area (e.g. stairway, narrow hallway or inside a building in general) then you will have to literally fine-tune not only its position, but also its range. There are two reasons. First you don't want to have some waypoints from this or that direction being disconnected. And second you should never connect more than one waypoint from one specific direction. Let me show you what I mean on another sketch.
Second part of Marine Bot navigation system are the paths. The basic meaning of a path is to get the bot from one location to another. It doesn't matter how far away the other location is because there is basically no maximum limit on path length. The path can be as long as you wish. Any path is build from waypoints. You can add any waypoint type to a path with the exception of a cross waypoint and an aim waypoint. Typical path creates a connection between two cross waypoints. In other words it gets the bots from one junction to another. Or from junction to important spot like a 'pushpoint' on push maps or any kind of object on obj_ maps or just to some sniper spot. Look at the next picture. The path is the purple horizontal line that runs through the 3 waypoints there in the middle. This is an example of typical path that created a connection between one cross waypoint on the left and another cross waypoint on the right side. The paths can have many colors and they can also alter the look a bit, but they will always look like a thick horizontal beams. Actually you can see that too. There's a path on the left side leading to a sniper spot. That path has a green color which tells you it's a class specific path. Only a bot with sniper rifle will be able to follow this path.
Adding a new path
Related console commands are: 'pathwpt start', 'pathwpt add' and 'pathwpt stop'
Use the 'pathwpt start' command while standing really close to the 1st waypoint (i.e. the waypoint where you want the path will start). Then move close to the 2nd waypoint and use the 'pathwpt add' command there. You've just created the shortest possible path. If you want to continue adding more waypoints you'll have to get close to each of them and use the 'pathwpt add' command there. Whenever you wish to end the path you can just type the 'pathwpt stop' command into the console. Make sure you have all waypoint in the path because 'pathwpt stop' command doesn't add anything. It will finalize the path. Finalizing the path is quite important step. If you didn't do it then the system would still take it so you want to keep working with this path. So any path changing command you would then use would be applied to this path. Actually you can use this feature in your favor. For example if you want to make that path for one team only. You can do so before you finalize the path. Anyway look at this sketch showing you the proccess of creating a new path in exact steps.
Working with existing paths
Related console commands are: 'pathwpt continue', 'pathwpt insert', 'pathwpt remove', 'pathwpt delete', 'pathwpt setdirection', 'pathwpt setteam', 'pathwpt setclass' and 'pathwpt setmisc'
Now when you already know how to create a new path and you may have already added several paths to your waypoints. You may want to know whether the paths can be changed in any way. Of course you can do it. It would have been insane if you couldn't edit them. There's a whole set of commands allowing you to alter any path you aren't happy with. You can continue adding new waypoints to the end of existing path. You can even insert one or more waypoints inside a path (anywhere between its starting and ending waypoint). You can also remove waypoints from the path. Or delete the whole path. Finally there are also commands allowing you to limit the path for one team only. Limit it for specific class. Alter the way bots can follow this path. These limiting factors are generally referred as path types. Please look up the appropriate commands in the list of valid commands below where you can find all the details.
Related console commands are: 'pathwpt setdirection <argument>' where argument can be one, two or patrol, 'pathwpt setteam <argument>' where argument can be red, blue or both, 'pathwpt setclass <argument>' where argument can be sniper, mgunner or all and 'pathwpt setmisc <argument>' where argument can be avoid_enemy, ignore_enemy or carry_item ... no quotes nor brackets
As I already said the term path type isn't correct because there really is nothing like a one type of a path. Every single path is defined by at least three factors. The first factor is the way the bots will follow this path (refered as a direction). Then there is a team restriction that works as a second factor. Weapon restriction is the third factor. The forth factor is optional. You can imagine it as hint for the bot. In some cases it's specified automatically based on the waypoints you add to the path (e.g. ammobox waypoint in a path will automatically set this factor). However there are also three options that you can set for this factor. It may look pretty difficult now, but it's actually quite simple. At the moment you start a new path the system automatically sets the three main factors to default values. Which creates a two-way path used by both teams and all classes. This is a default path. As you can see such path is pretty universal and doesn't create any limits. Every single bot will always be able to use this path. Okay but let's say you have just created a path leading from inside red spawn area. You don't want blue bots to use this path to visit red team spawn area. All you need to do is change the team factor to red team only by using 'pathwpt setteam red' command. That's all. No blue bot will ever be able to use such path. It wasn't that difficult was it? If you want to prevent also red bots from returning back inside their spawn area. You just change this path to one-way path using 'pathwpt setdirection one' command. Now red team bots will be able to use this path only to get out of their spawn zone, because one-way limiting factor doesn't allow the bots to use the path from its end point to its beginning. As you can see the whole magic in paths is to choose the right limiting factor for them ... if there is a need for it of course. It really is as simple as that. Let's see the details.
- One wayThe path will be one-way in the direction that it was created (start -> end). Often used on paths where there is a jump waypoint. Or paths leading from roofs back on ground are generally one-way paths. Make sure not to use a goback waypoint in one-way path. That's a fatal error.
- Two wayAlso called 'both way'. The bots can move along this path in either direction (start -> end) as well as (end -> start).
- Patrol pathA special type of path. It's basically two-way, but bot will not use it only once. The bot will stay on this path for a random period of time and repeat all the actions in the path (start -> end -> start -> end -> ...). Useful if you want a bot to patrol an important team goal or a strategically important area. However try to avoid using jump, ladder, shoot or claymore waypoint types on such path.
- Red team onlyOnly red team bots will use this path.
- Blue team onlyOnly blue team bots will use this path.
- Both teamsBots from both teams can use this path.
- Snipers onlyOnly bots with a sniper rifle will be able to follow this path.
- Machine gunners onlyOnly bots with machine-guns will use this path.
- All classesAll bots can use this path. No matter what weapon do they have.
- Avoid enemyThis is one of the optional hints. It will prevent bots from moving right towards the enemy. In case where the enemy is not in range of the weapon the bot is using he will ignore such enemy and will continue in standard navigation. Often used on paths in an area where is a danger of death fall. For example the river area on ps_river map. Or on roofs in general. Whenever you want the bot to hold his position.
- Ignore enemyThis is another of the optional hints. It tells the bots to ignore most enemies except those that are really close. Useful on paths that lead to the final map goal. For example the lighthouse on obj_sweden.
- Carry itemThis again works only as a hint that will tell the bot "follow me if you are carrying the goal item". However it doesn't prevent other bots from using this path too. Basically if bot is carrying the goal item he will look for these paths. If there are such paths. He will then ignore standard priority setting and choose just these paths. If you want to use this. Make sure you don't create a circle from such paths. You should mark only paths that will really get the bot to place to where the goal item has to be delivered.
Just a reminder. Every path you start is by default a 'two-way', 'both teams' and 'all classes' path.
Related console commands are: 'wpt triggerevent add', 'wpt triggerevent delete', 'wpt triggerevent setpriority', 'wpt triggerevent settrigger', 'wpt triggerevent removetrigger', 'wpt triggerevent info' and 'wpt triggerevent showall'
Last major addition to the whole Marine Bot waypointing system were the triggers. The simplest description is that they are a dynamic priorities on waypoints. The word dynamic means that they react on actual game events. They have been added to the system to allow bots play maps such as obj_bocage. So a map where there are big changes in the gameplay as a result of progress of either of the teams. If we stay on obj_bocage at the moment one of the guns was disabled the whole area is completely pointless. You don't need to visit it anymore. But there is no way to tell this to bots by using just the standard priority setting. They would keep visiting all the places no matter what happened. And that is stupid. I had to find a way to change that. Thankfully Firearms mod does send these short text messages to all players to inform them what has just happened. That's it. We can use these messages to change priorities on certain waypoints. That's exactly what the triggers do.
There are 8 slots for the game messages. You don't need to rewrite the whole message but you must use unique part of the message. Also you must write it exactly the way it is written in the game. Because everytime the game sends one of these messages the triggers do check them and look for a match with the message that is stored in each of the 8 slots. If they match then appropriate trigger is fired and priority is changed on all linked waypoints. You may have already guessed that the only waypoint type that can be linked is the 'trigger' waypoint. I'll use an example from obj_bocage to explain the whole thing.
First thing you should do is to capture all the messages. And find out the unique part of each message. Look at this picture showing you one of the messages that is being send short after the moment you've destroyed the yard gun.
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' 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.
Working with the parachute waypoint
You may also get in situation that one of the teams has to parachute on the map. Typically their spawn zone is on board of airplane or helicopter and they have to jump down. Therefore we have the parachute waypoint. As I say in its description this waypoint isn't meant to be used on the parachutes but works as a check gate. It will only open to the bots that have parachute. The bots that have no parachute will not be able to pass through this waypoint. They will have to return back to the beginning of the path. And find a way to get the parachute. So you will usually need just one parachute waypoint. You have to place it near the end of the ramp but you must give the bot enough space he can still turn back in case he doesn't have parachute yet. This also means parachute waypoints should be used on two-way paths. You'll prevent bots from trying to use this path to get back inside the airplane or helicopter by setting zero priority on the end waypoint there on ground. Look at the sketch showing you the best way of waypointing such spawn zone.
Sniper spot inside spawn zone
You may want to create some sort of protection on maps where the spawns are easily accessible. You would have to use a cross waypoint right inside the spawn area to create two separated zones. One will be for common bots who will simply leave the spawn area. And the other zone will be for the snipers who will then be defending the whole spawn area.
Let's start with adding few standard waypoint there. Try to cover most of the respawn spots. Next you should place a cross waypoint with relatively small range. Purpose is to connect only 3 standard waypoints not all waypoints inside spawn area. You then use two of these three waypoints to make the bots leave this area. I mean you'll start a path on them and build it so that they can leave.
Now you should find one or two spots for the snipers. Ideally behind some cover (e.g. window, small wall or sandbag). Place a 'sniper' waypoint there. Set some 'wait' time and add 'aim' waypoint in a direction the bot needs to watch. Next we need to start a short path on the last of the 3 standard waypoints that are connected to the cross waypoint. This path will get the bots to the sniper spot. So you need to build it that way. When the path is ready we will change it to a sniper only path. You are probably still standing next to the sniper waypoint so make sure you've added a goback tag on it. You can use 'wpt change goback' command or use the menu if you wish. Either way the waypoint will change its appearance. Having it done this way you basically told the bot that this is a dead end. There's no way forward there. Now the bot knows he needs to return back to the beginning of this path once he stops guarding it. Now you have to repeat it for all your sniper spots. Start all the sniper paths on the same waypoint you used before. This way bot will guard only once and then he will leave the spawn area. You should already know that bot doesn't use the same waypoint again so he won't see the other sniper paths when he returns back to the cross waypoint. If you prefer that the bot was guarding there almost all the time. You'd have to add fourth waypoint to the cross waypoint and start the other sniper path on it. The sniper bot will then almost all the time choose waypoint with the sniper path and he will almost always defend one or the other sniper spot.
There's an example of such spawn protection on the following picture. Notice that I left the other sniper position untouched. This way you can really see the short sniper path. If there was even the other path things wouldn't be clear.
And this picture shows changing any path to a path for snipers by using the menu.
Before you start with your waypoints
Many years ago when Marine Bot was in active development. One of the members from the former team once wrote a note to waypointing section of our forum boards. He suggested there that people should draw a sketch before they actually start working on waypoints. I fully support that because it's a really good idea. Especially if you are new to Marine Bot waypointing. You should really draw some sort of a sketch before you jump to the game and start to place waypoints all around. It doesn't have to be anything big. Hand drawn sketch on a piece of paper would work just fine. The point is to plan the general waypoint layout. Where you should build all junctions. Where will you create the main paths. You may even add couple notes about important spots so that you don't forget to add them once you start working. Things like "here is a narrow passage I should place a claymore waypoint there" or "here's a danger of death fall I will have to add avoid_enemy tag to all those paths" and so on. You may also mark important priority setting. Something like this ...
One of the ways how to waypoint a map
As I said in previous section you should start with the basic map layout. That means you should cover the basic navigation first. You can improve and/or extend it later on. Here's a simple step by step manual. This is not the only way how you can build waypoints for maps, but following these steps keeps things easy. Also you won't create many mistakes so the bots will then move quite well.
- First thing is to find the important spots where you should create a junction (i.e. to place there a cross waypoint). See this picture.
- Next you need to connect previously placed cross waypoints together. That involves using the default two-way paths. Now the bots will be able to get from one side of the map to the other. Something like this ...
- Now when the main paths are finished. We can tweak the range on the waypoints. If you didn't set the ranges as you were placing waypoints. Or if you have been moving with the waypoints when building the paths. You need to make sure the ranges are done in a way to make the bots use all available space. The bots will then move less predictably … more like a real human does. Don't overdo it though. Keep in mind the range on previous waypoint and the next one as well. And make sure there isn't any obstacle there (crate, wall, sandbag, tree, cliff or corner) that is blocking the way. See the following serie of pictures.
- Then you should set the priorities. I recommend doing all priorities for one team first and then doing the same for the other team. That way you won't miss any important junctions and the bots should always move toward enemy positions. Keep in mind what I said about the paths when I was explaining the ammobox waypoint. Rising the priority on a waypoint isn't always the only key. Working with path types can lead to way better result.
- Once you are done with the main paths you can start thinking of extending the waypoints. Adding a few camp spots and some class based paths (for snipers and machine gunners). Allowing the bots to move through the houses or getting on roof of the side buildings and so on. Basically you'll be building a complex path network.
- Now it's time to test your waypoints. First of all save them using the 'wpt save' command. Then turn off team balancing using the 'balanceteams off' command. Freeze the bot in order to check spawn area waypoint placement. Now you can recruit one bot to your team. Find him in the spawn area and unfreeze him using the 'mrfreeze' command again (it's a toggle between on and off). You should follow this bot and watch how does he move. Keep an eye on all weird things the bot may do. When you see something strange then freeze the bot and check the waypoints for errors. You may have forgotten something small like a range setting in a narrow passage or missing wait time on a sniper waypoint. Such things are easy to miss and the only way to find them is following the bot. Therefore you should repeat it several times for each team to be sure you've caught them all. Keep in mind to recruit and follow a sniper or machine gunner bot if you have such paths in your waypoints. Finally kick the single bot. Use 'observer' command to make bots ignore your presence. You should turn team balancing back on. Now you can recruit a few bots and watch them playing the map. Pay attention to both teams. How do they perform. Neither team should dominate the game. If both teams are winning and loosing the map at about same ratio you've made good waypoints. Congratulation!
As I said this isn't the only way how you can waypoint a map, but it allows you to fix the problems on the fly, extend the waypoints in waves and mainly release the waypoints. Because the bots will be able to play the map once you've done all the main paths. As you continue improving the waypoints the bots will only become clever and they start to play the map better. I hope I didn't scare you too much. Good luck!
Most common errors or bugs (i.e. things you should NOT do)
Okay the following series of pictures show common errors or fatal bugs that the people do when they waypoint a map. Most of the pictures come from former Marine Bot forums (the hidden development team only section). As you can see I sometimes drew a hint as a part of feedback. Some errors are easy to spot if you would run through the map. Many of them would have been caught if the waypoint creator spent more time testing the waypoints. However some errors are basically a general misunderstanding. The waypoints did work, but they just didn't feel right. Anyways let's see what we have here.
Let me remind you a few facts. The white horizontal lines do represent waypoint range. It's the space around the waypoint the bots will use to move/camp or do any other action on this waypoint. The most important thing about ranges is that they shouldn't intersect (or collide with) the game objects like the crates on this picture. This will cause that the bot will get stuck there most of the time. However you can use 'check_ranges' (without the quotes) command to turn the range highlighting on. So that you can always tweak the range to fit the local area. In our case you'll have to reduce the range on this waypoint in order to prevent bots getting stuck here. Moving the waypoint further away from the crates would be even better.
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. Set some wait time on it. Then add an aim waypoint or two there. Finally make the path end on that new waypoint. By the way what you see on this picture is called path ending in a void. It's a pretty common bug.
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 path merge'. Just to remind you a known fact. A path can only end at a junction (a cross waypoint) or there has to be a turn back marker … you know the 'ammobox' or 'use' or 'goback' waypoint.
Next picture shows just the same. Another example of 'invalid path merge'. The path on the left side is okay. The path on the right side isn't. A bot following it will behave strange here due to this error in waypoints. I mean the bot may suddenly turn around and return back north. The reason is simple. When the bot gets stuck because of faulty path he has to throw path navigation away and forget all waypoints and paths. The present ones as well as all previous else he would be stuck there for ever. The bot will then search for the nearest waypoint so it'll be the one he just reached. Next thing the bot has to do is a try to find a path on such waypoint. He has two options in our case. So he will choose one randomly. Now if the path is a two-way path the bot has to figure out if he is closer to the end of the path or to its beginning. Once he knows it he starts moving towards the other end of the path in order to get away from the problem spot. We can see the path ends here so the bot will most probably return back to north … from where he just arrived.
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.
List of all valid waypoint commands (use them without brackets)
While in game you can always use 'help' or '?' (without quotes) commands in console to access Marine Bot help. Where you can find simplified version of this list.
- wpt onShows waypoints.
- wpt offHides waypoints.
- wpt showToggles show/hide waypoints
- wpt autosaveToggles auto saving waypoints & paths to special files. Those are named 'autosave' with appropriate extensions. If you destroyed your waypoints, you quit the game or your Half-Life crashed before you saved your work you can load these waypoints back by writing 'wpt load autosave' (without quotes) into console.
- wpt saveSaves waypoints into the map waypoint file. It also automatically saves paths.
- wpt loadLoads waypoints from the map waypoint file. It also automatically loads paths.
- wpt load <name>Loads waypoints from a specific filename. Useful for upgrading waypoints from one version of a map to another (e.g. psobj_thanatos -> obj_thanatos)
- wpt loadunsupportedConverts waypoints made for an older version of Marine Bot into waypoints that can be used with the current version. Remember to save the waypoints after the conversion so that the changes aren't lost.
- wpt loadunsupportedversion5Converts waypoints made in waypoint system version 5 that was used in Marine Bot 0.8b into current version. Make sure to save the waypoints after the conversion so that the changes aren't lost.
- get_wpt_systemPrints the waypoint system version that the waypoints were created in as well as current version of Marine Bot waypoint system. By the way 'getwptsystem' works too.
- wpt clearDeletes all waypoints. They can be loaded back using the 'wpt load' command.
- wpt destroyDeletes all waypoints and erases both files from your HDD. The waypoints can't be loaded back.
- wpt countPrints information about waypoint amounts. Number already used, available for placing and maximum available.
- wpt info <arg1> <arg2>Prints important information about the closest waypoint or waypoint you specified using one of the arguments (without quotes). A few examples follow.
- wpt infoPrints only the basic information about nearby waypoint.
- wpt info 12Prints basic information about waypoint number 12 without the need to actually move close to this waypoint.
- wpt info morePrints most information about nearby waypoint. This is an ideal command for a key binding.
- wpt info more 12Prints most information about waypoint number 12.
- wpt info 12 morePrints most information about waypoint number 12. It does the same thing as the example command from above.
- wpt info fullPrints all information including a short note about what the bot will do when he gets to this waypoint.
- wpt add <type>Adds 'type' waypoint to your position. For available types of waypoints please check the 'waypoint type' section (above). If you use only 'wpt add' then normal waypoint (default waypoint) will be placed to your position.
- wpt deleteDeletes nearest waypoint. You have to be close to the waypoint to delete it.
- wpt change <type>Will change current waypoint status to the type you specify. For most types this command works as toggle. First use will add the type on this waypoint and second use will remove it. You can also easily add more types to a single waypoint (e.g. crouch + sniper + goback). But be careful when you use this command because some types will also reset the waypoint to default values for that particular type. For example if you want to change your waypoint to a 'use' waypoint then its range will be automatically set to 20 units. And if there was 'wait' time set on the waypoint it will be reset to zero. For available types of waypoints please check the 'waypoint type' section (above).
- wpt setpriority <number 0-5> <team>Will set waypoint priority for given 'team'. You must stand near the waypoint. Priority can be any number between 0 and 5 where 0 = no priority, 1 = highest priority and 5 = lowest/default priority. Just a reminder. Zero priority means the bot will ignore such waypoint. A few examples follow.
- wpt setpriorityWill equalize both priority values (i.e. reads both values from the waypoint and uses the higher one). For example if red priority was 3 and blue priority was 5 then blue priority will be set to 3 as well.
- wpt setpriority 2Sets both priorities to 2.
- wpt setpriority 2 redSets priority 2 for the red team.
- wpt setpriority 2 1Also sets priority 2 for the red team. As you can see you can use numbers as the team values where 1 = red team and 2 = blue team.
- wpt settime <number> <team>Sets waypoint 'wait' time (in seconds) for 'team'. It works same way as the priority command above.
- wpt setrange <number 0-400>Sets waypoint range. A radius around the waypoint which the bot will consider to be the waypoint itself. Range on a 'cross' waypoint determines how far away waypoints associated with that cross waypoint can be. More details can be found in 'waypoint range' section (above).
- wpt reset <arg1> <arg2> <arg3> <arg4>Resets values specified in particular arguments back to default.
- wpt reset helpPrints help for this command.
- wpt reset allResets all values.
- wpt reset typeSets waypoint type back to normal waypoint.
- wpt reset flagAlso sets waypoint type back to normal waypoint.
- wpt reset tagAlso sets waypoint type back to normal waypoint. Because people tend to call waypoint type by different names, we have them all.
- wpt reset prioritySets both priorities back to 5.
- wpt reset timeSets both wait times back to 0.
- wpt reset rangeSets waypoint range back to default value. This vary based on which type this waypoint is but usually it is 50.
- wpt reset time tagResets waypoint type as well as time.
- wpt reset range time tagResets waypoint type, time and range.
- wpt move <index>Moves the waypoint to your position. Basically you can change position of any waypoint that already exists on the map. So you don't need to delete it and add it anew.
- wpt moveFinds a waypoint nearby and moves it to your position. Allows you to tweak waypoint position. Be careful if there are more waypoints around you. You can easily disconnect waypoint from cross waypoint for example. Therefore you should pay close attention to your surrounding when using this command.
- wpt move 12Moves waypoint number 12 to your position. Allows you to move a waypoint over great distance in one go. This way you can also safely work in a area with many other waypoints because you can't accidentaly 'touch' different waypoint. Use 'wpt info' command to get waypoint index.
- wpt position <index>Prints 'index' waypoint position on the map using x/y/z coordinates. It will print your current position as well. Useful to get an idea where is this waypoint located.
- wpt detect <index>Prints all game entities (e.g. ammobox, button etc.) that are in vicinity of 'index' waypoint.
- wpt printallPrints list of all waypoints including their tags that are used on this map. It will print just 22 of them and then it will wait for you to type this command again to print next 22 waypoints. It is purposely done this way to allow you to actually be able to check them all. If it was done in one go then most of the output would have been beyond console history.
- wpt subscribe <name>Allows you to sign your work. It will save author's signature into .wpt file. This can only be done once and can't be changed. If there is a space in your signature then you have to use double quotes (e.g. wpt subscribe "Frank McNeil"). Without them you would write just Frank into the file. You should do it right at the beginning so you can easily destroy the waypoints and start anew if you have messed up your signature.
- wpt modified <name>Will save signature of person who modified the waypoints. This can be changed.
- wpt authorShows waypoint signatures if they exist.
- wpt drawdistance <number 100-1400>Sets the maximal distance from gamer (i.e. from you) where any waypoint will be displayed. Use this command if you see that waypoints flicker and/or some of them aren't displayed at all.
- wpt repair <arg1> <arg2>Runs automatic waypoint repair code based on the arguments you use. Each repair function will try to find and fix the specific problem with waypoints. Useful for fixing waypoints you've converted from old standards. Especially those from waypointing system version 5. However you can also fix waypoints where you clearly see the author didn't pay attention to proper debugging or placing in general.
- wpt repair masterrepairRuns several repair functions in exact order to achieve best results. Range and position repair functions are skipped due to being too aggressive and not meant for general use.
- wpt repair pathendWill focus on missing 'goback' waypoint on any path that does not end at junction (a cross waypoint). It can also change such path on a two-way path in order to allow the bot traveling back to the starting point of this path.
- wpt repair pathend 12Same as above, but the fix will be applied only on path number 12.
- wpt repair pathmergeWill focus on invalid path connection (i.e. when one path starts at the same waypoint where another path ends and this waypoint isn't part of a junction). Such merge usually happens when the waypoint creator use the 'start' command instead of the 'continue' command. Therefore if such merge is found then these two paths will become one (i.e. one of the paths will be deleted and the other path will be extended to cover the waypoints from the deleted path).
- wpt repair pathmerge 5Same as above, but the fix will be applied only on path no. 5.
- wpt repair rangeWill focus on poorly designed waypoint range setting by reducing it in order to prevent its intersecting with any solid object (e.g. a waypoint behind a sandbag where the range reaches up to the other side of the sandbag). Use range repair function only on waypoints where you clearly see the author didn't pay any attention to the range setting. This function was designed to allow people easy and quick way to repair waypoints that are either outdated or done using the autowaypointing feature. If the waypoints were done correctly then using this feature can make the waypoints worse.
- wpt repair range 123Same as above, but the fix will be applied only on a waypoint number 123.
- wpt repair range_and_positionAlternatively 'rangeandposition' or 'rangeandpos' work too. Will focus on poorly designed waypoint range setting. It will apply a combination of range reduction and waypoint reposition in order to repair it. The waypoint will be moved slightly away from the obstacle and its range will be reduced in order to give the bot enough free space. Use range_and_position repair function only on waypoints where you clearly see the author didn't pay any attention to the range setting. This function was designed to allow people easy and quick way to repair waypoints that are either outdated or done using the autowaypointing feature.
- wpt repair range_and_position 3Same as above, but the fix will be applied only on waypoint number 3.
- wpt repair sniperspotWill focus on incorrectly designed sniper spot at the end of a path. It will look for missing 'aim' waypoint and place one if needed. It can turn the waypoint into a 'sniper' waypoint if it is missing. Also it will check for the 'wait' time and set some 'wait' time if there is none.
- wpt repair sniperspot 11Same as above, but the fix will be applied only on a waypoint no. 11.
- wpt triggerevent add <trigger_name> <message>Adds message to given trigger slot. If the message includes spaces it has to be closed in double quotes.
- wpt triggerevent add trigger1 "Red Force occupies the village"Adds 'Red Force occupies the village' message to a trigger slot number one.
- wpt triggerevent add trigger2 "Blue Force occupies the village"Adds 'Blue Force occupies the village' message to a trigger slot number two.
- wpt triggerevent delete <trigger_name>Deletes message stored in given trigger slot (i.e. frees this slot).
- wpt triggerevent showallPrints what is stored in each of the eight trigger slots.
- wpt triggerevent setpriority <priority 0-5> <team>Sets second priority values for the 'trigger' waypoint. Works same as the command for standard priority.
- wpt triggerevent settrigger <trigger_name> <state>Links nearby 'trigger' waypoint to given trigger slot based on the state value.
- wpt triggerevent settrigger trigger1 onThis 'trigger' waypoint will switch to the second priority values at the moment message stored in slot 1 will show on your screen.
- wpt triggerevent settrigger trigger2 offThis 'trigger' waypoint will switch back to standard priority values at the moment message stored in slot 2 will show on your screen.
- wpt triggerevent removetrigger <state>Removes specified link from close 'trigger' waypoint.
- wpt triggerevent removetrigger onThis 'trigger' waypoint will no longer switch to the second priority values because the event that would do it has just been removed. This waypoint basically works as normal waypoint now.
- wpt triggerevent removetrigger offThis 'trigger' waypoint will no longer switch back to standard priority values because the event that would do it has just been removed. That means that since the moment a game event caused this waypoint to switch to using second priorities it will stay like that till the end of the map or map restart.
- wpt triggerevent infoPrints info about close 'trigger' waypoint. Where you can find out which trigger slots are going to turn it on and off if there are any. You'll also see all four priority values (standard as well as the second ones).
- autowpt onStarts autowaypoint as you walk. Adding new waypoint is based on distance between two waypoints.
- autowpt offStops autowaypointing.
- autowpt startToggles start/stop autowaypointing.
- autowpt distance <number 80-400>Changes the distance between two waypoints for the purpose of autowaypointing. The default value is 200. Minimum is 80 and maximum is 400 units.
- pathwpt onShows paths.
- pathwpt offHides paths.
- pathwpt showToggles show/hide paths.
- pathwpt saveSaves paths. It's not recommended to use this command (.wpt and .pth files can then get out of sync). Use 'wpt save' rather. Since that one saves both files.
- pathwpt loadLoads paths. It's not recommended to use this command (.wpt and .pth files can then get out of sync). Use 'wpt load' rather.
- pathwpt load <mapname>Loads paths from a specific filename (for upgrading waypoints from an older version of a map to a newer version, etc.). It's not recommended to use this command (.wpt and .pth files can then get out of sync). Use 'wpt load ' rather.
- pathwpt startStarts building the path. You must be close to a waypoint where you want to start this path. It automatically adds that waypoint to the new path.
- pathwpt stopStops/finishes building path. This command doesn't add any waypoint to actual path. It only finishes the path (i.e. this lets the system know that you are not going to work with this path from now).
- pathwpt continue <index>Continues working on a path that was already finished. For example if you've changed your mind and you want to add waypoints to an old path. You must be close to a waypoint this path includes. It doesn't have to be it's end waypoint. If there are more paths on nearby waypoint you can use unique path number ('index') to continue working on the path you really want.
- pathwpt addAdds a waypoint to the path you are working on. You must be close to the waypoint you want to add to the path. You can tell that the waypoint was added into because you will see a colored beam connecting this waypoint to the previous waypoint from your path. You should also hear a single bell tone.
- pathwpt autoadd <arg>Automatically adds any waypoint you are really close to ('touching') into the path you are working on. If you haven't started any path or you aren't continuing in any path then it does nothing. Be careful when you are using this feature when you are close to more than one waypoint because it is easy to add unwanted waypoints to your path.
- pathwpt autoaddToggles the autoadd feature on/off.
- pathwpt autoadd offTurns the autoadd feature off.
- pathwpt insert <wpt> <path> <pathwpt1> <pathwpt2>Inserts waypoint 'wpt' into path 'path' between waypoints 'pathwpt1' and 'pathwpt2' where 'pathwpt1' and 'pathwpt2' must be neighbours in the path. There can't be any other waypoint between those two in the path. This command is useful to fix problems such as a path intersecting a corner or some solid object. You can simply add new waypoint right next to the problem spot and use this command to include that waypoint into the path. Also you can use this command to move the beginning of a path onto a new waypoint. You can easily add new waypoints to the end of path. But there is no easy way to add new waypoint to the beginning of a path. Using this command is the only way how you can achieve that. Add the new waypoint and insert it into the path between its 1st and 2nd waypoint and then remove the waypoint that was the starting point previously.
- pathwpt insert 23 7 150 155Will insert waypoint no. 23 into path no. 7 between waypoints no. 150 and 155. Say the path was 148-149-150-155-159-170. As you can see the waypoints no. 150 and 155 are neighbours. After you use this command the path would be 148-149-150-23-155-159-170 where our two waypoints are no longer neighbours.
- pathwpt remove <index>Removes waypoint from a path. As always you must be standing near the waypoint you want to remove from the path. If there are more paths on this waypoint you should use path unique number (index) to tell the system you want to remove this waypoint just from this path.
- pathwpt delete <index>Deletes whole path. You must be standing near a waypoint that is a part of the path. You can also use path index as an argument for this command. The system will then delete path matching this number. This is useful in case where there are more than one path on your waypoint.
- pathwpt info <index>Prints information about a path on nearby waypoint. This way you can find path unique number (i.e. its index). This is a good command to bind to a key if you are working on your waypoints. If you already know path index you can use it as the argument for this command to get information about this path. So you don't need to move close to any waypoint in order to check the path.
- pathwpt printall <arg>Prints information about one or more paths based on the argument you use. Like the other listing commands it can split the output in pages if there's just too many paths to print. In that case you must type this command again to see the next page.
- pathwpt printallPrints a simple list of all paths used on current map. This is the case where the output will most probably be split into pages. So whenever you want to see the next page repeat this command.
- pathwpt printall nearbyPrints a simple list of all paths that are on the waypoint that is near you (you must be really close to the waypoint). This is useful in cases where there are more paths on a waypoint and you need to find their indexes. Or if you need to check them all.
- pathwpt printall 3Same as above but this time you know the waypoint index so you don't need to move to it and you can check things 'remotely'.
- pathwpt printpath <index>Prints list of all waypoints with their types in 'index' path. If the path is really long it will print just 22 waypoints and then it'll wait. Once you repeat this command it'll continue printing next 22 waypoints from the path. Untill you get to the end of the path or you type different path index.
- pathwpt countPrints the number of paths used. The maximum number of paths and the number of paths still available.
- pathwpt reset <index>Resets all path values back to defaults.
- pathwpt setdirection <direction> <index>Allows you to set whether this path is a one way path, a two way path, or a 'patrol' path. If you are just building a new path you can skip the index argument and the command will be applied right on this path. If you aren't then you need to be close to a waypoint that is part of the path for the command to work without the index argument.
- pathwpt setdirection one 2Will set path no. 2 as a one-way path. The path will be one-way in the direction in which it was created.
- pathwpt setdirection two 2Will set path no. 2 as a two-way path. Bots can move along this path in either direction. This is also useful, for example, for side paths to ammoboxes, or perhaps bandages. If the path does not end at a junction ('cross' waypoint) or some other specific waypoint, such as an ammobox waypoint, or a use waypoint, make sure the last waypoint in the path is a 'goback' waypoint. This will allow the bot to return back to the start of the path.
- pathwpt setdirection patrol 2Will set path no. 2 as a patrol path. This is special type of path. It's basically two-way, but bots will not use it only once. They will stay on this path for a time and repeat all the actions in this path.
- pathwpt setteam <team> <index>Allows you to dedicate the path to only one team. If you are just building a new path you can skip the index argument and the command will be applied right on this path. If you aren't then you need to be close to a waypoint that is part of the path for the command to work without the index argument.
- pathwpt setteam blue 2Path no. 2 will be available only for blue team.
- pathwpt setteam 2 2Same as above. You can use numbers even for team argument where 1=red team and 2=blue team.
- pathwpt setteam both 2Path no. 2 will be available for both teams again.
- pathwpt setteam redThe path on the closest waypoint (or the path you are just building) will be available only for red team.
- pathwpt setclass <class> <index>Allows you to dedicate the path to only specific class. Currently you can set them for snipers and machine gunners. If you are just building a new path you can skip the index argument and the command will be applied right on this path. If you aren't then you need to be close to a waypoint that is part of the path for the command to work without the index argument.
- pathwpt setclass sniper 2Path no. 2 will be available only for snipers.
- pathwpt setclass mgunner 2Path no. 2 will be available only for machine gunners.
- pathwpt setclass all 2Path no. 2 will be available for all bots again.
- pathwpt setmisc <misc> <index>Allows you to set additional flag for the path. The tags/flags are: avoid_enemy, ignore_enemy and carry_item (avoidenemy, ignoreenemy, carryitem will work too). You can imagine these as a sort of hints. Which will help you tweak bots behaviour in that area. If you are just building a new path you can skip the index argument and the command will be applied right on this path. If you aren't then you need to be close to a waypoint that is part of the path for the command to work without the index argument.
- pathwpt setmisc avoid_enemy 2Path no. 2 will now tell the bot to attack only enemy that is in range of his weapon. Useful on maps such as ps_marie where we have to be very careful around the bridge otherwise we risk either broken leg or even death.
- pathwpt setmisc ignore_enemy 2Path no. 2 will now tell the bot to ignore most enemies except those that are really close. You can use this to limit bots aggression in cases where he is really close to important map goal. For example capturing the costal lighthouse on obj_sweden where the bot should capture it at all cost.
- pathwpt setmisc carry_item 2Path no. 2 will now tell the bot that it will get him to a place to where he has to deliver goal item he carries now. It doesn't prevent other bots from using this path as well. But the bot who has the goal item will purposely choose this path.
- pathwpt checkinvalid <info>Allows you to get rid of all invalid paths (i.e. a path with length = 1) that you may have placed. Using the 'info' argument will also show you the index of any path that has been deleted throughout this proccess. Deletion of invalid paths is also done automatically while saving your waypoints.
- pathwpt checkproblems <save>All paths will be checked for possible problems and all findings will be reported. Use the 'save' argument if you want store them into Marine Bot error log file. Note: Problems marked as a BUG are fatal errors which would cause serious problems and you should fix them. While some of the problems marked as a WARNING are things you may have done on purpose, but the system still reports them so you can check them. For example if your path ends in front of button operated doors/gate and the cross waypoint is positioned behind it like on obj_thanatos. Breakable object (wooden wall or window) would fire such warning as well. The point is to help you in debugging your waypoints.
- pathwpt highlight <mask>Will hide all paths that don't match specified mask in 'mask' argument. This feature is very useful if you have a lot of paths in some area and you want to see which are usable for which team. Or to see how one specific path really look like.
- pathwpt highlight 2Will display only path number 2.
- pathwpt highlight redWill display only paths that are accessible by red bots (i.e. red team + both teams).
- pathwpt highlight blueWill display only paths that are accessible by blue bots (i.e. blue team + both teams).
- pathwpt highlightIf used without any argument it will turn the highlighting feature off. So all paths will be displayed again.
- check_aimsShows the connection between waypoints with 'wait' times and all valid 'aim' waypoints. Solid objects will block the connection between a 'wait' waypoint and an 'aim' waypoint. This command works as a toggle. So you can easily bind it to a key. Where first pressing will turn it on and second will turn it off.
- check_crossShows the connections between 'cross' waypoints and all waypoints within that 'cross' waypoints range. Again, solid objects will block the connection between a 'cross' waypoint and the waypoints within its 'range'. This command also works as a toggle. So you can easily bind it to a key. Where first pressing will turn it on and second pressing will turn it off.
- check_rangesDisplays two thin white lines that intersect in the middle of a waypoint, indicating the waypoint range. Like both commands above this also is a toggle. It should be bound to a key so you can easily check your waypoints.
Other useful commands that help you when you are testing your waypoints.
- observer <off>The bots will ignore you. You can either use it as a toggle or specify the 'off' argument to return the bots to normal combat behaviour.
- mrfreeze <off>The bots will completely stop. Good for placing waypoints without having to kick all the bots from the game. Again this command will toggle this mode or you can use the 'off' argument to return the bots to normal behaviour.
- botdontshoot <off>The bots won't shoot. It's a toggle command as above.
- botignoreall <off>The bot won't target any enemy. Like if there was no one else in the game. Works as a toggle command as above.
- mbnoclip <off>Allows you to fly. This is useful command for placing 'aim' waypoints in front of thin windows/holes that are normally unreachable. Or if you are watching bots how they play the map use this command to watch them from above. That way you won't be hit ... well okay not that often. Since explosions can still hurt you. Again it's a toggle command as above.
by Frank McNeil 2005-2019
end of file