According to what a server-log file was reporting, I went to check a code from 469b - mainly kicker class code for figuring what was improved there...
It's probably improved or not very improved, as far as I know whatever my custom MyLevel kicker is not messing up physics like plain kicker does.
Code: Select all
.....
.....
if ( Other.IsA('Bot') )
{
if ( bWasFalling )
Bot(Other).bJumpOffPawn = true;
Bot(Other).SetFall();
}
Other.SetPhysics(PHYS_Falling);
Other.Velocity += Push;
If you cannot see anything wrong here, perhaps I have to ask everyone (including Epic) what's up when you set physics "falling" in water. Does engine deal with this natively or it's causing that movement stuck as in KongLauncher and when Bot starts running in place in water after a dumb code has set him to fall ?
ALL movement physics in water should be SWIMMING and this "scientific stuff" has to be under a sanity check and not just making pawn to fall in any case.
I see in 469 a comment saying that randomize option won't replicate well - I'm agree, client might have another random data than server. It's why randomizing functions are not that healthy to be simulated because I don't think server will match with client here...
Perhaps mappers are not that dumb for putting this in water (except triggerable water zones...) but... I still have to ask about a pawn FLYING why does it need to be bugged with physics falling just like that, I'm finding this kicker class a joke not a code... A Pawn flying doesn't need to be "helped" by kicker in any way because it will move where wants without external "support" because physics flying allows pawn to do moves as it wants. Perhaps Pawns dying in radius also should have another deal here, just saying...
