actually_fred

When using ultraleap or VR controllers, putting your hand near a switch/button will automatically trigger the switch/button. When using hand-tracked controller emulation with a wide field of view (e.g. quest hand tracking + virtual desktop or OpenXR toolkit or HTCC), this is problematic - for example, when your hand is on the throttle, it's easy to accidentally turn off fuel pumps in the a10c. This is also a problem with ultraleap when looking near the throttle - it's only the narrow field of view compared to quest tracking that makes it not a problem when looking elsewhere. An option to ignore proximity and require a controller button/thumbstick action to interact would make these all better.

'direct touch' is very specialized - it gives better support for touching flat surfaces on quest *that are specifically extended to support directtouch*, and which may be floating in a 3D environment. It does not give the ability to touch 3D environments themselves, like cockpits or even the DCS menus, as (a) they're not on quest (b) DCS doesn't say report they're flat - it just provides an image for each eye combining the game world/background and the menus (c) they don't have the code to support directtouch

@BIGNEWYA smaller bug with native OpenXR - VR controller grip/aim/laser pointer angle is wrong - there's another report here which is probably native OpenXR due to the timing: Both that OP and I are using Oculus headsets (them: Rift S; me: Quest 2 or Quest Pro). For me, the controller angle is fine when using OpenComposite or the Oculus API - it's *only* wrong when using `--force_OpenXR`

Also seeing this with Oculus (Quest Pro and Quest 2) when using native OpenXR

It requires the game to support it, or external software. A lot of standalone games support it, but not all. The Quest does not have the ability to make hand tracking work in every game, even standalone mode. Full hand tracking support requires Eagle Dynamics to write code adding it to DCS (which is now possible given they're using native OpenXR, via XR_ext_handtracking). Without that, HTCC, Virtual Desktop, or OpenXR Toolkit are your options.

I'm going to shamelessly plug https://github.com/OpenKneeboard/OpenKneeboard#readme While custom kneeboards (like are in the excellent Iron Flag A-10C training campaign from @baltic_dragon) are ideal, it does give you in-VR access to most of the briefing; it gives you the text, images, weather, and (if you're in an A-10C) A-10C CDU calculations. The briefing support is really handy for the older or more basic campaigns, like the Ka-50 Georgian Oil War. it does not currently include the armament summary, friendly forces, threats, or airfield info from the briefing though. I think my knowledge of DCS lua and .miz file layout is the limiting factor there

No, I admit I did not see the release of “the first VR API” as you put it in 2014, after seeing the release of the oculus API in 2013.

I’m not going to consider “maybe they’re working on this in the background but no 6dof headsets or games released - and neither openvr or even the original rift were released” relevant to this discussion. That said, at in 2014, the oculus sdk was out for a year and openvr wouldn’t exist for another year. Still requires a valve-controlled API and uses a valve-controlled api loader.

OpenXR is the first standard. OpenVR was a single-vendor product, branded in the (apparently successful ) hope that people would think that putting “open” in the name actually meant something, even though the name itself means nothing.

> With OpenXR we now have a second chance to get rid of this nonsense. I *almost* agree with this - with OpenXR, we have a first chance to get rid of this nonsense; OpenVR could potentially have been a first chance if it wasn't actually just "the SteamVR API" and trying to get everyone into the Steam ecosystem. It's telling that even now, SteamVR assumes that it's the only OpenVR implementation, and has no support for setting SteamVR as the active OpenVR runtime. It was clearly designed to lock headset owners into steam.

Yes, it would be possible to fork "Open"VR with changes that aren't approved by Valve - but if Valve don't adopt them, it's irrelevant. Even Valve assumed no-one else would ever implement "Open"VR - which is why SteamVR has no option to set SteamVR as the "Open"VR runtime. And the ideology is largely irrelevant as the Valve-distributed openvr_api.dll is the only one that's whitelisted in anti-cheats. It's also slow and leaky (megabytes of RAM every time you ask it "is "OpenVR" (*cough* steamVR) running?")

> OpenVR could have been the unified API for VR and we never would have seen all this chaos No. "Open"VR was always a branding exercise. It was always the Valve VR API. It has always been fully under Valve's control, Valve have always been in control of which bugs get fixed and which headsets get optimized. It was never truly open or cross-vendor. Every vendor had the ability to opt in to being fully controlled by Valve; that doesn't make it an open API.

