.:: Bots United ::. - POD-bot back into shape.

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- Releases, Installers, Docs & Coding (http://forums.bots-united.com/forumdisplay.php?f=48)

- - POD-bot back into shape. (http://forums.bots-united.com/showthread.php?t=833)

Re: POD-bot back into shape.

sure, I tested it on 1.5 since I don't have Steam yet.

Re: POD-bot back into shape.

Ok, i compiled the podbot version sucessfully but i still won't startup.
Can anyone test my glibc 2.2 podbot version?

http://80.78.255.195/new/podbot_mm_i386.so
http://80.78.255.195/new/podbot_mm_i386.so

Re: POD-bot back into shape.

Two problems I've noticed after playing a little bit:

-- Bots don't buy after the first round
-- Doesn't work with Realbot WIP #9

First one prevents me from playing...um..fairly...lol

Second one is not much of a problem...just annoying...just wanted to use Podbot to waypoint easier

Also, what's new in the waypoint editor?

Re: POD-bot back into shape.

Some bugs...

1. shield pickup.

else if (iPickType == PICKUP_SHIELD)
{
if ((pEdict->v.weapons & (1 << CS_WEAPON_ELITE)) || BotHasShield (pBot) || pBot->bIsVIP)
bCanPickup = FALSE;
else if (BotHasPrimaryWeapon (pBot))
{
if (!BotRateGroundWeapon (pBot, pent)) // BUG
bCanPickup = FALSE;
}
}

I have changed a little to the BotRateGroundWeapon function (mine returns bool, CF's returns int). In the original PODBot code it should be like this:
if (BotRateGroundWeapon(pBot, pent) <= 0))

2. two crash bugs.

BotThink (bot.cpp):
if ((pBot->iStates & STATE_SUSPECTENEMY) && pBot->bWantsToFire)
{
int iTask = pBot->pTasks->iTask; // BUG

// Don't allow shooting through walls when camping
if (iTask == TASK_PAUSE || iTask == TASK_CAMP)
pBot->bWantsToFire = FALSE;
}

BUG: pBot->pTasks may be NULL sometimes.
in the original PB code: GetBotSafeTask(pBot)->iTask. or you can also check "if (pBot->pTasks)" manually. In my code I moved this code to LastEnemyShootable() function.

SoundAttachToThreat (bot_sounds.cpp):

extern threat_t ThreatTab[32];
.......
iIndex = ENTINDEX (pEdict) - 1; // BUG
ThreatTab[iIndex].fHearingDistance = 800.0 * fVolume;

BUG: ENTINDEX(pEdict) - 1 sometimes may be "out of the range" and this will causes invalid memory access. So we had better change this as well....
(This might be what causes the hostage crash problem IMO)

Here is what I'm doing:

Vector vecPosition = pEdict->v.origin;
if (vecPosition == Vector(0, 0, 0))
vecPosition = VecBModelOrigin(pEdict);

int iIndex = ENTINDEX(pEdict) - 1;
if (iIndex < 0 || iIndex >= gpGlobals->maxClients)
iIndex = UTIL_GetNearestPlayerIndex(vecPosition);

// Hit/Fall Sound?
if (strncmp("player/bhit_flesh", pszSample, 17) == 0
|| strncmp("player/headshot", pszSample, 15) == 0)
{
// don't change iIndex here, and in any following code.....
ThreatTab[iIndex].fHearingDistance = 800.0 * fVolume;
ThreatTab[iIndex].fTimeSoundLasting = gpGlobals->time + 0.5;
ThreatTab[iIndex].vecSoundPosition = vecPosition;
}

3. weapon selecting bug.

BotSelectBestWeapon (bot_combat.cpp):
iChosenWeaponIndex %= 24; // BUG
select_index = iChosenWeaponIndex;

You have added support to new weapons, yeah? like this weapons after 24 will never be selected :) You can change the 24 to "NUM_WEAPONS + 1"

Also it seems CF learnt BASIC first - he kept using abs() when he should use fabs() ;D

P.S. Thanks for your fix. Seems Valve has changed a lot from the initial release of CS 1.6..... I'll add them to my code. Thanks.

My CS 1.6 is still the old version (I copied the required files out of the steam cache with a binary editor in order to run offline. I just don't want to redownload all things with my slow modem). So I haven't any idea about the new CS 1.6....

Re: POD-bot back into shape.

Thanks a lot for this quality feedback ! :)

Quote:

Originally Posted by Whistler

Actually this doesn't matter much, since BotRateGroundWeapon() returns positive numbers only... There's nothing wrong in writing !BotRateGroundWeapon(), or is it ? Booleans are treated like unsigned chars by x86 compilers anyway.

Quote:

2. two crash bugs.

BotThink (bot.cpp):
if ((pBot->iStates & STATE_SUSPECTENEMY) && pBot->bWantsToFire)
{
int iTask = pBot->pTasks->iTask; // BUG

// Don't allow shooting through walls when camping
if (iTask == TASK_PAUSE || iTask == TASK_CAMP)
pBot->bWantsToFire = FALSE;
}

BUG: pBot->pTasks may be NULL sometimes.
in the original PB code: GetBotSafeTask(pBot)->iTask. or you can also check "if (pBot->pTasks)" manually. In my code I moved this code to LastEnemyShootable() function.

Right ! I missed this one... but hey, I can't just wait for ages for the code to crash at this very point in order to notice it :D Looks like you've been luckier than me ;) I'll grep in the source for every occurence of "pTasks->" and replace them with BotGetSafeTask() when necessary. (*edit*: wow, there were a LOT of them actually ! you should check it out too, there are many more than just this place)

