This guide is for making TFBots work with custom maps. What are TFBots, might one ask? Well, the wiki does a better job of explaining it then I do, so let me link the article from them:

Official TF2 Wiki on Bots
"AI bots are coded with sophisticated artificial intelligence designed to emulate player actions in game"

When you play offline practice, you are playing with the TFBots. The robots in MVM also are TFBots, but while this guide will cover making the correct navigation mesh to have them playable in a custom MVM map, it will not detail how to make a .pop file or the bots themselves.

A tip that's been passed around since the introduction of bots a long time ago is that typing into console sv_cheats 1; nav_generate will make the bots playable on any map. What this tip fails to cover is that this only does the ground work for making the bots playable by using a computer algorithm, and can leave many areas not covered or connected (for example, when cp_gorge wasn't officially in offline practice, inspired players who used this command would notice the bots would not leave BLU's forward spawn. This happened because the computer algorithm did not mark those areas as walkable, and so the bots just stood there! One would have to fine tune the navigation mesh to fix that). It can also make a lot of mistakes, such as saying that bots can travel through solid windows or try to jump up areas they can't reach.

By fine tuning the navigation mesh by hand, you can fix almost all of these problems. This guide will cover the more advanced, TF2 specific stuff that's not covered by the Valve Developer Community wiki, which you should definitely read first. Note, however, some things, like ladders, do not work in TF2, and that nav_jump markers have become obsolete.

Currently, the bots work nearly flawlessly on King of the Hill, Attack/Defense Control Point, and regular Payload game modes.

The robot forces will also work flawlessly on MVM maps, however TFBots on the RED team will not work well at all, as they must be teleported out of the spawn via a server command to have them be remotely playable, and they won't upgrade ever, so that's a lost cause for now.

Push Control Point maps work okay, however there are slight problems such as Engineers becoming stuck in spawn for no apparent reason on some maps.

Territorial Control works the same way as 5CP levels work, although they are much more of a pain to properly create a navigation mesh for due to the changing level geometry once a point is captured.

Circular Control Points, or 3CP, as well as any other weird game modes that have multiple points in play at once, make the Engineers act weird, in that they will constantly destroy and rebuild their machines until only one point is in play. Bots will also randomly stop in their tracks and go to the opposite point. It's still playable, though.

Payload Race, Special Delivery and Arena do not work. At all. Bots will not leave the spawn, except sometimes Sniper bots.

Capture the Flag works, albeit very basically. Bots will make a beeline for the intelligence and then make a beeline to the base to cap it. they will use the shortest route possible, will fire at enemies while walking right past them, Engineers will not build sentries, et cetera.

Medieval modes for game types that are compatible, such as Degroot Keep (attack/defend) or the custom map Morrigan Alley (payload) work, but in order to get the Medic, Sniper and Engy bots to stop acting weird the admin must enable "tf_bot_melee_only 1".

Bots will crash the game if they are used in custom server game modes that change their weapons, such as Randomizer. There is a server sourcemod plugin called Bot Weapon Randomzier[forums.alliedmods.net] that will give TFBots the various unlockable weapons, but sadly the plugin has not been updated in a while and currently gives massive server lag and other problems such as Spy bots building dispensers instead of sapping.

Bots do not work well with levels that have moving platforms, since the navigation meshes aren't updated fast enough and you can't parent a part of the mesh to a part of the level as it's a grid system. Elevators and train platforms are not usable and will cause weird bot behavior.

Bots also do not work well with levels with underwater portions. They frequently get stuck and drown. Try to make them not able to go into the water but able to get out in case they get pushed in.

I have not tried bots using custom modes like the Hidden, the Hunted, Zombie Fortress or VS Saxton Hale, but I assume that they would either not work since either they're based on Arena mode or in the Hunted's case they might just act like it's an attack/defend map. Any mode that gives custom classes will probably crash the server.

First, read the VDC guide on Navigation Meshes. I'm going to assume you've read it, and I will refer to it and note some changes that exist in TF2

• When you've already done nav_generate and you realise you've got spots on your map that don't have navigation paths but they should be there, use nav_mark_walkable THEN USE nav_generate_incremental. Don't bother with that quicksave stuff. Afterwards, you'll have a bunch of selected areas. Type nav_select_invalid_areas to clear the selection (if you end up having something selected after that then just delete it because it's an improper area).

