Bot aiming bug - fixes

[KWo]

I'm not questioning the bug exists, but I'm questioning the source of it since the same happens for the bot skill 100 (for that bot vecRandom should be [0.0, 0.0, 0.0], but it also happens the bot looks and shot into the sky. That may happen only in 2 cases - either z component is somehwere screwed up by some other code (not that one You and me were pointing to) or the vector of lastEnemy position is just a bot-itself position. I believ You have enough time to catch also that. That part You narrowed down until now probably helps a bit with bots with a skill < 100, but why 100 skilled bots are affected, too, by the same bug?
Anyway You are doing a good job - I just don't have enough time last time to make more tests like You are doing.

[mhanor]

I have already admitted in a previous post that I was wrong and you were right, the 100 skill bot is NOT affected because the vecRandom is the zero vector, see here:
http://forums.bots-united.com/showpo...&postcount=530

For now, I set target = pBot->vecLastEnemyOrigin - vecRandom, inside BotBodyTarget, instead of target = pBot->vecLastEnemyOrigin. It's a lazy solution, but I don't have to comment out pBot->vecLastEnemyOrigin = target; or rewrite anything else in that function.

Thanks for taking time to answer

[KWo]

I know what You wrote in previous post, but I know even if the bot is skill 100, there is the problem with bot shooting at the sky. I saw that very often. That's why I'm asking You to investigate more time (if it's possible) to catch that bug, too. This what You have found is affecting bots with skill lower than 100, but there is still something which affects all bots - including those with skill 100.

[mhanor]

Waw... You were right. I was just about to say that I haven't seen such a bug, but I've just witnessed a sudden change of aiming, at the sky, for a 100 skill bot. No firing though. It's kind of rare, compared to the other one.

[mhanor]

Is it normal for vecVisible to be the zero vector at bot_combat.cpp:437 ? An assert here fails pretty often.
Tracking the remaining issues is not as easy as the previous one.

LE:
issue #1: vecVisible is zero at line 437, because it was cleared by the last call of FBoxVisible at line 316.
issue #2: very often, conditions are met that lead to execution of line 276 and 437 for the same BotFindEnemy call. This doesn't look like a good thing.

Both issues seem to happen simultaneously (for the same BotFindEnemy call). Using a temporary Vector for FBoxVisible at line 316 (instead of vecVisible) and line 330, seems to fix the assert at line 437 (vecVisible != g_vecZero). But the 2nd issue remains (I don't yet understand the inner workings of BotFindEnemy).

[mhanor]

When the bot looks at a very near waypoint, approaching it, it does it either standing up - the look gradually lowers to the ground, because the waypoint origin is lower, compared to the eye/camera origin. Or it approaches it crouched, and the look goes up, because, now, the waypoint origin is higher compared to the eye origin. This is why, sometimes, the bot's look seems to follow an arched line across the sky, the bot just passed below the waypoint origin, or it moved in very close proximity to it. I don't have hard facts, I've come to this conclusions after watching a lonely bot navigate the map on its own, with visible waypoints turned on.

But this is not the only remaining issue.

[mhanor]

Maybe the bot shouldn't look at the waypoint origin if it's very near it (that also includes waypoints with radius 0).

c:\work\podbot_mm\bot.cpp line 5704

[KWo]

bot.cpp line 5704:

pBot->vecLookAt = paths[pBot->prev_wpt_index[0]]->origin + pBot->pEdict->v.view_ofs;

The line You are refering to is concerning to the situation - the bot looks at the wall at it's very near to it, but he could look at the previous Waypoint's origin (so he should look backward instead looking at the wall).
This what You are asking for (to don't look at the waypoint's origin if the bot is very near it) is already included in lines very close to this 5704.

bot.cpp line 5752:

      if ((pBot->dest_origin != g_vecZero)
         && ((pBot->fChangeAimDirectionTime < gpGlobals->time) && (!bDestAimingSelected)
         && ( (pBot->cCollisionState != COLLISION_PROBING)
          || ((pBot->cCollideMoves[(int) pBot->cCollStateIndex] != COLLISION_STRAFELEFT)
           && (pBot->cCollideMoves[(int) pBot->cCollStateIndex] != COLLISION_STRAFERIGHT)
           && (pBot->cCollideMoves[(int) pBot->cCollStateIndex] != COLLISION_GOBACK)))))   // KWo - 29.09.2010
      {
         if ((pBot->dest_origin - pBot->pEdict->v.origin).Length() > 15)
            pBot->vecLookAt = pBot->dest_origin + pBot->pEdict->v.view_ofs;
         else
         {
            MAKE_VECTORS (pEdict->v.v_angle);
            pBot->vecLookAt = pBot->pEdict->v.origin + pBot->pEdict->v.view_ofs + gpGlobals->v_forward * 300;
         }
      }

That should keep the bot's vector to look at the the same direction instead at the same point if the bot is very close to the waypoint.

[mhanor]

That line of code is the last that sets vecLookAt (I'm logging it). Looking at the bot at that moment, its sight is directed at a waypoint very near it. I'm not sure if it's limited only to that, but it seems that every time it approaches a camping waypoint, before settling into position, its aiming points toward the previous waypoint. This demo is quite eloquent: http://www.sendspace.com/file/6n3try

[POD]Make my Day (100) vecLookAt = path point.origin (1157.89 2853.93 176.03) c:\work\podbot_mm\bot.cpp 5704

[KWo]

Originally Posted by mhanor

That line of code is the last that sets vecLookAt (I'm logging it). Looking at the bot at that moment, its sight is directed at a waypoint very near it. I'm not sure if it's limited only to that, but it seems that every time it approaches a camping waypoint, before settling into position, its aiming points toward the previous waypoint.

That was exactly expected by the line of code above (bot.cpp 5704) - when the bot is approaching a waypoint near the wall (or some corner - like camping waypint usually is placed), he should look backward - instead looking at the wall in front of his path.

Originally Posted by mhanor

This demo is quite eloquent: http://www.sendspace.com/file/6n3try

Originally Posted by download loaction

demo.zip

File Size: 154.50KB
The file is not currently available. Our support staff have been notified and we hope to resolve the problem shortly. Please try again later.