VRSettings.LoadDeviceByName("None") closes the Editor / Player. Same with OpenVR.Shutdown.

I'm building a multiplayer VR game and trying to run 2 instances of the client on the same machine for more rapid development.

Each time I launch one of the clients, it shuts down the other (which I guess is expected behavior for a VR app) but in our case we want the first client to keep running, with no VR, switching over to an automated bot-mode, so the VR tester can play against a remote AI of sorts, fully testing the netcode, without needing a 2nd VIVE or tester.

Disabling VR should be no problem, but I can't find a way to do it that doesn't also close the app

* VRSettings.enabled stops VR from rendering, but it does not stop the application from being shutdown when a 2nd instance is launched.
* VRSettings.LoadDeviceByName("None") closes the application (including UnityEditor in Play Mode!)
* OpenVR.Shutdown() closes the application (including UnityEditor in Play Mode)

 

FWIW, I also tried it in the reverse. I set NONE as the initial option, and then loaded in OpenVR only in the 2nd instance. Nothing crashed in this case, OpenVR said it initialized ok, but the headset just showed the default loading area, and no input from Unity was received.

This might be two seperate bugs...in this case:
1. Set None as initial option
2. Call VRSettings.LoadDeviceByName("OpenVR")
3. Observe console log: "OpenVR initialized!"
4. Observe as your VIVE headset receives no input from Unity.

 

Asking the VR team to take a look. Regarding OpenVR.Shutdown, I suspect you'll need to take that back to Valve.

 

Thanks guys. This would be allow a huge production boost for us. My hunch is that calling VRSettings.LoadDeviceByName("None"), calls OpenVR.ShutDown() under the hood, causing the app to be shut down, so maybe it's all the same issue.

Ideally just setting VRSettings.enabled=false would be enough to sever the connect to OpenVR without shutting down. We can always call Application.Quit ourselves, and typically Steam manages app lifecycle anyways.

 

Thanks Joejo, will do, are you using f2 or f1? f1 was the latest last night when I was testing this.

 

Alright, so the crash seems to be linked to the presense of the SteamVr [CameraRig] prefab.

If that prefab was active in the scene (at any point), and you load Device "None" the crash will occur.

If you're using just a normal camera, and load NONE, all is good. Here's a reproduction case, but all you need to do on your end is drop SteamVR>[CameraRig] into the scene, and re-run your test. It should crash.

I did find one workaround which is, if I have a script, and set it's Script Execution Order < Default, and I disable the [CameraRig] in Awake(), then it does not seem to get initialized, and the shut down will not occur. Not ideal, but I can work with this approach for now



[Edit] After digging into it some more, I've isolated it to this single line which causes this behavior:

SteamVR_Camera.OnEnable(){
SteamVR_Render.Add(this); //Comment this out to prevent shutdown
}

Can't really figure out why tho....

 

Wicked, thanks for the attention guys really appreciate the quick responses. And thanks for passing on to Valve, wasn't sure how to really go about that.

 

As a more general solution (and one I'll include in the next update) you can modify SteamVR.enabled to the following:

public static bool enabled
{

get
{​

#if !(UNITY_5_3 || UNITY_5_2 || UNITY_5_1 || UNITY_5_0)

if (!UnityEngine.VR.VRSettings.enabled)

enabled = false;​

#endif

return _enabled;​

}
set
{

_enabled = value;
if (!_enabled)

SafeDispose();​

}​

}​