actually_fred

SMS *lowers* security by making your account vulnerable to SIM takeover, and is actively banned as a two factor method in all modern standards. Lots of banks use it for customer authentication, and that makes pretty much every computer security professional sad. They generally insist on different - actually secure - methods for their employees though. There's PC options including WinAuth (free) and 1Password (subscription, but well worth it as a general purpose password manager), but the downside of these is that malware on your PC can potentially steal the 2-factor configuration along with your username and password.

Both Google Authenticator and Duo Mobile *can* work offline; Google Authenticator gives you the option to sign in for backups etc, but you don't need to; as I understand it, Google's primary motivation here is simply reducing spam and account takeovers - it reduces their other costs, the app is not directly an income source. Duo Mobile supports the standard authentication offline, but the same app also supports enterprise 2FA services (which is where they get their money) If there are any of the big tech companies you do trust, almost all of their apps will work with this - Microsoft, Salesforce, etc; again, their primary motivation for giving away these apps for free is usually to reduce account takeovers, which are a cost for them. FreeOTP is probably one of the more common 100%-offline apps - and its' rated low on the apple store because it's entirely offline: no way to transfer to a new phone, need to re-setup everything or use recovery codes etc. "Entirely offline" means "easy to get locked out of your accounts".

You need an app that understands the specific form of QR code; there are many options. The app will show a 6 digit number when you open the app, which you type into ED login. ED are using an open industry standard, which is widely recognized by security experts as much better than email or SMS. It's a slightly outdated standard (webauthn would be good), but it's still a big step up over email/SMS. If you want a long boring read, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf explicitly states that email 'SHALL NOT' be considered 2FA.

This 2FA does not require an external service; it just requires an app that can understand the QR codes. Some of the apps do have a service for backups etc, but some are entirely offline, with no communication between the app, ED, or anything else on the internet. It's basically doing: - QR code contains some random data that ED save, and is unique to you - app also saves that - when you use the app, the app combines the current time with that random data, does a checksum, and shows you the last 6 digits of the checksum. ED do the same math and check they get the same result No service or communication required except for exchanging that random data in the QR code once, just that two things doing the same math get the same result.

There’s a standard (OATH-TOTP) for these; almost any generic authenticator app will work. This includes (among *many* others) - google authenticator - authy - 1Password - duo mobile it doesn’t link your phone number, regardless of which app you use it would be nice to see support for newer standards like webauthn too in the future though (Touch ID/face id/windows hello/yubikeys)

It is possible that you had a partially uninstalled version from 2022, *and* a 2023 version which could explain a crash; installing the 2023 versions uninstalls the 2022 versions, but if you then later install an older 2022 version by hand, thanks to Microsoft’s restrictions, that’s now a second independent installation that doesn’t replace the 2023 one. Uninstalling the 2023 version then will not clean up the 2022 one

All versions of OpenKneeboard this year delete that entry; versions from 2022 do not as Microsoft ban “windows apps” (.msix or .appx installers, or Microsoft store) from providing any kind of uninstaller. That said, there are no known or reproducible issues with leaving that registry key around, but as you’ve only posted them repeatedly on the forum here rather than reporting as a bug with OpenKneeboard before deleting it, there’s nothing I can do based on what you’re saying for other users who may have also recently uninstalled a 2022 version.

It will actually make it worse, as it will need to copy a lot of data between the integrated GPU/system memory and your dedicated graphics card. This takes away from both GPUs and your CPU.

FWIW, the best fix for this is on OpenXR or the Oculus API is to render the loading screens as a 'quad layer' rather than putting it into the eye buffers. When this is done, even if the thread locks up, the VR runtime is able to re-render the layer at the correct position, accounting for head movement. This isn't directly supported via OpenVR as OpenVR as does not support submitting multiple layers, but 'another sim' works around this by spawning a separate OpenVR overlay process for the menus. > If you use OpenXR you'll get a black screen Current behavior varies between headsets, runtimes, and based on your system performance - even when using OpenXR. Sometimes a black screen, sometimes tearing, sometimes takes you back to SteamVR home, sometimes flickers in between several of these.

Quest pro is *by far* the easiest to eye peek - it's designed for it, as it's intended more as a professional/AR headset than a max-immersion VR headset. That said, they made this customizable: - just use the quest pro: lots of eye peek - partial light blockers: free, included in the box: restrict it on the sides, but not downwards. Magnetically attached, remove really easily/quickly, even when you're wearing the headset - 'full light blocker': $50, blocks of the bottom and nose too. also magnetically attached, quick to remove, but you need to take the headset off, and can't be attached while charging

