MVM bot's navigation problem/bug(?)

Discussion in 'Mapping Questions & Discussion' started by 4242, Jul 16, 2016.

  1. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    So in mvm_cargo, It have doors for the trains to pass through and robots to take shortcut, so I have a navigation inside the door so robots know that they can walk through this door. Since that the door will keep either opening or closing, I have a tf_point_nav_interface to update the .nav file whenever if the door have opened (unblocked) or closed (blocked), saying whenever if robots can pass through or not.

    So I've been working on a new update, where the whole layout was changed but the trains and logic still stays the same. However I've found a bug where if I've made robot's train arrived to the map, all of the navigation inside the door became unblocked even though the door is still closed, making robots think that the door is opened and can walk through.


    Before the train arrived the navigation was blocked as intended


    When the train arrived the navigation inside the door was unblocked even though the door is still closed


    All of the other navigation in the door was also unblocked even though the train was not in this track

    I've tested it out without tf_point_nav_interface in the map and the navigation in the door would still unblock it, and I've tried using the tf_point_nav_interface to update the navigation after it had unblock it but it still stays unblock.
    I've also tested when there is a solid block inside the navigation, it still would unblock it.

    Even though it may sounds confusing because of a unique feature but it would be helpful if you know anything about that, even clues or hints.
     
  2. LeSwordfish

    aa LeSwordfish semi-trained quasi-professional

    Messages:
    4,102
    Positive Ratings:
    5,991
  3. Hyperion

    aa Hyperion L16: Grid Member

    Messages:
    810
    Positive Ratings:
    617
    Well, I'm MvM Expert only in the game, not navigation side :)

    However, only thing I can suggest (that works in Hammer quite often) is to recreate the door and .nav hint from scratch
     
  4. UKCS-Alias

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

    Messages:
    1,264
    Positive Ratings:
    748
    What i would check is if the tf_point_nav_interface does refresh it. The RecomputeBlockers command on that entity would normaly refresh those paths. Its how the rottenburg blockade gets its nav opened.

    And to note, just triggering it once might not always do it. Some doors are faster than others, so its recommended to make it refrehs a few times (for example 5x with a gap of 1 second). Making that constantly trigger or setting the delay below 1 second isnt recommended since that would become server heavy.
     
  5. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    I've tried that, triggering it after the train had arrived and it still unblock. However I've tried keep refreshing every 0.2 sec non stop and it did stays block, but that would likely cause a server lag.

    Also more testing, I've replaced one of the door to just a solid block, and it said that this nav is unblock all of the time but robots think that it was blocked so they take the normal path.



    What a amazing code valve have.
     
  6. henke37

    aa henke37

    Messages:
    1,836
    Positive Ratings:
    420
    Doesn't rottenburg have a tunnel the tank takes? I've never had a chance to play on the map, but perhaps you should look at that?
     
  7. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    Tank's tunnel is only for tunnel, not for robot's so the navigation is not needed in there
     
  8. ммα | ∂αиỉєℓ

    ммα | ∂αиỉєℓ L1: Registered

    Messages:
    42
    Positive Ratings:
    27
    Have you tried using a trigger block on the door with nav_avoid on it that gets disabled when the train comes, just an idea?
     
  9. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    I can easily do that but although I like the "blocked" better. If there is other option to fixed it then I'll have to do that then
     
  10. UKCS-Alias

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

    Messages:
    1,264
    Positive Ratings:
    748
    Try to block it off using a respawnroom visualizer (you can turn them on/off) and then use that nav trick.
     
  11. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    This might sounds a stupid question but how do I do that?
     
  12. Nuke

    Nuke L4: Comfortable Member

    Messages:
    159
    Positive Ratings:
    113
    I'm not a map expert (you know), but i'm sure if you rewatch how @Crash 's tutorial make respawn rooms, you might get info you need.
     
  13. UKCS-Alias

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

    Messages:
    1,264
    Positive Ratings:
    748
    in mvm it does go a bit further on that. but there are a few basics which make it work (which is why both mannhattan and rottenburg use them.

    A visualizer is like a team based clip brush. So if you make a visualizer using just nodraw textures and then make it for the normal respawnroom of red it will prevent bots from taking that path. Even though its open. The nav file will consider the regions this brush touches as 'blocked'. And this will make the bots avoid taking that path.

    To toggle the state you can just enable and disable the visualizer. But do keep in mind that when a bot walks on it he gets stuck. So you might want to avoid that to happen by either teleporting them outside of the blocked zone (will look less good) or you delay it until all bots are away (which you can try by using prefer and avoid zones - which in turn also can be toggled)

    In the end its trial and error what works best for you.
     
  14. henke37

    aa henke37

    Messages:
    1,836
    Positive Ratings:
    420
    I thought that bots outside of the navmesh will just default to running in a straight line towards their goal.
     
  15. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    So in more testing, If I keep refreshing the navigation up to a maximum of every 1.9 seconds then it would stays blocked, Although I don't know if every 1.9 seconds would be enough to make the server cause heavy load.

    I know the basics of the func_respawnroomvisualizer but the problem is slightly different

    Testing it out on a func_respawnroomvisualizer with the "Associated Respawn Room" is set to the same as the red's spawnroom, and robots is still attempting to walk through even though it always enabled. I don't know if showing you the vmf, bsp, nav and pop would help find the problem
     
  16. UKCS-Alias

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

    Messages:
    1,264
    Positive Ratings:
    748
    That way it sounds more like your door isnt blocking the path perfectly. And this can be multiple reasons:

    Something is wrong with the brushwork allowing small gaps to exist. If everything is ongrid this is most unlikely, but if everything is grid 1 then its likely to happen. It would explain why they still try to walk though.

    Did you set the door to start 'open'? If so close the door, by default and make it automaticly open on round start. Maybe it does take something for doors into the compile that records the blocking state and generating the nav would make it think to remain open?

    Nav squares are too large for the door itself making it not trigger the blocked state (again unlikely because even 1% of touching the square should already mark it blocked). And its very likely that its related to this since it shows when its properly working by showing the blocked state of the nav (ie. the square itself turns blue). Try to set a larger nav_avoid section at this area. Or try to use nav_split to reduce the nav square size.

    The bots cant find any alternative path using the nav, and they see this path as the only valid option (this overrules even blocked nodes). But this one is unlikely. Often can happen on steep hills and staircases that it wont generate a correct path.

    You must have the nav refreshing entity work. For mvm this is the only way to update the nav. And if you have done this there are a few extra questions to ask:
    What is the thickness of the door (for my maps all doors are at least 16HU wide)? What other attributes are set to it (maybe they think they can open the door)? How do the triggers look that activate the door and nav refresh (maybe its a timing issue)?
     
  17. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    I've set the lock grid to off and make the whole navigation to be inside the door and that didn't work.

    The door was started closed. I've tried to make many different combination to make either the door to start open or closed, when to open or closed and none of them work.

    Similar to the first one. I've tried splitting it to many 1x1 squares and that didn't work. there also isn't any func_avoid inside the door.

    There is a clear path that robots can take without taking the door shortcut.

    I've said that I've tested it out without having the tf_point_nav_interface in the map at all and it still would update it

    the func_door_rotating is 8HU. I've tested it out at 16HU and it didn't work

    List of func_door_rotating given value:-
    -Name
    -Render Mode: Don't Render
    -Speed: 300
    -Delay Before Reset (-1 stay): -1
    -Origin (X Y Z)
    -Distance: 90/-90 (one for each func_door_rotating)

    I've checked the input/output when spawning the train and it look like that it shouldn't change the door or update the nav at all

    If there is no other way then I'll have to stop using the "blocking nav" method and just use the func_avoid to do it.
     
  18. 4242

    4242 L2: Junior Member

    Messages:
    78
    Positive Ratings:
    62
    So I've replaced the blocking method to the nav_avoid. I should've done that earlier since that I've spent over 3 weeks trying to fix this.

    and now I need to fix another bug that appear about a week ago