Pawn PlayerState reference on client is sometimes NULL
I have run into some problems with the PlayerState reference inside the Pawn class. PlayerState is sometimes NULL on clients. This happens right after loading up a level with a server and multiple clients. It is still NULL if you keep waiting for many minutes, so it should not be a replication issue. It is also completely random which clients it happens with and on how many.
I have provided an image where I show that the PlayerState reference is NULL on two of the clients.
I have managed to isolate this issue down to the Player Controller function BeginSpectatingState that is called immediately at startup on all clients (I dont know why this function is called). The way I see it, the following is what normally happens:
This issue only happens sometimes, and only on clients. Most of the time, the PlayerState is ok. I have managed to reproduce this issue in a project based on the Third Person template. Please see my explanation below for the modifications I made:
Using Engine version 4.8.2, I created a project based on the C++ Third Person template, and did the following modifications:
To test, click the Play button as Standalone Game from inside the editor and test with at least four players (1 listen server and 3 clients). (Testing with more than two players increases the chances for it to happen). I also used the following settings: Uncheck "Use Single Process" and use Editor Multiplayer Mode as "Play As Listen Server".
When clicking the left mouse button on some of the clients, you will hopefully see that on some of them, the PlayerState reference is reported as being NULL. Most of the time however, the PlayerState reference is ok, therefore it is a good idea to test multiple times. Hopefully you will see it as NULL some of the times.
asked Jul 16 '15 at 11:39 AM in Bug Reports
(this is unfortunately not an answer but the system would not let me post my bug confirmation with more than 2000 characters otherwise)
We experienced some random editor crashes when testing our multiplayer game with more than 1 player in PIE where
Turns out that in some cases
I have made a tiny test project which implements a custom AGameMode, AGameState and APawn which just logs out when relevant steps are called during initialization. Then during the bad late call to AMyPawn::UnPossessed and during AMyPawn::Tick it prints a message that things are going badly.
It is seems very much a race condition in that it happens very randomly. Sometimes it doesn't happen at all between editor starts and sometimes it happens every second time. Sometimes it happens more often when testing with 4 or more PIE players instead of just 2.
Here is me running the project in PIE 4 times with 2 players. First and fourth time ended up with the client pawn having no PlayerState. I set the log output to just print info from the client (HasAuthority() == false) and only included lines regarding the controlled pawn here.
As one can see on the bad first and fourth attempt,
We confirmed this on two machines with 4.10.2, 4.10.3 and 4.11.0 preview 5.
The test project is attached.
Thanks for looking into this,
answered Feb 18 '16 at 03:02 AM
We were seeing this relatively consistently in a test project, and I was able to track down what I believe is the reason for some of the calls not working as expected.
The short version of the "fix" is to test for GetPawn() == nullptr in ReceivedSpectatorClass() before calling BeginSpectatingState(). That way only on the initial connect does it cause a problem. In our case, this fixed the problem. We also had a second potential fix that involved rebuilding the PlayerState pointer inside of the client reset when it acknowledged the pawn. This however still caused the Pawn value to thrash by switching to a spectator pawn and back.
The 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 the GameMode's default values.
answered Aug 01 '16 at 07:05 PM
We were able to find the repro for this issue and have submitted a bug report (UE-19058) for investigation.
answered Jul 23 '15 at 02:10 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here