I’ve run into a weird situation with development with Vive and was hoping someone here could help.
We have developed an application that runs with Vive, and upon testing saw it works fine on 3 of the machines in our office.
However, when we try to send a build to our client (Who is stationed abroad), they seem to be having an issue with connecting the Vive remotes with the application.
It would seem that when they open our application, a 2nd instance of SteamVR opens. The first instance has all the regular hardware connections, but the 2nd can’t seem to recognize any of the hardware, and our guess is that the application tries to read the data from this SteamVR specifically.
Has anyone got an idea on why SteamVR would open in more than 1 instance?
Thanks alot.
(We are running on Unity 5.4.4 with SteamVR 0.17
Unfortunately, I can’t get info on the specs of the client’s machine)
Having the same issue here: works fine on all the machines in the office, not on the client’s machine abroad.
I’m currently investigating two things, in case it helps you:
If you go to SteamVR settings under Developer, there’s a checkbox that says “Start SteamVR when an application starts.” Didn’t fix it for me, but you never know…
How high are the security settings on your client’s machine? Mine has it all on high, and I’ve noticed that when I disable Windows SmartScreen and set the Internet Options to Enable “Launching applications and unsafe files”, they can launch our application normally. Of course this isn’t a permanent solution, but it points to Windows’ security features as being the source of the issue.
My guess is that Windows doesn’t “trust” our apps to access running processes (namely the configured and ready SteamVR), so by default it starts a second one. But since the first one is already using the hardware, the second one is left with nothing.
If someone has a better guess about this, please do share. I’ve been trying to fix this issue for way too long.
Specs: Windows 10 Home, Unity 5.6.2f1, SteamVR version 1504061330
Had the same issue, eventually realized that it was solved when we asked the client to run the application as administrator. Kind of weird, but it solved it.