Re: Recast / Detour
 

Hi Immortal_BLG, thanks for jumping in.

I believe I have met these requirements, however I'll detail the code I'm using to see if you can spot the mistake (don't worry, it's not much code).

My BotThink function looks like this:

The NextMove function is pretty big as it does a lot of checking of the path and whether the bot is stuck or not, but its ONLY function is to populate pBot->y_move_speed and pBot->x_move_speed. It basically takes the direction the bot needs to move in, uses VecToAngles to work out the orientation in relation to the bot's current rotation and then has an if statement that says "if the bot needs to move diagonally-right then set y_move_speed to maxspeed and x_move_speed to maxspeed", or "if the bot needs to move backwards then set y_move_speed to -maxspeed and x_move_speed to 0" and so on.

The UpdateView function does a bunch of stuff related to the bot's vision, and also makes the bot look its current waypoint:


and finally the LookAt code is listed here:


So every frame, the bot determines which direction it is heading in (i.e. whether it is moving forwards/backwards and strafing left/right) and updates the v_angle and angles to face its current waypoint.

If I view the bot in first person mode as spectator, I can see its looking at the top of the ladder, and I have traces to confirm it is definitely MOVETYPE_FLY, and that it is currently trying to move forwards (the yellow line in the earlier screenshot indicates that y_movement_speed is maxspeed and x_movement_speed is 0 basically).

Not sure what I'm missing here.

Re: Recast / Detour
 

Did you tried my suggestion to set the *upmove* argument to max speed when the bot hits the ladder? :)

Also I as I see this is a custom map. Could you try to some of the default ones like cs_assault?

Re: Recast / Detour
 

Sorry, forgot to mention that I did try the upmove argument but didn't work :( It kind of made the bot walk funny though, at like 2/3 speed.

I'll try a standard map when I get a chance :)

Re: Recast / Detour
 

You need to invert the pitch of move angles

Re: Recast / Detour
 

This is really weird.

To rule out the possibility that the bot is looking in the wrong direction, I have am now forcing the bot look directly upwards all the time (v.origin + Vector(0,0,100)) and the bot is still rooted to the floor when touching a ladder.

I had assumed that pEdict->v.v_angles were the view angles, and pEdict->v.angles were the movement angles. However, when I implement your fix for the code, Immortal, the bot looks the wrong way (i.e. he looks at his feet, not upwards). This is both in first and third person. To me this suggests his movement and view angles are both being modified even though the code doesn't do this.

I have tried every possible combination of inputs into pfnRunPlayerMove, including both v.angles and v.v_angle in the second parameter, using the inversion in LookAt and not using it, and setting the upmove parameter to maxspeed.

I really don't get this at all :-(

EDIT: This also happens on official maps, and even if the bot accidentally touches a ladder while moving elsewhere. In other words, they're trying to move AWAY from the ladder, but by accidentally touching the ladder they become completely frozen and unable to move until they die or I restart the round. Seriously, what the hell?

Re: Recast / Detour
 

Well you derivate from HPB_bot which works well with ladders. It seems like while refactoring you forgot something?

I see this stuff in all HPB_bot derivates:
Where after additional check if the bot is going up or down a ladder the following code is executed
And then seems like the the vecAngles variable is only used
I really didn't know what exactly is the problem with your code, I don't know the HL engine so well but I guess that it must be something very small that is missing. Keep on trying different variant and check the older code that you had based yours.

Re: Recast / Detour
 

hi,
1. I think forwardmove,.., upmove are not in map coordinates but rather in "local" coordinates, with forward= dir. of wished move, ie dir. of look; climbing a ladder requires a positive value for forward speed and upmove=0.
2. bot will not climb if IN_FORWARD button is not set ( a speed!=0 is not enough)
hope this helps.

Re: Recast / Detour
 

Yes I forgot to write, you should combine fixed LookAt() function with giving fixed v.angles to RunPlayerMove.
If you already try it, so I don't know what can I advise to check next...
But if you say, that bot tries to move in opposite direction (away from ladder), then something wrong with bot move direction pitch...

