What can bots walk on?

[I Darkstar X]

Hear me out, hear me out.

I have no friends (or enemies) to test (to suffer in) my terrible (-ly confusing) maps, so I use bots, and strive to make my maps as bot-friendly as possible.

However, I've encountered a wee bit of a snag.

I like moving parts in my maps. I like having whole walkways burst out of the ground or bridges over gaps open and close periodically. But my poor bots often times cannot make heads nor tails of surfaces. For example, they will often slam themselves into a corner next to an open door, or throw themselves off a cliff because the bridge has moved, instead of taking an alternate route which exists certainly.

I have determined that the cause for some of the issues resides in that some brushes that aren't func_detail are intangible. I used nav_edit and found the cursor passed through the func_brush I was using.

So my question today is what nameable, disableable, etc., brushes can bots "see". Some tips on making maps with moving parts more bot-friendly would also be appreciated.

 

[DrSquishy]

As the map's nav mesh is generated for one given time, usually at the start of the map, anything new that'll pop up won't have a nav mesh connected to the rest of the map on it. This will also mean if something moves or disappears, they'll continue to use the old nav mesh to navigate, hence jumping off cliffs and such where a bridge used to be

 

[I Darkstar X]

As the map's nav mesh is generated for one given time, usually at the start of the map, anything new that'll pop up won't have a nav mesh connected to the rest of the map on it. This will also mean if something moves or disappears, they'll continue to use the old nav mesh to navigate, hence jumping off cliffs and such where a bridge used to be

But don't nav blocks have an "enabled" and "disabled" state? (dark blue smaller square within it.) Is there a way to make it actually register with bots who ignore its current state anyway. (Such as smashing their bodies against one-way doors.)

 

[nᵗʰSonata]

