Let go off auto-waypointing?
 

I played with RB and since a friend of mine was the server we had to let his bots learn maps... which sometimes just did not quite work out. We wanted to play a good game, but instead we where learning/teaching the bots nav side a lot, and it took a lot of time before i could actually 'enjoy' the game.

So i wonder, should i just make this nodes thing (auto) optional? I am thinking of the following:

- generalize goals (no more CT_SPAWN WPT, more like CT SPAWN AREA)
- make 'auto nodes' optional (or even remove it!)
- let user be able to waypoint maps

I think even this would not even be a problem to me to waypoint/node them myself. I'd rather enjoy good performing bots then none-performing/half-performing (since i know their potential).

We can also try the nav-mesh theory, but i would like to see it working in PMB's bot first, and i wonder what much advantage we have...

Anyway, thoughts?

Re: Let go off auto-waypointing?
 

navmesh yay!!!!!

This navigation works out great in the Official Counter-Strike Bot:)

Go for it Stefan:)

Re: Let go off auto-waypointing?
 

I'm sure it's a good idea, cause i'm downloading realbot to practice my aim and stuff, not to teach the bots maps :\

Re: Let go off auto-waypointing?
 

navmesh is complicated for me atm, because i have only a vague idea how it works (in theory that is), not in code. PMB said it would be easy to implement, so i bet its handy to take a study on it. Any help on this is appreciated ;)

Re: Let go off auto-waypointing?
 

Have you read this tutorial by PMB? It's really good stuff:)

Navmesh Tutorial:
http://racc.bots-united.com/tutorial-navmesh.html

Re: Let go off auto-waypointing?
 

Yes, i have read it, and i am reading it again. I guess i suck more in math then pmb atm. But frankly i don't have time atm to work on this.

Re: Let go off auto-waypointing?
 

i dont like the idea of having to download wp files, so i heavily suggest not reverting to that. it might be nice to turn off the autonoding tho. would save a little cpu, and prevent silly nodes from being added. it would also be nice to be able to remove a node, or maybe all connections to that node or something.

the navmesh thing looks really cool. if u can get that to work, then i definitely suggest doing that. of course that does take time to learn it and then implement it.

i like the current way of autonoding, altho it does take a while to get the paths down. i usually just run around for one full round, then add the bots. it gets enough paths to play on, and then i just try to take different routes every time.

Re: Let go off auto-waypointing?
 

you can edit nodes connections (removing all, adding connections, etc) already davek ;)

I am giving it a second chance.

Re: Let go off auto-waypointing?
 

true, but i dont like to removeall and start over. that is what it does right, remove all nodes? or does it just remove all connections to the node i am sitting on? guess i should go :RTFM:,

:D stilllove that smilie. despite its like of smiling.

i have also done the removeto, but that gets really complicated when u get a lot of nodes in a tight area.

Re: Let go off auto-waypointing?
 

I think PMB's navmesh is a bit different from Michael Booth's one. PMB's still needs a bit of "training" (it doesn't calculate the connections but tracks player movement to add "navlinks"), but Michael Booth's just calculates the connections directly.

Re: Let go off auto-waypointing?
 

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. ;)

Re: Let go off auto-waypointing?
 

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...

Re: Let go off auto-waypointing?
 

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) :D

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

Re: Let go off auto-waypointing?
 

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

Re: Let go off auto-waypointing?
 

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 ;))

Re: Let go off auto-waypointing?
 

You are not the only one about:

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

Re: Let go off auto-waypointing?
 

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

Re: Let go off auto-waypointing?
 

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...
:D
-eric

Re: Let go off auto-waypointing?
 

Oh I see now, thanks for clearing it up;)

Re: Let go off auto-waypointing?
 

@ Evy, yes i am interested in any source! :D

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.

Re: Let go off auto-waypointing?
 

Stefan

Please find attached some source code:
- DrawNodes.c takes a .RBN as input and generates a .BMP will all nodes and all neighbourood relationships
- DumpNodes.c takes a .RBN as input and displays some statistics about the nodes
- bot.* dll.cpp NodeMachine.* by adding new command (realbot debug nodes/goals/draw) it dumps existing nodes/goals in reallog.txt or generates a realbot0000.bmp with nodes, neighbourhood, goals and paths
- NodeMachine.cpp has also been modified to detect new goals (and to create a node if there are no node close to a goal)

I'll look further in the code for the auto-waypointing.

Thanks again for your time and the information you provided

-eric

Re: Let go off auto-waypointing?
 

thank you i will take a look at them asap. I also have changed my nodeMahcine cpp file to auto-add goals , in fact it was only one line of code ... :)