Re: Recast / Detour
 

This was the answer in the end. I changed my nextmove function to also set IN_FORWARD/IN_BACK/IN_MOVELEFT/IN_MOVERIGHT and the bot now climbs the ladder. Great!

The view angles are still messed up though, even though the bot is looking upwards, they climb very slowly as though they're looking dead ahead. If I manually set the bot's angles myself they climb just like a human, so my lookat function is dodgy.

As you guys have suggested, I'll go back through the original HPB bot code to figure it out.

Progress!

Re: Recast / Detour
 

A screenshot in action, showing the bot getting onto the roof of the warehouse in cs_assault.

https://dl.dropboxusercontent.com/u/...t_Climbing.png

I basically just copied the bot's looking code from the original HPB Bot (the code used to shoot at tripmines). It seems like all is now well, except that the ladder climbing is still not perfect. The bot usually pauses for a second or two at the foot of the ladder before beginning ascent, and still climbs significantly slower than a human, but at least they're doing it reliably now.

Re: Recast / Detour
 

Ok, it looks like the issue is to do with the bot's movement while on the ladder. I've put in some special case code for ladders so that the bot always moves directly towards/away from the ladder depending on whether they're climbing or descending, and the bot always tries to face more or less directly towards or away from the ladder.

Now it can climb and descend just fine :) Good stuff.

There are some tricky cases I need to look at where the navmesh gets confused as to where the top or bottom of a ladder is. For example, in cs_backalley there is a fire escape ladder, and the bottom of the ladder is placed perfectly, but the bot thinks the top of the ladder is INSIDE the room (i.e. on the wrong side of the wall), causing it to get stuck.

There may also be some issues with bots trying to climb the wrong side of a ladder (though I've not observed this yet)

Re: Recast / Detour
 

Any new progress? Btw check out RACC bot about navmesh and ladders, I think PMB have done it there. :)

Re: Recast / Detour
 

Hi Storm,

I've had a little break as I've been focusing on some work-related stuff for a big show-and-tell at my company's next innovation gathering. I did do some digging around in the recast/detour libraries to see if I could get the bots to jump down from ledges, but all I did was end up creating horrible mutated versions of the navmesh :P

The recast/detour library is actually pretty limiting. Any kind of movement that has to ignore the navmesh, like jumping, teleporting, dropping off ledges, swimming and ladder climbing must be handled via "off-mesh connections", which are just two points in space that the bot knows it can move between. Thing is, if you've got a long ledge that you can drop off like in cs_assault, how do you handle something like that? Just stick dozens of off-mesh connections all along the ledge? Must be a better way.

This lead me to take a look at Quake 3's Area Awareness System. The Quake 3 bots from what I could remember were capable of doing some impressive stuff, including running off ledges, jumping gaps, swimming through tunnels, navigate moving platforms, and even rocket jumping onto hard-to-reach areas. I'm wondering if I can incorporate any of the techniques it uses to create better dynamic path generation.

I'm thinking something like the bot being able to intuit shortcuts (such as dropping off the ledge rather than going down the stairs) on-the-fly somehow. Many of the AAS principles (walkable areas especially) share a lot in common with a navmesh. Need to think about it some more when I have time.

Re: Recast / Detour
 

Well some bots when are "in combat" mode, use shortcuts to hide or get better view faster even if it takes some damage to them. This mode does not use waypoints or navmesh. They just trace lines around them to check the environment and make decisions on the fly. When the hot situation is gone they return to their usual navigation. :)

Re: Recast / Detour
 

The navmesh is broken up into tiles which can be removed and inserted as necessary (for level streaming for example, or dynamic obstacles), so what I'm thinking is I could probably try and do a reachability test between tiles during navmesh generation, and if two meshes can be reached then create a connection between them.

Just need to figure out a reliable reachability test...

Re: Recast / Detour
 

