Talk:Nav Mesh

ZBOT WITH ALL NAV COMMANDS?

It would be great if someone could write here a Link to DOWNLOAD de ZBOT with FULL commands for Nav Editing. The one I have, doesn't have all the commands, and for example the one of nav_corner is not available and I really need it to add some interesting jumps.

---

Mike, I notice there are alot of commands, I'm assuming you have special binds? If you do, can you share them? -- ^Ben

---

This is a good source: http://www.turtlerockstudios.com/forums/csbot/viewtopic.php?t=725 -- Mark WiseCarver

This is starting to get a little big, how about making it a category with sub-articles? --TomEdwards 15:05, 30 Jun 2005 (PDT)

Agreed. How do I do that? -Mike

Go to category:Whatever and hit edit to add a description. Then add [[Category:Whatever]] to every article you split this page into and they will be added to it automagically. --TomEdwards 23:47, 30 Jun 2005 (PDT)

I would prefer to have it on one page. This is a task you would do all at once, so it's nice to have it all together. One window for this and the other for the game, since there's so much to remember, I think it's easier to have in one window. Perhaps we can reorganize is some so it is more intuitive, and also make it more concise. --Mungo

I take some of that back. I think the console commands section and the place names section could be their own articles, but I still would like the instructional part to stay together here. It doesn't really need its own category though, for just a couple of articles. -Mungo

I separated out the console commands into their own article so this page isn't so long. Hope no one minds. -mungo

Adding place names to your map

I've seen a lot mentioned about how to add place names using the in game navigation tool, but no mention on how to create a list of place names that you are able to use. Can this be done through Hammer? Thanks. --Evshell18 02:05, 24 Sep 2005 (PDT)

Nevermind, I didn't realize that you couldn't put your own custom place names in, and that you just have to call nav_place_use to see what names are available. --Evshell18 02:11, 26 Sep 2005 (PDT)

Left 4 Dead Meshes

I feel tempted to create a page relating to how Left 4 Dead meshes work in relation to marking; for instance marking an area "obscure" increases the amount of infected in that area, as well as spawning infected there rather crudely. On the flip side marking an area "empty" results in no infected spawning there. Would it be appropriate to add this information to this article (as there really isn't THAT much info, and the rest doesn't differ from the CSS mesh much) or create a new one? ~ Alfonzo 15 March 2009

Writing/Modifying AI to use Nav mesh

Has anyone ever done this? The nav mesh stuff is included in the sdk, and is the default system in an sdk template mod, but the default bots are only designed to run and pic random directions. Has anyone written / found ai navigation code for this method? --Welsh Mullet 22:11, 17 March 2011 (UTC)

Don't the CSS bots use the navigation mesh? Thelonesoldier 22:43, 17 March 2011 (UTC)

Yep, but the CSS bot code is closed source and basically the only thing not included in the SDK. As far as i know. I was wondering if someone had written plug-in bots for CSS or L4D as these both use meshs --Welsh Mullet 13:58, 18 March 2011 (UTC)

Team Fortress 2 Nav meshes

Expand

There's no TF2-specific information here regarding to nav meshes. I'll share what I know:

• Use tf_show_mesh_decoration to show nav attributes. tf_show_mesh_decoration_manual will show manually placed nav attributes.

• NAV_AVOID and NAV_STOP only work in the Counter-Strike series; they're never used in TF2.

• Use tf_mark to add TF2 specific attributes.

• I don't know how to mark an attribute with RED_ONE_WAY_DOOR or BLUE_ONE_WAY_DOOR. I tried using tf_mark but it didn't apply. I guess it's automatically generated by the game.

• You can make bots airstrafe to a spot by adding a nav mesh to the edge of the corner.

Attribute Information

Expand

• BLOCKED_UNTIL_POINT_CAPTURE blocks the point until the specified point is captured.
• BLOCKED_AFTER_POINT_CAPTURE blocks the point after the specified point is captured.
• WITH_FIRST_POINT to WITH_FIFTH_POINT specifies the point for the former two attributes.

