Since the mvm contest is going i think its a usefull thing to know what these things do.
Lets asume the map is like this. The grid shows the nav squares it generates, the yellow is walkable:
By default bots take the shortest path:
To make them take the outer path we can do 2 things, we use an avoid or prefer. The easiest is generaly to use an avoid since these are regions the bots will not walk at, while a prefer in some cases might be ignored due to lenghts (if the path to the hatch is shorter than the closest point of the prefer, the hatch gains priority).
Another way to manage these diffirences easier is:
To see these squares you need to go ingame and have your nav file already compiled using nav_generate.
When turning on sv_cheats and nav_edit you can see all the squares the nav generates. These are the squares used by the avoids and prefers. Remembering where large ones exist can be usefull to know since this is where they often break.
In my examples they are all of an equal size, but thats for illustration reasons.
Blockers
But since the most common part is to block a bomber. Lets block it. (later on i will show the example of a prefer and you can already see why its not recommended then)
Now, for these brushes to work they have 1 major requirement: they must contain all the nav squares entirely. A partial square is ignored. So lets look at these examples:
In this case i used a small avoid because it looks nicest with the details on the wall. but in this case the blocking will not work since none of the nav squares is fully covered.
To make it work you can do 2 things: enlarge the area, ensure the nav squares become smaller. The easiest is to enlarge the area. But you could make the squares smaller by having a displacement floor which some minor height diffirences. Or you could do a nav_split after each compile manualy (highly unrecommended since its time consuming)
Since they now cover the area, the bots no longer can take that path and will move to the side.
Now for a bomber, its still often recommended to plan your blocking area, in my example the path is short, but it still has a potential problem. Imagine if you knocked the bomber on the light purple dot.
In this case the bomber checks the other nav squares individualy. As the 3 sides are still blocked, it will walk to the upper nav to continue. It will not walk to the right first since its shorter, that nav area is still considered blocked. Only the area he is on is ignored. So it works fine here. But once he reaches the darker purple dot, he will move downward as thats the only unblocked path.
If we would extend the nav blocker to go further down to prevent this.
He would become stuck entirely. As a bot doesnt accept this, it now will ignore any blockers and decide to revert back to its original plan. It will ignore the blocking here.
So to get the most recommended output, you need to decide the moment where to block them. Too far backward and they will ignore it when blasted away, too much forward and airblasting a bot too far can set him back massively.
A general good line is to prevent the red team from pushing him too far by accident while still having it closest to them. However, when a detour is huge its often a bad idea:
This makes the bots reset the moment they are pushed back 2 squares to the left. But by that are forced to take a huge detour. Even though the small blocker is nice. its a bad situation here and exploitable by the players. It would be nicer to give the bots the advantage here and either make the whole left path blocked, or use the original situation.
Prefers
But now lets use the prefer instead since 'we' decided that instead of giving the bomber a dynamic path, we decided it would be static and instead would focus on hordes of flanking bots. Now for prefers its recommended to take the entire path as a prefer zone, since the bots decide wether they will use the prefer or not based on distances. Larger means more nav sections are closer to the bot until they are at the end. So in this case:
Although we in theory could take a shorter path:
The reason this one works is because point 2 is closer than point 1. But there is a reason why its unrecommended:
And using this info you would be able to do nearly all basic things. But do note that sometimes you can be creative and use prefers to allow the popfile maker to perform alternative tasks.
Extra info
Conflicts
Another very important thing: Prefers and blocks should not overlap during the same round! A nav square only can have 1 state with 1 filter (which can also be a filter_multi on that). This means that a blocker and prefer in the same area will conflict and create unintended behaviour (only 1 will win).
My avoids/prefers are getting ignored
An avoid (its the same for prefers) works by checking the tags on bots. By default it has no tags supplied, and the avoid doesnt work at all even though it is active. All bots have a tag by default to make a bomber listen to the avoids you will need a 'bomb_carrier' tag, for everything that is not a bomber the 'common' tag is given to them. The entity shows additional entities it can give.
Always be sure to fill in a tag, if there is none, it wont work.
Example of a more complex system
Lets take an example of what i did in skullcove. Skullcove has a rock in the middle which seperates a section into 2 parts. Even though for the bomber they are essentialy lanes, i allowed myself to modify some behaviour things to the bots using tags. I did put some of the paths in the below image, but thats for decorative reasons, the main part is just the rock.
Gray is the rock which isnt entirely suited to the nav and i was even required to use some nav_split in the editing to fix this. but the way it works remains the same. The example here isnt exactly matching the skullcove method since that one has the pathing staticly decided. But i want to show how it can be even more dynamic. And as you can see, these are taking diffirent regions due to the above mentioned conflict.
I had a blocking area for the bomber. and a prefer for tagged bots. Both could essentialy do the same, but 1 of the things i wanted was that i could mark bots to not take the same path as the bomber.
So i had a block and prefer with similar names (nav_left_allow, nav_left_block), which can easily be triggered to be turned on and off (using the wildcard: nav_left_*).
When the round decides the bomber should take the right path, we enable only the left resulting in:
So what happens here: the bomber sees the blocker and goes right. And since that avoid is only filtered for the bomber, he is realy not taking that one. For the other bots we tagged the prefer will matter. And although they might in the rare case be knocked to the right side, they will more often take the left and by that ensure both sides are occupied.
I even had multiple sections of these so i could make a both go entirely by the flanks starting on the left and finishing on the right. But this is where your creativity starts.
Lets asume the map is like this. The grid shows the nav squares it generates, the yellow is walkable:
By default bots take the shortest path:
To make them take the outer path we can do 2 things, we use an avoid or prefer. The easiest is generaly to use an avoid since these are regions the bots will not walk at, while a prefer in some cases might be ignored due to lenghts (if the path to the hatch is shorter than the closest point of the prefer, the hatch gains priority).
Another way to manage these diffirences easier is:
- Is it ment for the main path and required for the bomber to work? Use an avoid.
- Is it ment for flanking bots or capture bots which generaly wont be having a bomb on these areas? Use a prefer
To see these squares you need to go ingame and have your nav file already compiled using nav_generate.
When turning on sv_cheats and nav_edit you can see all the squares the nav generates. These are the squares used by the avoids and prefers. Remembering where large ones exist can be usefull to know since this is where they often break.
In my examples they are all of an equal size, but thats for illustration reasons.
Blockers
But since the most common part is to block a bomber. Lets block it. (later on i will show the example of a prefer and you can already see why its not recommended then)
Now, for these brushes to work they have 1 major requirement: they must contain all the nav squares entirely. A partial square is ignored. So lets look at these examples:
In this case i used a small avoid because it looks nicest with the details on the wall. but in this case the blocking will not work since none of the nav squares is fully covered.
To make it work you can do 2 things: enlarge the area, ensure the nav squares become smaller. The easiest is to enlarge the area. But you could make the squares smaller by having a displacement floor which some minor height diffirences. Or you could do a nav_split after each compile manualy (highly unrecommended since its time consuming)
Since they now cover the area, the bots no longer can take that path and will move to the side.
Now for a bomber, its still often recommended to plan your blocking area, in my example the path is short, but it still has a potential problem. Imagine if you knocked the bomber on the light purple dot.
In this case the bomber checks the other nav squares individualy. As the 3 sides are still blocked, it will walk to the upper nav to continue. It will not walk to the right first since its shorter, that nav area is still considered blocked. Only the area he is on is ignored. So it works fine here. But once he reaches the darker purple dot, he will move downward as thats the only unblocked path.
If we would extend the nav blocker to go further down to prevent this.
He would become stuck entirely. As a bot doesnt accept this, it now will ignore any blockers and decide to revert back to its original plan. It will ignore the blocking here.
So to get the most recommended output, you need to decide the moment where to block them. Too far backward and they will ignore it when blasted away, too much forward and airblasting a bot too far can set him back massively.
A general good line is to prevent the red team from pushing him too far by accident while still having it closest to them. However, when a detour is huge its often a bad idea:
This makes the bots reset the moment they are pushed back 2 squares to the left. But by that are forced to take a huge detour. Even though the small blocker is nice. its a bad situation here and exploitable by the players. It would be nicer to give the bots the advantage here and either make the whole left path blocked, or use the original situation.
Prefers
But now lets use the prefer instead since 'we' decided that instead of giving the bomber a dynamic path, we decided it would be static and instead would focus on hordes of flanking bots. Now for prefers its recommended to take the entire path as a prefer zone, since the bots decide wether they will use the prefer or not based on distances. Larger means more nav sections are closer to the bot until they are at the end. So in this case:
Although we in theory could take a shorter path:
The reason this one works is because point 2 is closer than point 1. But there is a reason why its unrecommended:
- The objective might not be centered, if the objective is slightly off center to the left. point 1 could sometimes still be a shorter path.
- You can add a flank or spine later on, when the path is set you will know you dont hinder them.
- It can ignore blocked areas. Especialy in combinations it wont always take an obvious path and could be simply overlooked
And using this info you would be able to do nearly all basic things. But do note that sometimes you can be creative and use prefers to allow the popfile maker to perform alternative tasks.
Extra info
Conflicts
Another very important thing: Prefers and blocks should not overlap during the same round! A nav square only can have 1 state with 1 filter (which can also be a filter_multi on that). This means that a blocker and prefer in the same area will conflict and create unintended behaviour (only 1 will win).
My avoids/prefers are getting ignored
An avoid (its the same for prefers) works by checking the tags on bots. By default it has no tags supplied, and the avoid doesnt work at all even though it is active. All bots have a tag by default to make a bomber listen to the avoids you will need a 'bomb_carrier' tag, for everything that is not a bomber the 'common' tag is given to them. The entity shows additional entities it can give.
Always be sure to fill in a tag, if there is none, it wont work.
Example of a more complex system
Lets take an example of what i did in skullcove. Skullcove has a rock in the middle which seperates a section into 2 parts. Even though for the bomber they are essentialy lanes, i allowed myself to modify some behaviour things to the bots using tags. I did put some of the paths in the below image, but thats for decorative reasons, the main part is just the rock.
Gray is the rock which isnt entirely suited to the nav and i was even required to use some nav_split in the editing to fix this. but the way it works remains the same. The example here isnt exactly matching the skullcove method since that one has the pathing staticly decided. But i want to show how it can be even more dynamic. And as you can see, these are taking diffirent regions due to the above mentioned conflict.
I had a blocking area for the bomber. and a prefer for tagged bots. Both could essentialy do the same, but 1 of the things i wanted was that i could mark bots to not take the same path as the bomber.
So i had a block and prefer with similar names (nav_left_allow, nav_left_block), which can easily be triggered to be turned on and off (using the wildcard: nav_left_*).
When the round decides the bomber should take the right path, we enable only the left resulting in:
So what happens here: the bomber sees the blocker and goes right. And since that avoid is only filtered for the bomber, he is realy not taking that one. For the other bots we tagged the prefer will matter. And although they might in the rare case be knocked to the right side, they will more often take the left and by that ensure both sides are occupied.
I even had multiple sections of these so i could make a both go entirely by the flanks starting on the left and finishing on the right. But this is where your creativity starts.
Last edited:
