actually_fred

For the majority of GitHub projects, if you're not a developer, you want to look for the 'releases' box. It's a pity they don't offer an option to make it more prominent, though it could be worth adding a link to https://github.com/rkusa/dcs-scratchpad/releases/latest to the installation section of the README null

No, it works with quests when developer mode is enabled. It does not work with rift or rift s.

I made a thing, and yes, it needs developer mode: https://htcc.fredemmott.com

Even without the linking, pre-2018 it would *usually* automatically activate with upgrades. When the automatic online activation didn't work, it always let me activate via the phone system.

It's really just a curiosity and doesn't make sense, but the Moore Threads MTT S80 has PCIE gen 5 - while delivering worse results than a GTX 1050ti, at around 5x the watts per frame.

np, thanks I'll easily admit that my documentation is very precise, specific, and... not the most approachable/readable, but it's the best I can do; approachable documentation is not one of my strongest skills. I'll be asking for community help with that in the next major release. The real fix is probably videos, but they take a lot of time, and need re-making extremely frequently - outdated videos are worse than no videos. I'm not able to spare the time for that at the moment

I'm sorry that something I made in my spare time and gave away for free didn't work out for you, but this tone is unnecessary, inappropriate, and harmful to a community that heavily depends on people giving away their free time to make things better.

It’s the Oculus runtime; it’s an essential part of oculus link/airlink in any game.

Flickering is part of the game/runtime, not the API. SteamVR tends to flicker. My experience: - SteamVR, OpenVR or OpenXR, G2: flickers - SteamVR, OpenVR or OpenXR, Quest Pro: flickers - WMR set as OpenXR runtime, G2: no flickers - Oculus set as OpenXR runtime, Quest Pro: no flickers - Old version, Oculus API, Oculus runtime, Quest 2: no flickers Not saying this is exclusive to SteamVR, and it's not really 'fixed' - WMR and the Oculus runtime just run on frame reprojection, so the more you move your head, the worse it gets - DCS just gives the runtime the 'what you see' view, and the runtimes are trying to create a new image just from that one, with no 3D world data. This can only really be fixed on DCS's end and isn't really tied to what API is used. Two fixes would be: - change the loading process to take a brief break every so often to push a new frame. The loading screens are often 10s-of-seconds-per-frame - DCS tells OpenVR/OpenXR/Oculus/Varjo "show this to each eye"; instead, for loading screens/menus, it could say "here's a 1m x 2m rectangle. Display it at (x, y, z), rotated by (rx, ry, rz)". This would allow the runtime to correctly render any head movement, even with 10s-of-seconds-per-frame In theory, either is sufficient, and if only one approach is taken, the second one is better. That said, only taking the second approach is still likely to 'flicker' in SteamVR, as by default SteamVR will fade in to the home environment if there hasn't been a frame for a few seconds.

To make the math easy, let's pretend the resolution was 3000x1000 and there's 3 slices: Sliced encoding on: it encodes 3 1000x1000 pictures per frame Sliced encoding off: it encodes 1 3000x1000 picture per frame Sliced encoding generally reduces latency, but - for a given bitrate - slightly reduces quality. The quality reduction is *very* slight - unless you're having driver or hardware issues, you almost always want it on. "Default" is probably along the lines of "on for nvidia cards and most others, off for cards that are known to have issues"

Pico have said this is coming by the end of the year.

You need to request this from Virtual Desktop/ggodin, and Pico for streaming assistant; there's nothing ED can do here.

The difference here is that the Oculus PC API is basically unchanged since the original Rift, and no new features will be added to it; when using the Oculus PC API, link/airlink are designed to act like a Rift, where 'shut down the headset entirely when I take it off my head' doesn't make sense - so there is no concept of removing and re-connecting a headset mid-game in the Oculus PC API. There is in OpenXR, and DCS isn't handling it well.

