I’m trying to get the FOnlineSubsystemSteam singleton so I can detect if Steam is initialized before I try to host/join a multiplayer game and pop up an error if it’s not. When I call IOnlineSubsystem::Get() and try to use Cast on the result I just get the compiler error:
2>C:\Program Files\Epic Games\4.9\Engine\Source\Runtime\CoreUObject\Public\Templates\Casts.h(176): error C2664: 'FOnlineSubsystemSteam *TCastImpl<From,To,UObjectToUObject>::DoCast(UObject *)' : cannot convert argument 1 from 'IOnlineSubsystem *' to 'UObject *'
2> , To=FOnlineSubsystemSteam
2> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
2> C:\EGS\DeathTractor\Source\DeathTractor\DTBPLibrary.cpp(127) : see reference to function template instantiation 'To *Cast<FOnlineSubsystemSteam,IOnlineSubsystem>(From *)' being compiled
2> , From=IOnlineSubsystem
I know FOnlineSubsystemSteam inherits from IOnlineSubsystem so I’m not sure why this is failing. What modules do I need to include in my project or headers in the file to get this working? Or is there some other way I can find out if the Steamworks API is initialized?
From what I remember the OnlineSubsystems themselves are inaccessible to game projects by default. Two things you can do though:
You can access the SessionInterface via GetSessionInterface, which will tell you whether or not the online subsystem you have can make sessions at all, which is a little more abstract and platform agnostic.
You can get the OnlineSubsystemSteam as a generic OnlineSubsystem by calling the Get function with an FName like this:
or something similar. It will still be a generic online subsystem pointer, but if it returns anything you know it’s a steam
/3. If you really want to tightly bind to steam, you can add Steamworks to your PublicDependencyModuleNames in your Project.Build.cs and call the Steam API functions directly. The ones you want are probably SteamClient and SteamAPI_IsSteamRunning
Unfortunately, as far as I can tell, the support for the steamworks api is a bit lacking in favor of supporting the generic interfaces. It’s not so bad since the api is really easy to use on its own, but using the platform specific parts that you’d expect to come with the various subsystems is more difficult than it could be, at least to my knowledge.