Waypointing

[Kronikles]

Hey,

when my gravebot froze, when my windows xp said to send error report, i checked what is contained in the report and found this

szAppName : hl.exe szAppVer : 1.1.1.1 szModName : hl.exe

szModVer : 1.1.1.1 offset : 009cab46

dunno if thats any help coz i know nothing about AI

Also these files are related to the freeze

C:\DOCUME~1\OWNER~1\LOCALS~1\Temp\WER2F.tmp.dir00\ hl.exe.mdmp

C:\DOCUME~1\OWNER~1\LOCALS~1\Temp\WER2F.tmp.dir00\ appcompat.txt

[Kronikles]

I've been doing more testing and for some reason, on daybreak the loop happens
very early in the game all the time. I've played daybreak about 10 times and it seems to happen in the first 5-10 minutes in the game, nothing more....


E----------D----------I----------T E----------D----------I----------T

When my game froze, I listened to the repeating sounds and I think I could hear the sound of someone spawning in si_deep. When I tried again I could hear the spawning noise again when it froze... spawning the cause??

E----------D----------I----------T E----------D----------I----------T

[hiyahin]

At first, that's what I thought it was, but according to Ghoul, it's more likely to be along the lines of weapons/ weapon changing. Maybe both would cause the freeze?

[Kronikles]

