help with some nav mesh issues

[Timlander]

Was wondering if I could get someone to help me with some nav mesh issues. I know all the basics of building the mesh, but the problem I am having is flow. IDK how to get the correct flow in the mesh. I can podcast and show you exactly how my mesh looks in real time while we chat on steam, etc. Been trying to figure this out for 2 months now with no luck.

[Collini_neut]

use z_show_flow_distance 1
when you spot a -9999 on your escape route, thats the problem
both numbers (x/y) should be numbers other than -9999
you also need a start saferoom (player_start or checkpoint nav) and an end saferoom (checkpoint nav)

[Timlander]

use z_show_flow_distance 1
when you spot a -9999 on your escape route, thats the problem
both numbers (x/y) should be numbers other than -9999
you also need a start saferoom (player_start or checkpoint nav) and an end saferoom (checkpoint nav)

Yea I pretty much understand all that. 1 thing I did notice is my player start is marked in z_debug as player start and a checkpoint. Would this cause any issues? And my saferoom is marked checkpoint finale. And last time I checked I believe every nav square was at -9999. Another thing I am having an issue with(which is probably causing the main nav errors) is I cant get the elevator navs to work. I have elevators in my map and the bots wont walk in them when I go to go up to the next floor. IDK how to fix that. I have tried looking at several guides and tutorials but none have helped thus far.

[zapwizard]

Use the nav_troublereport command to ensure you had no errors (other then mark battlefield). If you have a break in your nav, such at two entirely un-connected nav blocks, then flow won't compute properly.

For elevators, try making the nav squares manually. Make sure there is a one-way connection between the start and end nav squares for the elevator.

Mark both elevator navs with battle-station. When stand on an area marked as battlestation, the bots are automatically supposed to try to get close to that nav_square or an ajacent nav square also marked with battlestation.

[Timlander]

Use the nav_troublereport command to ensure you had no errors (other then mark battlefield). If you have a break in your nav, such at two entirely un-connected nav blocks, then flow won't compute properly.

For elevators, try making the nav squares manually. Make sure there is a one-way connection between the start and end nav squares for the elevator.

Mark both elevator navs with battle-station. When stand on an area marked as battlestation, the bots are automatically supposed to try to get close to that nav_square or an ajacent nav square also marked with battlestation.

Alright I will give this a shot. Thanks.

[Timlander]

Nah marking the elevators as a battle station did not help. Still getting nav errors and they will still not go in the elevators.

[ThaiGrocer]

I tried recreating the nav mesh like Deadline 2, map 2 from scratch in a test map with "the bare minimum". This is what I got: http://dl.dropbox.com/u/3762439/test_elevator.zip

What I can recall for this map, if my memory serves right. Let me know if you can't recreate it:

Optional: Start with a working escape_route before adding an elevator as the obstacle. Or do whatever that will give you confidence in your assumptions.
There is no need for any additional attributes.
No connections are needed between floors.
A finale area or info_changelevel with an actual existing map to transition to is necessary for a working escape_route.
I forget if the size of the nav areas on each floor have to be the same size and match up with each other x-y, but start simple at first.

This is as close as I can get to what Valve seems to have, but, as always, there is probably more than one to get an elevator to work properly. In fact, I do know there's more than one way. One way you should avoid is in one of custom campaigns I played recently where it involved a complicated set of trigger_push entities that would force the team in.

The limitation of Valve's way is that you need to have a linear path through the elevator. In other words, you can't make stops along the way down to the end of the elevator. Although, I think you might be able to combine the methods used in Shotgunefx's recent example of a changing escape_route: http://www.youtube.com/watch?v=FZVPHOcH-U4. I also remember in Suicide Blitz for L4D1, there was a stop along the way without using L4D2 stuff, so it's not impossible.

[Timlander]

I tried recreating the nav mesh like Deadline 2, map 2 from scratch in a test map with "the bare minimum". This is what I got: http://dl.dropbox.com/u/3762439/test_elevator.zip

What I can recall for this map, if my memory serves right. Let me know if you can't recreate it:

Optional: Start with a working escape_route before adding an elevator as the obstacle. Or do whatever that will give you confidence in your assumptions.
There is no need for any additional attributes.
No connections are needed between floors.
A finale area or info_changelevel with an actual existing map to transition to is necessary for a working escape_route.
I forget if the size of the nav areas on each floor have to be the same size and match up with each other x-y, but start simple at first.

