AAS_PlayerMovementPrediction() doesn't handle friction correctly

[zturtleman]

Report from @KuehnhammerTobias:

Bots in all games have two main problems (actually there are more, but two issues are really obvious):

• Their jump abilities are really low-skilled.
• Swimming (diving) is really unacceptable.

Both bugs are happen around here: https://github.com/zturtleman/spearmint/blob/master/code/botlib/be_aas_move.c#L592 in the function 'AAS_PlayerMovementPrediction'.

There are several problems:

1. The whole function checks for 'onground' which is sometimes qtrue/qfalse, but after being used a few lines down 'onground' is 'onground = AAS_OnGround(org, presencetype, entnum);' (either abused or naming confusion).
2. It is used to check the friction onground or swimming. The problem here is that predicting jump reachabilities is not onground but jumping is NOT swimming although it is not onground, hence for working jump prediction 'waterfriction' is needed for bypassing this bug.
3. swimming/diving will greatly improve by completely split this part of the function, remove the onground check (the bot can be onground AND swimming) and put all swimming parameters (accel, maxvel, friction) in a seperate if/else block.

In summary these lines are a major problem:

if (onground || swimming)
{
    friction = swimming ? phys_waterfriction : phys_friction;

[ghost]

I think I have found a fix for this issue: It seems that the main problem is how the friction is computed per frame (either onground or swiming). What I tried now is to use the computation from 'PM_Friction' from bg_pmove code instead of the approach from 'AAS_ApplyFriction' inside the bot code. Strange enough the results are good, the output AAS file now has both, jump reachabilities as well as swim reachabilities.

To make it clearer I will sum up the issue again: The default bug was that either jump reachabilities was generated (when compiling an AAS file), or correct swim reachabilities was calculated. The movement prediction code is not only used for generating AAS files, it is also used during bot game, which makes the problem even worse. This bug was already fixed here: https://github.com/ioquake/ioq3/commit/9c4c363cccf0d891c93500d392fa9d80d3070d27 where the specific friction was reversed. This mainly fixed the 'real-time' computation, but NOT the generation of correct AAS files.

I have to admit that I don't really understand why using a modified version 'AAS_ApplyFriction' is fixing the issue, hence I didn't make a PR yet. In other words, if someone is interested in fixing this issue, than I can make a PR, but I would need help than, to better understand whats going on here. I think it is worth noting that ALL idtech3 engines are concerned! Anyways here is a snippet how the reworked 'AAS_ApplyFriction' code would look like:

static void AAS_ApplyFriction(vec3_t vel, float friction, float stopspeed, float frametime) { float speed, control, drop, newspeed; //horizontal speed drop = 0; speed = sqrt(vel[0] vel[0] + vel[1] vel[1]); if (speed) { control = speed < stopspeed ? stopspeed : speed; drop += control friction frametime; newspeed = speed - frametime drop; // Tobias NOTE: why is 'frametime ' needed? See 'PM_Friction'. if (newspeed < 0) newspeed = 0; newspeed /= speed; VectorScale(vel, newspeed, vel); } }

The important thing seems to be 'newspeed = speed - frametime * drop;'

[ghost]

Additionally I will add a small patch I made for World of Padman as a blueprint: bspc-botlib-friction-fix-showcase.txt (rename the file from .txt to .patch or .diff,). Please don't ever apply this file directly as a patch, it was only made for demonstration purposes, to track the issue, though it will also fix the bug, I think. The 'new' solution of reworking the 'AAS_ApplyFriction' function seems more reliable.