Let go off auto-waypointing?

[dstruct2k]

I like PMB's navmesh better... The bots not only walk around a bit to get a "feel" for where they can walk, while they create their own navlinks, but they ALSO watch what players do. It's more human.


I mean, would you like a bot that knows of every hiding place in a map on its first round playing on it, or would you like a bot that has to explore a bit on its own, and maybe find a secret or two out from another bot or player?


One thing I don't like --- Individual bot navlinks. Sure, they make the bots seem more unlike the Borg (lol) but unless you're saving them to files for each and every bot, you're losing that uniqueness. Also, the filesize would amount to (for 32 unique bots) about 7 megs per map. Yeah, that's not bad. But imagine running 50 maps on your server, and having 64 bots defined in the botname.ini (or whatever it is)... That's 700 MB. You're getting close to a gigabyte. It's awesomely human, but computer's hard drives are a bit smaller than human brains.

[stefanhendriks]

i don't think we can draw conclusions yet from PM's bot as we haven't seen it live in action yet. I don't see a real positive side in storing for EACH bot the nav mesh data. Also, you have to think off what you WANT. Do you want to see 32 unique bots? Do you want to play and shoot some? Do you care about tactics? etc.

The bug Whistler pointed out fixed lots of the node problems, so i'll stick with the nodes. At the end they both do the same: guide a bot through the map...

[dstruct2k]

Don't get me wrong, the node system works quite well as-is (although it could use some assistance in automatically pointing out the bombsites, hostages, and spawn areas... but the only complaint I've got is that it takes 4 or 5 rounds to teach the bots how to use a map.

With PMB's navmesh (which is nicely coded up on that page, so you'd only have to integrate the code you'd have to do a "pre-round" for the navmesh to be created, but it would, in the end, beat the nodepaths hands-down.


Maybe I'll look into replacing the code in RB with the code layed out by PMB on that page, and see if I can create a semi-working navmesh bot.


And, I just thought of an idea to save filesize for the navlink files. First of all, only take 1 bot's navlinks from each team. (eg: 1 CT and 1 T) Secondly, run them through a ZIP or TAR compressor to reduce filesize. Each bot can have its own navlinks in-game, but only 2 bots get it saved, 1 for each team. This way, the bots aren't Borg-like, but they are more clan-like. (Discussing maps after the game, etc)

__________________
To anyone wondering what the Borg are:
http://www.startrek.com/startrek/vie...cle/70558.html

Stefan,

Just made a couple of utilities to dump & to draw the .RBN files. Let me know if you want the very basic source code for them.

It looks like:

1) bots won't try to move away from their known nodes, so, they really need a human player to learn ways, passages, ...

2) even when simply running on a map (with a 'slow' weapon) some nodes are created but are not linked to any neighbours... And, obviously as I'm running there IS at least one neighbour node. I'm afraid that the check for a close enough node should be more relax and at least try to 'link' with the previous position of a human player

2.bis) not sure whether the bots learn how to climb a ladder

3) the goals are not created if there are no nodes close to the goals, I've slighthly modified to add_goal function to force a node creation, and I'm still testing

4) the heurestic for in think_path() are a little too complex to really understand ??? but I'm afraid that this is the reason why bots are 'idle & camping' at the beginning of the round. I'll try to put some configuration items in the bot personnality: whether they protect hostage (CT), protect the bomb (CT), go to the other team spawn point, ...

Cool stuff anyway

-eric

[dstruct2k]

Perhaps a navmesh/nodemap hybrid? Have the bots follow the nodes, but with the ability to attempt to make connections to other nodes? It would be like navmesh in the sense that, if a node is in sight, it is a valid target to walk to, whether it's linked or not.

I would really like to see bots that move on their first round playing a map. How they manage that is up to you, but I'm tired of 6 T's being at their spawn when I'm the only moving CT and I'm trying to get at least 1 waypoint string from spawn to spawn. (Yes, I'm too lazy to "realbot remove" them all )

You are not the only one about:

I would really like to see bots that move on their first round playing a map.

There are indeed multiple ways to move forward, a potential one is to use Pierre-Marie's algorithms to generate a .RBN file from a .BPS. I.e. using navmesh reachability/walkability/connectivity information to generate a mesh of valid 'nodes'.

Issue will probably be that bots will move in a 'robot' way instead of a 'human' way.

-eric

[MusicMan]

I don't see why they would move weird because of navmesh?

Originally Posted by MusicMan

I don't see why they would move weird because of navmesh?

Not because of navmesh really but rather because if there is a navmesh-based tool to convert BSP into RBN files, I'm afraid that the RBN nodes will not be a natural path... Kind of going only around meridians, no short cut, not taking cover for the path, ...

Actually, the RBN nodes could be made human at the expense of putting enough AI in the code ;-)

Anyway, AFAIK there is yet no such utilities BSP -> RBN...

-eric

[MusicMan]

Oh I see now, thanks for clearing it up

[stefanhendriks]

@ Evy, yes i am interested in any source!

About the nodes, the only check that can fail is:
- distance
- trace_hull

most likely the 2nd in this case.

I am already around the 'camp at start' problem. But not everything is fixed yet. I will update the source asap so you can update it too with CVS.

I don't know if it is possible to create RBN files out of BSP files using some navmesh technique. Atleast, when i spoke to PMB about this he said that it was not that easy.

EDIT:
in reply to Evy's numbers...

1) there is some code , that i have removed now temporarily that makes bots move when there is only 1 or a few nodes. You can see f_wander_time (or fWanderTime) being set. When this is set, theb ots will NOT use nodes to navigate. THey can just walk forward into any direction and roam around.

3) ladders are easy. THey are nodes, as normal ones, with a BIT flag set , and that allows them to 'float'. Then they are connected to nodes that are only very close ones and also vertically different, horizontal they can differ a bit. There is not much different in the connecting and such, only but that they are connected with point_hull (like traceline).

4) the heuristic is not that hard in path_think(), neither in path(). Its a simple score system i have yet to balanceout. I already changed things for the next source update.