Note:On payload maps the payload is considered to be the first point.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not true! The payload is not counted as a capture point, so WITH_FIRST_POINT will still refer to the proper first capture point.

• SNIPER_SPOT and SENTRY_SPOT don't do anything as they only work in the scrapped raid gamemode. (Confirmed through looking in the Jungle Inferno leak and through observation in gameplay.)

(The following 2 attributes are meant to be used with doors.)

• DOOR_ALWAYS_BLOCKS makes the nav area blocked when the door closes.
• DOOR_NEVER_BLOCKS prevents the nav area from being blocked.

• UNBLOCKABLE prevents the nav area from being blocked.

Someone make a page for TF2 nav meshes. Amicdict (talk) 13:31, 2 July 2021 (PDT)

Sounds good, but before I add it to my sorts large to-do list, I gotta figure out a suitable page to put a link of the page after its done.

Also, if you don't mind, can you see ifDONT_HIDEandPRECISEserves any purpose for TFBots? Orin (talk) 13:54, 2 July 2021 (PDT)

Yeah sure. I'll report back what I can find. Amicdict (talk) 21:00, 2 July 2021 (PDT)

Ok yeah they both work in game as expected. Amicdict (talk) 21:02, 2 July 2021 (PDT)

Just to be sure.... What would (roughly) be the reactions of TFBots if they walk into a navigation area with thePRECISEattribute, and do TFBots use designated "hiding spot markers" (purple lines) at all?

Asking because both of these attributes have varying effects in all games I think, like thePRECISEattribute. In has no effect, but in it strips bots the ability to path with random variance? (not sure what it does in )

Similar case for theDONT_HIDEattribute too iirc; Bots in actually care for "hiding spot markers", but in none of the bots really make use of it. Orinuse (talk) 23:24 2 July 2021 (PDT)

Based off the Inferno leak, bot snipers use designated hiding spots as good sniping spots. I'm pretty sure PRECISE works as expected (as in it prevents "natural" variations in the movement), but I can't figure how to mark a designated hiding spot. Might just turn out that you need at least one free corner that has no connections, but I'm not sure on that.

A hiding spot is marked as an "ideal sniper spot" if the nav area of the hiding spot is larger than 200hu², or the farthest range area is larger than 1500hu². Otherwise it gets marked as a "good hiding spot" which aren't prioritized as much. Amicdict (talk) 12:23, 3 July 2021 (PDT)

Addendum: tf_show_mesh_decoration_manual when set to 1, won't show nav areas with RED_ONE_WAY_DOOR, BLUE_ONE_WAY_DOOR, TF_NAV_HAS_AMMO, TF_NAV_HAS_HEALTH, and TF_NAV_CONTROL_POINT, regardless of the value of tf_show_mesh_decoration. Also RED_ONE_WAY_DOOR and BLUE_ONE_WAY_DOOR seem to just only allow players on their respective team to go through.

Turns out that TF2 only recognizes sniper/sentry spots through func_tfbot_hint; Hiding spots seem to only be used by spies. Amicdict (talk) 19:55, 6 July 2021 (PDT)

