Current build registers as Now Playing SteamVR app, can't be used w/other apps

[treyharris]

I built the current head 6fcfebea9fa841e57b6f9e48283e93d0f7a28602 and was using it quite happily last night (the show cursor and always-on-top behavior was great for my use case! but today I can't. It now shows up as the active SteamVR app. So if I start a game, OVRDDP is killed, and if I start OVRDDP, the game gets killed. Simply running OVRDDP now shows up in the "Now Playing" box:

with just a generic now playing string identifier.

I honestly can't tell you what changed since last night. I was on the beta channel, but the beta hasn't changed in a few days (and the release, v1472685831, now matches the beta as of last night).

I also ran OVRDDP as Administrator the last time I ran it (I was having an unrelated issue and just thought I'd try it), and I believe that's the first time I ran this build as Administrator—I'd needed to run the 1.0.5 release as Administrator to get mouse clicks on Firefox to work, as we discussed, but that didn't seem to be the case with this build. Could something OVRDDP can do as Administrator while running, but not as a normal user, cause a pervasive change in future runs only? Because it did work the last time I ran it last night.

[treyharris]

Just read your message in the release notes, I hadn't seen them until now... I hope you feel better soon!

If others can duplicate this issue it might be a showstopper, though, so you might want to remove the v1.0.6 pre-release?

[treyharris]

Just FYI, v1.0.5 is showing this issue on my system, too. So this is either a SteamVR client issue, or it's something that happens after running v1.0.6 as Administrator that affects even prior versions of OVRDDP.

[Hotrian]

Very strange. I will try to reproduce :o

[Hotrian]

I could not reproduce this on the Null Driver. I tried launching as Admin and without, using v1.0.6 v1.0.6-preview and v1.0.5.1; I tried Job Sim, Cosmic Trip, and ED. I also tried launching the game first, or launching OVRDDP first, and it didn't seem to make a difference. I am running the latest SteamVR Beta.

Save files are not currently backwards compatible, so if you are going back to an older version you should delete or rename the folder located at C:\Users\<Username>\AppData\LocalLow\HeadlessOverlayToolkit\OpenVRDesktopDisplayPortal I will try to make the saves backwards compatible in the future to make it easier on everyone.

Pictures for proof: JobSim+1.0.6, CosmicTrip+1.0.5.1, CosmicTrip+1.0.6, ED+1.0.6.

Can you send me your log file? It should be located in the Data folder and called output_log.txt. The log file is erased each time you launch the application, so can you reproduce this issue and then send me the file?

I will try to reproduce this again launching Steam as Admin (which causes SteamVR to launch as Admin, and then this requires OVRDDP launches as Admin as well for some reason), but I don't expect this to make a difference.

[Hotrian]

I tried this again launching Steam as Admin, launching OVRDDP first then JobSim, then closing OVRDDP and launching again. It worked both times and did not close JobSim :o.

Can you try renaming the folder located at C:\Users\<Username>\AppData\LocalLow\HeadlessOverlayToolkit\OpenVRDesktopDisplayPortal

and trying again? It's possible something in your save file is derping it up but I can't imagine what.

[treyharris]

Renaming the folder didn't work, but downloading your build rather than the one I built following your instructions did fix it. Not sure what's wrong with my setup....

But deleting my settings brought up an interesting issue... I use the controller-based positioning, and initially the window was far off in the distance (the Z number read 4). I adjusted it back but then the window was absolutely enormous compared to how I had it. It was also 4. The other numbers were all zeros except for alpha which was 1. Strange, but I could fix that...

In any case, I'm now going again, so thanks for digging into this head-scratcher... if you think it's worth it I can give you more diagnostics, my build continues to produce this issue though yours does not. But probably can just chalk it up to one of those things....

[Hotrian]

initially the window was far off in the distance (the Z number read 4).

Maybe this is because v1.0.6 v1.0.6-preview generates default profiles if none are found? This hasn't been extensively tested but I didn't find any bugs while setting it all up. Strange that all the numbers would read 0 if it in fact had correctly generated and loaded the default profiles.

Edit: Accidentally a word

[treyharris]

What units are the values in? It appears the rotations are in degrees and the alpha and scale are coefficients (and the window size values are display coordinates, obviously) but what about the X/Y/Z? Meters?

I don't know if the origin coordinates for controller-based overlays are quite right; with Z=0, the default controller model's trackpad sticks through the overlay. Tweaking the value to -0.05 fixes that.

[Hotrian]

• X/Y/Z should be in Meters, this is how Unity handles units by default, and I'm pretty certain it's also how SteamVR handles units.
• Rotation is in Degrees. 360° would be a full turn.
• Alpha ranges from 0 to 1, where 0 is fully transparent and 1 is fully solid.
• Scale is in "Width in Meters", where 1 makes the Overlay 1 meter wide, and the Height is handled automatically. This is how SteamVR handles Overlay sizes itself. I didn't do any special processing.
• The origin for Controllers is indeed slightly inside of the controller. This is how the Unity Steam Code handles the Controller itself. I could offset it as you mentioned but didn't feel like changing this since this is where Steam intended the origin of the controller to be, and I'm pretty sure it's also the origin of the model itself.

[Hotrian]

I finally released v1.0.6 :). Can we get a follow-up on this issue?

I removed a bunch of unnecessary files from the source and this should cause Unity to regenerate files on it's own, which may have been the cause of the issue. I am using Unity 5.3.6f1 now though, because there was an issue with 5.3.5f1 and earlier that was fixed in 5.3.6f1, and I am not running into any issues advancing to 5.3.6f1. It's difficult to tell from that Unity Issue Tracker post what exactly was occurring, but IIRC Unity 5.3.5f1 did not like me messing around with Canvas elements that were attached to a non-main camera.

I had those files in the repo because I had issues rebuilding from source without those files, but I can't remember now exactly what the issue was, and I can't seem to reproduce it now.

[Hotrian]

Can we get a followup on this? Were you ever able to get the current head e02568ee7a3f5f630cad66cf7ea8158c79d2b121 to build properly? I tried cloning again multiple times and never had any issues, but there might be something special about my setup that I'm unaware of.

[Hotrian]

Closing this because you never got back to me and I don't have this issue :(. Reopen if this is still an issue.