Why don't you get your maps tested on the TF2Maps.net servers? There's not really much reason to design for bots outside of gamemodes using them (like MVM) since you can easily test with humans using the link I posted above, especially considering that humans are *much* better than bots.
(Also, after looking at the VDC page for nav commands, it seems to me like what you're trying to accomplish isn't possible with Source's implementation of navigation)

 

[I Darkstar X]

Why don't you get your maps tested on the TF2Maps.net servers? There's not really much reason to design for bots outside of gamemodes using them (like MVM) since you can easily test with humans using the link I posted above, especially considering that humans are *much* better than bots.
(Also, after looking at the VDC page for nav commands, it seems to me like what you're trying to accomplish isn't possible with Source's implementation of navigation)

But I can't directly view the testing, and retesting changes I make would take far too long.

(And I was afraid of that. Oh well, I guess I'll just have to compromise and make them less dynamic. Or fool the bots.)

 

[BigfootBeto]

I will be assuming you don't know much about nav meshes just because there are a bunch of useful things for optimizing a mesh.


You can make a manual nav mesh in order to have nav tiles floating in mid air. To disable these nav tiles when the bridge is inactive, you can use a func_nav_avoid. These brushes can be enabled/disabled with hammer I/O to correspond to when the bridge is open or closed.

Another way to create mid-air nav tiles without creating them manually is to compile a version of the map where the bridges are static world geometry (func_detail also works). Then doing nav_generate and it should make nav tiles on the bridges. Then you can use that nav mesh for the map where the bridges function properly. You can reuse nav meshes from previous map versions by simply renaming the .nav file to the same name as the map (.bsp).


For the problem of bots seemingly misunderstanding one-way doors, you will need one-way connections on the mesh.

Also there is a tf_point_nav_interface that with the input RecomputeBlockers, will do just that and update the nav mesh where doors are blocking a path or not. However, there is a caveat in that the update has a bit of delay and isn't very reliable for doors that are only open for a short time. These are used in mvm_rottenburg when the tank destroys the wooden barrier at the botspawn, allowing bots to take the new shortcut created. Pro tip: func_door is a solid that blocks nav tiles. func_movelinear is a solid that does not block nav tiles.


nav_mark_walkable - places a marker in the map for where to start sampling space for a new nav mesh.

nav_generate_incremental - does not erase the current nav, and adds to it instead starting by sampling around any nav_mark_walkable spots (sometimes it only does one at a time, in which case you will have to redo a few areas)

nav_analyze - this is necessary in order to saves the nav mesh after any manual changes.

nav_snap_to_grid 1 - self explanatory. Useful when drawing new tiles.

nav_begin_area - starts drawing a new nav tile from the cursor.
nav_end_area - completes drawing a new nav tile.

nav_add_to_selected_set - self explanatory.
nav_remove_from_selected_set - self explanatory.
nav_flood_select - Useful for deleting a bunch of tiles after disconnecting them from the rest of the nav mesh.
nav_clear_selected_set - useful for after nav_generate_incremented because the new tiles are automatically put in your selected set.

nav_connect - select 2 tiles at once to create a 2-way connection (light blue line). select only one tile, then hover the cursor over the 2nd tile to create a 1-way connection (for dropdowns) (dark blue line).
nav_disconnect - useful for removing bad connections that were automatically generated.

nav_split - cuts a nav tile in half along the line shown by the cursor. Useful when a large tile that was generated intersects the ground and you want to fix it.

nav_corner_place_on_ground - with the selected tiles, it will grab the corners and place them above the ground if they are underground.


The link was already posted for a complete list of commands, but here it is again:
https://developer.valvesoftware.com/wiki/Navigation_Mesh_Commands

 

[BigfootBeto]

But I can't directly view the testing, and retesting changes I make would take far too long.

Watching demo files (.dem) is a direct way to rewatch tests since you can fly around as a spectator in a replay of the game. The other way would be to attend the imps and be present during your map test. Yes, retesting changes can take longer, but that is part of the mapping process. Bots are decent at testing map logic and making sure everything works, but human players are best for testing how the map actually plays in a real gameplay environment.

 

[I Darkstar X]

You can make a manual nav mesh in order to have nav tiles floating in mid air. To disable these nav tiles when the bridge is inactive, you can use a func_nav_avoid. These brushes can be enabled/disabled with hammer I/O to correspond to when the bridge is open or closed.

Another way to create mid-air nav tiles without creating them manually is to compile a version of the map where the bridges are static world geometry (func_detail also works). Then doing nav_generate and it should make nav tiles on the bridges. Then you can use that nav mesh for the map where the bridges function properly. You can reuse nav meshes from previous map versions by simply renaming the .nav file to the same name as the map (.bsp).


For the problem of bots seemingly misunderstanding one-way doors, you will need one-way connections on the mesh.

Also there is a tf_point_nav_interface that with the input RecomputeBlockers, will do just that and update the nav mesh where doors are blocking a path or not. However, there is a caveat in that the update has a bit of delay and isn't very reliable for doors that are only open for a short time. These are used in mvm_rottenburg when the tank destroys the wooden barrier at the botspawn, allowing bots to take the new shortcut created. Pro tip: func_door is a solid that blocks nav tiles. func_movelinear is a solid that does not block nav tiles.

func_nav_avoid and tf_point_nav_interface. Got it! thank you so much for this. ^vv^
​

Watching demo files (.dem) is a direct way to rewatch tests since you can fly around as a spectator in a replay of the game. The other way would be to attend the imps and be present during your map test. Yes, retesting changes can take longer, but that is part of the mapping process. Bots are decent at testing map logic and making sure everything works, but human players are best for testing how the map actually plays in a real gameplay environment.

You make a fair point. Very well, I'll try this out, but I'll need to check how to obtain and watch these .dem files.

 

[BigfootBeto]

Oh yeah, one more thing I forgot to mention. A nav tile will only be considered "blocked" if the entire tile is covered. So if you find that func_nav_avoid or func_nav_prefer not working, it may be because the nav tile isn't covered correctly. This can be solved by either using a larger brush, or using nav_split to make the tile(s) smaller.

 

[I Darkstar X]

Oh yeah, one more thing I forgot to mention. A nav tile will only be considered "blocked" if the entire tile is covered. So if you find that func_nav_avoid or func_nav_prefer not working, it may be because the nav tile isn't covered correctly. This can be solved by either using a larger brush, or using nav_split to make the tile(s) smaller.

Roger that ^^ Thanks again

 

[nesman]

You make a fair point. Very well, I'll try this out, but I'll need to check how to obtain and watch these .dem files.

right now the demos site isnt in the most of working order iirc and you have to request it in a thread https://tf2maps.net/threads/demo-request-thread.38090/ as of right now. However viewing feedback giving on your map is viewed from https://feedback.tf2maps.net/

 

[DrSquishy]

right now the demos site isnt in the most of working order iirc and you have to request it in a thread https://tf2maps.net/threads/demo-request-thread.38090/ as of right now. However viewing feedback giving on your map is viewed from https://feedback.tf2maps.net/

Demos are back and recording right now

 

[I Darkstar X]

Demos are back and recording right now

Where would I find those?

 

[nesman]

Where would I find those?

https://feedback.tf2maps.net/ then select your map if you have submitted it and its been tested. On your map page it should say "View Demos" in the topish center area.