The rendered skeleton is a feature of OpenXR Toolkit which DCS can't see and isn't really related to any potential built-in implementation. The information DCS needs is all available via XR_EXT_handtracking, including the skeletal joint positions. FWIW, leap motion is also available via XR_EXT_handtracking; there's a pretty solid chance that a XR_EXT_handtracking implementation in DCS could replace the existing leap motion support, instead of *adding* to the amount of things that ED need to maintain and test.

This is pretty much required for DCS: hand tracking is not part of the PC oculus API. Even with developer mode, IIRC it's only availably via Oculus's unity editor plugin. With OpenXR + developer mode, it is at least available to every OpenXR app that adds support for XR_EXT_handtracking.

This should probably be a generic request for DCS to support OpenXR handtracking (XR_EXT_handtracking): - it is not quest-specific - meta consider quest hand tracking on PC to be a developer-only feature and lock it behind developer mode. It works, usually, but it’s not officially supported.

I disagree with this - moving your hand *near* a cockpit switch triggers it, and AFAIK this can't be turned off. This is especially problematic when using hand tracking and controller emulation rather than real controllers, especially with switched around the throttle: it's way too easy to accidentally turn off an A10C's fuel pumps when going to full throttle - the bindings for oculus touch controllers (thumbstick directions rather than buttons) need precision to trigger reliably, and are unintuitive.

If it reliably failed in the same place it could be a compatibility issue, but random means it’s giving wrong answers sometimes . This was enough for intel to accept the return of my 13900KS

If it’s failing randomly at different parts, you need to: - remove any overclocking - undo any voltage changes (especially under volting, including SVID) - try again if it still fails randomly, you need to make a warranty claim with your computer manufacturer, or intel if you bought your cpu boxed retail.

You might also want to try https://www.intel.com/content/www/us/en/download/15951/intel-processor-diagnostic-tool.html - turn on looping, let it go through a few (at least 3) full loops. Not necessarily the same issue, but my 13900KS developed some bad cores after a few months that would have similar crash/dmp files, worth trying.

I've been looking at this recently at my T500RS is dying of old age (and abuse ); Fanatec say "This product is not compatible with any PlayStation® console and cannot be upgraded to achieve compatibility." on https://fanatec.com/eu-en/racing-wheels-direct-drive-bases/direct-drive-bases/podium-wheel-base-dd1 . Are you using a Drive Hub or similar, or is there something I'm missing?

- support for more games - you can mix and match: quest hand tracking, but with pointctrl finger units for the clicking. This can be better or worse; for me, it means that I don't need a cable to the headset, or blackout curtains on my window

It would also be a useful workaround for when the VR support gets wedged and just displays a black screen on the headset when you take it off for a few seconds an hour into a mission. While ED should also fix those bugs, this would offer a straightforward 'reset VR entirely' path to workaround them while they're being diagnosed.

The first generation of Core i3 do not have AVX, for example the 2.93ghz i3-530 - https://www.intel.com/content/www/us/en/products/sku/46472/intel-core-i3530-processor-4m-cache-2-93-ghz/specifications.html

There's a hotfix for v54/v55 airlink issues - try rebooting your headsets https://communityforums.atmeta.com/t5/Get-Help/Known-Issue-Quest-Airlink-lags-and-stutters-after-V54-update/m-p/1060992/highlight/true#M217894

Just an anecdote: the gains from requiring modern processors can be ridiculously good in surprising situations. In my previous job, I retargeted a C++ app from Nehalem (Intel 2008 - SSE 4.2 but no AVX) to Sandybridge (Intel 2011 - adds AVX and CLMUL) got a 19x speedup in real-world tests on the same hardware. I was expecting maybe a 20% reduction in runtime, not a 95% one. That said, huge +1 on it should be clear on the product page

Meta don't expose raw eye tracking data - only a processed version designed for 'social' (e.g. expressions in Horizon Worlds/Workrooms). I'm just guessing this part, but it could be they decided that including an offset in their data gave more understandable/human-looking expressions in Horizon. For eye-tracked foveated rendering, we need where you're actually looking instead of 'what looks best to other avatars'.

Hand tracking works on quest pro in PCVR if developer mode is enabled, and using link/airlink (not steamvr or virtual desktop)