OnNetworkFailure called repeatedly after host quits

I noticed by printing out a log statement that when ConnectionLost occurs the OnNetworkFailure will be called continuously while the map is still loaded. Loading the menu did not work, but causing a ClientTravel then loading the menu ensured it was only called once.

void UPuzzlePlatformGameInstance::OnNetworkFailure(UWorld* World, UNetDriver* NetDriver, ENetworkFailure::Type Type, const FString& ErrorString) 
{
    UE_LOG(LogTemp, Error, TEXT("Network Failure Occurred: %s"), *ErrorString);
    if (Type == ENetworkFailure::FailureReceived || Type == ENetworkFailure::ConnectionLost) 
    {
         APlayerController* PlayerController = GetFirstLocalPlayerController();
         if (!PlayerController) 
         {
             return;
         }
         PlayerController->ClientTravel("/Game/UI/MenuSystem/MenuLevel", ETravelType::TRAVEL_Absolute);
         LoadMenu();
     }
}
2 Likes

@wirepair That is perfect! Thanks for sharing it mate. <3

I ran into the same issue and tried the recommendation here. However, I found that after the client was kicked back to the main menu that the client couldn’t join a new session on a new host. The log messages said that the session with my session name already existed.

LogOnlineSession: Warning: OSS: Session (GameSession) already exists, can’t join twice

I’m using UE5, so perhaps there’s some new changes related to this, given that this is an old thread. I found that I had to add a SessionInterface->DestroySession after traveling back to the MainMenu level (I didn’t do the LoadMenu call since my level already did that to start with).

However, this triggers the OnDestroySessionComplete callback from earlier (which recreated the game session again in hosting mode), so I had to add an extra boolean field to my GameInstance class to indicate ahead of time whether the create session should be done after the destroy session finishes.

It looks like there’s a parameter on DestroySession that takes a specific completion delegate for a specific call to DestroySession, which I imagine would make for a cleaner implementation in this case.

1 Like