PODBOT2.6MM after PMB...work still pending

[stefanhendriks]

to know if a bot is a vip :

// Is the edict a vip or not?
bool
UTIL_IsVip (edict_t * pEntity)
{
  if (mod_id != CSTRIKE_DLL)
	return false;
  else
	{
	  char *infobuffer;
	  char model_name[32];
	  infobuffer = (*g_engfuncs.pfnGetInfoKeyBuffer) (pEntity);
	  strcpy (model_name, (g_engfuncs.pfnInfoKeyValue (infobuffer, "model")));
	  if (strcmp (model_name, "vip") == 0) // VIP
 return true;
	}
  return false;
}

[>BKA< T Wrecks]

Wow... respect! Now we have 2-3 guys willing to continue the project (Austin / sPlOrYgOn / MusicMan), a moderator to keep things on track (SoUlFaThEr), and invaluable input from 1337 bot coders (stefanhendriks and of course PMB) - this looks good! Just wanted to give all you guys some support and encouragement - that's the least I can do. Thumbs up, guys!
Concerning the button thing: Stefan, which button did you refer to? The ones a bot walks up to is not such a big problem. All it takes is clever waypoint placement there. The buttons that require a player to "use" them are what's more problematic.
Oh, and I'd like to throw in another thought: Bots can often be observed pushing a "walk up to" button, and then running into the door before it has fully opened, thus blocking it. This way, even if a second bot "pushes" (=walks to) the button, the door might stay closed. With "use" buttons it's really the same, only worse (bots don't even push the button many times).
Would it be possible to keep bots from blocking doors somehow? I already mentioned this to PMB and SF once, but it kinda got lost in the middle of so many other issues, so here I go again:
Is it possible to determine whether an entity is in idle or triggered state? Is it possible to tell bots something like "if [entity that's triggered by the button the bot has just reached] is idle, then activate the trigger and wait for n seconds [determined by waypoints] before proceeding, else don't activate trigger and proceed to next node?
Hehe, this must sound like totally helpless baby talk to you coders, but imagine if we could get bots to even use elevators properly... 9_9

P.S.: There are even maps where bots get killed by opening doors (cs_arabstreets[2], cs_vineyard). Even if they succeed in pushing the button, they run into the door and die. So this waiting function would really make sense, I think. However, I can't tell if that's totally utopic and out of range or actually feasible...

[SoUlFaThEr]

i just hope that the things these different gentlemen do come together properly in one update.....meaning:

if the both have the same sdk.....and both do different things to it and release it.....we have 2 separate .dll's. one with his fix, one with HIS fix.

but i know it will be ok ... im just an old worry-wart!!

thanks for support T-Wrecks

[stefanhendriks]

i think i can get elevators working in CS_SIEGE

anyway, to get on the buttons:
as you said, on touch buttons you simply need a clever waypoint placement. FOr use buttons its actually the same. In fact, you can stand 'pretty far' to a use button!

What i do is like with hostages to use them:

- get near button
- use it
- set timer
- resume path to goal x

about the timer,
i use a simple fUseButton timer, when the timer is below gpGlobals->time , the bot is allowed to use a button. When it is above, it is not.

For multiple bots using a button and such, id on't see the problem really? I Have been playing de_prodigy and de_rats with dozends of bots, but did not encounter a problem.

Perhaps it is because my bots will ONLY use a button when it finds an obstruction in its path! It is not programmed to use a button BEFORE it hits the door. It goes the other way around:

- bot walks to waypoint/node
- bot traces a line to this waypoint/node
- when the traceline gets a hit to an entity read out what it is
- when it is a door only THEN start the 'find button and go to it' procedure. In this procedure the bot will also remember the button

when the bot has a button to remember it will also execute the 'what to do with the button when i am close'.

[>BKA< T Wrecks]

Hmmm.... *me exhausting my 3 brain cells*... let's see:

1. What you said about touch buttons is true, I think we agree on that...

2. What you said about push buttons (WP doesn't even have to be that near) is true as well, also in PB 2.6mm. Bots will go a longer distance to push a button. But there's something I don't understand. When I waypoint, I usually make bots pass a button first and then walk through a door. This way, the node sequence looks like this [bot approaching]...node 1 (near button)...node 2(in front of door)...node 3 (behind door)...[continue]. If the bot walks like this, can he check for the problem between node 2 and 3 (path obstructed by entity) BEFORE he looks for the trigger, which is already located at node 1? Or would your method mean that I could just waypoint happily through a door, and that bots would "sense" the entity obstructing their path and then stray from the waypoints to hit the button, and finally return to the node they were about to go to?

[SoUlFaThEr]

if its implemented the way he said it......you can just happily waypoint STRAIGHT throught the door without a worry man

no shit!

about cs_siege, one word :

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!

i hope you can assist our lads working on pod2.6mm to get those sort of "incredible masterpiece" code sequences to work here Stephan.

looks like theres another guy i have to SQUEEEEEEEZe

[stefanhendriks]

Afaik, i don't care about how you walk to a door, ie. If i walk to the button first and then go through the door (which is logical, i am not a bot ) then the bot does not care.

i don't know abou tpod waypointing that much, but i think you can still use the method. The bots will just sense the path is obstructed. You will have to overwrite the old path with a temp new path to the button, then when you hit the button, you simply create the path to the goal again, and u're done!

as for cs_siege, here is my theory:

set a flag on the waypoint/node that requires to be on an elevator. This waypoint MUST be on the floor of that elevator. When you set the flag, the waypoint will search for the entity that is the elevator and remember this. (so in editing mode the elevator should be downstairs, u should be in the elevator and then set the flag). Now, you also should have the node/waypoint at the button too already. When you got these 2 , then you are finished.

1) The bot will go to the node of the elevator
2) the bot will notice that this node is flagged
3) it will now go to the button you refer to by the flag
4) the bot goes to the button, hits use
5) the bot will go back to the elevator

