actually_fred

Yeah; their hardware is good, excellent value, and link/airlink are great - better than VD for me - when they work. On the other hand, Oculus frequently push out updates that break Link/AirLink features I depend on, or just break it entirely. I still use them when I can, but I also regularly use virtual desktop as a backup when link is broken yet again.

This is a hardware limitation; with the possible exception of the Varjo XR4 (the advertising material is... advertising material, not clear functional descriptions), no generally available headset is capable of rendering anything at multiple focal planes.

They seem to be moving stuff around a lot; googling for "leap motion download old versions of gemini" gets you a few links to pages with it.

Most of the replies in help threads contain factually incorrect advice, which makes setting up VR more confusing for everyone. I'm going to address a few common ones: - SteamVR + OpenXR: SteamVR supports OpenXR (it's an "OpenXR runtime") - if you want to use SteamVR + DCS, you want to start by setting SteamVR as your OpenXR runtime. You do not want to 'disable OpenXR' to use SteamVR, unless for some very rare reason you specifically want to use OpenVR. If you do this, no games that require OpenXR will work unless you change your settings back. - "OpenXR Tools for Windows Mixed Reality" is specifically for Windows Mixed Reality headsets. If you have a quest, rift, pimax, varjo, beyond, or any other non-WMR headset, do not install this software, and especially do not click the button to set WMR as your OpenXR runtime. If the tutorial you're watching or the guide or reading says to do this and doesn't say "just for G2" or "just for WMR", find a better guide. If you just want to see information on openxr, https://github.com/maluoi/openxr-explorer/releases/latest is a better tool, in combination with https://github.com/fredemmott/OpenXR-API-Layers-GUI/releases/latest if you have several OpenXR API layers (roughly 'plugins') installed*. - "OpenXR Toolkit" is not the same thing as "OpenXR Tools for Windows Mixed Reality" - "OpenXR Toolkit" is not the same thing as "OpenXR" - "OpenXR Toolkit" is never required. It's a great tool, install it if there's a specific reason you want it, but it's not necessary. - "Set WMR/your headset/SteamVR to OpenXR": this is the wrong way around and can confuse people: "Set OpenXR to SteamVR/WMR/your headset" is correct. It's a single OpenXR setting for all OpenXR hardware manufacturers and games - you are changing if OpenXR games use WMR, oculus, steamvr, or whatever, not a headset setting. Specifically these buttons in steamvr/wmr/manufacturer-specific stuff all change `HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1\ActiveRuntime` - SteamVR can simultaneously be your selected OpenVR and OpenXR runtime. Games will only use one at a time. - If WMR is set as your OpenXR runtime, your G2 can be used by openxr *or* steamvr-via-openvr *or* classic (deprecated) Windows Holographic *or* opencomposite-via-openvr* without any settings changes. Games will only use one at a time. - If Oculus is set as your OpenXR runtime, your quest/rift can be used by openxr, *or* steamvr-via-openvr *or* opencomposite-via-openvr *or* the classic (deprecated) libovr without any settings changes. Games will only use one at a time. - If you need to change your OpenXR runtime and the buttons in the various vendor-specific tools aren't doing what you want, https://github.com/rpavlik/xr-picker/releases/latest is a good tool * OpenXR-API-Layers-GUI can also be used to fix issues, but I'm recommending it here because layer (plugin) order matters, and the current version of OpenXR-Explorer sorts them alphabetically - this means that OpenXR-Explorer is not currently useful for troubleshooting API layer issues. This should be fixed in the next version of OpenXR-Explorer.

A quick repair will bring it back if needed. Check that Leap Motion support is disabled in DCS if you want to use leap motion via openxr instead.

> If using controller emulation That change is unneeded and has no effect when using touch screen/tablet emulation. If it has an effect with HTCC, you're using oculus touch controller emulation, which will not work correctly with this ring; it would need new firmware, and some changes to HTCC. I'm interested, but hoping to find a supplier for the batteries that can deliver to the US faster than March

Even if you're not using HTCC, https://htcc.fredemmott.com/hardware/ultraleap/README.html#pimaxs-hand-tracking-module - this will *only* affect OpenXR hand tracking, not classic leapc.dll integration, so you may need to delete leapc.dll from your DCS bin and bin-mt folders for it to apply (and re-do that every DCS update)

