MvM carrier pathing

Discussion in 'Mapping Questions & Discussion' started by Snowbat, Apr 7, 2014.

  1. Snowbat

    Snowbat L4: Comfortable Member

    Positive Ratings:
    I must be either really stupid or I must be missing something crucial, but despite Alias' explanation, I still have a tough time figuring out where to put my nav_avoids.
    From what I understood, a carrier bot will always try to find the shortest way to the hatch, unless you block off the shortest way with nav_avoids, forcing him to take another path.

    Consider these very simplified blueprints.

    Case 1
    The grey areas are the bot spawnzones and the black squares and rectangles are obstacles (rocks, walls, etc)
    There are two spawns as you can see. From here, two paths are possible: the blue one and the red one. If I want to force the carrier to take the blue path for example, would I have to direct it by adding nav_avoids at the spots marked by blue X's? Same goes for red path: if I want to direct it to the red path, would the avoids at the red X's spots be correct?
    Basically, I block all possible access areas so that he has no choice but to follow the path I want him to take?

    Case 2
    The grey part is an elevated ledge from which you can jump off to the lower white area. These ledges are connected to the lower level (white area) with stairs. The carrier can take the ledge, but I want to make sure he doesn't jump off. I know how to block the stairs of the green path: just put a nav_avoid (dark green X) on them. But how do I make sure he doesn't jump off the ledge as indicated with the light green arrows?
    Same goes for orange path. he runs up the ledge and I want to make sure he doesn't jump back down.
    How is that achieved?
  2. Berry

    aa Berry Sharing is caring, and I don't care

    Positive Ratings:
    Case 1 seems completely fine. Mvm_example includes the logic for different routes, and is fully changeable for different numbers of routes. Nav_avoids cover navigation areas telling certain bots not to take these routes (make sure you have the right filters on the nav_avoid).

    If it doesn't go right up to the walls however, bots will presumably still walk around it. You have to cover an entire floor or doorway or whatever with it.

    As for case 2, this seems a lot trickier. You could put a wall of nav_avoids around the ledge and they shouldn't drop down from it.

    However, if the ledge route takes them to the objective, they should not drop down because that's the equivalent of turning around and going back to spawn (essentially).
  3. henke37

    aa henke37

    Positive Ratings:
    Don't forget the power of func_nav_prefer, it can make bots try very hard to stay on a specific path.
  4. UKCS-Alias

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

    Positive Ratings:
    That would require nav editing to work since they need to cover a full nav square to work. If they dont do that the block is ignored. Snowbat wants to avoid nav editing.

    using nav_show_func_nav_prefer 1 and nav_show_func_nav_avoid 1 ingame you can see nav areas that are affected by a prefer or avoid. combined with nav_edit 1 you can actualy see if they can walk next to the area. since that nav block wont have a color yet still show its outline.

    Nav avoids are easier to use since they often only need a small path, but for upstairs areas this can quickly mean that you need a nav prefer to prevent them from jumping down again (for example on decoy, there is no faster path by jumping down since the bridges have the avoids, while on coaltown they could jump down a little earlier hence a prefer works better there)

    Still, use those 2 cvars ingame and debugging becomes alot easier. To even make testing each path easier make a relay for setting up each path and using ent_fire activate it ingame. You can swap paths without having to reload the wave in that case.
  5. Snowbat

    Snowbat L4: Comfortable Member

    Positive Ratings:
    Thanks guys. The nav_avoid placement is much more logical to me now. I'm kinda messing around with placing all relay entities to trigger everything and all, after that I'm have to do the nav'ing (and I bloody hate nav'ing) and then, I should have a playable version 1.
    Which is probably gonna suck because it's a first version... but ehh