Let's just wait until he is positive that it is something, hopefully this will be fixed soon... :'(

[BuMHeD]

Hey there guys,

I don't want to toss any fuel on the fire, but since we're on the topic of bot issues... I finally got a chance to run my server using your bot. I must say, I have never had more fun fighting bots in my life, so excellent job there. The problem I am having is that when I run a server with serveral bots (I tested it with and 2 human players, we had a server crash. It was an SZ_Getspace error that has been mentioned in previous posts on other forums. The error occurred at the exact moment that an 11th player joined. The server maxplayer value was set for 10, so naturally, when a player attempted to join, a random bot was kicked and the player was admitted... and as soon as the server confirmed his connection, the server crashed for everyone and the aforementioned error was received. The exact error reads as follows:

"SZ_GetSpace: Tried to write to an uninitialized sizebuf_t: ???"

The best research I could do on the topic was a random member of a forum that said that this error is caused when a player and bot are entering/leaving the server... and something with the bot and the HL.exe doesn't "jive.".... If you have any ideas, do share. Sorry to put more bad news out in the open, but I think it's important that you know. I have been able to run the server with small traffic (less than 4 players including bots) for 24 hours. As soon as the traffic gets labor-intensive, and the circumstances mentioned above are fulfilled, the server crashes. Goodluck.

*~BuM~*

[dub]

Ghoul hopefully found the problem (definitely the SZ_GetSpace: Tried to write to an uninitialized sizebuf_t: ??? error) & nice work with the bot.

     respawn_time = gpGlobals->time + 0.5;  // set next respawn time

should be

     respawn_time = gpGlobals->time + 2.0;  // set next respawn time

If this doesn`t fix the major bug add a some logging functions to your bot, I managed to find the podbot_mm num for edict bug with a little log helper
enjoy
Dubb .

[dub]

Just been checking for the bug on si_overtime & it seemed to occur a soon as i attacked a bot carrying a scientist with the briefcase. I`ll do some research and try to help you pinpoint the bug.
Dubb

edit
also a bot has just been killed by a nade when the infinite loop occured.

edit2 crash log

 BotThink
  BotChangeYaw
  BotFixIdealPitch
  BotFixIdealYaw
  BotFixBodyAngles
  BotFixViewAngles
  BotThink
  BotLookForDrop
  BotChangePitch
  BotChangeYaw
  BotHeadTowardWaypoint
  BotFindEnemy
  BotShootAtEnemy
  BotBodyTarget
  WeaponProjectileSpeed
  BotGetLead
  BotBodyTarget
  BotFixIdealPitch
  BotFixIdealYaw
  BotShouldEngageEnemy
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  BotGetEnemyWeapon
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  BotAssessPrimaryAmmo
  WeaponGetSelectPointer
  BotAssessSecondaryAmmo
  WeaponGetSelectPointer
  BotFireWeapon
  WeaponGetSelectPointer
  WeaponGetDelayPointer
  BotAssessPrimaryAmmo
  WeaponGetSelectPointer
  BotAssessSecondaryAmmo
  WeaponGetSelectPointer
  BotAssessPrimaryAmmo
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  WeaponGetAmmoResearchDiff
  BotAssessSecondaryAmmo
  WeaponGetSelectPointer
  BotAssessPrimaryAmmo
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  WeaponGetAmmoResearchDiff
  BotAssessSecondaryAmmo
  WeaponGetSelectPointer
  BotAssessPrimaryAmmo
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  WeaponGetAmmoResearchDiff
  BotAssessSecondaryAmmo
  WeaponGetSelectPointer
  WeaponGetSelectIndex
  WeaponGetSelectPointer
  WeaponGetAmmoResearchDiff
  Switch weapon
  BotFindItem
  WeaponGetSelectPointer
  BotAssessGrenades
  BotAvoidContact

it seem`s like it goes in a inifinte loop in BotAvoidContact

[Ghoul]

I tried that, I added alerts to every function, looked through log after log. Everytime the crash occured, the last function reported was different. I think this is because there is a delay between the ALERT function being called, and it actually being printed in the console.

I just disabled the attacking code (commented out the IN_ATTACK and IN_ATTACK2 lines) and the problem still occurs. I'm pretty sure it doesn't have anything to do with taking damage or attacking, everything so far points to switching weapons. Switching weapons while the bot is doing something.. but what? That's the question.

[EDIT] Actually I have been testing.. and a few times now I have been getting BotAvoidContact as the last function called. I did a few tests to pinpoint this:

Played a game with nearly all weapon function removed. The bots moved around and just constantly switching between two weapons. There were many bots, all running around switching weapons. The game 'crashed' quickly, and I looked at MSVC++ and say "BotAvoidContact" as the last function.

Then I went into a game with just me and a bot. I ran up to the bot so he'd target me and begin attacking (er, switching weapons). After about a minute, the game began looping. Again, AvoidContact was the last function. I started the game again, but this time I didn't join. I just let the bot find a scientst to try and attack. He was there, running at the scientist, switching weapons.. but the game never crashed. The bot wasn't trying to avoid the scientist either, the avoid code wasn't running (for some reason, I'm not sure, something must of been over riding it). I let that run for 5 minutes, and there were no issues.

So, I comment out the if line BotAvoidContact(); in bot.cpp and run the bot again, this time testing to see if the single bot begins looping when trying to attack me. Five minutes go by of him strafing around me in circle switching weapons without a problem. So, I uncomment BotAvoidContact and go back into the game. This time it begins looping in half a minute. Comment BotAvoidContact back out and start the game, this time adding 16 bots. Although it was running at 10 FPS (major console spam from all the functions being called), the bot ran for 20 minutes without crashing (with 16 bots, I'd be suprised if it went for 20 seconds normally). I'm going to do some more tests, then run an overnight test to see if it goes all night. Here is a summary of the problem found so far:

When the bot runs, there is a small chance that HL.exe will enter an infinite loop (it'll begin using 99% of the CPU) under S&I. This ONLY happens under S&I, and involves two things. First, the bot must be switching weapons for the looping to begin (why is one question). Second, the contact avoiding code must be active for the looping to begin. If these conditions are met, the program goes into a loop for some reason. The contact avoiding code is used for bots so that they don't get stuck on each other, monsters, or other objects in the level (note: not walls). The questions are why does switching weapons and contact avoiding cause the problem when they're completely unrelated, and why does this only occur in S&I?

Anyway, I have some more testing to do. If this is indeed the problem, expect a 0.3 very soon.

[dub]

Ghoul found it, definitely happen`s in BotAvoidContact at the end of the function call i added this

          if (pBot->f_avoid_time <= gpGlobals->time && !pBot->pAvoid)
          	{
          		pBot->f_avoid_time = gpGlobals->time + 0.1;
          		// avoid contact
          		BotAvoidContact (pBot);
          		UTIL_DumpToFile ("BotAvoidContact Finished\n");
          	}

and it never reached the finished message, so im 100% certain it happens in BotAvoidContact. Just add a max tries on the BotAvoidContact find entity in sphere loop to fix the bug
enjoy
Dubb .

edit..
shoudn`t you have a break when the bot find`s it required entity to avoid.
ill do some more research later today (5:00am in the uk need to get some sleep).

[Ghoul]

No, when looping through entities there are no breaks (usually) because of how the loop is set up and the function works.

while ((pEnt = UTIL_FindEntityInSphere( pEnt, pBot->pEdict->v.origin, 64 )) != NULL)

Passing pEnt as the first parameter tells the engine to go to the next entity in it's list of entitys within the sphere, until eventually it'll return NULL. When NULL is returned, the while stops.

I know this code works, it's used in the HLDM code and has never caused a problem.

I much just rewrite the function, and maybe the problem will go away.

[EDIT] Just added a simple counter to the loop as well, testing to see if that makes a difference. Will edit this post if it does.

[EDIT2] The looping still occured even though I had created a int set to 0, incremented it by 1 each loop, and added (i < to the loop rules.

I'm not quite sure if it is my code which is causing the problem (as in, my code directly), or code that my code is causing that is causing the problem (in the si.dll, engine dll, or somewhere else). I'm going to leave the bot on all night just for sure test that this fixes it, then I'll do more investigating tomorrow. This all looks mighty promising.