SteamVR "Always" launches with UE4.24.3 without -vr steamworks arg. or enable hmd if Plugin enabled in project

[uno1982]

In previous versions of the engine you could pass the -vr argument in launch for steamworks and support both flat and VR title options by not calling enable hmd, keeping the setting launch in vr to false project settings and controlling the stereo based on using an hmd detection function. This appears to no longer work. The application will indeed still launch flat but "always" opens steamvr if the plugin is packaged with the application. https://cdn.discordapp.com/attachments/575076664132763653/743666726880935986/FlatSupport.mp4 https://cdn.discordapp.com/attachments/575076664132763653/743666746879377579/exitsteamvr.mp4

[1runeberg]

Hi @uno1982 - yes, this is expected if the plugin is enabled. you can alternatively put a higher priority hmd that is not steamvr if you dont want the plugin to kick in.

[uno1982]

But is there a way to allow a Flat or Steamvr option any longer? used to you could simply not pass the -vr command and steamvr wouldn't just load up no matter what if the headset was unplugged. The problem is that steamvr loads regardless of if a headset is present or not. I guess this wouldn't be a problem but I have people reporting that steamvr "the current beta version" doesn't properly detect if the hmd is indeed present or not for me to control the behavior at the application level.

[1runeberg]

The initialization is controlled by the engine not by the plugin, ideally the engine shouldn't call a SteamVR Init if that param is loaded, but this may be best addressed by Epic. I have noted it down though in case there is a way we can control it from our end in future versions.

[uno1982]

This is a comment from my discord users that are having a problem. 𝓒𝓗𝓔𝓔𝓩𝓤𝓢Yesterday at 9:26 PM it just seems that steamvr has to be open for the game to run if I close steamvr it closes the game short of unistalling steamvr and then launching it idk.

He is saying this behavior exist even while the hmd is completely unplugged from the machine. My application detects the hmd and uses a command to either run stereo or flat. But no matter what I've been unable to not "always" load up steamvr

[uno1982]

The difference is that I can indeed close steamvr as shown in the video and the application stays open. I also do not launch into stereo as his pc is seeming to do in "the beta branch" but I'm in the current build of steamvr and not opted into beta.

[1runeberg]

Yeah, the plugin is meant to have SteamVR on as it's designed to be used with SteamVR - enabling SteamVR however can be controlled by the engine, but in order for any function of SteamVR to work we need to do a SteamVR Init.

So as I mentioned, ideally the engine shouldnt activate the plugin's init function if the engien has the capacity to provide developers with a flat game. Currently the way the engine is architectured, plugins are loaded at load time and must be loaded.

We do not have control over this. but I have noted it in case we can do something from our end in future versions.

[uno1982]

Could you also look into seeing if something has changed with the hmd detection function of openvr? as thats what I'm using to call the stereo command. And I think the beta branch may have modified the way this is handled?

[1runeberg]

Hi @uno1982 - can you open a separate issue for that please in the OpenVR repo :) Thanks!

Please put some more detailed info as well including exact calls you are making and repro steps if any.

[1runeberg]

The difference is that I can indeed close steamvr as shown in the video and the application stays open. I also do not launch into stereo as his pc is seeming to do in "the beta branch" but I'm in the current build of steamvr and not opted into beta.

Hi @uno1982 - are you saying this is only happening in beta? if so, can you please provide this detail in the new issue as well. Since this is runtime related, best in the Steam forums, but i'll prod internally. thanks!

Ideally if you can provide the behavior you are seeing in non-beta vs the issue you are seeing in beta in that ticket or ideally Steam forum post, that'd be great. Let me know the link and i can discuss internally (forum so it'll be visible for others who may be experiencing hte same issues)

[uno1982]

Correct. As shown in my video even though steamvr opens the game uses openvr to detect the hmd and doesn’t run the stereo command and steamvr is fine with you closing it. The game continues to run. In beta branch ppl are reporting to load into stereo meaning it’s like it’s returning true and detecting the hmd even with it not plugged in and if they close steamvr it closes the application. Ticket is here https://github.com/ValveSoftware/openvr/issues/1422

[1runeberg]

Correct. As shown in my video even though steamvr opens the game uses openvr to detect the hmd and doesn’t run the stereo command and steamvr is fine with you closing it. The game continues to run. In beta branch ppl are reporting to load into stereo meaning it’s like it’s returning true and detecting the hmd even with it not plugged in and if they close steamvr it closes the application

Thanks so much for the report @uno1982, will look into it!

[1runeberg]

Hi @uno1982 - trying to replicate this - what are you using on your app to detect hmd presence, is it via an openvr call in C++ or just he BP provided by UE?

[uno1982]

It’s the openvr function that is just blueprint exposed.

[uno1982]

I’ll be able to give you an exact logic chain shortly

[uno1982]

