PB: "Block with hostage" ignored by Bots?

[Pierre-Marie Baty]

This is great, Wei !

Could you put the download on a site that does not require MSN ? I don't want to install that .NET password stuff...

[Pierre-Marie Baty]

Originally Posted by >BKA< T Wrecks

2,3,5 and 6) Yes, I think this A* pathfinder has its little flaws... Yesterday, when I wanted to test some difficult routes, that bot totally ignored my "debuggoal" commands and never even reached one of the points I specified :'(
Maybe it's because the map has close to 600 waypoints with lots of connections, many of them involving jump combinations etc. and the pathfinder has a hard time getting along with that?

The debuggoal commands may still be trying to use the old pathfinder which is disabled... I gotta check that ; if it's the case making them use the new A* algorithm should fix the problem.

Btw, would it be possible (without totally insane amounts of work) to include a kind of "security flag" that forces the bots to
a) not consider a waypoint as reached before they are actually standing precisely on the spot (right now, there's a certain radius, and if bots move inside that radius, the waypoint is "reached". This can lead to problems with ladders & ledges as well as with those "walk-into" buttons present on some maps).

POD-bot already has a "waypoint radius" feature which allows the waypointer to set the "radius" of a waypoint. Setting a radius of 0 will make the bots reach the waypoint *exactly*.

b) approach the WP walking, unless it's a jump connection?

Not sure it would be a good idea ; the bots would keep slowing down and going faster each second when they reach their next waypoint and leave it...

Keep us up to date with your experiments anyway

[>BKA< T Wrecks]

Originally Posted by Pierre-Marie Baty

POD-bot already has a "waypoint radius" feature which allows the waypointer to set the "radius" of a waypoint. Setting a radius of 0 will make the bots reach the waypoint *exactly*.

Hm, that's not what I was referring to. I know about the waypoint radius that can be set manually. What I was referring to (although I gotta admit I could have expressed myself clearer) is THIS:

[Taken from Count Floyd & Botman's "How to do Waypoints for POD-Bot" document accompanying the PODBot 2.5 release]
"The bots have a hardcoded radius inside my DLL where the Bot thinks he reached this precious waypoints."

This is what makes PODBots vulnerable for some problems, like in the following example:

Imagine a high, straight wall. Imagine its top is just as wide as a man (or bot, if you prefer). Imagine there's a ladder fixed to one side of the wall. Imagine a waypointer wants bots to a) climb up the ladder and b) having reached the top of the wall, turn either left or right and walk along the top of this wall.
What will happen? Well, I`ll tell you: Bots will climb the ladder, and upon reaching the top ladder waypoint, located at a short distance from the first normal waypoint on top of the wall, in direct line with the ladder, they will turn right or left immediately and... *smash* ...die a very ugly death.
Why? I suppose because when two waypoints are relatively close to each other, their hardcoded radii overlap, making the bot unable to distinguish which of the two waypoints he has reached and which one is still a tiny bit away from him.

Another problem with the bots's movement is their tendency to smooth the connections established by waypoints. On open grounds, this makes their movement appear more natural and fluent, but in tricky corners it makes things difficult.
Imagine a door, and right next to the door a "walk-into" button that opens the door. Of course you'll want bots to
a) walk into the button
b) walk a few steps back and to the side, until they face the door
c) walk through the door.
In order to achieve this, your waypoint connections will look a bit like a Z, where the upper left end of the Z is the point where the bot starts. The upper right point is the button. The lower left point is the waypoint in front of the door. And the door is at the lower right end of the Z.
Nice. In theory. In practice, bots will turn this Z into a figure that resembles a horizontally mirrored S, smoothing out the two acute angles of the Z.
This way, they will tend to turn around before reaching the crucial button waypoint, make an elegant curve and bump head first into the door...

Now I was wondering (dreaming) if this hard-coded radius could be deactivated for some waypoints???

(BTW, my posts seem to keep getting longer - if this continues, I'll change my name to "Lord Megathread" and sponsor glasses for you all... :-) )

[Austin]

Originally Posted by >BKA< T Wrecks

What will happen? Well, I`ll tell you: Bots will climb the ladder, and upon reaching the top ladder waypoint, located at a short distance from the first normal waypoint on top of the wall, in direct line with the ladder, they will turn right or left immediately and... *smash* ...die a very ugly death.

This is a known pod 2.5 ladder problem and I have never seen any workaround for it. On some maps they will not even dismount from the ladder. Bummer...

Originally Posted by >BKA< T Wrecks

This way, they will tend to turn around before reaching the crucial button waypoint, make an elegant curve and bump head first into the door...

For this, while editing your waypoints, turn on noclicp mode and fly into the wall some just behind the door button THEN place the waypoint!
Enjoy...

[Pierre-Marie Baty]

Austin, could you send me your super-kickass waypoint editor that you did for PoXBot ? I will put it into this podbot DLL and if I manage to fix the few remaining bugs T Wrecks is talking about soon you'll be able to have the same level of performance than podbot 2.5, at some point, with CS 1.6. This will make people more patient while waiting for the upcoming next generation bots, and perhaps attract more people to Bots United too ; what do you think ?

[Austin]

Originally Posted by Pierre-Marie Baty

Austin, could you send me your super-kickass waypoint editor that you did for PoXBot ?

Sure, sending it now.

But I only worked on it a few nights and all I did was reorganize the commands and menus and added some shortened versions of the commands so you can type wp add instead of waypoint add and pwp on instead of pathwaypoint on, and I fixed some bugs and crashes.

I guess the nice thing is for people new to waypointing there is one menu where you can get to everything so all they need to know (or all we need to tell the new folks) is ONE command to bring up the one main menu, that gets you everywhere else.

We did some pretty serious testing to make sure the waypoints are totally compatible with pod 2.5.

Originally Posted by Pierre-Marie Baty

I will put it into this podbot DLL and if I manage to fix the few remaining bugs T Wrecks is talking about soon you'll be able to have the same level of performance than podbot 2.5, at some point, with CS 1.6. This will make people more patient while waiting for the upcoming next generation bots, and perhaps attract more people to Bots United too ; what do you think ?

1) I think it is great. This is what I thought all along. Why not tweak the 2.6 source to have a great bot, since pod is still a major contender for the #1 spot STILL! I thought we could have a great bot quickly with a minimum amount of effort to "hold us over" until the next generation bots are finished. And also thought this would attract many to this site. This is what I wanted to do starting about the middle of last summer when SoulFather and I started working on Pox.

2) For me it is a bummer, since I HAD TO GIVE UP CS, and shut down my servers. I own my own business and things are just crazy for at least for the next 12 weeks. I have been coding day and night 7 days a week JUST to meet the minimum deadlines... CS was too much of a distraction.

I will send you the code now...

[>BKA< T Wrecks]

Originally Posted by Austin

For this, while editing your waypoints, turn on noclicp mode and fly into the wall some just behind the door button THEN place the waypoint!

Thank you for your help, Austin! The thing is that I already tried this method successfully with POXBot, but then I discovered that with other PB variants the distance for a waypoint to be placed inside a wall also varies - with the new PB plugin, I had to stick the WP even deeper into the wall than with POXbot. And I don't want to know what happens when you place a wayoint so far into a wall that it can be reached from the room on the other side of the door...
Not to mention that with another new pathfinder, the whole mess may change again... *sigh*
That's why I thought that in some cases it might be nice to force bots to reach a waypoint 100% exactly... oh well, what would life be without dreams?

[Austin]

Ok, here is something I forgot to mention.

I really liked pod bot and only ran pod 2.5 on my server but I hated how they bunched up at the doors making them a too easy kill. This was especially bad for my servers where I forced 3-4 humans to the same side against 28 bots! They would really bunch up at the doors. So to fix this here is what I did with great success. The maps became immediately way more fun and playable with the pod bot.

