“PlayerStates for all players exist on all machines (unlike
PlayerControllers) and can replicate
freely to keep things in sync.”
If this was true then it should never be printing false. (except for maybe the first few ticks due to order of initialization) So far I’ve only been able to replicate this in the editor but it makes testing multiplayer in the editor near impossible if you use playerstate.
well. i face that “Bug” a few times. seems like both players in editor spawn at the same time , making sometimes the functions on the event begin play and the first ticks of the client to fail. what i v done to avoid that is to add delay (like 0.3sec) to delay all init actions that need the player state.
This is most likely the case. Occasionally, events will fire off in a different order than expected, which can lead to results such as what you are seeing. Adding short delays is typically the way to resolve any problems of this nature.
Nope I already thought of that. (And mentioned it in the question) that screenshot is from 30 seconds+ into the game. Still reporting that playerstate isn’t valid for one of the players.
To solve the problem you guys are talking about, in my actual game I have a macro I run on tick that checks if playerstate exists and if so it fires my custom init event behind a do-once. The issue is it sometimes never gets called. Spent half the day yesterday trying to track it down before I realized that sometimes it just never exists.
I tried checking the dedicated server option in the editor but got the same thing, sometimes no playerstate.
Currently to test I’m packaging every time and using a batch file to launch it twice, once as listen and once connecting to the loopback address. Not ideal but it works without any issues. Makes me wish there was a hotkey to package the default platform
For some reason this is marked as the accepted answer and I can’t un-accept it. Hoping maybe this comment will uncheck it? It’s really confusing how staff marks these as accepted without giving time for me to respond.
I’ll convert the conversation to comments for the meantime. Answers are automatically accepted; however, posting a new comment will reopen the thread. Just for future reference.
Since the delay is not resolving the issue, I’m glad to continue looking into the issue. I’ll report back as soon as I have additional information.
After some additional investigation, it appears that this issue has been resolved in our internal branch, and the fix will be available in a future engine release. Thank you for your report and repro steps.
Hi Sean, that was a little bit old i know, but was this resolved in 4.13?
I’ve seen issues with player state in 4.13 on a dedicated server, if the bug is still there i will wait, if not i will investigate more and start a new bug request.
Thanks!
We can continue to use this thread since it’s the same issue.
I remember testing this a few months back and being unable to run into it in 4.13, so if you’re still seeing it I’d like to get some repro information in order to get a bug in if necessary.
What steps are you taking when this issue is occurring?
I have the same issue with 4.13.2, and I was able to reproduce it with the third person template.
One Player state is valid, others are invalid using PIE.
