Player State: None on multiplayer clients

I’m currently attempting to access the player states of other players from the local player. However it seems that client pawns don’t have a player state in my setup. Context: Process Scores is called on Tick, Self is my pawn which is created and possessed by the server in my GameMode, the resulting log looks like this:

LogBlueprintUserMessages: [VRBaseBP_C_0] Client 1: I don't have a player state
LogBlueprintUserMessages: [VRBaseBP_C_1] Client 1: I don't have a player state
LogBlueprintUserMessages: [VRBaseBP_C_0] Server: I have a player state
LogBlueprintUserMessages: [VRBaseBP_C_1] Server: I have a player state

Blueprint generating the log:

Additional thoughts:

  • The documentation on PlayerState says the following: “PlayerStates are replicated to all clients”
  • I am able to access all PlayerStates through the GameState PlayersArray on both the clients and the server (however I need to know which pawn is attached to the PlayerState so this isn’t particularly helpful)

This is really strange. Maybe Replicates parameter isn’t true, but it’s true by default anyways.
I had a problem similar to this: when pawn just spawned it hadn’t Player State on clients. It’s appears after couple frames without any notification because of network lag. But I needed PS to initialize the gun, or player will be unable to shoot. Fixed it by moving Player-State-dependent code to server side.
PlayerStates themselves are replicated, their variables always valid among network members.
And yeah, only server should control pawn possession, if client will possess pawn next thing will happen:
Client will possess pawn, but server will think, that nothing happened, so replicated variable PlayerState will stay null;
Client will be able to control pawn, especially if pawn movement isn’t replicated, but as soon as something changes with this pawn on server side there will be problems.

Bumping for visibility.

Thanks for the response! However I don’t think this is quite true as “all” the player states ARE available to every client. However the only reliable way I have found they be accessed is through the GameState->Players Array.

The issue I run into there is that I’m not sure which player state is associated with which pawn. I have put in a hacky work-around where in the GameMode OnPostLogin I assign a replicated variable “pawnReference” to my PlayerState. Then on the pawn I loop through the GameState->Players Array until I find a Player State with a matching pawn.

I suppose the best example of what I’m trying to do (and haven’t seen in any of my searching) is how one would use the playerName variable in PlayerState and put that name above everyone’s (pawn’s) heads in a multiplayer game.

You have actually further bolstered my point :slight_smile:
Player states are on the server. Yes they are replicated, but the SERVER has to be the authority to pass the variables.

As I stated above, you can not get them locally. You need to get the server to do it which is why I mentioned the RPC call. GameState is server which is why it can return it.

PlayerStates does exists on client and clients can get access to them without help of the server. Variables of PlayerStates are also modifiable, but as soon as they changed on server side clients receive values from server and overwrite old ones.

Hi there

Here is an example for you to try:

The example is not perfect but gives you the idea. On begin play it checks if the server is getting the player state, if so, check if valid and feed the variable. If not then the client Ask the Server to get their player state. So the server executes and feeds the client´s player state

Try something similar to my example and it will work. Good luck

This answer made me babyrage a little bit.

player states, although replicate, are on the server
Correct… But are also accessible from clients.
variables within the player state are replicated but you do not own the player state locally hence it is returning invalid on local
Incorrect. The entire idea of replication is to keep clients up-to-date with data from the server. So if player states are replicated, which they are, then clients should always have the same player state data as the server. The only time this is NOT true, is when the replication condition is not met, or when clients locally change replicated variable data (which will be overwritten when it changes on the server)

I have very similar question.
@Dr_Jerm: Did you ever found a answer or get the point why player state are invalid sometimes?