Quote:

SoundAttachToThreat (bot_sounds.cpp):

extern threat_t ThreatTab[32];
.......
iIndex = ENTINDEX (pEdict) - 1; // BUG
ThreatTab[iIndex].fHearingDistance = 800.0 * fVolume;

BUG: ENTINDEX(pEdict) - 1 sometimes may be "out of the range" and this will causes invalid memory access. So we had better change this as well....
(This might be what causes the hostage crash problem IMO)

Here is what I'm doing:

Vector vecPosition = pEdict->v.origin;
if (vecPosition == Vector(0, 0, 0))
vecPosition = VecBModelOrigin(pEdict);

int iIndex = ENTINDEX(pEdict) - 1;
if (iIndex < 0 || iIndex >= gpGlobals->maxClients)
iIndex = UTIL_GetNearestPlayerIndex(vecPosition);

// Hit/Fall Sound?
if (strncmp("player/bhit_flesh", pszSample, 17) == 0
|| strncmp("player/headshot", pszSample, 15) == 0)
{
// don't change iIndex here, and in any following code.....
ThreatTab[iIndex].fHearingDistance = 800.0 * fVolume;
ThreatTab[iIndex].fTimeSoundLasting = gpGlobals->time + 0.5;
ThreatTab[iIndex].vecSoundPosition = vecPosition;
}

Nice solution... Although I'm not sure it REALLY can crash... from my experience I noticed that all sounds that were emitted through pfnEmitSound() (and NOT pfnEmitAmbientSound()) are attached to a client. But of course, adding this check won't cost much. Thanks :)

Quote:

3. weapon selecting bug.

BotSelectBestWeapon (bot_combat.cpp):
iChosenWeaponIndex %= 24; // BUG
select_index = iChosenWeaponIndex;

You have added support to new weapons, yeah? like this weapons after 24 will never be selected :) You can change the 24 to "NUM_WEAPONS + 1"

Also it seems CF learnt BASIC first - he kept using abs() when he should use fabs() ;D

Haha, yet one more ! there are countless little bugs like that and it's a real pain to catch them all :D and I'll have a look around and check for the fabs() issue too... Thanks for the hint !

Quote:

P.S. Thanks for your fix. Seems Valve has changed a lot from the initial release of CS 1.6..... I'll add them to my code. Thanks.

No problem, there are certainly a couple other bugs left, as you just proven me :) But what is fixed, definitely is. :)

BTW, you know you can use the [ code ] and [ /code ] tags to post C code in the forums ?

Re: POD-bot back into shape.

Another interesting fix, in BotDoWaypointNav():

Code:

   // BEGIN UBERL33T CODE OF YO MOMMA: special door handling

   UTIL_TraceLine (pEdict->v.origin, pBot->wpt_origin, ignore_monsters, pEdict, &tr);

   if (strncmp (STRING (tr.pHit->v.classname), "func_door", 9) == 0)

   {

          pBot->iAimFlags = AIM_DEST; // look at door and only at it (so it opens in the right direction)

          // if bot hits the door, then it opens, so wait a bit to let it open safely

          if ((pEdict->v.velocity.Length2D () < 2) && (pBot->f_timeDoorOpen < gpGlobals->time))

          {

                 bottask_t TempTask = {NULL, NULL, TASK_PAUSE, TASKPRI_PAUSE, -1, gpGlobals->time + 0.5, FALSE};

                 BotPushTask (pBot, &TempTask);

                 pBot->f_timeDoorOpen = gpGlobals->time + 1.0; // retry in 1 sec until door is open

          }

   }

   // END UBERL33T CODE OF YO MOMMA

Interesting enough for a release perhaps ? 8)

Re: POD-bot back into shape.

although i am not fimiliar with the pod's source , i don't see why this should fix anything? When opening a door, you must look at it, true, but waiting is in my experience just unnescesary code. I mean, when you open a door, you keep walking to it untill it opens...

In fact, a 'stuck' code will not fool into this, because you detect total 'freezement' of a bot to detect if it is stuck...

Re: POD-bot back into shape.

You're wrong Stefan... for a real client yes, you keep pressing the forward button, but for a bot which uses the obnoxious pfnRunPlayerMove, if the bot keeps trying to rush through the door both the bot and the door will get stuck. The door won't open at all, it will just play endlessly the "open door" sound, and the bot will jump/turn around like crazy because it'll believe it's stuck. ONLY if the bot steps back from the door then the door will open. I defy you to show me a RealBot navigating a door correctly if you do it this way. :P

The code I posted works; tested; 200% guarantees; the bot doesn't wait any longer than the time necessary for the door to open, due to the TraceResult check (the TraceLine passes as soon as the door is sufficiently open for a bot to pass too).

Re: POD-bot back into shape.

I still don't see the point. I don't think the RunPlayerMove function has anything to do with this.

THe engine sees an entity that tries to open a door. Simple.

Try this, run a game, and open a door. And when you open the door, walk to it, face it , and keep pressing forward. It will work.

Now, let a bot try this. It will work aswell, why? Because there is nothing changed in the whole 'way of opening a door'. You simply 'push' it. The engine does not give a damn if its a fake client or not here. (it would not make sense).

For opening doors, i have seen RB succeed lots of times. The only failures are because doors are already open (and thus the connection is not valid), so that needs improvement. But the process of opening a closed (not using a button) door is not a problem for RB.

Re: POD-bot back into shape.

Can someone make it so that PODBot & RB play nicely without either the podbot_mm.dll or the realbot_mm.dll crashing?
I want RB to learn off podbot.