Steam recognize the editor as if the game was playing
Steps to Reproduce
Hi There,
since the new release of 5.6, Unreal editor is triggering the “Now Playing” on Steam, this would block anyone from launching a build from within the steam client while having the Editor in background.
I’ve seen that this is caused by the fact that the SDK is now loaded by the FSteamSharedModule, and this is done during the StartupModule and no longer in the Init of the Steam OSS.
In order to fallback to the previous logic, I’ve tried to make this loading lazy, through this method
static inline void LazyInitialize() { if (IsAvailable()) { auto& ModuleRef = Get(); if(! ModuleRef.AreSteamDllsLoaded()) { ModuleRef.LoadSteamModules(); } } }This Lazy load is called whenever ObtainSteamClientInstanceHandle or ObtainSteamServerInstanceHandle is called, while during the Startup Module I execute the “normal” Load only if((IsRunningDedicatedServer() || IsRunningGame())
This way I’ve tried to achieve the same result while keeping the older behavior in editor, but, if some feature required the SteamSDK, it would have been loaded right away.
The only two notable points that require a particular attention are:
- SteamSocketsModule: that checks for dll loading in order to enable steam networking; I’ve added a LazyLoad call here if not Editor
- OSSModuleSteam: I’ve removed the check for dll loading before registering the OSS factory
This seemed to be an effective way of providing a “shared” SDK while being disabled in the Editor, do you see any issue with this approach?
Regards,
Fabio Segantin
Hi Jake,
thanks for the answer here, it’s strange that this behavior arose only after 5.6 migration if nothing changed; I need to check this further to understand why.
Yes lazy loading would simply postpone the issue, thus if it’s triggered, the Editor will be seen as “playing” from there on; the idea was to keep it “as is” in order to avoid explicitly turning off Steam on editor in case it was needed somehow, but to post pone this loading up to the last moment; this way we kind of have both approach limiting all “damages” or discomfort only to a minimum.
I’ll try to check if I understand why it happened in 5.6 but not on 5.5 and eventually come back here.
thanks, Fabio
Hi! We’ve just upgraded from 5.5 to 5.6 and are having the same issue
[mention removed] Have you found the reason for this behaviour by any chance?
We were planning to investigate it on our own, but happened to see this post 
I’ve seen that my solution works up until any feature requiring Steam is used (it was intended to be retro-compatible and to provide the same features as before); unfortunately a lot of our games are using SteamController plugin from the start, voiding the fix altogether.
Setting that plugin’s TargetAllowList to Game solved the issue for the Editor, but we have seen that, any Windows SKU not related to Steam (e.g. Epic Games store) would trigger the same bug because the Target is obviously seen as Game.
[mention removed] Do you have any suggestion on how to restrict those usages? Is it better to provide a global turnoff by ini and using its hierarchy to manually turn on/off the SteamDll loadings?
Not yet, unfortunately my solution seems to reduce the impact, but as soon as a project uses a steam feature, we are back to the original bug (e.g. steam input), I was OOO the last weeks so I didn’t investigate this further yet
Hello,
SteamSharedModule hasn’t been touched since 5.3, not counting the shuffling of IPAddressSteam from the socket subsystem to the shared module.
If I remember correctly, even if you perform the lazy loading for Steam to match the behaviour to what you were previously seeing, it will still have the issue of Steam seeing the game is “open” even after you terminate your session because Steam will now see the editor as an open game executable since it was linked to the standalone exe.
If your workaround is working to fulfill your needs, I would recommend keeping it as I don’t foresee it causing great issues so as long as the Steam OSS is working in the cases where you need it to work. Other possible solutions would be editing the Steam plugins to be game only, or locking Steam behind a custom config so that the editor launches a version of the game that does not have Steam for testing non-Online related components and only testing Steam via standalone.
Thanks, -Jake
How are you separating your separate SKU’s? Following the Lyra example i.e. looking at LyraGameEOS.Target.cs, plugins which use EOS are explicitly enabled in the target file so that they are not loaded in non-EOS configurations. That’s generally our intended way of implementing such a functionality.
-Jake
we use CusomConfigs to separate SKUs, unfortunately Steam is our Default one on Windows, thus we need to disable plugins dynamically from the Target.cs, anyway this seems to work
if (Type == TargetType.Game && ( ( "EpicGamesStore".Equals(CustomConfig) || //Any Win64 SKU || Platform.ToString() == "WinGDK" ) || !IsSteamEnabled()) ) { //Common list from released games. DisablePlugins.Add("Steamworks"); DisablePlugins.Add("SteamShared"); DisablePlugins.Add("SteamSocket"); DisablePlugins.Add("SteamController"); DisablePlugins.Add("OnlineSubsystemSteam"); DisablePlugins.Add("OnlineSubsystemSteamServer"); }Probably fewer plugins could be specified, but this works