[BETA] [Build 624] Wrist overlay missing

[SteeveMonkey]

The wrist overlay seemingly does not render at all when the app is launched through steam.

Steps to reproduce the bug:

1. Launch XSOverlay by either clicking play on it in the steam library or launching SteamVR with XSOverlay set as a Startup Overlay App
2. Wait for XSOverlay to load
3. Look at back of wrist

Expected behavior: When the app finishes loading, I expect to find the wrist overlay located on the back of my wrist, however it is seemingly nowhere to be found.

Output Log: Launched from Steam Library: output_log_2023-10-17__05.34.00.txt Launched directly from executable: output_log_2023-10-17__05.40.04.txt

Additional Information: I have discovered that I can get around this issue by launching the executable directly from the app files instead of launching it through Steam. This causes XSOverlay to connect to SteamVR and have its status tracked by steam like normal, while the wrist overlay renders as expected.

[Xiexe]

Hi, is this still happening after the latest beta 625 RC5 update?

[SteeveMonkey]

I can confirm that this is still an issue in the latest beta build (build 627). I didn't see your comment before build 627 was released, so I was unable to test on build 625.

I also realized that I forgot to mention another difference in behaviour between the two launch options: When launching directly from the executable, there is a little grey XSOverlay window that opens up on my desktop and stays there while the app is running, which does not seem to show up at all when launched through Steam.

I also did a little more testing in the latest build to see if I could find any more differences in behaviour between the two different launch methods. When doing so, I discovered that when launching through Steam, the UI seems to be physically present in the play space but is invisible, as I can get the little blue pointers to show up on the back of my wrist and also an area in the floor in the centre of the play space. The wrist makes sense as it lines up with where the wrist UI would be (although the size and shape of the area seem off to me, but that is hard to determine accurately without being able to see the UI). However, the only thing I can think of for the area in the centre would be the Setting UI which used to show up there in older builds, but I can't find anything there when I launch directly from the executable. The only piece of UI I have managed to get the capture overlays to show up by double-clicking 'X' on my left Oculus Touch controller, and was able to interact with them like normal, just unable to access or see the UI that normally shows up underneath each overlay. I also was unable to get the pointers to show up on anything other than the capture overlays after opening them for the first time, even when closed the pointers would not show up in the areas I could get them to do so before

[Xiexe]

The only difference between launching through steam and launching the exe should be launching with the command -batchmode, which hides the main process window.

Try launching it without steam with -batchmode and see if it experiences the same issues as launching through steam.

[SteeveMonkey]

Launching XSOverlay outside of steam with the '-batchmode' flag does cause the main process window to be hidden, but the wrist UI is still visible and working as expected

[Xiexe]

Launching XSOverlay outside of steam with the '-batchmode' flag does cause the main process window to be hidden, but the wrist UI is still visible and working as expected

This is probably the most bizarre thing I've heard. There should be no feasible difference between the two.

If you go into Task Manager and check the detailed process tree, sort by name, do you see 4 XSOverlay processes?

It should have: Node Server Media Manager Main Process Process Manager

[tomaae]

I may have the same issue, except it wont show up even when executed using binary. But an idea, could it be caused by conflict between node.js distribution you use and installed version? I have v20.5.1 on my pc.

[Xiexe]

The nodejs version needed is bundled with the application so I'd be surprised if that were the case. Is the node server actually starting up for you?

[tomaae]

yes it is, correct version too. it may be attempting to use parts from other version tho depending on your envinroment.

[SteeveMonkey]

All 4 Processes do show up regardless of launch method.

However, I did a bit more digging and found out that the issue is related to how I have my system set up. I currently have Windows set up with Junctions in the C drive for 'Program Files', 'Program Files (x86)', 'ProgramData', and 'Users' that redirect to the same folders on my B drive. The idea behind this setup was to allow me to easily wipe the C drive partition without losing my installed programs and their configuration files. But, after using this setup for a while, it is becoming apparent that many things on Windows do not play nicely with Junctions, which is starting to make this setup a bigger hassle than it is worth. I should probably just work on getting a backup system that works similarly to timeshift on Linux, then continuing to try and make the Junctions work. So, anyways, the issue seems to be caused by the fact that the program is running from a path that has a Junction in it. I have tested this and verified that running the executable directly from the Junctioned C path produces the same result as launching from Steam does, which appears to be the same path that Steam is using despite it reporting that the Library is on the B drive and not the C drive. So now it is clear what the issue is and what I could do to fix it on my end.

I know that running the application through a Junction would be an extremely niche use-case that would likely not be worth accommodating. So, I apologize if I have wasted your time with this, it should have been one of the first things I looked into and tested before making this issue.

With that being said, I am willing to help by seeing if I can reproduce the issue @tomaae is having, since I do use Node.JS for development, I just haven't set that dev environment back up since my last Windows reinstall. Although, I should probably get my setup de-junctioned before doing anything there, just to ensure that my bizarre and somewhat broken setup does not have an influence

[Xiexe]

Update:

It looks like chromium has a wont-fix bug filed for this.

Chromium will not properly open if the path includes a junction or a symbolic link. Docs for the wrapper I'm using

Link to the chromium issue tracker

Good in the sense that it should be an easy response to people who are having the issue, annoying in the sense that it involves the user going out of their way to fix it.

I may try to find an automated solution to fix it but currently don't know what that might be.

If you have any suggestions, let me know.

[Xiexe]

Closing this as I've pushed a fix that will show a warning on the live branch if you've installed and launched from a symlink or junction.