MVM bot's navigation problem/bug(?)

[FortyTwo]

So in mvm_cargo, It have doors for the trains to pass through and robots to take shortcut, so I have a navigation inside the door so robots know that they can walk through this door. Since that the door will keep either opening or closing, I have a tf_point_nav_interface to update the .nav file whenever if the door have opened (unblocked) or closed (blocked), saying whenever if robots can pass through or not.

So I've been working on a new update, where the whole layout was changed but the trains and logic still stays the same. However I've found a bug where if I've made robot's train arrived to the map, all of the navigation inside the door became unblocked even though the door is still closed, making robots think that the door is opened and can walk through.

Before the train arrived the navigation was blocked as intended

When the train arrived the navigation inside the door was unblocked even though the door is still closed

All of the other navigation in the door was also unblocked even though the train was not in this track

I've tested it out without tf_point_nav_interface in the map and the navigation in the door would still unblock it, and I've tried using the tf_point_nav_interface to update the navigation after it had unblock it but it still stays unblock.
I've also tested when there is a solid block inside the navigation, it still would unblock it.

Even though it may sounds confusing because of a unique feature but it would be helpful if you know anything about that, even clues or hints.

 

[LeSwordfish]

I'm not an expert on MVM nav, but i'll ping a couple of people who are: @Turbo Lover @Hyperion

 

[Hyperion]

Well, I'm MvM Expert only in the game, not navigation side

However, only thing I can suggest (that works in Hammer quite often) is to recreate the door and .nav hint from scratch

 

[UKCS-Alias]

What i would check is if the tf_point_nav_interface does refresh it. The RecomputeBlockers command on that entity would normaly refresh those paths. Its how the rottenburg blockade gets its nav opened.

And to note, just triggering it once might not always do it. Some doors are faster than others, so its recommended to make it refrehs a few times (for example 5x with a gap of 1 second). Making that constantly trigger or setting the delay below 1 second isnt recommended since that would become server heavy.

 

[FortyTwo]

so its recommended to make it refrehs a few times (for example 5x with a gap of 1 second).

I've tried that, triggering it after the train had arrived and it still unblock. However I've tried keep refreshing every 0.2 sec non stop and it did stays block, but that would likely cause a server lag.

Also more testing, I've replaced one of the door to just a solid block, and it said that this nav is unblock all of the time but robots think that it was blocked so they take the normal path.

What a amazing code valve have.

 

[henke37]

Doesn't rottenburg have a tunnel the tank takes? I've never had a chance to play on the map, but perhaps you should look at that?

 

[FortyTwo]

Doesn't rottenburg have a tunnel the tank takes? I've never had a chance to play on the map, but perhaps you should look at that?

Tank's tunnel is only for tunnel, not for robot's so the navigation is not needed in there

 

[ммα | ∂αиỉєℓ]

Have you tried using a trigger block on the door with nav_avoid on it that gets disabled when the train comes, just an idea?

 

[FortyTwo]

Have you tried using a trigger block on the door with nav_avoid on it that gets disabled when the train comes, just an idea?

I can easily do that but although I like the "blocked" better. If there is other option to fixed it then I'll have to do that then

 

[UKCS-Alias]

Try to block it off using a respawnroom visualizer (you can turn them on/off) and then use that nav trick.

 

[FortyTwo]

Try to block it off using a respawnroom visualizer (you can turn them on/off)

This might sounds a stupid question but how do I do that?

 

[Nuke]

This might sounds a stupid question but how do I do that?

I'm not a map expert (you know), but i'm sure if you rewatch how @Crash 's tutorial make respawn rooms, you might get info you need.

 

[UKCS-Alias]