[SoUlFaThEr]

ok heres a question based on your listed explanation of the elevator process:

once the bot does hit the button and goes back into the elevator......will he wait? because they used to do that to...hit the button in siege, get in the elevator as waypointed with special one-way paths......but then the bot never waits......and comes back out.

i had trid one time in as_steel to make the bot run in circles inside the elevator after hitting the button...........all with oneway paths.......this was a SERIOUS PITA...because back then there was no autopath max distance menu!
i did the same with de_station(awesome map! but ruined by the elevator)

my point is.....podbot cant stand still waiting unless he thinks he may be in danger if he moves.....willl he wait on this flagged waypoint after hitting the button?

[sPlOrYgOn]

I think i'm just going to stop changing the code now and just look through it for a few days/weeks until i get used to/know where to find/navigate it really fast.
btw PMB

// On Assault Maps target VIP first !

on line 150 bot_combat.cpp

[Austin]

Originally Posted by sPlOrYgOn

I think i'm just going to stop changing the code now and just look through it for a few days/weeks until i get used to/know where to find/navigate it really fast.

We need to sort out how this is going to fall together.
We need a "code librarian" if we are gong to have several people working on the bot or it will be total kAIos. Something that could work at first, for simple isolated changes is what sPlOrYgOn has already done. (sPlOrYgOn not bad for a first try at it. The first thing I will do when I get back and finally get started is have a look at this but it looks like you are on the right track and your efforts will not be lost.)
1) Put in a fix AND TEST IT!
2) Post the code here in the forum.
3) We all agree that the bot should work like this.
4) The librarian adds in the code and does the build and posts the release with source and custom installer..

I would volunteer to do this. But you guys have to be patient for about 2 more weeks. I still will have some time and be chinking in every few days.

BTW,
What is THE EXACT source we are starting with?
I noticed some new POD26MM projects in the filebase.
The source that is in the podbot.zip from the filebase is exactly the same as
the source I got from PM's site on 4/12.

PM, anyone, is this THE version to start with?