Can bots walk on props?

kufte

L1: Registered
Jan 31, 2016
13
0
I have a stupid idea for a map, but for it to work the bots will need to walk on metal sheets and pillars from Egypt. Will the navigation mesh allow it?
 

Hipster_Duck

L2: Junior Member
Dec 20, 2015
99
71
I'm not familier with nav meshes but if they can't walk on the props you could always make the areas they need to walk on out of invisible clip brushes.
 

Startacker!

WANT ME TO BE REAL? MAKE ME.
aa
Jun 15, 2013
647
1,197
Yea, the navigation mesh will allow it. For best results, type nav_edit 1 and use nav_mark_walkable on your props to mark them as walkable. Once you think you've marked enough, type nav_generate_incremental (A standard nav_generate should work, I just use incremental for some reason). If it all looks good, finish it up with a nav_analyze.
 

Da Spud Lord

Occasionally I make maps
aa
Mar 23, 2017
1,339
994
Yes, bots can walk on props as long as it is marked in the navigation mesh. If it's a thin prop like a log, it may not generate an area on the prop automatically, and you'll need to add it manually. The Valve wiki page listed above should explain how to add it manually. I recommend marking those parts of the mesh with "nav_precise" (aim at the area and use that command, areas marked with nav_precise have a green plus in them), and bots will be more careful when walking across that area.
 

Hyperion

L16: Grid Member
aa
Jun 8, 2015
840
659

Da Spud Lord

Occasionally I make maps
aa
Mar 23, 2017
1,339
994
For future, I don't ever recommend manually building nav. It is way too complicated and takes mote time than it is worth to. Invisible clips and nav_walkables are the way to go
Manually building a navmesh from scratch isn't worth it, but editing a generated mesh to add areas that the mesh won't automatically generate on is worth it, especially if nav_mark_walkable and nav_generate_incremental won't generate a mesh on top of it (which is common on thin bridges, like the log near the first point of Swiftwater).
 

UKCS-Alias

Mann vs Machine... or... Mapper vs Meta?
aa
Sep 8, 2008
1,264
816
Do note that for an mvm map its best to clip nearly everything a bot should be able to walk on or walks next to. Bots can have diffirent sizes and sometimes this might mess up with their behaviour. Dont blindly rely on the prop creating a correct nav. Large props are usualy not a problem, but a smaller fence often is. The nav needs to have smooth connections for the bot to be able to succesfully walk on it.
Even when having a wider prop, as soon as they have to walk a slight edge upward, clip that edge so its smooth.
For future, I don't ever recommend manually building nav.
The only time to ever edit the nav would be to split nav sections. This due to the behaviour of avoids, prefers and prerequisites in mvm.
 

Da Spud Lord

Occasionally I make maps
aa
Mar 23, 2017
1,339
994
The only time to ever edit the nav would be to split nav sections.
There are other situations too. The automatic mesh generation process is far from perfect, from generating a mesh at the bottom of a death pit to making connections through walls and rails. Whenever I generate a new navmesh, I usually like to run around the map with nav_edit 1 to check for any problems in the mesh.
 

MOCOLONI

L6: Sharp Member
Dec 16, 2014
373
89
Yea, the navigation mesh will allow it. For best results, type nav_edit 1 and use nav_mark_walkable on your props to mark them as walkable. Once you think you've marked enough, type nav_generate_incremental (A standard nav_generate should work, I just use incremental for some reason). If it all looks good, finish it up with a nav_analyze.
More than "nav_generating" I think it's better to "nav_analyze". It keeps suggesting you to use it whenever you save non-minor changes to the .nav file, either an existing or new one.
 

UKCS-Alias

Mann vs Machine... or... Mapper vs Meta?
aa
Sep 8, 2008
1,264
816
The problem is mainly that the effort spent to fix the nav is often too much work compared to using some tricks in hammer to just force the engine to generate a correct one. There are often small tricks you can perform to change the way a nav is generated. Sometimes just putting a 8HU clip at the bottom of the staircase to get a slightly diffirent start angle can be unnoticed while playing, but already give the nav generation a diffirent behaviour.

Do note that you arent going to just compile your level once for testing, you should do it many times and fixing those bugs 50 times is realy a lot of effort for something you might solve permanently in 5 minutes spread acros 30 seconds between each test compile for visuals. And dont say 'ill just do it when making a release version', because that indicates you arent testing it enough, or are spending a massive time on it at a very late state.

The thing that im talking about is bots getting stuck behind a corner, things that can be rare anyway but can involve a lot of testing to fix. Trying to find a permanent solution of which you no longer have to care about is better. Hence solving these things in hammer can be far more efficient.

Sure, some things require nav editing in the end anyway (some maps just require it). But avoiding any editing work is more convenient anyway. And also are less prone to mistakes during editing.

Do note that skullcove had about 20 minutes worth of nav editing each time. Which in the end has resulted easily into over 10 hours! Its not a little time you save.
More than "nav_generating" I think it's better to "nav_analyze". It keeps suggesting you to use it whenever you save non-minor changes to the .nav file, either an existing or new one.
nav_analyze is normaly the last step of a nav_generate. Its what considers the vision within the map and where bots can stand at a safe location compared to an other square. It contains extra information which the game requries for a good AI. A few things to consider it analyzing is the fastest path between nodes at an X distance, wether a jump down area is actualy safe to jump down from (bots will avoid paths that make them take damage from trigger_hurt), extra hints about dangerous or safe areas (although mvm doesnt use this info), and probably even more info i cant even think about. These are things you cant do when editing the nav yet are vital. Thats why each edit requires this.