Stoo wrote:
So, since the redirect happens in the Think method, it happens both in the clients and on the server, correct?
Yes.
Although I think that you need to think about the Think() (

) method only as if it was running on the server only:
The Think() method "transfers" an entity from one state to the next.
Human player entities are special mostly because their thinking is not driven by the frame time, but by the incoming player commands.
So would the vehicle also get any kind of position updates on the different clients directly from the server?
Yes.
Is there any chance that a client somehow misses a few command updates, and the vehicle on that client starts "drifting" from where the server thinks it is?
Non-local clients (the other players you see running or driving around) are, for your local client, just like any other server controlled entity: They're updated via the same networking mechanism / type of network messages (
not via player commands).
Your local client uses player commands for prediction (in Think()), and sends them to the server, also for Think(). The server then sends the result of your local client back to you in regular network messages, just like for any other non-local client or monster.
Any "asynchronity" that may occur during this process is automatically and properly handled. (In short, if the servers authoritative data is different from what or where the client thinks it was at the time the servers data is for, it corrects the matter by re-applying the player commands from the time in the past the server sent authoritative data for. This is called re-prediction. It's implementation in Cafu is very robust and reliable, I'm quite proud of it.

)
Also, how would I adjust the camera to render from the vehicle, rather than where the player switches to "driving" mode? I've had some... amusing results from experimenting with this (shot through the map's roof at one point

), but I haven't puzzled out how it should actually work.

Well, I'm not sure how to answer this best, but in the mental model above, where the player internally changes state between walking and driving, the player "becomes" the vehicle when he enters it.
Maybe it helps to think not of a vehicle, but of a jetpack: As soon as the player picks up the jetpack (enters the vehicle), its internal state changes (fly/drive mode instead of walking), with side effects like different physics (jetpacks are flying, vehicles driving, ...), modified head-up-display for flying (or the armatures of a car), and the players model visible to other players changes as well (has the jetpack on the back, or the vehicle all around him).
I admit it's a far shot, but does that provide some answer to your question?
Also, something else:
When I recently started some improvements to the Scripting system, my intention was to only make a short diversion from my current mission (improving the game code), and to return to it quickly, so that I can better help you with your questions and possibly work towards a vehicle sample implementation.
Unfortunately, the Scripting improvements turned out to be a lot more complicated than expected, and took a lot more time. Good news is that it's almost done now, all the brainteasers and cruxes are implemented in the latest revision. (If you're interested, see the UniScriptState.* files in
http://trac.cafu.de/browser/cafu/trunk/Libs for details.)
I still need at least the upcoming weekend to finish this up, but then will return to improving the game code. This in turn is subdivided into several sub-items, but I'll focus on the
HumanPlayerEntT
first (and possibly try implementing some vehicle code, too

). In any case, my (main and/or side) goal would be to make both the implementation of vehicles easier, and to put myself into a position to provide firmer answers to the topic.