1) I took out all the doors!
You can do this using ripent.exe to export he map entities, hack them to remove the doors and then use ripent.exe to import your changes back in.

You could also remove all doors using botman’s stripper2 utility.
There are two types of doors to look for, func_door and func_door_rotating.
You could also send me a note and ask for my remove all doors utility.
It is a meta mod utility that strips out all the doors.

I did notice a problem with removing all the doors.
On some maps the console will issue an error message when a player triggers the non-existent doors and on some maps that have a lot of doors and a lot of players this can cause laggggg when the message scroll in the console.

(now that I am writing this I just thought that maybe I could have also removed the trigger for the door to avoid this message?)

2) Now I haven’t tried this but this should also work.
Use the same method to hack the map but MOVE THE SWITCH FOR THE DOOR to right in front of the door on the floor! This way the bots will walk over it and never miss it! Tell me what map you are hacking and I will take a look at it and try this for you.

3) The method I finally settled on was this and it works super well.
First I changed all func_door_rotating in all of my maps to func_door.
This way all doors now slide into the wall instead of swinging open. Pod has a terrible time with the doors that swing open.

I then also set the delay, the time the doors will remain open to 30 seconds.
This has the advantage of letting more bots through the doors before it closes helping them to not bunch up.

I also set the speed the doors open to very fast.
This keeps the bots from pausing at the doors while it is opening, and switching into their “I am now blocked so run my unblocking code”. They usually will run right in.

Everyone on my servers could see this giant improvement in game play using these methods.

I actually never hacked a map to move the door switch but I am sure it can be done.
Send me the map name you are working on and I will send you a hacked version.
Now I just thought of something else. Why not add a trigger for ALL DOORS in the maps but place the trigger somewhere, where:

1) The bots will always walk over it before going through it. (may have to do some interesting things with the waypoints to force this)

2) Have it far enough away to insure the door will be open when the bot reaches it.

This would be good.

Of course the idea is to have a bot that can handle doors almost as well as humans, even when 20 are trying to go through at the same time, from both sides!

Now that would be some ace bot coding!

[>BKA< T Wrecks]

Whoa... man, that was the Über-reply, the mother of all replies, the one to rule them all - phew!
It's really a-ma-zing how deep you have dug into that matter and with how many suggestions you come up. I almost feel guilty when I tell you now that I probably won't need most of these methods. Anyway I'm surprised to learn just how many nifty little tools there are to "adjust" a map.
However, I think that with Pierre-Maries PB plugin bot navigation has improved so far that bots take many different ways, thus no longer trying to rush through that little door at the same time. Besides, even rotating doors can be ok for bots to get through if the approach angle is ok, the wp radius is zero and the connection between the two wp's in front of and behind of the door goes through the right half of the door. At least I have never experienced grave problems with rotating doors. Ok, so once in a while a bot needs 3 times to go through, or maybe two bots meet each other just at a door and get stuck for 20 seconds, but all in all it's still more of an exception than a rule. And I just like realistic doors...
Moreover, we (my friends and I) tend to play with no more than 8 - 10 bots on one side (plus us humans), so the danger of bots getting stuck is not that big, too. And I hate it when a map is so full of players that you can't take a step without being involved in firefights... takes the tactical dimension out of it, if you ask me. Oh well, just a matter of taste.

But your method of just removing entities could be VERY interesting in the case of those maps where bots need to push ("use") a door before it opens. Do you know de_snowflake? That's a really nice and interesting map, and a friend of mine asked me to make the waypoints. So I did- only to discover during the test phase that the doors are too much for the bots.
Can maps "modified" with this tool be saved? This might be interesting for the whole bots-united staff, because if one day BU hosts maps it might be a nice feature to have a unique, bot-compatible version to offer!

P.S.: Hostages are also entities, right? I'm just wondering because from CS 1.4 or something on, the third hostage in cs_rio has been unmovable - it might be possible to make this great map fully operational by just removing that one annoying hostage entity. Would that be possible?

[Pierre-Marie Baty]

About the post scriptum:
sure. It "might" not, it *is*.