in mvm it does go a bit further on that. but there are a few basics which make it work (which is why both mannhattan and rottenburg use them.

A visualizer is like a team based clip brush. So if you make a visualizer using just nodraw textures and then make it for the normal respawnroom of red it will prevent bots from taking that path. Even though its open. The nav file will consider the regions this brush touches as 'blocked'. And this will make the bots avoid taking that path.

To toggle the state you can just enable and disable the visualizer. But do keep in mind that when a bot walks on it he gets stuck. So you might want to avoid that to happen by either teleporting them outside of the blocked zone (will look less good) or you delay it until all bots are away (which you can try by using prefer and avoid zones - which in turn also can be toggled)

In the end its trial and error what works best for you.

 

[henke37]

I thought that bots outside of the navmesh will just default to running in a straight line towards their goal.

 

[FortyTwo]

So in more testing, If I keep refreshing the navigation up to a maximum of every 1.9 seconds then it would stays blocked, Although I don't know if every 1.9 seconds would be enough to make the server cause heavy load.

I'm not a map expert (you know), but i'm sure if you rewatch how @Crash 's tutorial make respawn rooms, you might get info you need.

I know the basics of the func_respawnroomvisualizer but the problem is slightly different

in mvm it does go a bit further on that. but there are a few basics which make it work (which is why both mannhattan and rottenburg use them.

A visualizer is like a team based clip brush. So if you make a visualizer using just nodraw textures and then make it for the normal respawnroom of red it will prevent bots from taking that path. Even though its open. The nav file will consider the regions this brush touches as 'blocked'. And this will make the bots avoid taking that path.

To toggle the state you can just enable and disable the visualizer. But do keep in mind that when a bot walks on it he gets stuck. So you might want to avoid that to happen by either teleporting them outside of the blocked zone (will look less good) or you delay it until all bots are away (which you can try by using prefer and avoid zones - which in turn also can be toggled)

In the end its trial and error what works best for you.

Testing it out on a func_respawnroomvisualizer with the "Associated Respawn Room" is set to the same as the red's spawnroom, and robots is still attempting to walk through even though it always enabled. I don't know if showing you the vmf, bsp, nav and pop would help find the problem

 

[UKCS-Alias]

That way it sounds more like your door isnt blocking the path perfectly. And this can be multiple reasons:

Something is wrong with the brushwork allowing small gaps to exist. If everything is ongrid this is most unlikely, but if everything is grid 1 then its likely to happen. It would explain why they still try to walk though.

Did you set the door to start 'open'? If so close the door, by default and make it automaticly open on round start. Maybe it does take something for doors into the compile that records the blocking state and generating the nav would make it think to remain open?

Nav squares are too large for the door itself making it not trigger the blocked state (again unlikely because even 1% of touching the square should already mark it blocked). And its very likely that its related to this since it shows when its properly working by showing the blocked state of the nav (ie. the square itself turns blue). Try to set a larger nav_avoid section at this area. Or try to use nav_split to reduce the nav square size.

The bots cant find any alternative path using the nav, and they see this path as the only valid option (this overrules even blocked nodes). But this one is unlikely. Often can happen on steep hills and staircases that it wont generate a correct path.

You must have the nav refreshing entity work. For mvm this is the only way to update the nav. And if you have done this there are a few extra questions to ask:
What is the thickness of the door (for my maps all doors are at least 16HU wide)? What other attributes are set to it (maybe they think they can open the door)? How do the triggers look that activate the door and nav refresh (maybe its a timing issue)?

 

[FortyTwo]

Something is wrong with the brushwork allowing small gaps to exist. If everything is ongrid this is most unlikely, but if everything is grid 1 then its likely to happen. It would explain why they still try to walk though.

I've set the lock grid to off and make the whole navigation to be inside the door and that didn't work.

Did you set the door to start 'open'? If so close the door, by default and make it automaticly open on round start. Maybe it does take something for doors into the compile that records the blocking state and generating the nav would make it think to remain open?

The door was started closed. I've tried to make many different combination to make either the door to start open or closed, when to open or closed and none of them work.

Nav squares are too large for the door itself making it not trigger the blocked state (again unlikely because even 1% of touching the square should already mark it blocked). And its very likely that its related to this since it shows when its properly working by showing the blocked state of the nav (ie. the square itself turns blue). Try to set a larger nav_avoid section at this area. Or try to use nav_split to reduce the nav square size.

Similar to the first one. I've tried splitting it to many 1x1 squares and that didn't work. there also isn't any func_avoid inside the door.

The bots cant find any alternative path using the nav, and they see this path as the only valid option (this overrules even blocked nodes). But this one is unlikely. Often can happen on steep hills and staircases that it wont generate a correct path.

There is a clear path that robots can take without taking the door shortcut.

You must have the nav refreshing entity work. For mvm this is the only way to update the nav.

I've said that I've tested it out without having the tf_point_nav_interface in the map at all and it still would update it

What is the thickness of the door (for my maps all doors are at least 16HU wide)?

the func_door_rotating is 8HU. I've tested it out at 16HU and it didn't work

What other attributes are set to it (maybe they think they can open the door)?

List of func_door_rotating given value:-
-Name
-Render Mode: Don't Render
-Speed: 300
-Delay Before Reset (-1 stay): -1
-Origin (X Y Z)
-Distance: 90/-90 (one for each func_door_rotating)

How do the triggers look that activate the door and nav refresh (maybe its a timing issue)?

I've checked the input/output when spawning the train and it look like that it shouldn't change the door or update the nav at all

If there is no other way then I'll have to stop using the "blocking nav" method and just use the func_avoid to do it.

 

[FortyTwo]

So I've replaced the blocking method to the nav_avoid. I should've done that earlier since that I've spent over 3 weeks trying to fix this.

and now I need to fix another bug that appear about a week ago