EDIT:
this dump to bmp thing is actually pretty cool. You can cleary see how many nodes are where and how/if they are connected. I don't see any real problems with that at all. Also goals are found pretty good too. I saw de_dust and de_dust2 being really being 'black' on some spots due so many possible connections. So i'd say this stuff works good.

Its like with most things, the information is available, now lets make some good use of it. :)

Re: Let go off auto-waypointing?
 

Warning,

when you do auto-add a goal, then be sure you skip this for HOSTAGES. Somehow hostages (EVEN WHEN DEAD!) block tracelines/hulls... and they sort of return WORDSPAWN. I dont know why yet. I am investigating how the goal-machine reacts when i walk NEAR a hostage. ..

Re: Let go off auto-waypointing?
 

NEW:

Okay guys,

in addition to the annoying 'bots don't do anything' thingy i have the following:

- a goal can have a bad score

this means;
ie a bot tries to create a path to a goal, when it fails, it gives the goal a BAD score of PLUS 1. So when 10 bots try to go to a goal, and 10 fail, the bad score is 10.

The goal with the fewest bad score is a good one. This means, when you run around the map for the first time and only 1 goal is reachable for some, that this goal will automaticly (pretty fast) become the goal and bots start moving. I saw a bot moving after 1 round now instead after a few. It took some time for the bot to realize the other goals are not ready yet. They will become ready soon.

Every round the bad score gets 1 point less, so eventually they end up to a ZERO score. (and all goals will be reachable again).

I am trying to balance this more or perhaps someone else has a good addition to this?

Re: Let go off auto-waypointing?
 

does this mean that if i start a round with my team vs 10 bots but the bots only have a way to reach one goal, will the other goal get a bad score of 10 if they happen to all try the unreachable one first?

if so, then wont they always choose the reachable one for the next ten rounds, even if i add a path to the previously unreachable goal?

Re: Let go off auto-waypointing?
 

@davek,

Lets say you are on a team with 10 bots, and you have made ONE path to to the terrorist spawn, meaning lets say 2 spawn points are connected. (2 goals).

This means for 10 bots that a few will move to one of the 2 spawn points. The others get a score of 1 (since the goal with the fewest bad score is checked you wont get accumulation that fast, unless EVERYTHING is score 1.. which will not happen with 2 good goals)...

now, when all things EXCEPT the bad goals are scored 1. The next round the bad scores get - 1 and all goals are again at score 0. Meaning the goals are 'in the race' again to be choosen.

THere is one problem, when a specific spawn point cannot reach the 'reachable' goals (because the spawns are not connected) , then bots can give the 'good goals' a bad score as well. However, since a few bots give those good goals NOT a bad score, they will eventually be choosen anyway.

The next step for me is to get the spawn points connected pretty fast. Do mind that when any RB version is officially released the RBN files will be included (as optional package though).

There is code that gives RB the posibility to 'walk around' when no nodes are present. It is quite hard though to make bots walk in a more logical way when there are no nodes available.

Re: Let go off auto-waypointing?
 

ok. cool. sounds good to me now that u explain it that way :)

Re: Let go off auto-waypointing?
 

Nice! I assume the CVS is updated?

Re: Let go off auto-waypointing?
 

Stefan,

As I'm still puzzled ???:( why some nodes are lacking neighbours even when I first run as a human player all over the map... I tried to dig deeper in the RBN files and in NodeMachine.cpp.

It looks like in cNodeMachine::add(), there is probably a mistake:
If I understand it correctly, this means that as soon as the move is not strictly horizontal, a check is done whether a human shape can go through the move without hitting anything.

Which is correct when the player/bot falls, but, IMHO it is not correct when the player/bot just move from one plane to another one (like in moving from an horizontal plane to a downhill slope -- like in as_oilrig when going from the horizontal platform to the downhill slope leading to the 'control tower').

What about a basic test to check whether the player/bot is falling or simply going downhill ? Like:

NB: attached newer version of DumpNodes & DrawNodes with more information and checks.

-eric

Re: Let go off auto-waypointing?
 

Hmm, well i did not really check on that but i did not see troubles with slopes yet. I have to investigate that.

There would be an easier check though to know if a bot is falling (or floating...), i thought there was a function who returns true/false on floating on a specific vector, i think that works better. Anyway, will test ur suggestion.

On what maps does this happen btw? Only as_oilrig?

Re: Let go off auto-waypointing?
 

I did some tests on the line of code you mentioned Evy, but it is not it. So i am looking it somewhere else...

EDIT:

Around line 642, you find some lines that look similiar to the following updated lines... this makes the de_dust crates connectable now.. and i will test as_oilrig now, but i don't forsee any problems

EDIT 2:

I have tested oilrig, and i see another problem. Its done in a few lines later, and actually the lines are not wrong...

