actually_fred

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"

v1.2-beta2 includes support for hats: https://github.com/OpenKneeboard/OpenKneeboard/releases/tag/v1.2-beta2 This also includes the changes in v1.2-beta1: https://github.com/OpenKneeboard/OpenKneeboard/releases/tag/v1.2-beta1 If you're using WMR, https://github.com/OpenKneeboard/OpenKneeboard/blob/master/docs/troubleshooting/wmr-kneeboard-position.md More generally: bind a button/combo to 'recenter' in OpenKneeboard settings; it generally works best if you use the same button/combo for VR recenter in DCS and OpenKneeboard. OpenKneeboard asks to be in the same place every time; it's up to SteamVR and/or the headset manufacturer to make that happen, and OpenKneeboard can't detect when they fail; recentering as soon as you're in-game is the best workaround.

No ETA, though you can get an idea of progress here: https://github.com/OpenKneeboard/OpenKneeboard/projects/2

It currently supports joystick buttons; the warthog throttle pretends that some of its' hats are buttons - these one works. True hats are not currently supported - updates for that will be here: https://github.com/OpenKneeboard/OpenKneeboard/issues/80 The easiest way is to use multiple tabs; alternatively, you can switch out Saved Games\OpenKneeboard\settings.json with different versions for different aircraft. Updates on support for profiles in general will be at https://github.com/OpenKneeboard/OpenKneeboard/issues/63 . The DCS forums aren't really the right place for IL2-related questions, though I won't be working on anything IL2-specific (like automatic switching) as I'm banned from posting in their community (my guess is for explaining OpenKneeboard's anti-cheat warning, though no reason was given).

I end up looking at DCS .dmp files for OpenKneeboard, as every non-VR and oculus SDK overlay app (e.g. OpenKneeboard, Discord, Steam, Razer Synapse, Rivatuner, MSI afterburner...) intercepts IDXGISwapChain::Present; if multiple overlay programs are being used, they can interfere with each other, and crash DCS. DCS `.dmp` files often contain 'impossible' combinations of modules (as shown by `lm` in windbg) ; for example, I've seen the WMR OpenXR dll loaded but without any openvr_api.dll - I'd expect to see OpenComposite's openvr_api.dll It would be useful for me - and I'm guessing for you - to be able to see a more definitive list of which DLLs have been loaded Adding MiniDumpWithUnloadedModules to the DumpType parameter of your MiniDumpWriteDump function call would make it easier for me - and you - to identify interfering software when looking at crash reports.

I've added some more docs: https://github.com/fredemmott/OpenKneeboard/blob/master/docs/troubleshooting/dcs-tabs.md https://github.com/fredemmott/OpenKneeboard#adding-pages-and-tabs-to-the-kneeboard > add documents to, let's say, the theater tab? For now, the theater tab only loads built-in pages (which only exist for caucasus and NTTR); if there's a standard place for them inside saved games, I'll make it load those too - but I don't think there is. If someone can confirm there's no 'standard' place for per-map user kneeboard pages, I'll probably add support for `Saved Games\OpenKneeboard\Maps\MapNameHere` in a future version

I've added some more docs: https://github.com/fredemmott/OpenKneeboard/blob/master/docs/troubleshooting/dcs-tabs.md https://github.com/fredemmott/OpenKneeboard#adding-pages-and-tabs-to-the-kneeboard

I'll probably re-add that as an option; I briefly added it, and both myself and the person who originally asked for it ended up disliking it, as it makes it harder to go to the first or last page, so removed it pretty shortly after.

It’s reasonably likely we’ll end up with the same toolbar from the main app in the top header of the kneeboard