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.