NOTE: Much of the details have been updated (see comments).
It appears that the map name should be received during the initial messages from the Host as it challenges the client. For some reason, none of this takes place as the host never sends a response to the initial connection request from the client.
Original:
I’ve recently been tweaking our game code to network over Steam.
I’m able to successfully create and host a session on Machine A (with Steam Account A) but when I go to connect from Machine B(with Steam Account B), my TravelURL ends up using the projects default game map. An example of the browse log print:
“steam.123456789:7777//Game/Maps/MainMenu_Entry”
Obviously I don’t want to be using the main menu in this client travel URL, I want to be travelling to the map that the host is hosting and currently in. I’m not sure exactly where the problem is occuring. When I look through engine code, it would appear that the FURL constructor does a protocol check and then sets the FURL map member variable to the projects default map. Is this where the problem is occurring, if so why?
On the client, when I step through the code, I can see the session settings correctly, and see that the map name is correctly set to the target map on the Host Machine. I’ve been debugging this all morning and cannot understand why the client is travelling to the wrong location.
UPDATE: ADDITIONAL DETAILS NOT RESOLVED
Further to this, I’ve managed to work out a “Hack” get around for this issue. Once the host player host a a session (and therefore game) type in the same travel URL as an open console command, the session can be joined by the client.
There’s clearly something happening in a open command which doesn’t happen in the logic taken from shooter game.
If someone could assist me with this as soon as possible that would be great, it’s not ideal for my team to have to use this get around constantly for development testing.
Update: Additional details - still no resolved: It appears that when joining the prospective session, the client sends a connection request via the UPendingNetGame, but never receives a reply (no rejection, no handshake, nothing). The host prints to log that it has received the message but appears to do nothing with it (OnlineAsyncTaskManagerSteam.cpp). The host should be sending back some sort of reply (whether it’s rejection, or success to be begin a handshake). The host does appear to hit OnP2PSessionConnectFail in OnlineAsyncTaskManagerSteam.cpp with error 4 which (when cross referenced with the Steamworks API) means Timeout. I have no idea why the timeout is occurring though.
The game still only works if we type in open <mapName>?game=FFA?Listen on the host after a session is created.
Once the console command has been entered, the client can join without any problems.
Our clients were using non-seamless travel when joining the server, but your comment got me thinking.
I realised that our main menu game mode had seamless travel, so host was performing seamless travel to their own server.
Obviously that must have been the difference - once you performed the console command, the host uses absolute/non-seamless travel to rehost the match.
I could have sworn that our game used to use non-seamless travel and had this problem, but there must have been something else in the past causing other problems. Thanks for your reply, even though it seemed like something too obvious, and it wasn’t directly what the problem was, it ended up leading to a solution.
So after all of that, it turns out that despite our clients all using non-seamless/absolute travel to go to the host, the host themselves was not using non-seamless travel.
Once MrMightyErik commented above, it got me thinking (and then realising) that the host wasn’t using non-seamless but that the console command would have triggered a non-seamless travel to the restart/re-host.
Quick tip for anyone else who ends up here: Make sure your host is initialising their session and host game using non-seamless travel. Once into your multiplayer game mode, they should then be able to use seamless travel to continue the game loop (end match > new match etc).
MrMightyErik
Oct 2018
Okay so I am not sure if this will fix your problem but I had a really similar one today.
I fixed mine by making sure that the first time the client connects to the server he does so with a non-seamless travel.
AgentMilkshake1
Oct 2018
So after all of that, it turns out that despite our clients all using non-seamless/absolute travel to go to the host, the host themselves was not using non-seamless travel.
I would like to thank you both, from the bottom of my heart. I just found this and it ended up leading me to the solution for a nearly identical problem that I have been pulling my hair out on for 3 days. Not sure why I only found this post now, but I am ever so grateful that I did.