The easiest way to deal with that would probably be to add them to an aircraft tab's folder in saved games - you can see the paths it looks for those in the tab settings. If there's an X by the one in saved games, that just means that it doesn't exist yet, and you can create it if you want to. I'm probably going to add some level of lua scriptability at some point; this would include fully-lua-defined tabs, but I probably will also add 'lua-assisted' tabs - e.g. a folder tab where you can write lua code that changes which folders it's looking for based on which aircraft you're flying. I could also add 'custom prefix' to aircraft/terrain, e.g. "My Documents\Controls\<aircraft>", though this might be a bit too niche to be worthwhile, especially once it's possible with lua scripting. Might also add JS scripting - it's my preference, but OpenKneeboard already deals with some lua, and it fits better with the current DCS modding community.

No, there’s no simple way for that, its 99% the same technical problem as bookmarks.

You also need to set Oculus as your active OpenXR runtime; this is in the Oculus PC app settings, or you can use a tool like https://github.com/rpavlik/xr-picker

While it would be relatively straightforward for OpenKneeboard to run Lua (and it will probably support some level of Lua scripting in the future), that wouldn't help here: the problem is getting access to the internal DCS/module features that these lua kneeboard pages depend on to work. It would probably require per-module DCS patching, and likely have problems with IC and need frequent per-module updates to keep up with changes in DCS.

Probably not that difficult, it's just not seemed the most interesting way to spend my free time yet. That said, there are some minor complications: before bookmarks can be persistent, it needs to understand and track which kinds of content are persistent - and they can move. For example: - if you add a PDF, and bookmark page 5, the bookmark should be persistent - what if the PDF is modified or replaced? Trash the bookmarks or assume the page numbers still make sense and keep them, assuming the page count is >= the bookmark? Change tracking for PDF is not usable for this. - what if the bookmark is a text file and the text file is modified? The ideal would probably be to erase the bookmark if the modifications are *before* the bookmarked page, but otherwise should preserve it - radio log bookmarks should not be persistent as the radio log itself is not - mission briefing bookmarks should only be persistent within the same mission - if you have a folder tab and you bookmark `b.png` within that folder, close openkneeboard, add `a.png` to that folder, then re-open OpenKneeboard, the bookmark should still point at `b.png` - even though the page number for that bookmark has been increased by one

There are currently no known crashes except when running as administrator which can only be fixed by Microsoft and is generally a bad idea anyway; if you’re not running as administrator sorry it’s complex, but if you follow the steps at https://openkneeboard.com/troubleshooting/crashes-and-freezes.html I might be able to fix whatever you’re encountering, or point you in the right direction.

The one big gotcha is eye-tracked dynamic foveated rendering. This is possible on the QPro - not the Q3 - and can lead to *huge* GPU savings in DCS (and Pavlov, but not as much in other games where quad-views can't be used so DFR is implemented with other techinques). Personally the QPro's eye tracking latency was too high for me (I love it on the Pimax Crystal though) - but the majority of people don't seem to have a problem with it and it *really* helps with DCS framerates. Q3 is definitely a better all-round headset, QPro is probably a better DCS headset.

I've spent the last few days making https://github.com/fredemmott/OpenXR-API-Layers-GUI ; this is a tool for managing your installed OpenXR API layers and removing old/corrupt ones - it won't install them for you. OpenXR API layers extend OpenXR games/apps; some popular layers include: - HTCC - Liv Stabilization - OpenKneeboard - OpenXR Motion Compensation - OpenXR OBS Mirror - OpenXR Toolkit - Quad-Views-Foveated - Ultraleap's OpenXR support - Varjo-Foveated - XRNS This tool lets you enable/disable any of these that are installed, re-order them, and can automatically detect and fix common problems: Separate versions are included for: - 64-bit API layers installed system-wide (most common, using HKEY_LOCAL_MACHINE) - 64-bit API layers installed per-user (Liv stabilization, extremely old versions of OpenKneeboard; using HKEY_CURRENT_USER) - 32-bit API layers installed system-wide (HKLM in the 32-bit registry) - 32-bit API layers installer per-user (HKCU in the 32-bit registry) For help, see https://github.com/fredemmott/OpenXR-API-Layers-GUI#getting-help ; I'm often unable to respond in threads, and I'm not able to respond to support DMs on any platform.

Yeah, that's been fixed since January That said, it is a new thing (last month or two) that the old installations actually affect DCS.

> 2023-10-19 20:23:15.080 INFO APP (Main): Command line: Z:\SteamLibrary\steamapps\common\DCSWorld\bin\DCS.exe --force_enable_VR --force_steam_VR Remove --force_steam_VR, and make sure you have your OpenXR runtime set to Oculus. Also make sure you have multithreaded beta enabled in the steam game settings.

> it is in the 1 frame per second area. If you're happy with your VD setup, stick with it, but for Link, if you've ever used Oculus Debug Tool or Oculus Tray Tool, reset everything in it back to defaults and try again

Not tried for flight sim, but I'm getting rid of the one I *just* got for my sim racing rig: - my face gets much warmer than with a crystal/g2/quest. Perhaps not an issue for flight sims, but it is for that. Much more active. - Varjo is the *only* headset I've ever tried that says 'too many monitors' and requires me to physically unplug some and reboot - Possibly related: it's really stuttery if I have my Neo G9 Ultrawide connected as the only monitor. It's perfectly happy if I unplug that and use a little 10" monitor that usually shows a racing dashboard The actual visual quality is great, lenses are much better than the crystal, and VFOV felt just a little smaller than the crystal (perhaps 'just a little' for me because VFOV matters less for racing than flight sims) - but the heat and monitor-compatibility stuff just makes using it too annoying.

I've not tried forcing MT to OpenVR, but it definitely is possible to force it to the legacy Oculus API by sufficiently breaking your OpenXR configuration - DCS MT will always *try* to use OpenXR, but if it fails in the right way, it'll fall back to the Oculus API.

I've found that for things to work well, I need the latest gemini driver from a few days ago (uninstall the old one, then install the new one), and to replace DCS's LeapC.dll with the new one, in both bin/DCS.exe and bin-mt/DCS.exe - this is especially true if you have Ultraleap's OpenXR support enabled (even though DCS doesn't use OpenXR-based hand tracking)