Function is GetisHMDConnected exposed return GEngine->XRSystem.IsValid() && GEngine->XRSystem->GetHMDDevice() && GEngine->XRSystem->GetHMDDevice()->IsHMDConnected();

works in official release but appears to be inconsistent in beta branch of steamvr

GetHMDDevice()->IsHMDConnected() comes from the class HEADMOUNTEDDISPLAY_API IHeadMountedDisplay : public IModuleInterface

My application relies on the XRSystem to get other things like device type as well but because my command isn't ran off of anything other than this one check I don't think anything else would be causing the issue.

[1runeberg]

GetIsHMDConnected isn't part of the standard Blueprints for UE. Is this from another plugin?

[uno1982]

I’m not certain this is a direct path to understanding the behavior of why closing steamvr closes the app but I’m almost for certain it’s because after the engine init returns true the engine assumes the app is utilizing steamvr/openvr .... you get the same behavior at times if the engine editor loads up with an hmd connected and you attempt to close steamvr but if the hmd isn’t connected you can close without issue.

[uno1982]

It’s just an exposed blueprint function that calls the standard function. Create a function in a c++ controller that returns this and include it in your header to expose.... return GEngine->XRSystem.IsValid() && GEngine->XRSystem->GetHMDDevice() && GEngine->XRSystem->GetHMDDevice()->IsHMDConnected();

[1runeberg]

Behavior is consistent for me in a standard VR Template... can you provide a minimal project (e.g. VR Template) that I can test against both SteamVR Release and SteamVR Beta with consistent results? It's looking like in your end that node is returning incorrect results for some reason.

Its beyond scope of our support for any engine issues, but if it's something with our beta runtime or the plugin itself, then we should fix this.

[uno1982]

You’ve been able to load the editor with 4.24.3 in steamvr beta branch without the hmd connected and exit steamvr without it closing the editor?

[1runeberg]

Maybe I'm confusing your issue report here - the one I'm trying to verify is your stereo mode not starting if hmd is not connected (behavior you expected) in a build, the ones you were demoing in the videos.

or are you trying to reporting a new/different issue?

[uno1982]

It’s the same issue I’m calling my stereo command based on the returned value of the same issue. If the editor loads up without an hmd but steamvr inits and thinks there is one because this above xr returns true then closing steamvr results in both my stereo command running without a hmd and exiting steamvr resulting in the initialized app to close (my game and the editor)

[uno1982]

It’s the same underlying issue. That’s why I’m asking “have you been able to load up ue4.24.3 editor allow steamvr to start without an hmd plugged in and close steamvr without it closing the editor” while opted into the beta branch. Because the expected behavior is to be able to close steamvr in the event no hmd was detected and steamvr init gets a false result from xrsystem. The same check is what determines if VR preview is available or the steamvr input icon is displayed regardless of if steamvr loads up

[1runeberg]

Hi @uno1982 - I need to understand the actual issue and do my own root cause analysis. So far I've been unable to replicate it at least with vanilla ue. And no, in 4.24 closing steamvr beta without an hmd doesnt crash or close the editor from my end.

i think im missing somethign here? are you using another plugin that could be using steamvr/openvr calls? or if you can provide me with a minimum project that I can use to investigate, that'd be great.

[uno1982]

It’s not a crash steamvr overlay pops up and says “closing steamvr will close the unreal editor”

[1runeberg]

yeah, that's an expected behavior, but it shouldn't actually close the editor, as the UE Editor is whitelisted to not close.

are you using another plugin that could be using steamvr/openvr calls? or if you can provide me with a minimum project that I can use to investigate, that'd be great.

[uno1982]

I’m not using any other plugins in my reproduction I’m only exposing this blueprint but to reproduce you don’t even need to modify the vanilla project.

[1runeberg]

can you provide me with that minimal project so i can use it for testing?

this is because im not getting the same behavior as yours, so trying to figure out whats different.

init issues usually happen if there are steamvr calls happening somewhere else. but key thing is behavior should be consistent between beta and release.

[uno1982]

Yeah I’ll be able to get you something after I return from the office

[uno1982]

Sorry was on my phone and tried to hit reply

[uno1982]

It seems inconsistent to say the least and “might” be that the function call reference that includes xrsytem in the inherent controller class is causing a “call” similar to what your asking about a plugin or module? Which causes this to occur more frequently? But a plugin isn’t necessary to reference another loaded module directly from a c++ class. None of the following requires an additional plugin(outside of steamvr) to call.

return GEngine->XRSystem.IsValid() && GEngine->XRSystem->GetHMDDevice() && GEngine->XRSystem->GetHMDDevice()->IsHMDConnected();

[uno1982]

https://docs.unrealengine.com/en-US/API/Runtime/Engine/Engine/UEngine/XRSystem/index.html

[1runeberg]