This is as close as I can get to what Valve seems to have, but, as always, there is probably more than one to get an elevator to work properly. In fact, I do know there's more than one way. One way you should avoid is in one of custom campaigns I played recently where it involved a complicated set of trigger_push entities that would force the team in.

The limitation of Valve's way is that you need to have a linear path through the elevator. In other words, you can't make stops along the way down to the end of the elevator. Although, I think you might be able to combine the methods used in Shotgunefx's recent example of a changing escape_route: http://www.youtube.com/watch?v=FZVPHOcH-U4. I also remember in Suicide Blitz for L4D1, there was a stop along the way without using L4D2 stuff, so it's not impossible.

There are 3 elevators total. As of now 2 of those are needed for use in the escape route. The 3rd I am undecided weather I will make it mandatory or not. All 3 elevators are between 2 stops only. Meaning they start at one floor, you press the button and you reach your destination. So there are no multiple stops. I did not create the elevators with tracktrain, I created then by using info targets and logic relays. I will see what I can make of your elevator test right now.


This is what i got when trying to run the map in l4d:


CModelLoader::Map_IsValid: Map 'maps/elevator_test.bsp' bsp version 21, expecting 20
map load failed: elevator_test not found or invalid


EDIT AGAIN: Never mind that is my bad. I tried running it in L4d and not L4d2. Just formatted so re downloading L4d2 now.

[Timlander]

So I did not see anything special about the elevator nav. Is there something I am looking out for? I did notice that you marked the spawn and safe room as escape routes though which I have not done. I marked the elevators as a battlefield on my map and they still wont go on it....

[ThaiGrocer]

Sorry, I didn't know you were doing L4D1. Anyway, there shouldn't be a need for attributes like BATTLEFIELD. If I can recall correctly, func_elevator was one of the necessary elements to allow the nav to create a working escape_route. Starting simple first helps.

I've never encountered a way to mark an escape_route manually. Aren't they automatically generated after opening the map, usually after analyzing? Ones manually created seem to disappear after you reload a map or analyze, roughly speaking.

[HellaLouYaah]

If your goal is to connect the start and stop nav areas, just make nav areas manually in between, ensuring they are not farther apart(on the z axis) then the bot can jump. Connect them in succession, and if z_show_flow_distance 1 is set you will see the -9999 thing change to something valid when you run the nav_recompute_flow command.

The nav areas don't need to be exact in length/width. If you need more explaination let me know, but it's pretty simple.

[Timlander]

Sorry, I didn't know you were doing L4D1. Anyway, there shouldn't be a need for attributes like BATTLEFIELD. If I can recall correctly, func_elevator was one of the necessary elements to allow the nav to create a working escape_route. Starting simple first helps.

I've never encountered a way to mark an escape_route manually. Aren't they automatically generated after opening the map, usually after analyzing? Ones manually created seem to disappear after you reload a map or analyze, roughly speaking.

I did use func_elevators. Yes they are supposed to be generated automatically but it does not always work out that way.

If your goal is to connect the start and stop nav areas, just make nav areas manually in between, ensuring they are not farther apart(on the z axis) then the bot can jump. Connect them in succession, and if z_show_flow_distance 1 is set you will see the -9999 thing change to something valid when you run the nav_recompute_flow command.

The nav areas don't need to be exact in length/width. If you need more explaination let me know, but it's pretty simple.

I do not understand what you are saying here? Connect start and stop nav areas?

[HellaLouYaah]

Umm, where your elevator "starts" and "stops". Basically it's just putting nav squares in between the starting position and stopping/end position. They need to be placed no farther apart(vertically) than a survivor bot can jump. That's like 50units, or 5ft or so. You'll know if they're too far apart if the escape route doesn't connect.

But you also say you used func_elevators so the navs should connect automatically anyways...

[ThaiGrocer]

I did use func_elevators. Yes they are supposed to be generated automatically but it does not always work out that way.
I was trying to point out that manual marking of escape_route disappears once you re-open the map. But yeah, it gets a bit unintuitive. For me, the issue was having an info_changelevel that wasn't leading to any existing map. Changing that yielded a working auto-generated escape route. As a side note, I did try to break it afterward with a nav blocker without any issues, but I think a more feature complete map might show me something more headache-inducing. :)