Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Steam Travel URL using default map instead of MapName in session settings

Hi there,

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.


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:


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.


Product Version: UE 4.20
more ▼

asked Sep 03 '18 at 01:03 PM in C++ Programming

avatar image

275 13 18 33

avatar image AgentMilkshake1 Sep 03 '18 at 07:51 PM


So on top of the wrong map loading, 60 seconds later, the client ends up timing out.

I'm assuming this is because the client isn't in the main map/mode so is considered irrelevant and times out.

 LogNet: Warning: UNetConnection::Tick: Connection TIMED OUT. Closing connection.. Elapsed: 60.01, Real: 60.00, Good: 60.00, DriverTime: 60.01, Threshold: 60.00, [UNetConnection] RemoteAddr: <steam address and port here>, Name: SteamNetConnection_0, Driver: PendingNetDriver SteamNetDriver_0, IsServer: NO, PC: NULL, Owner: NULL, UniqueId: INVALID

This is not resolved still.

avatar image AgentMilkshake1 Sep 03 '18 at 10:32 PM

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.

avatar image AgentMilkshake1 Oct 05 '18 at 04:15 PM

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.

avatar image MrMightyErik Oct 10 '18 at 10:24 PM

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. Have a look at the following https://docs.unrealengine.com/en-us/Gameplay/Networking/Travelling

Almost at the top it says when you need to use non-seamless travel

Hope this fixes your problem.

avatar image AgentMilkshake1 Oct 11 '18 at 02:04 PM

Hey MrMightyErik,

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.


(comments are locked)
10|2000 characters needed characters left

1 answer: sort voted first

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).

more ▼

answered Oct 11 '18 at 02:07 PM

avatar image

275 13 18 33

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question