Steam - Client Timeout (but works with NULL)

I have been working on getting sessions working with Steam.

I followed the following tutorial

I am testing this with 2 different steam accounts and computers. I can successfully see and join sessions that I create.

However, when I join a session it takes me to my MainMenu map instead of my Foo map.
And then shows the connection getting TIMED OUT.

I have attached the server and client logs to this post.



So within the client log I see the following

LogNet: NetworkFailure: ConnectionTimeout, Error: 'UNetConnection::Tick: Connection TIMED OUT. Closing connection.

However, the server travels to the correct map, “Foo”.
My c++ code looks just like the tutorial for this

SessionSettings->Set(SETTING_MAPNAME, FString("Foo"), EOnlineDataAdvertisementType::ViaOnlineService);

UGameplayStatics::OpenLevel(GetWorld(), "Foo", true, "listen");

As you can see the server is calling OpenLevel with the “Foo” map and the “listen” parameter.

Within OnJoinSessionComplete I am calling ClientTravel. Which to my understanding should open the “Foo” map now that the server is on that map. However, as you can see from the logs it opens MainMenu.

void UFPSGameInstance::OnJoinSessionComplete(FName SessionName, EOnJoinSessionCompleteResult::Type Result)
	GEngine->AddOnScreenDebugMessage(-1, 10.f, FColor::Red, FString::Printf(TEXT("OnJoinSessionComplete %s, %d"), *SessionName.ToString(), static_cast<int32>(Result)));

	// Get the OnlineSubsystem we want to work with
	IOnlineSubsystem* OnlineSub = IOnlineSubsystem::Get();
	if (OnlineSub)
		// Get SessionInterface from the OnlineSubsystem
		IOnlineSessionPtr Sessions = OnlineSub->GetSessionInterface();

		if (Sessions.IsValid())
			// Clear the Delegate again

			APlayerController * const PlayerController = GetFirstLocalPlayerController();

			FString TravelURL;

			if (PlayerController && Sessions->GetResolvedConnectString(SessionName, TravelURL))
				GEngine->AddOnScreenDebugMessage(-1, 10.f, FColor::White, TravelURL);
				PlayerController->ClientTravel(TravelURL, ETravelType::TRAVEL_Absolute);

The TravelURL is being output as the following, which is my server’s IP address.

Does anyone know why it is going to the WRONG map? And why I’m getting the timeout?
Will OpenLevel and ClientTravel work like this? Or do I need to use ServerTravel instead of OpenLevel?

I tested this against the NULL subsystem instead of Steam and it all works correctly. The client doesn’t timeout and is put into the correct “Foo” level.

I tried replacing

UGameplayStatics::OpenLevel(GetWorld(), "Foo", true, "listen");



But I get the same behavior as before.

Also, I should note that when using Steam I get 9,999 for the PingInMs session property. But when I use NULL I get correct ping results. I’m not sure if this is related.

I am able to ping the server from the client via cmd just fine. (and the other way around)
As well as run a tracert both ways.

Thank you!

I have the exact same problem. Do you have already found a solution or workaround?

I figured out that the server does not welcome the player. So the client does not know where to travel.

It should look like this:

LogNet: Welcomed by server (Level: /Game/CatchHunt/Maps/UEDPIE_1_Default, Game: /Game/CatchHunt/Blueprints/Game/BP_CatchHuntGameMode.BP_CatchHuntGameMode_C)
LogLoad: LoadMap:

I found the solution!

You just need to add the bIsLanMatch option to your open level call on the server.
Like this:

UGameplayStatics::OpenLevel(GetWorld(), "Foo", true, "listen?bIsLanMatch=1");

More server options

Hope it works for you as well.

1 Like

I had the same issue and this fixed it, but only in the lan case.
When I tried to join a steam session over internet, the same timeout issue appeared.

I just lost my afternoon on this, so I’ll share the fix here :slight_smile:

In the case of an internet steam session, you actually need NOT to mention the bIsLanMatch at all, like this:

UGameplayStatics::OpenLevel(GetWorld(), "Foo", true, String::Printf(TEXT("listen%s"), bIsLanMatch ? TEXT("?bIsLanMatch=1") : TEXT("")));

Not sure if this is a bug.