Spawning on a deploy vehicle sometimes puts player into strange viewpoint

[Colin Basnett]

This is an age-old bug that's been around since the the original "MDV" system. The problem appears to be that of replication.

This can be reproduced 100% of the time by doing the following:

1. Run a dedicated server.
2. Spawn a spawn vehicle and "activate" it (can be done on Freyneux and Lamormenil by turning the engine off).
3. Move player to slot 2 (machine-gun).
4. Use the LeaveBody command. (This is so that the vehicle doesn't self destruct while you're away from it)
5. Type stat net
6. Note the number of channels (eg. 49 Channels)
7. Join Spectator.
8. Toggle the spectator cameras until you're at a viewpoint where the spawn vehicle will no longer be relevant.
9. Wait until your channels drop, indicating the spawn vehicle is no longer being replicated (takes about 5 seconds).
10. Join your old team and attempt to spawn on the spawn vehicle.

Your viewpoint will be borked, and it is only remedied by switching positions or leaving the vehicle.

I'm assigning this to @Matt_UK because the fix for this will probably share a lot in common with other recent fixes compensating for unpredictable replication.

[Colin Basnett]

A quick and dirty fix would be to set bAlwaysRelevant to true for spawn vehicles. However, this still doesn't fix the underlying issue, since the player could, in theory, still not have the actor replicated when he tries to get in the vehicle upon spawning.

[Colin Basnett]

Marking this as a blocker, since it is integral to the spawning system not being a buggy piece of crap. We plan on using the deploy vehicles on more maps than before, so this problem will start to become ubiquitous.

[Matt Hands]

Should be a fix in commit 261157c.

Worked on this jointly with Basnett & kicked ideas around, logging different chains of events. Here are the notes in DHWheeledVehicle (to avoid repetition, other Vehicle classes say read notes in DHWV):

[EDIT - notes removed as updated & expanded later & moved to DHVehicleMGPawn class]

[Andrew Theel]

If this works I'm dumb founded.

[Matt Hands]

Well, it works !

But I also noticed this separate, unrelated bug https://bitbucket.org/darklightgames/darkesthour/issues/369/deploying-into-a-moving-spawn-vehicle dumps player out of vehicle if driver's seat is taken.

Basically, you could only ever try to enter the driver's position of a spawn vehicle. And if the driver's slot was occupied, it didn't try any weapon pawn positions. I've fixed that and resolved that issue, but now that we can spawn into vehicle MG (or cannon) positions it - as is so typical - revealed major camera bugs when deploying into replicating VehicleWeaponPawns ! That problem is pure, good ole' replication timing issues, i.e. the net client has the weapon pawn but not the VehicleWeapon.

Anyway, have solved the new, unrelated problem and will commit. The solution is to use PostNetReceive() to do certain things when certain essential actors are received through replication.

[Matt Hands]

All problems should be fully fixed in commit 6d9c168.

The updated & expanded notes below, now in DHVehicleMGPawn.ClientKDriverEnter, give a full explanation.

    The process of deploying into a spawn vehicle involves spawning a player pawn, possessing it, then entering the vehicle
    Entering results in unpossessing the player pawn, possessing vehicle, moving (effectively teleporting) player pawn to vehicle's location & attaching it as the 'Driver' pawn
    Because vehicle can be on other side of the map & not currently net relevant to the client, the vehicle actors may not exist on the client & have to be spawned locally
    There are a complex series of interactions, which don't always happen in the same order, because actors are not always replicated in the same order

 1. First problem is that the PlayerController is often in state 'Spectating' when the critical PC.ClientRestart() function gets called at the end of vehicle possession
    State 'Spectating' ignores PC.ClientRestart(), most critically resulting in the PC's ViewTarget not being set to the vehicle & POVChanged() not being called on the vehicle
    This gives a completely screwed up camera view, until the player switches to another vehicle position or exits
    After experimenting with various workarounds, I believe the fix below is probably the simplest & cleanest, & it appears to work reliably
    We send the client's PlayerController to state 'PlayerWalking' because that's the normal state a player would be in when entering a vehicle (so it's effectively neutral)
    It is essentially a hack, but it seems to be an effective, safe & minimal hack to achieve a specific & vital purpose (so it's a 'good hack'!)

 2. Second problem affects VehicleWeaponPawns with a VehicleWeapon, i.e. MGs & cannons, where client may not yet have received the VehicleWeapon actor through replication
    Without VW actor, state 'EnteringVehicle' will fail to switch to an interior mesh or play BeginningIdleAnim, which can really screw things up, until player transitions or exits
    Fix is if we don't yet have VW actor, we avoid going into state 'EnteringVehicle' now & instead flag that we need to as soon as PostNetReceive() detects we receive VW actor

 3. Third, lesser problem is that client may not yet have received the VehicleBase actor through replication, in which case we can't set StoredVehicleRotation
    Without StoredVehicleRotation, the player gets an unwanted camera swivelling effect on entering the vehicle
    Fix is if we don't yet have VehicleBase actor, we flag that we need to set StoredVehicleRotatio as soon as PostNetReceive() detects we receive VehicleBase actor

[Colin Basnett]

Re-opening this as it still affects the Higgins boat!

[Matt Hands]

Ah, I see that Higgins vehicle class overrides ClientKDriverEnter, which is where the critical fix is. Will add, test & commit tomorrow morning.Will resolve this.

[Matt Hands]

Fixed for Higgins boat in commit 3cdbc6e.