Bot aiming bug - fixes

[mhanor]

I think I have found how the bot gets its aiming scrambled when a visible enemy hides behind an obstacle, and ends up looking at the floor or at the sky. There's a bad decision somewhere, and the result is in the BotBodyTarget function (bot_combat.cpp), it adds vecRandom to the current value of vecEnemy and vecLastEnemyOrigin (through local static 'target'), while saving these values in the current pBot structure. It will do that for the next several game frames, each time adding vecRandom. I know that for sure because I've watched the code at work. I assume the defect doesn't appear while the enemy is visible because pBot->vecEnemy gets refreshed each frame.

I'm not sure what would be the correct fix, but, by commenting the line:

pBot->vecLastEnemyOrigin = target; // KWo - 25.01.2008

at the end of BotBodyTarget function, it seems to improve the bot's behavior.

[KWo]

That line should save the last visible position of the bot, so he remembers for a while last enemy instead just forget him after 1 second or so. The problem is - the bots hsouldn't react on each noise every frame, becase it's inhuman. When You are hunting an enemy, You are remembering alos the last visible position of him and for some time You are trying to be more careful for that direction, no matter what You can hear around. For bots with lower than 100 skill, the aiming should be a bit scrambled (defined by AIM_OFFS_X,Y,Z) and updated every 1 second (higher frequency - the scrambling effect is annoying and inhuman). That line shouldn't affect the normal aiming for the bot with skill 100.

[mhanor]

As I've said, I don't know if it's a proper fix. The 100 skill bots are also affected.

There's a bad feedback in the code. BotBodyTarget gets called even if the enemy is not visible anymore. The hearing capabilities of the bot are not an issue here. We can assume that it's deaf. I have seen bug in action in both situation, when the bot's enemy was very near and got behind an crate or a wall, and when the enemy was some distance away (when hearing is not possible even for a human).

The pBot->vecEnemy or pBot->vecLastEnemyOrigin are used in BotBodyTarget func, to compute local static 'target', then at the end of BotBodyTarget, vecRandom is added to 'enemy' and pBot->vecEnemy and pBot->vecLastEnemyOrigin get reinitialized with this last 'enemy' value. At the next game frame, same thing happens, using a pBot->vecEnemy or pBot->LastEnemyOrigin, that already has been scrambled by vecRandom in the previos frame. Remember, the enemy is not visible, pBot->vecEnemy or pBot->LastEnemyOrigin have not been refreshed.

Setting a constant vecRandom in BotFocusEnemy and adding some code in BotFocusEnemy func, where it calls BotBodyTarget func:

   if (pHostEdict)
   {
      if ((pHostEdict->v.origin - pBot->pEdict->v.origin).Length() < 30.0)
      {
         UTIL_ServerPrint("[frame %4d before BotBodyTarget] pBot->vecEnemy = (%4.2f %4.2f %4.2f) pBot->vecLastEnemyOrigin = (%4.2f %4.2f %4.2f)\n",
            g_iFrameCounter, pBot->vecEnemy.x, pBot->vecEnemy.y, pBot->vecEnemy.z, pBot->vecLastEnemyOrigin.x, pBot->vecLastEnemyOrigin.y, pBot->vecLastEnemyOrigin.z);
      }
   }
   vecEnemy = BotBodyTarget(pBot->pBotEnemy, pBot);
   if (pHostEdict)
   {
      if ((pHostEdict->v.origin - pBot->pEdict->v.origin).Length() < 30.0)
      {
         UTIL_ServerPrint("[frame %4d after BotBodyTarget]  pBot->vecEnemy = (%4.2f %4.2f %4.2f) pBot->vecLastEnemyOrigin = (%4.2f %4.2f %4.2f)\n",
            g_iFrameCounter, pBot->vecEnemy.x, pBot->vecEnemy.y, pBot->vecEnemy.z, pBot->vecLastEnemyOrigin.x, pBot->vecLastEnemyOrigin.y, pBot->vecLastEnemyOrigin.z);
      }
   }

Here's the output for one 100 skill bot, with a constant vecRandom (at the start of BotBodyTarget) set to (10.0,10.0.10.0) - it helps to observe the issue:
http://www.sendspace.com/file/3qn229
For example, check lines from 774 through 865, and then 928 through 989. Two bots playing on awp_india, one is being observed, while the other hides, then comes again in view, then hides, and so on.

I'm not the only one that has observed the bug, check what Serious Sam said at the start of this page.

[KWo]

BotBodyTarget gets called from BotFocusEnemy function, which gets called only when AIM_EMENY flag is set (that one requires normally to let the bot see the enemy at least for the moment). After 5 seconds or so - if the enemy is no longer visible, that flag should get cleared. That might be a problem if the flag is not cleared. About vecRandom - for the bot with skill 100 that vector should be {0.0, 0.0, 0.0}, so it shouldn't scramble at all the aiming of the bot. Can You try to printout also that vector? Maybe it is somewhere screwed up, so You can see the scrambling effect also for the bot with the skill 100.

[mhanor]

You were right, I forgot that I was overriding vecRandom with my constant vector. vecRandom is (0,0,0) for a 100 skill bot and such a bot is not affected by the problem.
But the problem is there if vecRandom is not the zero vector. If the enemy dissapears from sight and if the bot doesn't hear it, for the next consecutive frames, it will add vecRandom to the bot's current vecEnemy/vecLastEnemyOrigin, and these values return in the following BotBodyTarget function calls. The bot stops "following" the fantom from the sky or from the ground, after 1-2 seconds, I'm assuming the AIM_EMENY flag gets cleared.