Clarity yes, colors no. I never noticed shimmering on either 100%; I'd probably have stuck with the quest pro if I could revert to earlier versions of both the firmware and PC software. Quoting myself here - Ultraleap released a new driver yesterday around 5 minutes after I posted that fixes a lot of the previous problems There's still some bugs (which fortunately don't affect PimaxXR users) and things I can improve in HTCC for Ultraleap, which I'd expect to improve both actual leap motion devices and the pimax hand tracking module.

For a leap motion 2.0 with the 5.13 drivers: - if you want to use DCS's built in leap motion support, disable OpenXR support in leap motion control panel; there's some bugs in the current version that interact badly with DCS - if you want to use HTCC, you need to use the 5.13 driver, service, and leapc.dll, but with 5.6's API layer. This is fiddly. For a leap motion 1.0 or other older ultraleap product, use the 5.6 drivers instead. Ultraleap are planning a new driver soon which hopefully fixes this.

Coming from a Quest Pro, yes: For me, Link/Airlink have been great since I first got access to them years ago - until this year. Several mandatory firmware/driver updates this year have made them unusable for me this year (either not working at all, poor framerate, stutters, or needing to downgrade bitrate to the point I can't read A10C MFCDs) and I've had to wait 1-2 months for Meta to push another update fixing things again. Setting up the Crystal was for the first time was weird (bad translations didn't help), the controllers shipped stuck together, the firmware update is jank especially for the controllers ("shake the controllers periodically during the update to prevent them going to sleep"... really?) - but once it works, it just keeps working. For me, eye tracking and foveated rendering on the Crystal is a *huge* step up from the Quest Pro; this varies from setup to setup and person to person as everyone's perception is different, but dynamic foveated rendering on the quest pro had latency that was extremely noticeable and annoying to me - by comparison, on the crystal, it's so good I had to dig into the logs and enable debugging mode to check it was actually working and I didn't just magically have great quality and framerates by some other means. The Crystal has slightly better clarity in the center (only really noticeable for MFCD and cockpit text), the clarity goes much further out than the Quest 2, but the lenses aren't as good as the Quest Pro - I get some very noticeable chromatic abberation at the edges. Hand tracking: I currently have a leap motion 2.0 glued to the Crystal, and there's issues with the current driver + OpenXR support. It's possible to workaround them, and a new fixed version should be out soon. I could have also done this with the quest pro + virtual desktop, but for the crystal this is temporary, assuming they ever restock the Pimax hand tracking module in the USA. It shows up as in stock in their store, but actually isn't: if you enter a USA shipping address on their site, it will say 'no shipping options available', and if you ask them or order from them via another site (e.g. Ali Express), they'll tell you it's out of stock in the USA. As the module is an ultraleap, it will likely have the same driver problems as the glued-on leap motion. I would prefer a Quest Pro with January 2023's firmware and Link, but I'd prefer a Crystal over the whole experience for this year. That said, this is a huge 'your mileage may vary' - it seems for both headsets, a reasonable amount of people have a great experience, and a reasonable amount of people have a terrible experience.

The current version of the Ultraleap Gemini driver (5.13) also seems to install an OpenXR layer that doesn't play nicely with DCS; the 5.6 version from https://developer.leapmotion.com/releases appears to work fine (for people with a leap motion/ultraleap/non-Oculus headset with hand tracking)