Discovered an odd bug in nav meshes.

Discussion in 'Team Fortress 2 Talk' started by Star Bright, Mar 15, 2017.

  1. Star Bright

    Star Bright L2: Junior Member

    Messages:
    74
    Positive Ratings:
    59
    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.

    [​IMG]

    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):

    [​IMG]

    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:

    [​IMG]

    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!
     
    • Thanks Thanks x 2
    • Like Like x 1
  2. ics

    aa ics http://ics-base.net

    Messages:
    696
    Positive Ratings:
    422
    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.
     
  3. Star Bright

    Star Bright L2: Junior Member

    Messages:
    74
    Positive Ratings:
    59
    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.
     
  4. MegapiemanPHD

    aa MegapiemanPHD Doctorate in Deliciousness

    Messages:
    972
    Positive Ratings:
    485
    Bots are weird.
     
    • Agree Agree x 2
  5. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    834
    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.
     
    • Agree Agree x 1
  6. The Jill

    aa The Jill

    Messages:
    13
    Positive Ratings:
    122
    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.
     
    • Thanks Thanks x 4
  7. Micnax

    aa Micnax I maek map

    Messages:
    2,057
    Positive Ratings:
    1,387
    :eek:
     
    • Agree Agree x 1