Perhaps this is an issue with the DestroySession Blueprint function.
When players join a game, they are first taken to a lobby, then travel to a game-play map via seamless travel after everyone selects their options.
If a client calls DestroySession from the lobby that they initially joined, it works fine.
If a client calls DestroySession after seamless travelling to the game-play map. It fails.
The lobby and the game-play map use different PlayerControllers, and DestroySession takes a base PlayerController reference as an argument. I find the argument odd because all the API functions I see on the C++ side of things only take a string for the session name that you want to destroy, and doesn’t act on a player controller.
Is it possible that in an effort to expose DestroySession to blueprints that the devs put the SessionName in the PlayerController when they join, but forgot to copy it to the new controller when they are swapped?
Edit: The following warning prints to the log:
DestroySession - Cannot map local player to unique net ID
I guess the ID is getting lost somehow when switching maps. Not sure how that could happen though.
Some one should take a look at your C++ or Blueprint of “DestroySession”.
There’s not much to it. I join a session and it brings the client to the lobby map that the server hosted a session in. To keep things simple, I just call the DestroySession BP function when a key is pressed on a client, then print the result, success or failure.
If I do it from within the lobby (the map that was used to host the session) the client successfully destroys the session.
If I do it after the server takes the client to the gameplay map via seamless travel, it fails.
I know that the travel was successful because both the server and client are properly replicating in a match over the network, so obviously, the session is still open.
I’m literally calling one function and getting different results before and after travel.
Well this one was pretty silly on my part.
The reason why it fails is because I overwrote the CopyProperties function in the PlayerState. It allowed me to carry over player info from one map to the next, like their character and color choices. However, I forgot to call the base class version of CopyProperties.
Sure enough, when looking through the source, the base PlayerState::CopyProperties function copies over the net ID and other session information. Thus, when travelling maps, all of that was lost. So once I added the base class call, all was well.
Oops.