Bot aiming bug - fixes
 

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:
at the end of BotBodyTarget function, it seems to improve the bot's behavior.

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

bot.cpp - from the line 3093:
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...

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

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.

Re: Podbot Beta 3.0 Updates? ^^
 

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

Re: Podbot Beta 3.0 Updates? ^^
 

bot.cpp line 5704:
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:
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.

Re: Bot aiming bug - fixes
 

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

Re: Bot aiming bug - fixes
 

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.

Re: Bot aiming bug - fixes
 

Regarding the last problem I've mentioned, about the bot looking at the waypoint origin, this is not resolved in the "e" version.
The problem is that, while the bot moves, as it approaches the lookat origin, that is either lower or higher (if the bot is crouched) compared to the camera/eye origin of the bot, the sight lowers or moves up, tracking the location pointed by the lookat vector (last set to a waypoint origin), even if that is very near the bot or even passing through the body of the bot. This causes unnatural viewing angles. The bot should give the impression that he's looking in the distance, not tracking a point near it.

For the bot, it is very easy to track one point, because it uses the lookat vector, that describes an exact point in space and it's available and it's used for every game frame. For a human player, tracking an exact point is not so easy. A human player usually moves while maintaining the view angle, making adjustments to it as he needs. If he is not tracking an enemy, the human maintains the angle in reference to the ground he walks on.

Of course, this issue is merely cosmetic.