If you have any more addendums, put them here, as while the page will take some time before its made, I'm still planning about the layout of the page. Oh yeah, late but about the thePRECISEattribute, you use themarkcommand. I'm not entirely sure what its for though, but someone I lnew figured out it disables some kind of "obstacle avoidance" AI. More details at the page for the list on navigation area attributes. (Can't link it now, I have something to attend to) -Orin (talk) 08:11, 7 July 2021 (PDT)

Ok thanks. Also tf_show_gate_defense_areas and tf_show_point_defense_areas don't seem to do anything based off the code leak. - Amicdict (talk) 20:15, 9 July 2021 (PDT)

Page 2:

Expand

Correction: DOOR_NEVER_BLOCKS prevents the area from being blocked if the door its in closes. - Amicdict (talk) 19:26, 12 July 2021 (PDT)

Also it turns out that the payload is not counted as the first point. Amicdict (talk) 19:50, 12 July 2021 (PDT)

Amicdict, by any chance do you already know how does the game determine which point is a "first" or "second"? I'm making a draft of a page and this just hit my mind. Is it the "incursion flow" thing? - Orin (talk) 09:12, 24 July 2021 (PDT)

I'm uncertain on how the game does this, as I haven't reviewed this mechanic in the Jungle Inferno leak yet. However I think it just uses the required previous point inputs. - Amicdict (talk) 19:30, 24 July 2021 (PDT)

Sniper Spot Confusion

Expand

I'm confused on what is recognized as a sniper spot by TF2. From what I got in the Jungle Inferno leak, sniper bots are supposed to position themselves near func_tfbot_hints, but from my observations in-game, it feels like Snipers are using hiding spots (the purple and green lines that generate at corners) as sniper spots (I'm unable to confirm this). It's possible that I might be misinterpreting the code, but it's also possible that Valve changed Sniper bots to use hiding spots instead of func_tfbot_hints as sniper spots. I'm probably going to need reverse engineering to figure this out, if it ever comes to that. - Amicdict (talk) 23:47, 13 July 2021 (PDT)

Of course it's also possible that Sniper bots use hiding spots as fallback sniper spots in the event that func_tfbot_hints are missing. I can't really know. Amicdict (talk) 23:50, 13 July 2021 (PDT)

PvP Snipers use something called "theater" areas I believe, not sure what exactly theater areas are. I'm surefunc_tfbot_hintis actually used, but they just don't always stick to it. MvM snipers definitely need them.

Oh yeah, if you seetf_mark SNIPER_SPOTorbot_hint_sniper_spotentity, ignore them as they're mostly currently-irrelevant leftovers.- Orin (talk) 03:24, 22 July 2021 (PDT)

Yeah I had a feeling the game automatically set Sniper Spots after looking through the Jungle Inferno leak. What a shame though; they could should have just reused `SNIPER_SPOT` and then wouldn't have had to do all that mess. - Amicdict (talk) 18:35, 22 July 2021 (PDT)

Its a leftover from the infamous unused Raid mode I believe. In current MvM, there's still a way to make bots spawn only at nav areas with `SNIPER_SPOT`, and it works just fine I think. - Orin (talk) 08:48, 23 July 2021 (PDT)

The game just uses SNIPER_SPOT to highlight func_tfbot_hints on the nav mesh; SNIPER_SPOT itself does not do anything. - Amicdict (talk) 19:58, 23 July 2021 (PDT)

Alright, confirms what I was thinking then. I probably should reinstall TF2 at some point to mess with these things again. - Orin (talk) 20:09, 23 July 2021 (PDT)

You should also probably get your hands on the Jungle Inferno source code leak too, so that it'll be easier to understand how bots work. - Amicdict (talk) 19:35, 24 July 2021 (PDT)

TF attributes override each other's blocked statuses.

Expand

I just found out that the blocked statuses from TF2 nav attributes override each other and the block status from the Source Engine nav attributes. Here is the priority:

1. TF_NAV_UNBLOCKABLE
2. TF_NAV_BLOCKED (and by proxy BLOCKED_UNTIL_POINT_CAPTURE and BLOCKED_AFTER_POINT_CAPTURE).
3. TF_NAV_BLUE_ONE_WAY_DOOR (TF_NAV_RED_ONE_WAY_DOOR will be processed if TF_NAV_BLUE_ONE_WAY_DOOR doesn't consider itself as blocked.)
4. TF_NAV_RED_ONE_WAY_DOOR(NAV_MESH_NAV_BLOCKER will be processed if TF_NAV_RED_ONE_WAY_DOOR doesn't consider itself as blocked.)
5. NAV_MESH_NAV_BLOCKER (from func_nav_blocker).
6. The internal blocked status made by the Source Engine itself.

For instance to actually have an area that is RED-only and blocked until 3rd point is captured, you would want to stack two nav areas. The first area would have BLOCKED_UNTIL_POINT_CAPTURE and TF_NAV_WITH_THIRD_POINT, and the second nav area would have TF_NAV_RED_ONE_WAY_DOOR. This way the game will properly process both attributes and will have the desired result.

Trying to stack the three attributes onto one area would just result in the area being unblocked for both teams after the 3rd point is captured.- Amicdict (talk) 19:33, 18 July 2021 (PDT)

tf_show_X cvars

Expand

• tf_show_actor_potential_visibility - Shows areas potentially visible to a demographic (Purple for both teams, red for RED team, and blue for BLU team).
• tf_show_bomb_drop_areas - Shows areas where BLU bots can get to and can drop the bomb.
• tf_show_blocked_areas - Shows areas blocked by a demographic (Purple for both teams, red for RED team, blue for BLU team).
• tf_show_control_points - Show areas that a control point (not payload) is on in yellow, and adjacent areas in dark yellow.
• tf_show_in_combat_areas - Shows areas that are in combat from dark red to red depending on the amount of combat.
• tf_show_enemy_invasion_areas - Shows the areas that the enemy team will invade.
• tf_show_incursion_flow - Shows paths (as vectors within tf_show_incursion_flow_range) a team takes to get to the capturable point (1 shows RED team paths, 2 shows BLU team paths).
• tf_show_sentry_danger - how sentry danger areas (colored red for RED sentries and blue for BLU sentries). 1:Use m_sentryAreas. 2:Check all nav areas.
• tf_show_sniper_spots - Shows (purple for both teams, red for RED team, and blue for BLUE team) areas that aren't within tf_show_sniper_areas_safety_range units of the enemy invasion area.
• tf_show_sniper_areas_safety_range - The range in which sniper spots withinin the invasion areas are not shown through tf_show_sniper_spots.
• tf_show_train_path - Shows the train track path for the payload cart.

If anyone is working on one, how's the progress on the TF2 nav mesh page? - Amicdict (talk) 21:19, 18 July 2021 (PDT)

I haven't allocated time to start writing a real page yet, sorry. Starting with the List of TF2 Navigation Mesh Attributes would be easier to follow up with other related pages I believe.

• tf_show_incursion_flow_gradient - Shows the path a team takes to get to the capture-able point as gradient colors (1 shows RED team paths in red, 2 shows BLU team paths in blue).
• tf_show_incursion_flow_range - The range in which incursion flow vectors are visible
• tf_show_incursion_range - Highlight areas with incursion distances between tf_show_incursion_range_min and tf_show_incursion_range_max cvar values
• tf_show_incursion_range_min - Minimum range to show incursion distances within with tf_show_incursion_range.
• tf_show_incursion_range_max - Maximum range to show incursion distances within with tf_show_incursion_range.

These are the additional cvars I missed. - Amicdict (talk) 22:00, 18 July 2021 (PDT)

Correction for tf_show_blocked_areas: Areas colored bright red, not purple, represent areas blocked for all teams. - Amicdict (talk) 01:21, 22 July 2021 (PDT)

For tf_show_blocked_areas areas colored purple represent areas blocked for all teams. I just got confused on the bright red for some reason. The text that appears upon hovering over a nav area will also show text displaying what that nav area is blocked for. - Amicdict (talk) 03:52, 24 July 2021 (PDT)

Working on a guide for TF2 nav mesh development.

I'm working on a guide for making TF2 nav meshes. Linked here. - Amicdict (talk) 18:28, 17 August 2021 (PDT)

That list on TFAttributes(?) overriding each other will be really really reaaalllyy useful - Orin (talk) 14:24, 18 August 2021 (PDT)

Should the page's contents be split/moved?

Just a passing thought; Currently the page goes into a bit of technical details about nav meshes, then guides the reader on how to edit a navigation mesh, and it seems like the page ends up having a conflicted focus. So, should that latter part of the page be mostly moved into its own page? I say mostly, since I think it'd be ideal to keep the nav editing section, but as something like how this page does it. - Orin (talk) 10:12, 19 August 2021 (PDT)

I thought about your idea, but I don't think the topics of the page (technical details vs. editing) are conflicting enough to make a separate page. I mean, the page says "There are .nav files and this is how you can generate them / edit them / set place names / achieve certain effects / and this funky stuff might also be important". I think the topic Nav Meshes fits on one page. Which sections would you propose should be moved? --Popcorn (talk) 17:06, 19 August 2021 (PDT)

Something like the names for the2.3, 2.6, 2.7, 2.8, 2.9, 2.10, 4.1-4.4, 5.2, 5.4, 5.5sections, might change in the future. To me it looked like they went really thorough on the editing a navigation mesh, and I'm feeling it overshadows other topics possible to be added here (or already is), like the NAV File Format and this section about NAV subversions. Myself I think navigation mesh editing fits here still, but currently this page really looks more like a "Navigation Mesh Editing" page, and future editors might make that gap even larger. - Orin (talk) 20:04, 19 August 2021 (PDT)

Ah ok. What would you think of this page being the "top" page leading "down" to subpages, such as nav format, nav editing (the content of this page), nav commands/ConVars and whatever? --Popcorn (talk) 07:02, 20 August 2021 (PDT)

Better idea: What about the Category: Navigation Meshes? --Popcorn (talk) 07:14, 20 August 2021 (PDT)

To #1: For now, a (quickly thought out) concept: Navigation Mesh explanation -> Intro to what is contained in a NAV file -> Intro to navigation mesh editing, then lastly the resources like nav convars. This is just based on what's already existing in the page (that isn't just a "footnote" like the See also section). Just a concept so something might improvise this in tje future. - Orin (talk) 13:27, 20 August 2021 (PDT)

To #2: That category apparently doesn't exist and I didn't knew, will come in handy for sure, but seems more suiting to keep pages in it that aren't desirable to be here. For context, I'm treating this page (Navigation Meshes) as a "hub" that gives an intro to all relevant navigation mesh topics out there, while the category page helps to catch the not-so-important topics. (Category page has more roles but that's one of it in my eyes). - Orin (talk) 13:27, 20 August 2021 (PDT)

I see, so we want a "hub". If I get you right, we'd have two ideas we could implement:
1. Treat this page (Navigation Meshes) as a "hub" (Main article: Link) and create the page Navigation Mesh Editing or Navigation Mesh Editor to move this page's sections (except 6.1 SubVersions) down there.
2. Treat Category: Navigation Meshes as a "hub" and write the intros there. I thought of something like the Category: Level Design.
I'd prefer 2. to give the Categories more sense but 1. is also plausible as some pages already do it that way. --Popcorn (talk) 04:55, 21 August 2021 (PDT)

If you prefer "2." then I guess you probably already have a good idea for that approach? But if we go with that, what about this page, does it get a redirect to the category? (assuming the page still gets its contents migrated elsewhere) - Orin (talk) 10:24, 21 August 2021 (PDT)

The Category: Navigation Meshes cannot be created by us, so I guess it's gonna be "1.". Which title would you prefer? Navigation Mesh Editing or Navigation Mesh Editor or ...? --Popcorn (talk) 07:49, 23 August 2021 (PDT)

Navigation Mesh Editing seems more fitting to me, there's an actual GUI-based nav editor in 's tools mode (but its broken) so the other title could be misleading. And about that page creation title ban, I forgot I tried to circumvent it when this page was being newly edited. - Orin (talk) 09:15, 24 August 2021 (PDT)

Page 2: Ouf. Navigation Mesh Editing also can't be created for the exact same reason. Well then I guess it's gonna be Nav Mesh Editing, right? As usual, when linking to it, one could overwrite the title appropriately, such as [[Nav Mesh Editing|Navigation Mesh Editing]]. --Popcorn (talk) 06:59, 25 August 2021 (PDT)

That's a shame, and that title looks good to me! The search engine I use picks up that "Navigation Mesh Editing" title added with{{DISPLAYTITLE}}too. - Orin (talk) 10:37, 25 August 2021 (PDT)

Issues with page creation

Due to a banned expression, users are not allowed to create any pages with Navigation in their title and it seems that this problem is either not being solved or can't be solved by the admins.

Now, there are still two (outdated) language pages for this page. Would it make sense to move those to Nav Mesh Editing/es and Nav Mesh Editing:jp (and give the existing language pages a redirect)?
Also, to avoid any future issues with language pages of this page (Navigation Meshes), would it be an idea to move it to Nav Meshes? However, it doesn't seem necessary at the moment. Apparently, this page (Navigation Meshes) had been created before the banned expression thing was active. --Popcorn (talk) 12:01, 31 August 2021 (PDT)

I'd actually like to rename this page to Nav Mesh, since this article refers to the mesh in singular form. I do agree with the other rename options though. - Amicdict (talk) 13:25, 31 August 2021 (PDT)

And yes I'd like for this page to be renamed to prevent future language issues. - Amicdict (talk) 20:50, 1 September 2021 (PDT)

There also seems to be the same issue for the Navigation Mesh Commands pages. - Amicdict (talk) 20:54, 1 September 2021 (PDT)

Seeing as how the banned expression will not be unbanned anytime soon, there is really no harm in renaming the page. It's a good idea to rename the page either so that people can make translations with {{lang}}. - Amicdict (talk) 04:45, 9 September 2021 (PDT)

If there turns out to be problems, you can just undo the rename. I'll go ahead and rename the navigation meshes pages. - Amicdict (talk) 07:20, 9 September 2021 (PDT)

That's, great! I didn't even know about the move function. Thanks! --Popcorn (talk) 15:56, 9 September 2021 (PDT)

The issue has been resolved now. - Amicdict (talk) 20:53, 26 April 2023 (PDT)

The page Navigation mesh can be edited again it seems.

Should we rename this page back again? - Amicdict (talk) 20:10, 26 April 2023 (PDT)

Oh. Forgot about that. I got used to it by now. :D So I guess no, not necessarily, the short name works fine aswell. --popcorn (talk) 12:16, 5 February 2025 (PST)

TF2 - Payload Map Control Points

I've been editing a few navigation meshes in TF2, and I've been having trouble with the BLOCKED_UNTIL_POINT_CAPTURE attribute specifically on Payload maps. There are instances where I've marked zone(s) to be blocked/unblocked on the third point capture which are being blocked upon the cart reaching the first checkpoint.

The only reason I can think of is that when you use tf_show_mesh_decoration, only the most recent checkpoint that the cart has reached is marked as a control point (in green), whereas maps with standard control points always show every (currently active) control point in green. So I can only assume that any checkpoint capture triggers the BLOCKED_UNTIL/AFTER_POINT_CAPTURE status. I'm not sure how to deal with doors and such that aren't automatically assigned the correct blocked/unblocked status on Payload maps because of this. Rodafy (talk) 20:01, 4 February 2025 (PST)

Actually, I'm not sure if the WITH_X_POINT_CAPTURE attributes work as intended at all... I've tested a few areas on CP maps with different settings and they are always blocked/unblocked on the first point capture regardless of which point is listed. Am I just doing something wrong, or? Rodafy (talk) 06:00, 5 February 2025 (PST)