Discovered an odd bug in nav meshes.

Star Bright

L2: Junior Member
Jan 4, 2016
75
65
Tonight, I was playing around with bots on pl_erosion_a6 (because I have a lot of time on my hands, like custom maps, and like watching bots) and I encountered a bit of an oddity.

385C45B1868B6BBC9302ADE5A3BC0AF7FF821377


I've seen something like this before, where despite having perfectly valid spawn exits, bots decide that the way the crow flies (the closest part of which in this particular instance happens to be that corner of the spawn) is the best way - and their AI refuses to tell them that the door nearby is actually working perfectly. I've seen this issue before on even official maps like Badwater, so the fact that it's a custom map has no bearing on this glitch.

First, I thought it was a nav mesh issue. The nav mesh generator is weird - sometimes it loves making these connections that make no physical sense, and sometimes it just doesn't like to connect two adjacent locations. With nav_edit 1 on (on a different match to make sure):

78E7DD15A15F6094BBC798A83593F9576CD9ADB9


Connections look fine to me. Corner is correctly identified and everything.
It wasn't until I turned on tf_show_mesh_decorations 1 that the problem becomes more apparent:

BBA9A0F2F66644CABB172B54FF9DA12424B8E2D1


Despite the fact that third is capped (see hud), the mesh is showing the logic for second point being the blue respawn area.

So with this, we can identify that the nav mesh is not correctly being updated. But what causes this?
This, I wasn't able to get a screenshot of, so I'll need to take a moment to explain something about how payload works on a technical level. When a blue player touches the trigger_capture_area nestled around the cart, an impulse is sent to the cart to move forward. Then, the payload checks to see if a red player is standing nearby. If so, it blocks further impulses to move forward until the red player is dealt with or the blue player leaves the trigger_capture_area. However, it does not block the first impulse to move forward. Which means that if the payload is a fraction (I'm talking fractions of hammer units) away from the capture path_track node, it will still move forward and capture, despite a red player being present on the payload.

This isn't the main issue causing what's happening here, but an aside that leads to the real issue. When a blue player leaves the trigger_capture_area, the cart decelerates to a quick stop. The stop isn't sudden, though, so there's a chance that it could still be moving onto, say, a path_track node that captures an area despite the deceleration process. If you want to recreate this, go onto a payload map, push the cart as close as you can to a checkpoint without capturing it, and then continuously move in and quickly outside of the cart's push zone. If you push it just the right amount, the cart will cross the capture point, and nobody will be standing inside the capture zone. THIS is the root cause of my initial issue. For some strange reason, this capture (which, by the way, won't show up in the kill feed or console, since nobody was standing inside of the capture zone when the point was captured) is why the nav mesh won't properly update, leaving the bots to obtain a sudden fascination with one particular corner of the spawn.

What can be done about this? I have no idea. Why does it happen? Beats me. Why am I reporting this? I dunno, I thought it would be a cool little thing to share that I've discovered. Is it relevant? Most likely not, since this primarily affects bots and I haven't yet seen any major other bugs stemming from this one.
Either way, thanks for reading!
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
541
The logic where blu pushes cart and red arrives there and then blu leaves, is coded in within the game. It is designed that way so if red player is standing at the cart, the cart always moves a bit even if red is there stopping it.

I've had a situation that you described in my maps where the last payload cp didn't show capturers in the hud. I can't remember how i fixed it but i've never seen this happen in regular points in any maps. That tells me it's very rare.

Fix to your problem in the first image would be to split the spanwroom mesh into smaller areas. If bigger chunk is connecting to smaller chunk, bots do not always navigate correctly. This applies to any connecting pieces of the map mesh.
 

Star Bright

L2: Junior Member
Jan 4, 2016
75
65
Fix to your problem in the first image would be to split the spanwroom mesh into smaller areas. If bigger chunk is connecting to smaller chunk, bots do not always navigate correctly. This applies to any connecting pieces of the map mesh.
Even if I did that, they would still freak out in the corner. Like I said, the issue was their mesh not updating properly and the bots being told their old spawnroom is their current one, so they think they're trapped inside wherever they currently are.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
I have bots jumping up and down in a corner on two maps. One of them is a clean, 64-unit grid remake of Turbine. I tried cutting the mesh up and deleting the portion that covers the corner, but they just won't move to the doorways to get out of the room, despite the fact it is a proper path on the mesh. In both maps, they are in the corner that is closest to their objective (the enemy flag and a KoTH CP), so it's as if they want to get there but they aren't doing it properly. They are stupid.
 
Sep 14, 2015
13
147
This sounds like an event isn't being triggered when the cart captures a point sans players. That would explain the lack of kill-feed event, and game-logic that follows from that event not occurring.

We'll take a look.