Bot Waypoints - tips and tricks?

I found this very helpful thread that details how bot waypoints are added, edited and removed.

What is not so clear is, where should the waypoints be placed?

I added some to the map (mvxdm05) that I'm currently working on and then watched 4 bots play some DM in it, they moved around quite okay in the map, but did get stuck in one area - am I right in assuming that for the bots to work perfectly a "light beam" should be able to "hit" then everywhere they stand within the map? So, while I am editing the waypoints, if I can find a place to stand where no light beams hit me, this would be a location a bot could get stuck in?

Also, regarding the placement of waypoints, is it best to place them on pickups, to ensure they can get them?
And what about the number of waypoints in a map, can you add too many?

I have your map on my server and waypointed it for the server bots back when I added it.
https://p.teknik.io/uVdwb
Generally what I do is

• make sure all white dots are linked to one other
  
• place the white dot in the center, or never too close to a wall
  
• space out the waypoints as much as possible i.e if there's a long hallway I try to cover that hallway with as little waypoints as possible, of course, on curved or crooked ones, I'll match the contours.
  

If you are in an area where no light beams are hitting you, then you are in an area the bots can not navigate to. They may get stuck if they are pushed or spawned there. However even if you fully waypointed the map, they can still get stuck on any complex geometry, ridges, etc you may have on the map (in this case you should add bot clip or ai-noenter brushes).

You don't need to explicitly place a white dot on a pickup, the bots will move to it on their own if they see it. There's also a cvar that places waypoints on  all pickup items, so I generally think it's not needed to manually put those for pickups. I heard you can encourage them to go for an item more by putting a waypoint near it, but I'm not 100% sure.

I don't know about any upper limit for waypoints. However bots tend to stop and pivot around white points (esp. if its wide open space with a lot of waypoints), this sort of makes them slower moving or more awkward since they kill whatever velocity they managed to accumulate if they decide to do that stop/pivoting action.

Bots generally can't figure out jumps and gaps unless you use hardwired waypoints for the situation. (e.g the bots on my server can jump to the MH on Fuse). Even then that's not really guaranteed (tried for Toxicity).

@Antares, thanks for your feedback.

Regarding the placement of waypoints on pickups - when I was watching the bots play, I never saw them take the Hagar, even though there was a waypoint at the top of the stairs leading to the weapon, but not a single bot grabbed the item, they ran close to it, but then jumped of the ledge instead. However, other weapons without waypoints on them would be collected...

I'll experiment some more on the weekend, to see what works best.

One question, how do you "hardwire waypoints" to get bots to pick up "hard to get items", for example the Mega Health in my map, mvxdm05?

If you know git, you might wanna experiment using the new bot code on this branch. Here are instructions how to compile xonotic, after that just switch to that branch on the data repo. Maybe whatever is causing them not to pick up hagar is already fixed.

Depends what you mean by hard to get - there is no way to make bots pick up anything that requires jumping afaik - e.g. on fuse they'll never pick up mega health or the 50a near RL.

Depends what you mean by hard to get - there is no way to make bots pick up anything that requires jumping afaik - e.g. on fuse they'll never pick up mega health or the 50a near RL.

And that is where you are wrong.
You can come on to my server and vcall gotomap fuse and witness some of them hopping to MH just as Antibody has.

Code:

Oct 11 19:21:35 <v-pacific>    <Antibody [dev]> nice, that bot can laser up to the MH?

^ except he was mistaken and it just jumped to it.

• Bot stuck
  

If bot spawns and doesn't move at all it means there's no waypoint connected to that spawnpoint. To make sure player spawnpoints are connected you can run g_waypointeditor_unreachable in the console. It is supposed to show a player model on unconnected spawnpoints, but it doesn't work due to outdated code, you can look at the console output though. I fixed this feature (among other things) in my branch bot_waypoints.

• Waypoint on pickup
  

It's not strictly necessary to put waypoints on pickup location, but if you do it there's a benefit: when bot reaches the item, it does less calculations to find another goal as it doesn't need to evaluate all the nearest waypoints to find the more suitable one to reach the new goal. So I would recommend to put waypoints on pickups that bots often run to.