Even if you make the best tests about reachability there will be always places that will need manual placement. Even the official CSbot have navmesh editor to place additional connections by the user when needed. There is even packs with .nav files around the net.

So don't be very disappointed if you cannot create the best pre-play automatic creation.

Note: You can do like the JKBotti does. Create connections dynamically based on the regular players that are currently playing the map. In this way when they go to hard to reach places you will save their movement points and after that the bots will be able to use them. :)

Re: Recast / Detour
 

Yeah I'm not expecting to be able to create the perfect bot, but I want to get close ;)

One of the biggest challenges is the fact that a navmesh "wall" is simply the edge of the navmesh. There is no way to tell if there is any actual level geometry in the way, or if it's just a ledge that the bot could feasibly walk off.

I think my first port of call will be to stop the recast library from eroding edges, so that bots can walk right on the very edge of walkable areas if necessary, and also to prevent it discarding walkable spots it deems as being too small. This should help a little, in so far that it no longer erects a barrier along the edges of a ledge.

Re: Recast / Detour
 

Yes, the navmesh cannot tell you if there is wall on the edge but the game engine can. Walking the bot must be combined algorithm with navmesh and game engine check routines. :)

Re: Recast / Detour
 

Hello Neoptolemus!
Look at THIS link, here Mikko make annotations builder for recast, combine it with some HL related changes and trace line checks will allow to create jump connections and maybe more...

BTW:
As for AAS, Quake3 uses a modified (more informative) BSP format, by which the creation of AAS became possible.
We do not even have the opportunity to realize the normal TraceHull function with custom hull size or even TraceLine, that will hit clip nodes...

Sorry for bad English...

Re: Recast / Detour
 

Hi Immortal_BLG,

Thanks for the link, I'll take a look when I can. Had to have a bit of a break due to personal matters, but hopefully will pick this back up again soon!

Re: Recast / Detour
 

Just a quick update. I've decided to take a different approach. I'm going to modify the existing recast demo tool (the one I linked to earlier, either in this post or the one in the HPB bot forum) so that it parses BSP files instead of OBJs, and have it retain useful information like entity positions and so on.

This will give me much greater flexibility when debugging paths and so on, as it will allow me to easily visualise the entire navmesh as it's generated, and conveniently mark data points without having to run the game and write some finicky code to draw it all within the game itself.

I eventually envisage being able to load a BSP into the application, and see the simplified level geometry and navmesh, but also all the extra bits it's generated such as door points, ladder points, hostage locations, sniper positions, cover locations and so on. I'll store this inside the navmesh itself so that it is part of the Recast library rather than the demo app, which will be purely for visualisation only.

In theory, I can perfect the generation of the navmesh and pathfinding within the application, then simply migrate the library over to the bot itself and hook it up.

Re: Recast / Detour
 

Hmm, I though that you are parsing the BSP already, perhaps I misunderstood something earlier. Anyway I also think that this is the best approach. :)

Re: Recast / Detour
 

Oh yes, I'm parsing the BSP already, but from inside the game. The Recast demo is a separate application written by Mikko, who is the original author of Recast. It's essentially an OpenGL renderer with a built-in GUI that can parse OBJ files and generate a navmesh.

I'm planning on switching development to the demo tool as it makes it a lot easier for me to view debug information on the navmesh itself, so I can see all the tiles, show/hide elements of it, and it has a path testing tool too. First step is to have it parse the BSPs directly instead of OBJ files, which should be mostly a copy/paste of code from the bot.

The idea is that I can use it to perfect the navmesh generation engine, then port it over to the bot code itself and have the bots benefit, rather than develop the bot directly and have limited testing tools at my disposal :)

Re: Recast / Detour
 

Now I got it. Sounds like a good plan. Good luck then. :)

Re: Recast / Detour
 

Right, finally got it parsing BSPs properly. Had a bit of a frustrating moment where it was coming out garbled, but I think it's down to the fact that OBJ files start indexing at 1. All sorted.

