<div>Hey Robert,</div><div> </div><div>I was looking at the bulletsim code for avatar movement and noticed that it's implemented with SetLinearVelocity.  It doesn't really have an accumulator or any notion that it shouldn't apply a firm velocity in some directions in some circumstances..   and I think directly setting linear velocity to the TargetVelocity is the thing that is making avatar movement feel unrealistic in many cases.    </div>
<div> </div><div><div>The way that the Physics.Manager interface was implemented for avatar movement was 'target velocity' should reflect where the avatar aims to move in force..   not necessarily it's velocity directly..  it's more like a representation of 'effort'.   This is also why the above scene feeds TargetVelocity to physics only when it changes...    Physics is supposed to hold on to whatever it was set to last and apply it each step until it changes.</div>
</div><div> </div><div>As it is right now, movement is too 'regular'..    and forces get applied in circumstances that don't really make any sense physically.   </div><div> </div><div>For example(again, these are meant to point out issues to help by demonstrating)...   tap page up repeatedly.    BulletSim sets the linear velocity to {<0, 0, 9.983999>} causing the avatar to move up slightly and then fall..   but repeatedly..   the avatar will 'hop upwards' against gravity in thin air.   </div>
<div> </div><div>It should know not to apply a Z force from Avatar Movement when the avatar is not flying and not contacting an object of some kind (best if contact at feet level).       The results of applying a Z Linear velocity improperly can be demonstrated by falling from the air and pressing a directional key.   Note how it improperly affects your Z velocity stalling your fall.   The other side effect of setting Linear velocity is..  when running into objects, you often run through them until, your position moves or you release a key because linear velocity is directly being set and passed to the client causing interpolation to move your avatar through the object until the client gets another update.   The client will get another update when the avatar position moves significantly or rotates or the velocity changes significantly.</div>
<div> </div><div>It seems like..   input from the above scene is being applied once per button press 'push' via TargetVelocity..   which is setting Velocity.. in BSCharacter.Velocity that is then being sent to ForceVelocity and getting applied.     Then the scene stops applying new forces..    because the targetvelocity isn't changing..     and the EntityUpdate call seems to be re-applying the force from the physics engine causing what ever velocity the physics engine is reporting to perpetually repeat as long as the entity keeps updating.</div>
<div> </div><div>I'm trying to be helpful with an explanation.      For avatar movement, I would take TargetVelocity in and, each step, I'd apply an impulse that was likely to get the avatar to the target velocity within certain conditions.    If the avatar wasn't flying..   then the Z component of TargetVelocity should be treated like a slightly delayed jump.   If the avatar is falling and not flying, then Z should be ignored...  the avatar's fall shouldn't be stopped because they pressed a direction arrow...      If AlwaysRun is set, then the X and Y component of the target velocity should be multiplied by a greater then 1 multiplier like 1.3f to increase the velocity and give the effect to the user that the avatar is running.</div>
<div> </div><div>Hopefully this comes across as helpful :)..   that's the intent anyway.</div><div> </div><div>Best Regards</div><div><br>Teravus</div><div> </div><div> </div>