The slopes are so steep that a player walking on it is having to much velocity, causing a good distance and also a great difference of height. When checking the node you create and the last created node. The height can be HIGHER then a max possible jump (60 units). THe check fails here, it says "its to high to jump". So going down is no problem now due the given fix above, but going UP is a problem now.

You could say, okay, we remove the height check. But then again you have the problem that nodes will be connected to stuff a bot cannot jump to. Both nodes are not floating. When jumping on normal crates, both nodes are also not floating, so there is not much to change. The condition is here:

perhaps some genius can stand up here?

EDIT 3:

Thanks to PMB i could distinguish a steep slope and a normal slope (crate/flat) and so i adjusted the code and now it connects FINE on oilrig! :) I have updated the CVS ladies....

EDIT 4:
CVS seems to be down, cannot update yet.

Re: Let go off auto-waypointing?
 

EDIT 14918279487329857235:
9_9

(Joking lol)


Did that oilrig problem get fixed? Because, what I would suggest, is if there is upwards motion already (or any motion, really) to allow jumps that extend to 75 or even 90 units, depending on what's needed on oilrig.



By the way... Is there some code somewhere that's limiting the bots to 3/4 walking speed? They do a walk/run constantly... not full running speed but faster than walk (and it makes footsteps)....

Re: Let go off auto-waypointing?
 

the oilrig problem is solved yes.

The walk speed is limited somewhere in the cBot::UpdateStatus() function. It differs for CS 1.6 and CS 1.5, but there is no way to tell how much a bot is limited.

here is the snippet:

in CS 1.5 this info is sent by engine messages, but in CS 1.6 you can directly catch this because engine messages are not sent this way.

Re: Let go off auto-waypointing?
 

source is updated.

Re: Let go off auto-waypointing?
 

Stefan

Last CVS version is MUCH better regarding the selection of goals and paths. Really =)

On the other, when trying to waypoint a new map, I still find some issues/suggestions:

1) doors seem to prevent finding neighbours (probably because the tracehull function detects a door 8o and assumes that it is a wall)... I was unable to put a path between each side of a door in cs_siege and es_cell due.

1.bis) a similar issue would be a 'breakable' between two nodes, if tracehull detects a breakable, it should anyway establish a neighbour

2) the limit of 80 nodes per meredian is not enough... I made some test, and numbers like 100 or 120 are common on some maps. The attached NodeMachine.h has increased the limit to 120 for NODES_MEREDIANS

3) the attached NodeMachine.* is also checking for other goals like VIP rescue zone. There are also 2 ways to find the hostage rescue zone ;)

3.bis) what about adding goals for pre-dropped weapons like on some maps fy_iceworld, ... ? I will try anyway to do it and see what happens

4) cosmetic 8D the comments in BotShouldDuck are a simple cut & paste of BotShouldJump and therefore are quite misleading

5) the debug bitmap has been rescaled a little to avoid placing points just at the border of the bitmap

6) last point, the attached ChatEngine.cpp contains some more code to work with accute letters (I'm French speaking :D ): basically it removes all accent from letters and make the sentence comparison without being case sensitive

NB: the attached DumpNodes & DrawNodes are a little sexier (like drawing the axis & meredians, ...)

Hope it helps you to continue your EXCELLENT job

-eric

Re: Let go off auto-waypointing?
 

Do you encounter any trouble with noding new maps Evy? I hear people got problems and i have to figure this out first before i do anything. It might be musicmans dll or it is a real bug in the bot (which i assume)....

thx for the source files i will download them and apply changes where i find nescesary ;) Ie meredians is a good hint, i never really did a research i did a simple math though :)

Re: Let go off auto-waypointing?
 

You are right, except for es_cell which was new, the cs_siege one was relying on an existing RBN file where the connectivity between nodes is already bad... So, even your fixes of Friday will not help this 'old' RBN file. I'll try to restart from scratch.

-eric

Re: Let go off auto-waypointing?
 

I have made some changes to the distance check and the 'steep' check. Its not much, but its recommended to use them. I will update the source. The changes you proposed are not yet in though, so backup your files first.

Re: Let go off auto-waypointing?
 

I suggest you add display of these 'meredians' (not a clue what you're talking about).

And I also suggest you fix the "realbot node draw" display. The nodes are often invisible even though I am standing right next to them. Is this because there is a limit to the number of sprites it is rendering? I have a Celeron 1.3GHz (a crappy P3, basically) and I find absolutely no problems with filling the screen with those nodes. It'd help a ton because it's difficult noding a map when you can't tell where you've gone.

Re: Let go off auto-waypointing?
 

well, there should be a more effecient way of drawing the nodes. However, i thought there was a limit that the engine could show... dunno exactly though.