This is a pretty good summary, but you're missing a couple of things:
> For player movement, what happens is that player's aren't
> really physically simulated at all!
But your own explanation says this isn't true:
> After physics simulation occurs, the player entity is
> reconciled with the VPhysics entity. Any VPhysics damage or
> position/velocity differences are copied back into the
> entity.
So reconciliation could mean that the vphysics data is copied over to
the game - which means the original game simulation is replaced with the
physics simulation. It could also mean that the vphysics data is thrown
away, or blended into the result. It's much more correct to say that
the players are always simulated in game code AND vphysics code. Then
the results are selected or blended based on heuristics. Gravity runs
in both simulations - the output position of the game physics provides
the input direction for the vphysics simulator.
> Correction: the shadow is not updated for every CUserCmd, but
> for every _batch_ of commands.
correct.
> When the commands
> finally to arrive, they are then all simulated in the
> timespace of a single frame.
not correct.
float flSecondsToArrival = ( ctx->numcmds +
ctx->dropped_packets + additionalTick ) * TICK_INTERVAL;
The shadow is updated once, but the resulting output target is reached
over some amount of future ticks.
> What exactly are the non-obvious differences between the
> Player/Vehicle/Shadow/Motion controllers?
Player and shadow controllers are nearly identical. The idea is to
solve an overdetermined system for impulses that will cause the physics
object to arrive at the target position & orientation at some point in
the future (usually the beginning of the next tick). Vehicle
controllers include a vehicle suspension, steering, and engine model -
and are generally forward controllers (you give them input and they
generate physics, they don't solve for impulses).
Motion controllers are just generic hooks to let you introduce your own
impulses to the object at the time that it is integrated. You implement
IMotionEvent and add velocity to the object to "steer" it. A shadow
controller is a motion controller with some specific behavior that
chases targets.
> > To get movement code identical to HL1, effectively all you
> would need
> > to do is remove the code from VPhysicsShadowUpdate(), but then your
> > player would lose all interaction with physics objects, and
> why would
> > you want that?
sv_turbophysics is effectively this plus some forces that push you out
of moving physics objects. Short of predicting the simulation on the
client, this is a reasonable tradeoff once latency is high enough.
Jay
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