The text file I've attached is real, I just overridden vecRandom to observe how vecEnemy and vecLastEnemyOrigin evolve over time.

Although you could see the bug for yourself just by watching the bot in action, here's a demo:
http://www.sendspace.com/file/vzkptd

[mhanor]

[frame 12] target set at line 710 
[frame 12] target is (-556.01 -1102.06 49.03)
[frame 13] target set at line 710 
[frame 13] target is (-556.06 -1101.96 49.03)
[frame 14] target set at line 715 
[frame 14] target is (-556.14 -1101.81 32.03)
[frame 15] target set at line 715 
[frame 15] target is (-556.24 -1101.63 32.03)
[frame 16] target set at line 715 
[frame 16] target is (-556.37 -1101.40 32.03)
[frame 17] target set at line 715 
[frame 17] target is (-556.51 -1101.14 32.03)
[frame 19] target set at line 783 
[frame 19] target is (-546.51 -1091.14 42.03)
[frame 20] target set at line 783 
[frame 20] target is (-536.51 -1081.14 52.03)
[frame 21] target set at line 783 
[frame 21] target is (-526.51 -1071.14 62.03)
[frame 23] target set at line 783 
[frame 23] target is (-516.51 -1061.14 72.03)
[frame 24] target set at line 783 
[frame 24] target is (-506.51 -1051.14 82.03)
[frame 25] target set at line 783 
[frame 25] target is (-496.51 -1041.14 92.03)
[frame 27] target set at line 783 
[frame 27] target is (-486.51 -1031.14 102.03)
[frame  0] target set at line 783 
[frame  0] target is (-476.51 -1021.14 112.03)
[frame  1] target set at line 783 
[frame  1] target is (-466.51 -1011.14 122.03)
[frame  3] target set at line 783 
[frame  3] target is (-456.51 -1001.14 132.03)
[frame  4] target set at line 783 
[frame  4] target is (-446.51 -991.14 142.03)
[frame  5] target set at line 783

Logging the local static 'target' is done inside the BotBodyTarget function. The "target is" is displayed at the end of the function.
At line 783, 'target' receives the current value of pBot->LastEnemyOrigin, then adds vecRandom to it, then pBot->LastEnemyOrigin gets the value of 'target'. It does that the next frame and so on, until AIM_ENEMY is cleared. That's why when commenting that line, the bot stops chasing phantoms, because it breaks this bad loop.

[KWo]

OK. When I have a time I'll try to find a good solution to prevent that side-effect. Basically that function should scramble aiming of the bot with the skill lower than 100, but all of the time the "centre" of the scrambling should be the real last saved enemy position, when he was visible (so it doesn't go to the hell like it does it now). The scrambling should update the aiming position about every 1 second, so it doesn't make the bot shaking (it should make him just worse aiming - like a worse player). I had a problem with bots not wanting to shoot - it came from the fact the "real" enemy position was too much different than the aiming position, so the function to start press "IN_ATTACK" button didn't want to let the bot shoot. That's why aiming position (vector of lastenemy is made like aiming position - which updates vector of last enemy by the target vector.

[mhanor]

Weird. When the enemy hides, I see a lot of shooting, done by any bot if pb_shootthruwalls is set, in the ground and in the sky, which is pretty far away from the real enemy position.

[KWo]

bot.cpp - from the line 3093:

      if (!FNullEnt (pBot->pLastEnemy) && (pBot->bShootThruHeard)) // KWo - 13.07.2008
      {
         pBot->iAimFlags |= AIM_LASTENEMY;
         pBot->iStates |= STATE_SUSPECTENEMY;
         if ((pBot->f_bot_see_enemy_time + 1.0 < gpGlobals->time)
            && (pBot->fLastHeardEnOrgUpdateTime < gpGlobals->time)
            && (pBot->fLastSeenEnOrgUpdateTime < gpGlobals->time))
         {
            pBot->vecLastEnemyOrigin.x += RANDOM_FLOAT (-300.0, 300.0);
            pBot->vecLastEnemyOrigin.y += RANDOM_FLOAT (-300.0, 300.0);
            pBot->fLastHeardEnOrgUpdateTime = gpGlobals->time + 1.0;
         }
      }

If the enemy is "shootable" through the obstacle, every 1 second his position is somehow estimated (he cannot know exactly where the enemy is). As You can see it affects x and y only - so he shouldn't shoot into the sky...

[mhanor]

You're still questioning if the bug exists? I can't tell, using my english skills
The bot can shoot in the sky, that happens when the "vecLastEnemyOrigin -> target -> vecLastEnemyOrigin" loop starts, because the z component of the vecRandom, in BotBodyTarget, is not zero. Am I right? Each bot has a constant skill number, for the remainder of its lifetime. When that loop is in effect, for each frame, it adds that constant vector, set through the BotAimTab vector (index computed using the bot's skill number). As the bot's aim moves, it draws the internal diagonal of a parallelepiped in the space, a diagonal of opposite corners. One of this opposite corners is the true last enemy origin, the other opposite corner has the coordinates of the true last enemy origin plus multiple of vecRandom, which is constant for each bot (because its skill is constant).

LE: actually, it's not a parallelepiped and no straight line is drawn, because vecRandom is not constant, each component is calculated as RANDOM_FLOAT(limit1,limit2). But the z component is not zero (unless it was a random result for that macro, or whatever it is).