T3D 1.1 Final - Slowing Ai Think They're Stuck - w/Fix - RESOLVED (THREED-1977)

T3D 1.1 Final

win7 32bit

Target:
Ai scripts/code, movement, onMoveStuck

Issue:
As an Ai approaches it's destination, it calls onMoveStuck and starts "freaking out" a bit until it finally inches to it's goal and halts. This is because of it's "mMoveSlowdown" variable so that it reduces speed to move smoothly to a stop rather than a sudden halt.

There is a failsafe to prevent onMoveStuck from happening when an Ai starts moving, but not when it starts to stop moving.

from aiplayer.cpp

Quote:
addField( "moveStuckTestDelay", TypeS32, Offset( mMoveStuckTestDelay, AIPlayer ),
"@brief The number of ticks to wait before testing if the AIPlayer is stuck.nn"
"When the AIPlayer is asked to move, this property is the number of ticks to wait "
"before the AIPlayer starts to check if it is stuck. This delay allows the AIPlayer "
"to accelerate to full speed without its initial slow start being considered as stuck.n"
"@note Set to zero to have the stuck test start immediately.n");

Repeat:
Make sure you have an echo in scripts/server/aiplayer.cs "funtion DemoPlayer::onMoveStuck" and "function DemoPlayer::onReachDestination". Spawn an Ai, have them run to a final destination (not a looping path or they'll never stop) and watch them struggle with the final steps and "freak out" whilst they do it. Check the console for onMoveStuck callback spam.

Having slower moving Ai (stock AiManager has the Ai slowed down by 50% - %player.setMoveSpeed(0.5)) makes this worse.


Suggest:
There are a few options available.
Lowering the maxDistance for starting slowdown - 5 units/m is kinda big and slowdown still looks fine when called at just 1 or 2 unit/m.

bool AIPlayer::getAIMove(Move *movePtr)
{
//...
         // Set movement speed.  We'll slow down once we get close
         // to try and stop on the spot...
         if (mMoveSlowdown) {
            F32 speed = mMoveSpeed;
            F32 dist = mSqrt(xDiff*xDiff + yDiff*yDiff);
            F32 maxDist = 2.0f;//5.0f;//yorks
            if (dist < maxDist)
               speed *= dist / maxDist;
            movePtr->x *= speed;
            movePtr->y *= speed;
         }
         else {
            movePtr->x *= mMoveSpeed;
            movePtr->y *= mMoveSpeed;
         }
//...
}

Whilst that is really a workaround, it might be best to actually prevent the onStuckMove callback being when the Ai is in "mMoveSlowDown".

//...
         // We should check to see if we are stuck...
            F32 locationDelta = (location - mLastLocation).len();
            if (locationDelta < mMoveStuckTolerance && mDamageState == Enabled) {//yorks added damageState check
				if (!mMoveSlowdown){//yorks added ignore if we are slowing down
				mMoveState = ModeStuck;
               throwCallback("onMoveStuck");
				}//yorks added this here
//...

Note: that includes my "not onMoveStuck when dead fix here

Whilst this stops the onMoveStuck callbacks, the Aiplayer does still "flip out" a bit (especially when moving slow - %player.setMoveSpeed(0.5) - and up an incline), which I suspect has more to do finalizing their mMoveTolerance distance from the destination than anything else - hence my first code change in mMoveSlowDown.

As ever, remember I'm not a programmer and just make this schtick up as I go (though I do test the hell out of it). :P