Can bots walk on props?

Discussion in 'Mapping Questions & Discussion' started by kufte, Apr 16, 2017.

  1. kufte

    kufte L1: Registered

    Messages:
    13
    Positive Ratings:
    0
    I have a stupid idea for a map, but for it to work the bots will need to walk on metal sheets and pillars from Egypt. Will the navigation mesh allow it?
     
  2. Hipster_Duck

    Hipster_Duck L2: Junior Member

    Messages:
    99
    Positive Ratings:
    77
    I'm not familier with nav meshes but if they can't walk on the props you could always make the areas they need to walk on out of invisible clip brushes.
     
  3. squ1rrel

    squ1rrel L4: Comfortable Member

    Messages:
    158
    Positive Ratings:
    72
  4. Startacker!

    aa Startacker! L�: Void Walker

    Messages:
    245
    Positive Ratings:
    268
    Yea, the navigation mesh will allow it. For best results, type nav_edit 1 and use nav_mark_walkable on your props to mark them as walkable. Once you think you've marked enough, type nav_generate_incremental (A standard nav_generate should work, I just use incremental for some reason). If it all looks good, finish it up with a nav_analyze.
     
  5. Da Spud Lord

    aa Da Spud Lord L0: Crappy Member

    Messages:
    845
    Positive Ratings:
    573
    Yes, bots can walk on props as long as it is marked in the navigation mesh. If it's a thin prop like a log, it may not generate an area on the prop automatically, and you'll need to add it manually. The Valve wiki page listed above should explain how to add it manually. I recommend marking those parts of the mesh with "nav_precise" (aim at the area and use that command, areas marked with nav_precise have a green plus in them), and bots will be more careful when walking across that area.
     
  6. Hyperion

    aa Hyperion L16: Grid Member

    Messages:
    810
    Positive Ratings:
    618
    For future, I don't ever recommend manually building nav. It is way too complicated and takes mote time than it is worth to. Invisible clips and nav_walkables are the way to go
     
    • Agree Agree x 1
  7. Da Spud Lord

    aa Da Spud Lord L0: Crappy Member

    Messages:
    845
    Positive Ratings:
    573
    Manually building a navmesh from scratch isn't worth it, but editing a generated mesh to add areas that the mesh won't automatically generate on is worth it, especially if nav_mark_walkable and nav_generate_incremental won't generate a mesh on top of it (which is common on thin bridges, like the log near the first point of Swiftwater).
     
  8. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    794
    Do note that for an mvm map its best to clip nearly everything a bot should be able to walk on or walks next to. Bots can have diffirent sizes and sometimes this might mess up with their behaviour. Dont blindly rely on the prop creating a correct nav. Large props are usualy not a problem, but a smaller fence often is. The nav needs to have smooth connections for the bot to be able to succesfully walk on it.
    Even when having a wider prop, as soon as they have to walk a slight edge upward, clip that edge so its smooth.
    The only time to ever edit the nav would be to split nav sections. This due to the behaviour of avoids, prefers and prerequisites in mvm.
     
  9. Da Spud Lord

    aa Da Spud Lord L0: Crappy Member

    Messages:
    845
    Positive Ratings:
    573
    There are other situations too. The automatic mesh generation process is far from perfect, from generating a mesh at the bottom of a death pit to making connections through walls and rails. Whenever I generate a new navmesh, I usually like to run around the map with nav_edit 1 to check for any problems in the mesh.
     
    • Agree Agree x 1
  10. MOCOLONI

    MOCOLONI L5: Dapper Member

    Messages:
    243
    Positive Ratings:
    60
    More than "nav_generating" I think it's better to "nav_analyze". It keeps suggesting you to use it whenever you save non-minor changes to the .nav file, either an existing or new one.
     
  11. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    794
    The problem is mainly that the effort spent to fix the nav is often too much work compared to using some tricks in hammer to just force the engine to generate a correct one. There are often small tricks you can perform to change the way a nav is generated. Sometimes just putting a 8HU clip at the bottom of the staircase to get a slightly diffirent start angle can be unnoticed while playing, but already give the nav generation a diffirent behaviour.

    Do note that you arent going to just compile your level once for testing, you should do it many times and fixing those bugs 50 times is realy a lot of effort for something you might solve permanently in 5 minutes spread acros 30 seconds between each test compile for visuals. And dont say 'ill just do it when making a release version', because that indicates you arent testing it enough, or are spending a massive time on it at a very late state.

    The thing that im talking about is bots getting stuck behind a corner, things that can be rare anyway but can involve a lot of testing to fix. Trying to find a permanent solution of which you no longer have to care about is better. Hence solving these things in hammer can be far more efficient.

    Sure, some things require nav editing in the end anyway (some maps just require it). But avoiding any editing work is more convenient anyway. And also are less prone to mistakes during editing.

    Do note that skullcove had about 20 minutes worth of nav editing each time. Which in the end has resulted easily into over 10 hours! Its not a little time you save.
    nav_analyze is normaly the last step of a nav_generate. Its what considers the vision within the map and where bots can stand at a safe location compared to an other square. It contains extra information which the game requries for a good AI. A few things to consider it analyzing is the fastest path between nodes at an X distance, wether a jump down area is actualy safe to jump down from (bots will avoid paths that make them take damage from trigger_hurt), extra hints about dangerous or safe areas (although mvm doesnt use this info), and probably even more info i cant even think about. These are things you cant do when editing the nav yet are vital. Thats why each edit requires this.
     
    • Thanks Thanks x 1