I see you just started with it so I'll give you some sort of general MB waypointing course ;). First you need to know that MB waypointing system uses waypoints and paths. The waypoints are pretty self-explanatory issue and I'm sure you already found the purpose of them. So I'll tell you something about paths. They do improve the navigation by 100%. Because they allow you to link the waypoints to something more general or global or how should I say it. Basically the waypoints themselves are just points in 3d space, but the paths do link these separated points to ... well yeah ... paths :) or routes the bots will then follow.
The path itself needs to start somewhere (at some point so on some waypoint). Then it can connect as many other waypoints as you need/wish. And of course it also has to end somewhere. Yet again it has to end on some waypoint. The most common use of the path is to create a connection between two cross waypoints. In other words it has to get the bot from one intersection to another one. Look at this picture. It's an example of what I wanted to say.
The path is the purple horizontal line that runs through the 3 waypoints there in the middle. As I said above it created a connection between cross waypoint #1 on the left and another cross waypoint on the right side. The paths can be colored with more than one color, see the MB waypointing documentation for more info. They can also alter the look a bit, but they will always look like horizontal beams. Okay that's about all you need to know for now.
Now a bit more about your waypoints. See this first picture.
The white horizontal lines are a representation of the waypoints' range. The range is the space around the waypoint the bots will use to move/camp or do any other action at this waypoint. The most important thing about ranges is that they shouldn't collide with/intersect world 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 this case you'll have to reduce the range on this waypoint in order to prevent bots getting stuck here.
Similar to standard waypoint range is a cross waypoint range. But the main difference is that the bots don't use this range. I mean the bot will NEVER move towards the cross waypoint position. This waypoint works as a marker to start AI routines inside the MB codes. Basically the cross waypoint range tells the bot which waypoints are available to him. The bot then picks one of these waypoints in order to get to different parts of the map. Look at this picture.
You can see there are 4 other waypoints that are inside the cross waypoint range. So the bot can pick one of these 4 waypoints if he enters the cross waypoint from the same direction I did on the picture. By default the bot will never pick the same waypoint he used to enter the cross waypoint. In other words the bot won't do a 'U' turn at cross waypoint … well unless you enforce it by the priority and like setting. That isn't the case here. That's the reason why I said there are only 4 options for the bot 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. At first we don't want that waypoint be connected to this cross waypoint, because there already is one waypoint connected in that direction (path). And 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 the waypoint located. So in this case the bot would know he has to jump over the broken wall.
Okay next picture shows another example of bad cross waypoint range setting. We can see the same problem as above. The range on this cross waypoint is again too big. It shouldn't reach up to the second jump waypoint.
Also I strongly recommend to create a short path towards the ammobox instead of having a single waypoint there. Because the paths now store info about few important things. Ammobox waypoint is part of it. Let's see what I mean.
What I did there is that I simply reduced the cross waypoint range a bit. Then I added new standard waypoint between the cross waypoint and the ammobox waypoint. And finally I created a short path on these two waypoints. Having it done this way makes things easier. As I said above paths now inform the bot about certain things. A path with an ammobox waypoint will tell the bot 'use me if you are low on ammunition'. The main point is that you don't have to set any priorities on these additional routes. All you need to do is keep higher priorities on the main routes. Basically the only two waypoint types that are meant to be used as a single waypoint (not part of any path) are the cross and aim waypoints. Any other waypoint type should always be part of at least one path.
Now I'm not sure if you want to allow all the bots to camp here, but I personally wouldn't do it. I think that only the sniper bots should do it. Any other bot should just rush the streets. Anyways here are some tips how could it be done. First this is how it looks now. As I said this layout will result in all bots camping there ... well okay at least those bots that will spawn close to this spot.
You might want to put a cross waypoint there. Which would 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.
Let's start with adding new standard waypoint there. This new waypoint will be connected to also newly added cross waypoint with relatively small range. The purpose is simple. Connect only 3 standard waypoints. Then we use the new waypoint to build a short path to the sniper spot. When the path is ready we will change it to a sniper only path. Final step is adding a goback tag on the sniper waypoint. Just get really close to the sniper waypoint and use 'wpt change goback' command. Or use the menu if you like. Either way the waypoint will change its appearance. Having it done this way will tell the bot that this is a dead end. The bot now knows he needs to turn back and return back to the beginning of this path once he's done with the sniping. Let's see what have we done with this area. Notice that I left the other sniper position untouched in order to show the before and the after.
I'd recommend to start with drawing the basic map layout. I mean do 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 can one waypoint maps, but I think following these steps keeps things easy. Also you shouldn't create many mistakes so the waypoints will be less bugged.
As I said this isn't the only way of waypointing a map, but it allows you to fix the problems on the go, extend the waypoints in waves and mainly release the waypoints to public/servers. Because the bots should be able to play the map once you've done all the general paths and they will only become better and better as you improve the waypoints. I hope I didn't scare you too much. Good luck!
Okay the following series of pictures show common errors or bugs if you want the people make. Most of the pictures come from former Marine Bot forums (the hidden development team section). As you can see I drew notes and like on them as a part of the feedback. Some errors are easy to spot just by running through the map. Many would have been caught if the waypointer 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.
This path has no meaning the way it is now. First the bot can't reach the window camp spot. And then the path doesn't even have a proper ending. If path doesn't end at a cross waypoint then there has to be a waypoint that tells the bot to turn back and follow the path in opposite direction. There are 3 waypoints like that. An ammobox waypoint and use waypoint are the first two waypoints that when used at the end of a path will make the bot turn back (after getting the ammunition or using a button on wall of course) and return the same way he used to get to his present location. 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. I mean adding a goback sniper waypoint in front of the window. Setting some wait time on it. Then adding an aim waypoint or two there. And finally making the path end on that new waypoint.
The following 3 pictures will show us a path ending in a void ... like on the previous picture. I mean the paths would have been okay if they were actually connected to the whole net. This kind of a bug happens when the waypointer 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. It is always a good idea to help the bot face the ladder while 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.
The following picture shows the change that has been drawn on the previous picture. Notice the range setting. Using values like 10 or 15 will make the bot slow down and align himself before touching the ladder.
One last ladder example. We aren't at cross waypoint this time, but we should still help the bot. There is enough space so adding an additional waypoint isn't a problem. You wouldn't even have to delete the whole path. There is a command to deal with cases like this. Check the documentation for 'pathwpt insert' command.
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 do the waypoints so the bot is facing the button while still moving towards it. I guess that the following sketch tells all. 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 the path highlighting feature to reveal the nasty bug.
We have already seen it. A path ending in a void. The only difference here is that the waypointer thought he can merge two paths. That's forbidden though. Just to remind known fact. A path can end at a cross waypoint or there has to be a turn back marker … you know the ammobox or use or goback waypoint. Next picture shows the same ugly bug. 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 as well as previous else he would be stuck for ever. The bot will then search for the nearest waypoint. It will be the one he just reached. Then the bot will try to find a path on such waypoint. There are two options here. He will pick one randomly. Now if the path is a both way path the bot has to figure out if he is closer to the end of the path or if he is closer to its start. Once he knows that he starts moving towards the other end of the path in order to get away from the bugged spot. Seeing the path ends here the bot will most probably return back to north … from where he just arrived.
There are 3 more pictures displaying this bug. Now 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'. So use it to finish the faulty path at cross waypoint.
The word for the following pictures is simplicity. I think the first two pictures are clear enough.
Having two cross waypoints this close makes things just too complicated. You need to work with way to many priority and range settings and waypoints in general. In the end you only slow things down as the more cross waypoints the more computing is needed when the bots actually play the map. As you can see just one cross waypoint can handle the 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 pick a sniper only path over standard path. He won't do it always as we need a bit of randomness in bots' behavior, but most of the time the bot will follow this logic. See the following pictures they show even worse examples.
This last one is just a pure madness.
The previous pictures showed us excessive use of cross waypoints. 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 look like a bad cross waypoint range, 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 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 more human like as 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.
Let's see some more waypoints that serve no purpose. The path is short and straight. 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 predictable. The bot will follow the same route even without the waypoint. Therefore there is no purpose having an additional waypoint there.
by Frank McNeil 2005-2013
end of file