actually_fred

Hey - this is all a bit off-topic, and would be better suited to the main VR forum rather than the bug report/suggestions forum. In particular, there's another recent thread on thumb/finger mice.

There's really just one thing needed here:

This is half way between a bug report and a feature request: DCS's built in support for hand tracking is highly immersive, but not practical, because of how control interactions are triggered by a moment of 'touch'. For example: due to the switch positions and limitations of tracking, pushing the throttle fully forward will often... incorrectly turn off fuel pumps or engines in the A-10C eject stores in the F-16 activate the fire suppression in the F-18 due to tracking limitations and just closeness/stability, interacting with the UFC in the A-10C can incorrectly trigger a fire supression handle in many aircraft, interacting with the lower front and side panels can lead to accidentally ejecting HTCC still exists for DCS entirely because of this issue. Suggested fix Add option to require a button to be held for an interaction to happen Add option for a pointing gesture triggering a 'laser', like a controller, which *also* requires a button to be held if the above option is also on "A button can be held" should support: mouse buttons (e.g. PointCTRL with stock firmware, generic 'ring mice' from amazon/ali express) - this would need to ignore the mouse cursor position and just use the hand tracking position directinput game devices (e.g. pointctrl with HTCC firmware, slugmouse) nice to have: optionally some kind of gesture, e.g. pinching thumb and index fingers XR_FB_hand_tracking_aim makes this easy, but is not universally supported. It is currently supported on Quest Link in dev mode only, Quest-series headsets via Virtual Desktop, and Ultraleap-based devices (including the hand tracking module on the original Pimax Crystal) it can be implemented more generally by comparing joint positions this should be optional because like hand tracking overall, it is not perfect; people who have buttons bound are likely to want to disable this to further reduce the chances of incorrect interactions

Download link: <https://github.com/OpenKneeboard/Fresh-Start/releases/latest> For most people, uninstalling OpenKneeboard from add/remove programs is sufficient; there's a few cases where it isn't: the uninstaller intentionally does not delete your settings; if you want to start with fresh settings, this tool can help you (or you can just delete the settings files yourself) Microsoft limitations prevent OpenKneeboard installers/uninstallers from banning or repairing some edge cases, such as installing certain older versions after newer versions without uninstalling newer versions first If multiple versions were installed simultaneously (e.g. via the above edge case), Microsoft limitations sometimes prevented installs/upgrades from cleanly removing all previous versions instead of just one previous version This tool cleans them all up. In short, use this if: you tried or used to use OpenKneeboard and want to kill it with fire you want a complete fresh start of OpenKneeboard, deleting your previous settings you're having problems, and have been using OpenKneeboard for a long time; e.g. some of the issues it can repair only occur if you've had a 2021 version of OpenKneeboard installed, then installed a 2025 version, then installed a 2021 or 2022 version again

HTCC is an alternative hand tracking implementation for DCS World. It: reduces immersion: hand models won't line up and should be disabled (see instructions) improves practicality: drastically reduces the chances of accidentally triggering switches, which frequently leads to accidentally ejecting, turning off fuel pumps, or pulling fire handles Download here: https://github.com/fredemmott/HTCC/releases/latest Then read: https://htcc.fredemmott.com/getting-started.html Highlights Improved compatibility and reliability, including SteamVR added basic report on OpenXR usability added option to fix basic Ultraleap issues (including the hand tracking module for the OG Pimax Crystal) added option to enable/disable the suspend/hibernate gesture completely rewritten settings app Please note: While SteamVR itself supports hand tracking, most SteamVR headsets and drivers do not HTCC is limited by DCS's 'absolute mouse' support (e.g. like a touchscreen or tablet). HTCC's in-game experience will never substantially improve. Requests for improved hand tracking experience should be sent to the game developers, and should be asking for improved hand tracking - not for improved HTCC support. HTCC is a workaround; everything it does could - and should - be done at least as easily and at least as well in the game itself. I do not provide any support for HTCC on these forums. See https://htcc.fredemmott.com/getting-help.html

Make sure you have the windows installer service running. If not, set it to start automatically and reboot. if you don’t have the windows installer service or it won’t start, you need to reinstall windows - it’s broken, usually due to an over eager attempt to “de-bloat” it.

Yep, and the current nvidia driver has a known issue in that it often crashes in D3D12 games with HAGS off.

HAGS is *usually* best left on nowadays but it’s still a “can vary - try it and see” thing. For people holding back on win10 or old versions of win11 it’s more likely to be good to turn it off