SteamVR is both an OpenVR and OpenXR runtime. It assumes it's the only OpenVR runtime. SteamVR's runtime option sets SteamVR as the active OpenXR runtime. Oculus, PimaxXR, and WMR's runtime options set themselves as the active OpenXR runtime. OpenComposite's (which you generally don't want with DCS now) runtime switcher lets you choose between OpenComposite and Steam as the active OpenVR runtime.

I mostly agree with your post, but in my experience it's unfair to put that much blame on WMR for SteamVR. Perhaps it truly is that bad for you - however, both SteamVR and the `openvr_api.dll` as published by Valve have a lot of bugs and performance problems which vary greatly between machines - and for some people, is just pathologically bad, regardless of headset. Maybe it particularly dislikes some drivers/motherboards/whatever, but WMR for SteamVR is not consistently hugely worse than other SteamVR drivers. SteamVR truly sucks at the most essential part of it's architecture: efficiently passing GPU textures between processes. The exception is SteamVR-native headsets like the Valve Index and HTC Vive; by coupling so tightly to SteamVR, they're able to avoid a lot of its' issues.

Here’s a fairly technical post I wrote on this: https://fredemmott.com/blog/2022/05/29/vr-software-components.html

No; OpenXR is a standard, not a piece of software; however, depending on your headset, you may need to download and install headset-specific software that adds support for OpenXR.

I sketched up what this changes for Oculus Link users; as for how to use it, mbucchia's comment covers everything on a fresh install; mods/past optimizations can make things *much* more complicated. Virtual Desktop users must use SteamVR or switch to Link/Airlink.

Sorry, I'm not super active here; https://github.com/openkneeboard/openkneeboard#getting-help has better ways to get help. That said, https://github.com/OpenKneeboard/OpenKneeboard/blob/master/docs/troubleshooting/huion-tablet.md probably addresses your issue

This is an ignorable bug in OpenXR Tools for Windows Mixed Reality - it does not affect games or anything else. OpenXR Explorer is an alternative tool without this bug.

> Check your registry at HKLM\Software\Khronos\OpenXR\1\ApiLayers\Implicit. There shouldn't be any key pointing to a file outside of ProgramFiles. I disagree with this - it is perfectly valid for them to be anywhere. The problem is that OpenXR Tools for WMR is sandboxed, which means its not compatible with all valid OpenXR API layers. As such, it is not suitable for use as a debugging/testing tool - use OpenXR Explorer instead. That said, it will be compatible with the next version of OpenKneeboard, however... > I can't remember exactly what OpenKneeboard did, but I thought the latest version took extra care to not break OpenXR Tools. The current betas (and the next stable release) will coincidentally fix this - they install to program files instead, but this is primarily because of Microsoft changing the restrictions on registry access for MSIX "full trust" apps; Windows updates removed the ability to reliably write to the registry. I needed to move away from MSIX, so MSI + Program Files + HKLM made sense. A past alpha changed the ACLs on ProgramData\OpenKneeboard to allow access to sandboxed apps; I removed that as the MSIX changes happened shortly after. OpenXR Tools for WMR are not compatible with current stable releases of OpenKneeboard; this is ignorable, and a bug/shortcoming/oversight in OpenXR Tools for WMR. > Check your registry at HKLM\Software\Khronos\OpenXR\1\ApiLayers\Implicit. There shouldn't be any key pointing to a file outside of ProgramFiles. You also need to check HKCU; current stable releases of OpenKneeboard should be there instead of HKLM

Modern "windows apps" are annoyingly restricted There should be a launcher in `C:\ProgramData\OpenKneeboard` that you can create a shortcut to. The next version will be an old-fashioned MSI going into Program Files instead of the MSIX windowsapp thing, as: Microsoft keep locking down MSIX/Windows Apps more and more; stuff doesn't work as well as it used to because of this Some Microsoft tools that OpenKneeboard uses used to *require* MSIX - but don't any more

Sorry, I'm not often on these forums; it looks like you've both found either Discord or GitHub Discussions though For others: - if the app opens, click on "Help" in the bottom left - if not, check out https://github.com/OpenKneeboard/OpenKneeboard#getting-help

> One of the latest event before the freeze is related to the OpenKneeboard mod ("Game event: friendly fire"). That's just openkneeboard saying it's seen (and ignored) a friendly fire event. At least openkneeboard's handling of that event is unrelated to any freeze. I'll remove that logging though, it's not really needed. https://github.com/OpenKneeboard/OpenKneeboard/blob/2c3262fd2ccb6039a8a331fe6d4201d5f0483a69/src/dcs-hook/OpenKneeboardDCSExt.lua#L192

> Am I correct to expect it to be pulling all the flight frequencies and tacans in from briefing - didn’t see that’s in my test miz- maybe I need to try a different miz.. If the mission kneeboard images (not briefing) include it, they should be shown in the 'Mission' tab. If you're on a stable release, nothing from the briefing will be shown. If you're on the betas, there is a separate briefing tab, but it doesn't include the frequencies/tacans unless the mission author put them in the briefing text or images. If someone can show me how to figure those out from the LUA files in the theater and mission (ideally without using DCS functions), I can add them.

Take a look at https://github.com/OpenKneeboard/OpenKneeboard#getting-help ; if the guides linked here don't help, please include whether or not you're using VR, and if so, what headset you're using, and if you're using OpenComposite > Where does the program install? I checked my program files after i ran the msix.zip and even tried searching for it but i can't find its install path? C:\Program Files\WindowsApps ; this is used for any MSIX or Appx package, and anything installed from the MS store. Windows locks this down a lot and it's not really possible to workaround that without breaking stuff. It can be launched from the start menu, or as 'openkneeboard.exe' without a path; if you need an exe path for some other launcher, use C:\ProgramData\OpenKneeboard\OpenKneeboard-Launch-WindowsApp.exe > Subsequently - how would i uninstall if i cant get it to work? "Add or Remove Programs"