MVM map robot pathing issue

  • Site Migration: See bugs? Report them here. Want something changed or have an idea? Suggest it here.


L1: Registered
Sep 2, 2013
HI All,

I am working on a Man vs Machine map and have run into a development snag. I have 4 paths for the bots to possibly traverse through (here I'll call them: upper_right, right, left, upper_left) but the carrier always goes the same route, which is my upper_left pass.

I've set up the logic correctly I believe. I have checked my logic_relay's, logic_case, nav_prefer and nav_avoid paths against the example and official maps and everything appears to be correct.

For a little more detail, if the bomb carrier is suppose to go the upper_left path it does so with no hesitation. If in turn, the bomb carrier should go one of teh other 3 paths it appears to attempt to go down the lower left path for a moment then turns around and hopes along an incline near the upper_left path until it makes it up and then continues on the upper_left path to the bombsite

Does anyone have at ideas on why my bomb carrier is not going the proper direction?

I can provide images or even the file is someone has the time an interest to help me.

Thank you,


Grand Vizier
May 14, 2008
The bots will always take the shortest distance path they can find, and the nav_avoids are basically just invisible walls* that only affect the bots. *awful walls, bots can get knocked through the avoids and then they just find a new shortest path from their new position.

In your case it sounds like there's a gap leading into upper_left that is always open, and it just happens to be the shortest route even when one of the other 3 are open. To fix this you just need to re-position your nav_avoids or make more to make sure that the bots can't consider upper_left a viable path except when it's meant to be open.

edit: to add, if it's only the carrier doing this, and not the other bots. Then you need to tag your nav_avoids to include the carrier as well as the common bots.
Last edited:


L1: Registered
Sep 2, 2013
Thank you for the advice Ravidge, I'll look into increasing the area of the avoid triggers.


Mann vs Machine... or... Mapper vs Meta?
Sep 8, 2008
To add to ravidge. The func_nav_avoid brushes are based on the nav areas from the nav files. If they arent overlapping enough they wont take the nav area as part of the avoid. this can give invisible gaps.

Worse is, when a prefer and avoid touch each other they can conflict and the avoid or brush is able to take the whole nav section allowing paths to be blocked which shouldnt be blocked.

Using the following 2 commands ingame can help on spotting the areas which have an avoid brush over them.
nav_show_func_nav_avoid 1
nav_show_func_nav_prefer 1
Note that these are affected by the state they are in (enabled/disabled)

If a brush appears to big or seems to overlap with an other you have to nav_split the section. Its not a bad thing to have to nav edit in an mvm map. nav_generate doesnt take the brushes into account when it makes the whole mesh. In my map i edit the nav mesh everytime. Its far better than just to make the brushes larger all the time. Too large will affect bots the wrong way.

Imagine a side path with a length of 1024. If you have a nav avoid of 128 even when they are pushed 800 units into the path they still walk back. If it was 1024 long once it touched the brush it already started to ignore it and would take the path as if it was normal.

And again to add to ravidge. When a bot is pushed into a nav avoid they will ignore the whole nav block to decide their shortest path. Any connecting block is still going to take effect which is sometimes making them walk backward. If they dont have any possible path they take the shortest one regardless of any entities. So if they are in the middle of a square avoid and on each side there is a seperate block they take the shortest path. Even if that path would require them to walk through 20 avoid blocks and the other side would be just 1.
However, if a path is fully blocked they are still taking prefer areas into account. It is possible to force the bots to walk a circle this way if for example they jump down at the end of the prefer area. They from that point will see the prefer as a viable shortest path.