.:: Bots United ::.  
filebase forums discord server github wiki web
cubebot epodbot fritzbot gravebot grogbot hpbbot ivpbot jkbotti joebot
meanmod podbotmm racc rcbot realbot sandbot shrikebot soulfathermaps yapb

Go Back   .:: Bots United ::. > Cyborg Factory > POD-Bot mm > Releases, Installers, Docs & Coding
Releases, Installers, Docs & Coding Where the official development happens

Closed Thread
 
Thread Tools
Re: POD-bot back into shape.
Old
  (#11)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 46°43'60N 0°43'0W 0.187A
Default Re: POD-bot back into shape. - 23-02-2004

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



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."
  
Re: POD-bot back into shape.
Old
  (#12)
eAnic
Guest
 
Status:
Posts: n/a
Default Re: POD-bot back into shape. - 23-02-2004

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

Last edited by eAnic; 23-02-2004 at 04:22..
  
Re: POD-bot back into shape.
Old
  (#13)
[+Duracell-]
Member
 
Status: Offline
Posts: 65
Join Date: Jan 2004
Default Re: POD-bot back into shape. - 23-02-2004

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.
Old
  (#14)
Whistler
Summoner
 
Whistler's Avatar
 
Status: Offline
Posts: 1,499
Join Date: Feb 2004
Location: Mist Village
Default Re: POD-bot back into shape. - 23-02-2004

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.
Old
  (#15)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 46°43'60N 0°43'0W 0.187A
Default Re: POD-bot back into shape. - 23-02-2004

Thanks a lot for this quality feedback !

Quote:
Originally Posted by Whistler
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))
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 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 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 ?



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."
  
Re: POD-bot back into shape.
Old
  (#16)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 46°43'60N 0°43'0W 0.187A
Default Re: POD-bot back into shape. - 23-02-2004

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 ?



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."
  
Re: POD-bot back into shape.
Old
  (#17)
stefanhendriks
RealBot Author
 
stefanhendriks's Avatar
 
Status: Offline
Posts: 3,088
Join Date: Nov 2003
Location: Netherlands
Default Re: POD-bot back into shape. - 23-02-2004

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


Author of RealBot, "Arrakis" and "Dune 2 - The Maker" | co-Founder of Bots-United | Fundynamic | Blog | E-Mail me
  
Re: POD-bot back into shape.
Old
  (#18)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 46°43'60N 0°43'0W 0.187A
Default Re: POD-bot back into shape. - 23-02-2004

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.

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



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."
  
Re: POD-bot back into shape.
Old
  (#19)
stefanhendriks
RealBot Author
 
stefanhendriks's Avatar
 
Status: Offline
Posts: 3,088
Join Date: Nov 2003
Location: Netherlands
Default Re: POD-bot back into shape. - 23-02-2004

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.


Author of RealBot, "Arrakis" and "Dune 2 - The Maker" | co-Founder of Bots-United | Fundynamic | Blog | E-Mail me
  
Re: POD-bot back into shape.
Old
  (#20)
DreamLord34
Member
 
Status: Offline
Posts: 415
Join Date: Jan 2004
Default Re: POD-bot back into shape. - 23-02-2004

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


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
vBulletin Skin developed by: vBStyles.com