That call is implemented in steamvrhmd.cpp (or at least should be), this part was developed by Epic and should hook up to the XRSystem. We can recommend changes here, but normally issues here are dealt with by Epic directly. Anything else that might be using steamvr i cannot guarantee the effects.

Results should be consistent though between main and beta, which is what I'm concerned about since it might indicate something is broken in beta.

But so far I cant confirm without a minimal project from you where you're seeing inconsistent results between the two,

[uno1982]

Yeah I’ve only been able to replicate it randomly and rarely with vanilla but if I get it consistent enough I’ll send and record it. But I can confirm it doesn’t happen at all with the official steamvr release.

[1runeberg]

would appreciate that @uno1982 , certainly interested in making sure before a beta comes out to "release" we weed out any potential issues unreal devs might face. im just not hitting it on my end.

[uno1982]

My main problem is this is literally the “only” method as of now ue4 devs have to support both VR and flat gameplay as there doesn’t seem to be any steamworks arguments or other methods to offer this. Not without packaging two separate client branches which would be ridiculous

[uno1982]

[uno1982]

Ok so this occurs on the current steamvr release once you've tested using VR preview stop then attempt to close steamvr. Up until that point you can exit steamvr at any time from the editor. The behavior I'm seeing with beta is that you get this behavior regardless and steamvr is somehow telling xrsystem that the hmd is there when it isn't there and whatever is telling steamvr to close the editor "after preview is ran" is already done causing the editor to close without an hmd or a preview being ran. It's just strange inconsistent behavior.

At this point the editor may close or it may hang.

[uno1982]

So i've tested with wmr, and oculus also. Apparently if home, viveport, wmr dash etc services are running steam starts up with the headset in standby. Even with the hmd unplugged and the vive extention box turned off, oculus hmd unplugged and wmr hmd unplugged etc. If the headset was previously detected steamvr must be restarted. I think something in this chain of actions may be the "higher percentage" of the reports of this issue for my users.

[uno1982]

Unless they get the 108 msg they cannot play flat and this seems to be caused by a number of factors based on the way the other services may be feeding steamvr info in the beta branch vs the current branch. I don't know if its because they played a game left up home, viveport, wmr dashboard unplugged the hmd, closed steamvr then when it opens back up its like "yeah there the hmd is, but its in standby" vs the current release etc. I hope this helps narrow things down. But I'm sure its about as clear as mud.

[uno1982]

I'm not for certain this is a beta vs current release problem as much as it's a order of operations issue with no method to clearly tell UE4 that you want to run in FLAT mode within a project packaged with the steamvr module. I'm certain this isn't a problem for most projects as there aren't very many games that are both flat/vr and users that have VR are wanting to load up in the flat version vs the steamvr version that are running ue4.24.3 or higher. Most of them are ue4.22 or below and the argument method worked without issue. Steamvr input was not init within the engine the same way and you had more freedom on how to tell steamvr when to load with an application or not. My flat only players don't have issues because steamvr isn't installed on their machine and apparently if steamvr isn't there then it doesn't matter. The game continues to load up without prompting to install it or anything. Just logs this <[2020.08.14-23.42.15:097][ 0]LogHMD: Failed to initialize OpenVR with code 110> and keeps going about it's business

[uno1982]

I need a way to force the above behavior for players with steamvr installed that want to play flat because detection of the hmd seems to have way too many variables at play or issues with detection ☝️

I'll say it again. I'm not sure what changed or why it changed regarding the -novr, -nohmd argument for launching applications but I'd regard this as a bug and think it should be communicated to steamvr, openvr, openxr, and epic to figure out why this is no longer supported.

There are reddit post all over talking about this exact issue:

"Try "-nohmd" in the launch parameters/startup line, if it happens to be an Unreal Engine 4 game. The Spyro Reignited Trilogy does this. I assume the developers did not disable something in the build/compile of the game. That or SteamVR is suddenly causing it (it didn't used to do it to me on my WMR headset, but the last couple of SteamVR betas, it does now). It looks like it's an old topic too, looking at some posts from some time ago."

https://cdn.discordapp.com/attachments/416040783779463171/744020225548353577/2020-08-14_21-29-08.mp4

[uno1982]

https://github.com/EpicGames/UnrealEngine/pull/6980/files Accept this pull

[uno1982]

https://github.com/ValveSoftware/steamvr_unreal_plugin/issues/106 Looks like this has come up before.

[1runeberg]

Yeah, I'm aware of #106 which is why I tagged this as enhancement in case we can do something from our end, but I can't guarantee it.

For the PR, we have no control over that, developers need to follow this up directly with Epic for the engine fix itself.

[uno1982]

Ok good deal. Thanks Rune appreciate it 👍🏼

[uno1982]

I’m going to close this since it looks like an actual engine issue that may be resolved via cherry picking or pull request.