Well, my thoughts.
As it stands now, our vehicle code is basically: game code authoritative, and
VPhysics along for the ride. Velocity and position (and angular as well) are
all done in PhysicsSimulate(), basically, integrating player input. A
VPhysics shadow of *realistic* mass (read: not "infinite" like player shadow)
is dragged around to match,
Generally, when you're in space, you don't hit much. Since it's game movement
code, I'm running the same codepath on client and server, and pediction is
all good.
Now, touching is the hard part. As I cannot predict collisions client-side,
this is what happens:
1. Server decides that collision has occured. Sets "m_bPhysTouching" to
true. (Networked var).
2. A few millisecs later, client shows that m_bPhysTouching is now true.
Short-circuits prediction.
2. Server decides that collision has ended. Sets "m_bPhysTouching" to false.
3. A few millisecs later, client shows that m_bPhysTouching is now false.
Reverts to predicting.
Basically, whenever the client is told that it is in VPhysics contact, rather
than mispredicting wildly it shuts down prediction and relies soley on server
input. Hence the jumpiness.
----
I could probably fix that problem with some poking at the interpolation
system, to use it in that interval. (How expensive is
ShutdownPredictable()/InitPredictable(), relatively?) The problem, though,
is that I don't think it fixes the base problem. I'm going to take the
player code as an example. Feel free to point out my errors.
As to the player, VPhysics doesn't usually spin or push him very much. For
example, if he's in a big-box room with no massive VPhysics features, the
only things he is affected by is gravity and the walls/floor. In such a
situation, the movement code is almost totally dependent on gamecode, i.e. in
game_shared/gamemovement.cpp. He's basically dragging along a physics
shadow; if he runs through, say, a small prop, gamecode ignores that and runs
straight through, a frame later and the shadow catches up and boots it aside
(hence physical interaction with the world) as it comes by. Game code is
capable of doing all the movement rules (and since it's game code, its easily
predicted) because all it cares about is whether a spot in the map is empty;
if a UTIL_Trace* says it's ok to go there, it goes there, and doesn't have to
worry about the VPhysics consequences (because there aren't any). In some
cases, the VPhysics shadow may even lag slightly behind, if for example
multiple CUserCmds are processed this frame.
Now, for our vehicle. The thing is, our vehicle has to be physically
responsive. If the player crashes into a wall, he just slides off; it our
vehicle does, it has to get spun around physically. As far as I know, there
is no way to predict that. To do it in gamecode, you'd have to be able to do
a sort of tracehull that gives you an actual point of collision and a plane
normal, something which I haven't seen an access to. But if there was a way,
I could get truly predicted physics. (Caveat: I've been talking
about "bumping into" and "collisions" as in bumping into a massive static
object like the World. Those are predictable. Actually bumping into another
VPhysics simulated object would likely lead to the same problems that players
have now.)
So that's my spiel. What do I want to know?
* Preferbly, how to do a tracehull that will give me collision info.
* Failing that, how to temporarily turn off/turn on prediction efficiently.