FWIW, the session being terminated is not an unexpected error - the error is DCS calling a function that requires a session after the session has been terminated, i.e. DCS is not properly handling the OpenXR session lifecycle (https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#session-lifecycle) The XR_SESSION_STATE_LOSS_PENDING message should have been received by DCS first, and DCS should have paused its' interaction with the headset, and recreated later: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrEventDataSessionStateChanged Probably Link de-activating or entering some kind of sleep mode when you remove the headset. This especially makes sense for airlink on battery. XR_ERROR_SESSION_LOST means that no handling has been done here, and calls are incorrectly being made with a no-longer-valid XrSession. IMO the 'may' behavior here is basically the bare minimum for any VR experience with play sessions that last more than a few minutes: all headsets should enter a lower power/heat mode when removed from the head, and terminating the session is a reasonable low-power behavior for wireless headsets. Removing the headset temporarily should be expected for games with multi-hour sessions. A better alternative would be MSFS-style switching between VR and non-VR: when the XrSession is lost, switch to non-vr. When user hits shift-tab or some other shortcut, recreate the session and switch back.

OpenXR API regardless of which vendor's implementation (runtime) is used for it. OpenXR is the future; Meta, Microsoft, and Valve all encourage it over their native APIs. Meta and Valve have both said new features will only be supported via OpenXR. Any headset vendor who advocates any other SDK is stuck in the past, and likely trying to minimize the cost of ticking the 'we support PCVR' box. I don't think ED should be picking up this development cost for them. When a vendor supports OpenXR but DCS has bugs or lower performance with OpenXR, you should report the bug to the vendor, not expect ED to make a significant investment and long-term maintenance commitment to paper over the issue, especially as it's either a short-term issue, or the vendor bluntly does not care about PCVR. This doesn't apply to SteamVR-native headsets, as OpenXR is now the recommended game development API for SteamVR. ED should not take time away from improving the game and modules to implement and support obsolete technologies. Vendor support - pro OpenXR: Oculus API (a.k.a. libovr): Meta recommend using OpenXR instead. The Oculus API is discouraged by Meta since July 2021, unsupported by Meta since August 2022: https://developer.oculus.com/blog/oculus-all-in-on-openxr-deprecates-proprietary-apis , and have announced all new features will only be supported via OpenXR OpenVR (a.k.a. SteamVR API): Valve recommend using OpenXR instead since June 2020: https://steamcommunity.com/games/250820/announcements/detail/2522527900755718764, and have announced all new features will only be supported via OpenXR Windows Holographic API (a.k.a. WMR API): Microsoft recommend using OpenXR instead and the WinRT-based Windows Holographic API is marked as 'Legacy'. https://learn.microsoft.com/en-us/windows/mixed-reality/develop/native/getting-a-holographicspace HTC Vive Wave SDK: this is only for standalone (android) headsets. OpenXR is HTC’s only documented PCVR SDK. Old headsets (e.g. the original Vive) require SteamVR, so also support OpenVR. Vendor support - neutral: Varjo SDK: they fully support OpenXR, but don't appear to encourage or discourage it over the Varjo SDK Vendor support: work in progress: Pimax's "XR SDK" (not the same thing as 'PimaxXR'): officially they don't support OpenXR yet except via SteamVR, however most of their recent news articles/tutorials that feature PCVR use the third-party PimaxXR (sometimes with OpenComposite). IMO OpenXR via PimaxXR feels 'unofficially preferred' for Pimax PCVR. Despite this, I'm putting it in 'work in progress' given the stance on their developer docs. It's also worth noting that DCS does not/has not ever supported the Pimax XR SDK directly. https://developer.pimax.com/document/faq/#does-pimax-pc-vr-devices-5k-8k-etc-support-openxr-sdk Pico. OpenXR is only supported via SteamVR, or for standalone; apparently their customer support have claimed that OpenXR support is expected in streaming assistant by the end of the year: https://www.reddit.com/r/PicoXR/comments/11g4827/openxr_runtime/ Virtual Desktop: OpenXR is only supported via SteamVR; other APIs have better support. I don't think there's a true 'negative' category here in terms of the (hopefully near) future, though 'work in progress' is negative in current state.

While it is more work for overlay developers, the OpenXR API layer approach is much more performant and flexible than the SteamVR Overlay system. It's largely equivalent to the game itself adding a HUD or overlay. For OpenKneeboard: - if you're using OpenXR + SteamVR , disable OpenKneeboard's SteamVR support, and mark DCS's exe (both ST and MT) as using OpenXR in OpenKneeboard's settings; auto-detect should not enable OpenKneeboard's OpenXR support when SteamVR is in use, but better to be sure. Sometimes though, SteamVR overlay performance is just abysmally bad with any overlay, even FPSVR; OpenXR does not have that problem. - if that doesn't help, or you're using some other configuration, https://openkneeboard.com/getting-help.html

@ldnz's fix is in https://github.com/OpenKneeboard/OpenKneeboard/releases/latest

> I mean all the text in the kneeboard Are images fine? What about mission briefings in OpenKneeboard? Could you try a chuck's guide or DCS manual PDF - do you have the same problem? Could you share a screenshot e.g. of the steamvr mirror window (not the DCS mirror window)? This sounds like a windows encoding/locale change, and the questions above are to try and confirm that - OpenKneeboard in particular requires files are UTF-8; another option would be missing or corrupted fonts. OpenKneeboard requires: Segoe UI Segoe MDL2 Assets Consolas These should all be included with windows

> gameoverlayrenderer64.dll That's the Steam (*not* SteamVR) overlay - the thing that gives you the shift-tab in-game steam features

FWIW, this is based on @Boris's post - the only major difference is that OpenKneeboard uses magvar at bullseye, which varies both by lat/long and by mission date.

> I believe it boils down to pancake lenses vs Fresnel lenses. Pancakes get the edge-to-edge, though quality of materials and design is still a huge variable both for the lenses and the optical stack overall; for the quest pro, they're great, but there are other headsets with pancake lenses which are a huge step down in visual quality compared to good fresnel headsets

Just to clarify: there is no such thing as 'OpenXR Motion Reprojection'; there is WMR motion reprojection, which confusingly can be enabled from OpenXR Tools for Windows Mixed Reality, or OpenXR Toolkit - but it is part of WMR, not OpenXR. For WMR DCS players, it can look like an OpenXR thing both because of where the settings are, and because when using SteamVR, SteamVR motion reprojection is used instead of WMR motion reprojection. It has no effect whatsoever on other headsets. Some other manufacturers have similar technology (like Oculus ASW). I'm being pedantic here as there is a huge amount of content talking about 'OpenXR' features which are written by G2 users, is WMR-specific, and is very confusing to others because it doesn't apply to Pixmax/Varjo/Oculus/... even when using OpenXR.

A higher framerate isn't actually needed to fix menu/loading distortion for Oculus and OpenXR, there is a better way that DCS could do things: Right now, DCS always draws a left eye and right eye view of a 3D world. When a 2D thing (loading screen, in-game menu/dialog) is being shown, it would be much better for it to provide the Oculus or OpenXR runtime with "here's a 2D image, display it at *this 3D position* with *this 3D rotation*"; the runtime is then able to accurately compensate for headset movement even without a good framerate. OpenXR: this would be mean providing two layers in `xrEndFrame`, the second being an https://registry.khronos.org/OpenXR/specs/1.0/man/html/XrCompositionLayerQuad.html Oculus API: similar - ovrEndFrame/ovrSubmitFrame/ovrSubmitFrame2 (DCS will use one of them, doesn't really matter which) with a https://developer.oculus.com/reference/libovr/v32/structovr_layer_quad Other than the raw work to do it, the downsides are: OpenVR doesn't /really/ support this, but ... another flight sim that recently gained SteamVR support ... works around this by pretending to be two steamvr apps: the game itself, and a steamvr overlay app. Overlay apps aren't supported by opencomposite though. ED could do the same, or keep things as-is on SteamVR, but either way it would add complication and mean maintaining two ways for things to work. When the runtime is fully responsible for world-locked or head-locked rendering at the headset framerate but DCS is running at a different framerate, the 2D stuff will be much more accurately world-locked - but this means it won't necessarily be in sync with the 3D world around it (e.g. the hanger in the menu if the menu was a 2D layer)

> VR *Assuming* the cursor position -> coordinate lua stuff continues to work in VR, if you have a graphics tablet (think wacom or huion, not 'phone' or 'microsoft surface/ipad') this should 'just work' using https://openkneeboard.com/features/window-capture.html to capture the DcsTheWay window, using the graphics tablet to press the buttons. I've not tested as I mostly play with the heavily scripted campaigns with all the necessary waypoints preloaded.

Updating the link from my previous post: https://openkneeboard.com/getting-help.html is the best place to get help > So if you're crashing in DCS MT - it may be Openkneeboard. Would need feedback from others to confirm. Could you use the link above, and include: - which headset you're using (if any) - DCS crash logs and dmp files (or the zip that includes them) If you're using Oculus or non-VR, work through https://openkneeboard.com/troubleshooting/oculus-or-non-vr.html#game-crashes first So far I'm not aware of any issues involving MT and OpenKneeboard. Just to recap: I am not regularly active on these forums. Use the information on the OpenKneeboard website (https://openkneeboard.com) for help or issues with openkneeboard.