• Don't use nav_jump. Just make a bi/unidirectional connection between the floor and the area the bot should jump to.

• Make sure there's a path underneath every ammo and health kit, even if they're not reachable, as bots will attempt to get to them. So, if there's a log hanging over a point that has a small health kit on it, if there's no path there the bots will run in circles underneath it, so make one.

• When you nav_generate a payload map, where the payload starts a path is made on top of the payload with nothing underneath. Delete that path and make one underneath the payload.

• Bots don't understand transparent walls, like fences or windows. For example, in Barnblitz if there's a sentry on the final point bots will attempt to shoot through the fence near the right as you enter the point trying to destroy the sentry but end up just shooting a wall.

• Try to avoid areas where bots will have to crouch. If there's a spot under a staircase, try to only have paths there where the bot can walk while standing up. Bots have trouble crouching, even if the area is marked to crouch, and might just try to go through the area while standing and then get stuck in place trying to enter.

• Don't do place names, that's only useful for CS:S

• Don't do this:

Do this:

(the second image shows a small square area hovering in midair over the gap with a bidirectional connection between the top area and a unidirectional connection to the bottom area)
Bots will need to have a path on top of a railing to jump over it, unlike how the wiki states that the path needs to be like the former and the bots will eventually jump over it. I mean, yeah, they'll eventually jump over it, but it's just dumb to see bots huddled against a rail for 30 seconds until they climb it.

• Since ladders don't work properly in TF2, some map will use tiny yet extremely tall invisible playerclip staircases in front of the ladder to give the illusion of one. The nav_generate won't pick these up, so you should create a path from the floor to the top of the ladder, connecting the path to the top floor where the ladder ends and the bottom floor where it begins.

• Use nav_precise if you want a bot to not fall off of a ledge, to walk on a super tiny path you made, to enter a doorway, etc.

• Nav_generate usually won't make paths on horizontal ladders going straight or diagonally. Nav_mark_walkable usually doesn't work either. You need to manually make the paths as tiny squares connecting to each other near their corners along the path if it's diagonal, or just a regular path if it's straight. Make sure to make it nav_precise, and split a square in front of the path with precise so the bots can line up with the path.

• Don't do this:

Do this:

Bots will try to drop through the floor if you do the former, and will end up walking in circles and jumping. When dropping from a ledge, a bot should continue walking while falling, so make the drop diagonal by making a unidirectional connection from the ledge to the floor a little bit in front of where the ledge ends. Make sure if a bot can't jump up to an area that the fall is unidirectional, as bots will attempt to jump if it's marked bidirectional. Nav_generate incorrectly makes areas bidirectional all the time so be wary.

• If a bot needs to drop through a hole, make sure he lands on a square path that's directly center to the hole and does not go under the ledge or the bots will circle around and jump like idiots. If a path goes both underneath and in front of a ledge the bot will attempt to drop through the closest area, which is directly underneath, so make sure to split areas that do that.

• If a bot suddenly stops dead in its tracks when it reaches a ledge, that's because the path it's on goes past the ledge into the air. Make sure the path doesn't do that by splitting it so it ends before the ledge ends, then have it drop via a (uni/bi)conditional direction.

• If this happens:

Then nav_split the parts so that when you do nav_corner_place_on_ground (without selecting the corners unless you're a masochist that wants to do each corner one by one) it will look like this:


• Delete areas that bots can't fit into, like those silver barricade props that have tiny gaps in the back where a square path is usually generated between the poles. Bots will attempt to hide there, and end up trying to fit into there for a while until they get killed or something grabs their attention.

• Delete stuff like this:

The bots will try to cut corners and end up lower on the staircase instead of crossing over. Try not to have bots try to jump up part of a staircase from the floor perpendicular to the staircase, just have them walk around and up instead.

• Delete areas bots will never, ever get to, like the bottom of a cliff or past the playable area where no player can get. Make sure there are paths to walk if a player can feasibly get there, since crafty wrangler Engies can build teleporters anywhere and if a bot teleports to an area with no navigation path then he'll be stuck on the teleport.

• I'm not entirely sure if you need to mark staircases or not with nav_mark_attribute STAIRS, but I do it out of habit.

TF_MARK is the command to mark certain areas of the navigation mesh to have some sort of logic, like "this door closes when point A is captured". This command is entirely new in TF2 and doesn't exist in other Source games, and there is no documentation on it, so I'm going off of experience (mostly trial and error). As far as I know, you can't tell what areas of the navigation mesh have TF_MARK commands done to them, so be careful when using them.

• Let's say you have a Badwater-esque Payload map. When you want to make something blocked until a point is captured, or blocked after one is captured, you need to use TF_MARK BLOCKED_(UNTIL or AFTER, don't include the parenthesis)_POINT_CAPTURE, then TF_MARK WITH_(FIRST, SECOND, THIRD, FOURTH, or FIFTH)_POINT. With payload, the first point doesn't exist. Rather, it's where the payload starts. So the first point you cap is actually the second, and so on and so forth.

• With 5CP, the first point on the left (RED's last point) is FIRST, and the point on the right (BLU's last point) is FIFTH, and in between is SECOND, THIRD (mid), FOURTH. At least, it usually is, it depends on how the map maker sets up the point logic.

• 3CP has A as FIRST, B as SECOND, and C as THIRD. Depending on how the mapmaker does the capture logic this may be off.

• Territorial Control is a tricky thing to make a navigation mesh for. If you have an area that's blocked when a different area is contested make sure that the area where it's blocked is marked with nav_transient If you play and it's not marked as blocked (with a dark blue perimeter inside the path) then make sure the path is 100% inside the blockage and either raise the path entirely with nav_corner_raise (make sure you don't use nav_corner_select or else you'll only raise one corner) or delete and remake the path.

• Regarding spawn rooms, don't use TF_MARK UNBLOCKABLE. Instead, use TF_MARK (RED or BLUE)_ONE_WAY_DOOR and TF_MARK DOOR_NEVER_BLOCKS. The area will still have the blocked blue perimeter inside the path, but the correct bots will travel through it and the enemy team won't try to enter it. Also, if the spawn's exit only, make sure the exit is unidirectional. Finally, make sure the path that connects the outside to the inside is underneath the door. If you just connect the outside to the inside with a uni/biconditional connection and there is no physical navigation mesh square underneath the door the bots won't know there's a door there.

• I don't know how to detect tf_mark SNIPER_SPOT or SENTRY_SPOT areas, I've always assumed that they're added on nav_generate but I could be wrong. I haven't had enough time to play around with them but most of the time the nav_generate command will put them in good areas. If you want to add a specific area for the snipers or enies to use, point at and/or mark an area and type the command in. Honestly, Valve has not been clear on these new navigation meshes for TF2 so I'm just going off of experience.

• Regarding setup gates, use TF_MARK BLUE(or red if it's like Well)_SETUP_GATE and TF_MARK DOOR_ALWAYS_BLOCKS). Snipers, Spies and Engies on the Blue team will try to pass through the door anyways, that's an AI problem and you can't do anything about that.

• Use TF_MARK DOOR_NEVER_BLOCKS on regular doors in your map. Meaning, the path underneath the door has this command.

• Use TF_MARK DOOR_ALWAYS_BLOCKS if it's a special door that opens when a point is capped then never closes (unless another point is capped or something)

• I don't think there's a way to check what TF_MARK commands you've done on a certain area, so if you're unsure just do TF_WIPE_ATTRIBUTES and redo them.

• When doing a TF_MARK command, it will be done on the path you are looking at, unless you've marked an area, in which case it'll do it to the marked area.

This is what I use to make navigation mesh editing easier while still being able to play and test the map. Here's a link: HERE[pastebin.com]
I'd post it here but I can't get the BBCode to work here since there's a code tag symbol in it.
Save as navedit.cfg, when in game type "exec navedit.cfg" into console.

There's also the config on the Valve Developer wiki, but it replaces certain keys like W and mouse1 so you can't test the map without undoing them.

Make sure if you're editing the nav mesh that the bots are not in play; you can be alive in the level, but if the bots are running around it may cause a crash.

Remember, save often! When you're done, make sure to nav_analyze as well.