We were seeing this relatively consistently in a test project, and I was able to track down what I believe is reason for some of calls not working as expected.
short version of the “fix” is to test for GetPawn() == nullptr in ReceivedSpectatorClass() before calling BeginSpectatingState(). That way only on initial connect does it cause a problem. In our case, this fixed problem. We also had a second potential fix that involved rebuilding PlayerState pointer inside of client reset when it acknowledged pawn. This however still caused Pawn value to thrash by switching to a spectator pawn and back.
long version of what was happening, based on my testing, was as follows. Note that our Pawn class was loaded via LoadClass and was not loaded by GameMode’s default values.
- Net Player joins
- Player pawn class is loaded via GetDefaultPawnClassForController
- Player pawn is spawned via SpawnDefaultPawnFor
- ClientRestart() is called inside of Server’s Possess
- ClientRestart() sends a null for NewPawn since PackageMap has not ack’d pawn class (blueprint class)
- ClientRestart() happens on client, sets to NULL pawn, does not enter Playing state since Pawn is null
- Controller’s Pawn replicates, calls OnRep_Pawn, sets Pawn
- Pawn’s PlayerState replicates, calls OnRep_PlayerState, sets PlayerState
- GameState’s SpectatingClass replicates, calls OnRep_SpectatorClass, which calls ReceivedSpectatorClass, which is forwarded to all local player controllers
- Since state is Spectating because ClientRestart() failed, and SpectatingPawn is null, it calls BeginSpectatingState()
- BeginSpectatingState() sees that Pawn variable is set, calls Unpossess()
- Unpossess clears Pawn’s PlayerState variable on client
- ClientRestart() is called again on a retry with correct Pawn value.
- ClientRestart() uses SetPawn rather than possess, which does NOT set PlayerState locally
- ClientRestart() AcknowledgesPawn
- ClientRestart() changes state to Playing