Just going to start working on the placement of icons for things like ladders, doors, hostages etc so we can start seeing the automatic generation of a tactical layout for BSPs opened in the program. Once there's enough of interest, I'll release a version for people to play with.

Re: Recast / Detour
 

Count me interested. :)

Re: Recast / Detour
 

Just rebuilding the off-mesh connection code in Recast at the moment. Right now, off-mesh connections have to be positioned somewhere on the mesh, which makes sense except that the top and bottom of a ladder brush in the BSP won't sit exactly on the mesh itself.

At the moment, I have a clunky system where I generate the mesh, then find the closest point on the mesh to the ladder points and add them to the off-mesh connections, then regenerate the mesh. This works fine but like I said, it's clunky.

I'm currently looking to rebuild the system so it does that automatically, but the way it currently handles off-mesh connections doesn't make it quite so simple.

Once I've finished that I'll add a bit of rendering code to render little icons at the top and bottom of ladders so you can see where they are. Then I'll probably release a build so you can play with it :)

Re: Recast / Detour
 

Nice, I can't wait to see it. :)

Re: Recast / Detour
 

Very nice! I also would like to try out the build and the bot template once it's released. :)

Re: Recast / Detour
 

Hi guys,

Unfortunately I've not had time to work on this, so I'm just going to release the source as it is.

I've cut back on a lot of the experimental stuff which really didn't work, so what you have is essentially the following:

- Ability to process the current map data to generate a navmesh in Recast
- Able to export map and navmesh data to OBJ format
- Basic pathfinding functions including finding random points, generating paths and so on
- Basic steering to avoid corners and getting stuck
- Able to process ladders and include them in the navmesh
- Frustum-based vision for near-perfect simulation of player FOV
- Function stubs for events like bot killed by player, bot killing player, bot seeing player etc.

I want to keep working on this but probably won't get a chance to until Christmas. I'll probably step back from navigation and work on other stuff like bot vision.

Download the source and pre-compiled dll here:

https://dl.dropboxusercontent.com/u/...t_20151102.zip

Have fun!

Re: Recast / Detour
 

Thanks a lot for the sharing. Actually I have been working also on my private project until recently and it seems that I'm in the same situation as you waiting for Christmas...

I will check out the code as soon as I get some free hours. Btw I would recommend to create a project in GitHub. :)

Re: Recast / Detour
 

Yeah I have a few projects on Github already, I'll migrate it there when I have a moment and get VS connected. Good shout :)

Re: Recast / Detour
 

I just tried the bot, and overall it's awesome!:thumbup: Bots were getting stuck sometimes, but it's still very promising.

It really feels like ZBOT navigationally; they were able to cut corners when navigating throughout an alley, instead of navigating strictly on the center part of the alley (because waypoints are usually placed in the center).

Thank you for developing this! Can't wait for the future version of the bot. :)

Re: Recast / Detour
 

Glad you like it! Doesn't surprise me if the bots have a ZBOT feel to them, as ZBOT also uses navmesh for navigation. Recast uses its own method of generating the navmesh using a voxel grid, which may differ from ZBOT's implementation, but the end results will probably be fairly similar.

I ended up stripping out a lot of the extra navigation stuff I had written, as the overall benefit wasn't really that great, and the code had become messy from constant re-writes, so to make it easier for people to extend I decided to remove it and keep it clean and simple.

I did notice some odd quirks in the code where I had clearly been testing stuff out and not bothered with proper coding convention. I'd also like to tidy up the steering code so that the adjustments based on proximity to a wall are split into a separate function and so on.

I was just thinking about ways to better do bot vision. I want to, eventually, take into consideration things like alpha in a texture, so if an opponent is hiding behind a func_illusionary, it can tell the difference between a chain link fence and the curtains in 747, and will reduce the chances of the bot seeing someone if they are behind a bush (where most of them is obscured) vs if they are behind a chain link fence (where most of them is visible).

I tend to talk a lot, it's hell not having the time to implement your ideas ;)