Pawn Possession in 4.6.1 Failing

Since moving to 4.6.1 possession of a players pawn fails on the first attempt every time.

I’ve confirmed this by migrating our code back to 4.5.1 and the first call to ClientRestart is successful every time.

Is there anyone at Epic who can possibly point me in the direction of changes that could have affected pawn possession over a network? Perhaps there’s a change that I’m unaware I need to make?

Reading the release notes possession is only mentioned once, and that is in reference to a comment in the code, but something clearly has changed.

It was suggested it could be caused by overriding of BeginPlay in a PlayerController but removing the override did not fix the issue.

What’s incredibly confusing about this issue is the Pawn actually exists on both the server and the client. However when ClientRestart is called the first time the value that the client ends up seeing as the NewPawn is always NULL on the first attempt, despite the server sending a pointer to a Pawn. With the retry you’d think it wouldn’t matter but after the initial spawn the retry signal sent from the client doesn’t make it through until a few retries. As a result the player is left without control of the pawn that is theirs.

Again, this problem doesn’t exist in 4.5.1 and was introduced somewhere in 4.6. I wanted to check out 4.7 to see if it is still an issue but ran into a few of the Known Issues in 4.7 and decided to just migrate back to 4.5.1 for now.

This does not happen at all in the editor with the “Dedicated Server” option selected, only when the server and the client are run separately outside of the editor.

I am more than willing to package up the project and provide it in order to help diagnose this issue if there isn’t some other change I’m missing.

It’s normal for the RPC to get there before the pawn does, and it’s explicitly handled. The only thing I can think of that changed that could cause it to happen every time is the introduction of async loading of networking objects. You can try setting net.AllowAsyncLoading to 0 in defaultengine.ini to see if this changes anything for you.

Thanks John, I’ll give that a try later today!