Camera becomes disembodied when attempting to enter a vehicle position that the player cannot

[Colin Basnett]

Steps to Reproduce

1. As Player 1, enter any tank with riders as a Tank Commander and turn on the engine.
2. As Player 2, enter the tank as a Rifleman.
3. As Player 2, press 1 to attempt to drive the tank.
4. As Player 1, begin driving the tank forward.

Results

Player 2's camera will become 'disembodied', as though it has lost its parent translation.

http://youtu.be/e791TIOZFsY

Expected Results

Player 2's camera should have no visible changes in behavior.

[Matt Hands]

This is a very complicated sequence of events !! I don't have a fix yet, but today I found what's causing the problem, so that's probably half way there.

Basic sequence is RiderPawn.KDriverLeave, VehiclePawn.TryToDrive (FAILS as not a tanker), RiderPawn.KDriverEnter. Amongst all that a huge amount of things are getting changed and then changed back: possession, collision, ownership, ViewTarget, etc, etc.

From logging everything I could think of, I've found that on the client the player pawn ('Driver' of the rider pawn) loses its attachment to the tank. This seems to be because AttachDriver isn't being called on the client, I suspect because StartDriving isn't being called clientside on the player pawn/Driver. StartDriving is called by server function KDriverEnter, so you'd only expect it to be called on the server. However, there is this note in Pawn that says StartDriving event is also called on client on transitions of bIsDriving setting. That's native code, including bIsDriving, so we can't get at it, but I suspect the rider failed switching process is not triggering a bIsDriving change, so no StartDriving, no AttachDriver, no Base for player pawn.

After the bug, when you switch between rider positions then AttachDriver gets called clientside and the bug is cured.

But another way of tackling the problem would be to add a clientside check in the rider pawn class when attempting to switch positions. If not an eligible position for a non-tanker then don't even start the sequence of events - no KDriverLeave. Sounds like a workaround, although a simple and probably effective one. But in fact it's probably a positive thing to do anyway, as a simple client check can prevent a wasted sequence of network replication & server processing. A general approach I think could be used more widely to optimise network & server performance.

[Matt Hands]

Fixed as part of commit 28ed820, which implements the new rider pawn replication system.

The fix is clientside sense checks in SwitchWeapon, before sending the ServerChangeDriverPosition function call to the server. This optimises network performance generally, as well as avoiding this rider camera bug.