Two contrasting approaches: RTSS is 'delay stuff', Turbo Mode is 'remove delays'. Both can increase latency, but 'remove delays' is usually the better of the two Reason that 'remove delays' can be bad for latency is say you want 1 frame per second, and it takes 100ms to render a frame. Say your next frame is due at exactly 10:00:00 The theoretical ideal time to start that frame is 09:59:59.900 - in practice, most runtimes will aim to start a little earlier, say .895. If the game says 'ready to start the next frame' at .801, the runtime may introduce a .094 delay. Turbo mode gets rid of that delay, so your frame will be ready at .901, but it will still be displayed at the next panel refresh at 10:00:00.000 - so it will be 99ms out of date. Another frame will be ready at 10:00:00.101, but that will be discarded, with the goal of making another for 10:00:01 With RTSS or non-VR tools, when they have any effect on VR, you'll still have whatever delay the runtime wants (which will change), but also whatever delay RTSS inserts, and RTSS has no idea about when the next panel refresh rate is. Usually this is either 'no effect' or 'adds an extra 1 frame of delay'.

You seem to have skipped or misread this section twice - note 'non-placebo effect': RTSS is not capable of modifying framerate in a way that respects VR panel timing; all it can do is delay the game loop based on non-VR data. If you are getting a smoother result with RTSS, it is because is most likely it's delaying it enough to entirely miss a panel refresh, effectively adding a 1 frame delay with out-of-date headtracking. If this is the case, the root cause would either be DCS having unpredictable CPU load or over-optimistic wait time prediction in the pimax software. For this kinds of issues, Turbo mode has its' own problems, but is a often a better workaround, at the cost of increased GPU load (but not higher per-frame load) - the 'real' fix is to report the problems you're having to pimax and ask them to improve their runtime - in particular the implementation of xrWaitFrame.

Anyway, the actual way to limit the game to 72hz in VR: - set headset to 72hz - turn off 'turbo mode', 'prefer framerate over latency', and any similar options in the headset software and any third-party mods. Note that if you're using mbucchia's quad views layer (you probably don't need it on the pimax), it turns on turbo mode by default If that's not sufficient, test disabling all mods with https://github.com/fredemmott/OpenXR-API-Layers-GUI. If you have > 72hz with all mods disabled and it set to 72hz in the pimax software, contact pimax support. The *only* way to get correct frame pacing is for it to be dictated by the headset/runtime, not the game or any third-party software, as it should match the display panel timing.

RTSS and similar tools literally modify the 'send this to my *monitor*' thing, which is not used for VR. The game will usually render to the mirror window in a way that just tells windows "here's a frame, display it whenever you're ready, or don't" - the game doesn't wait for it to display. A forced limit or forced vsync forces the game render to wait for the next permitted frame time *when sending to the monitor*. When not placebo, this limits the entire game, so it ties your VR headset to your monitor's behavior, which is bad. It's placebo when the game more thoroughly decouples VR from the monitor behavior.

RTSS affects your mirror window - it does not directly affect your headset. There’s a fair chance it’s placebo, but if not and the mirror window ends up somehow linked to the VR display, it likely varies depending on your vsync settings, your monitor refresh rate, and if your monitor supports Variable Refresh Rate when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.

For openxr, capframex, RTSS, presentmon and others may be easier, but the numbers they give are wrong, and they can actively harm the VR experience because they work on the “send to mirror window” part of the game, not the VR part. https://github.com/fredemmott/xrframetools?tab=readme-ov-file#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games If you go beyond monitoring with these into framerate limiting, vsync, or other modifications, these will either do nothing to VR beyond placebo, or tie your headset to your monitor's timing rather than the runtime's timing, often leading to stutters, motion misprediction, and other tracking issues. Edit: for example, accurate support for OpenXR has been an open feature request for CapFrameX for over a year: https://github.com/CXWorld/CapFrameX/issues/277 While Google's AI and a guest post on Pimax's blog say PresentMon support OpenXR, this is incorrect. This is obvious from the fact that it does not have an API layer. The only other way it could provide accurate numbers would be if it integrated with the runtimes - given PresentMon itself is open source, it would be an unusual choice for them to integrate with some runtimes, but none of the open source ones (like VDXR) - and another bad choice to display incorrect information on other runtimes rather than a 'runtime not supported' message which woudl require an API layer. PresentMon can hint about your load, but this says nothing about timings/bottlenecks unless something is at 100%. I'm also not seeing any trace of OpenXR-related code in PresentMon's source code.

While I don't have a workaround or solution, please let Varjo know the bug in v4.4 and above is important to you; despite it not being in their 'known issues' list, they've been aware of it since at least November. It also affects other world-locked OpenXR overlays. I've been keeping track of the details over on https://github.com/OpenKneeboard/OpenKneeboard/issues/698 as Varjo do not appear to have a public bug tracker.