Regarding the placement of waypoints on pickups - when I was watching the bots play, I never saw them take the Hagar, even though there was a waypoint at the top of the stairs leading to the weapon, but not a single bot grabbed the item, they ran close to it, but then jumped of the ledge instead. However, other weapons without waypoints on them would be collected...

Maybe they see a goal more appealing to them before reaching it and change path. Btw you can see path to their current goal with g_debug_goalstack 1

Bots generally can't figure out jumps and gaps unless you use hardwired waypoints for the situation. (e.g the bots on my server can jump to the MH on Fuse). Even then that's not really guaranteed (tried for Toxicity).

Hardwired waypoints should be added with care, they can be used to recover bot from bad places or to go somewhere in a reliable way. In this sense adding hardwired waypoints on fuse to get mega health is not good, chances of failing is too high. Also if you set bot skill <= 4 they will always fail since bots don't bunnyhop at all (actually there are some individual bots with low movement skills that don't bunnyhop even if bot skill is higher than 4).

You can define hardwired waypoints by manually linking 2 normal waypoints in the file <map>.waypoints.hardwired (create it if it doesn't exist). You can see how links are defined by looking at <map>.waypoints.cache.

Regarding the jumppad that leads to the hagar, I noticed that waypoints aren't auto-generated for it in my branch. After some debugging I concluded that current code is wrong as it puts destination waypoint in the air, in other words a player model put exactly on that waypoint origin would fall down. Furthermore this bad waypoint causes issues when you add another waypoint near it, you would expect they get linked but there's a good (random) chance they don't.

To make sure jumppads with an almost vertical trajectory are usable by bots you shouldn't put target too close to destination but a little bit higher. In this case it suffices to raise jumppad height from 32 to 34.

That's not a bad idea, Lyberta. terencehill, if you think this is a viable approach can you create an issue on the tracker for it?

It's not strictly necessary to put waypoints on pickup location, but if you do it there's a benefit

Can you make a command that will automatically put waypoints on pickups?

Code:

g_waypoints_for_items 1

in server.cfg (dedicated), or autoexec.cfg (listen), or mapname.mapinfo (execute on specific map(s) only).

I think g_waypoints_for_items at some point was disabled because waypoints created with it are broken if you play game modes where certain items are disabled (e.g. no weapons in instagib). Also, depending on the map, it adds too many waypoints, which slows down path finding.

Regarding the jumppad that leads to the hagar, I noticed that waypoints aren't auto-generated for it in my branch. After some debugging I concluded that current code is wrong as it puts destination waypoint in the air, in other words a player model put exactly on that waypoint origin would fall down. Furthermore this bad waypoint causes issues when you add another waypoint near it, you would expect they get linked but there's a good (random) chance they don't.

To make sure jumppads with an almost vertical trajectory are usable by bots you shouldn't put target too close to destination but a little bit higher. In this case it suffices to raise jumppad height from 32 to 34.

Hi terencehill, thanks for your feedback.

Regarding the last sentence about fixing the jumppad, sorry but I don't understand what you mean - what target shouldn't be to close to which destination? Also, when you say the jumppad height could be raised, are you talking about the trigger_push or something else?

I meant that jump should be higher so that it ends up more safely on the floor, so yeah, raise trigger_push's height.

Hi all
I have another quick question, since we can't (easily) get the BOTs to splash-jump (or jump extra long distances), is it possible to create a trigger_push that can only be triggered by BOTs?
Looking at the entity options in NetRadient, it doesn't look like that would be possible, maybe there is a trick?

Another option I am considering is building a bridge for the BOTs using the BOTCLIP texture/brush, good idea or not?

I don't know about bot only triggers. But botclips should be carefully made so the bots don't appear to slam into an invisible wall if they ever get tossed up. I don't know how much of this applies to darkplaces, but I see it's also used for improving bot behavior and host/game performance.
http://linradiant.intron-trans.hu/docs/B...Guide.html

For a more complete and updated guide please take a look at https://gitlab.com/xonotic/xonotic/-/wik...-waypoints

For a more complete and updated guide please take a look at https://gitlab.com/xonotic/xonotic/-/wik...-waypoints

Good job, terencehill! It can be interesting to make a good behavior for the bots!