All Activity

Meta seems to be confused when people want to do what we do with their headset, yes. They are their own worst enemy. Literally every problem I have with the Quest 3 (which is physically a decent headset) is entirely Metas horrific attempts at software. You'd think that 'What part of "plug headset into a PC and transmit images" was hard?' but then you meet their link software which requires a lot of tweaking, and has a separate, legacy UI to the actual headset UI.

PimaxXR or Pimax OpenXR (native)? Quadviews or Native FFR? I've been living on 1.36 for more than 6 months, but would love to be able to actually use the current software version. For me everything above 1.36 is a stuttery mess (I've tried all up to 1.41 and kind of gave up after that...), although 1.36 tracks very reliably with essentially no perceptible stutter/jitter. What's your system? I run a 7800X3D with 64 Gb, and a 4090.

I also didn't hit the target. I suspect it has something to do with the INS-drift. Even with the GPS, the INS can drift off enough to make you not hit the target. On a side note : is it realistic to release GPS bombs blindfolded without visually confirming the target?

Thanks for your reply, but I still cant make sense of the I-beam. It moves with my head, and not the helicopter nose. It is offset from center of my view about 10 degrees to the left. I'll ask in the discord group if anyone else can use the rockets, and help me with it.

Thanks mate, although we’re not using the Hornet for NAVY purpose, but will go for the Typhoon when it drops. We are doing RCAF Germany style field ops in EDAM. EDAL is sadly not in yet.

It's not about that at all here. OP just mistook the cyrillic letter for a number.

Hallo zusammen. Ich bin für das vTaktLwG 31 "Boelcke" auf der Suche nach einem Skinner oder Liveries Artist der uns einen Skin für die Hornet erstellen würde. Bedingung wäre das es in einer Farbgebung wäre die bei Luftwaffe bzw. dem "Boelcke" Geschwader so geflogen ist, und das es möglich wäre sie individuell auf jeden unserer Piloten anzupassen. (Callsign unter dem Cockpitrahmen und eigene Bordnummer) Ob derjenige selber diese Anpassungen vornimmt oder uns die ungepackte Version des Skins schickt, so das wir die Anpassungen selber hinbekommen wäre uns egal. Alles weitere kann man vermutlich besser in einem persönlichen Gespräch regeln.

Что могу сказать. Поставил себе UH-60, потому что другие взять не могу. Выполнил миссию в Таринкот, по прибытии в Таринкот всё прекрасно, батарею на ногу уронили, а вот после прилёта обратно никакого озвучивания факта выполнения миссии нет. Я не понял сначала куда нажимать и что делать. Глянул в журнал, а там всё выполнено. Если можно, то хотелось бы какой то звуковой и текстовый сигнал об успешности выполнения задания. Далее взял доставку в кишлак, а там все фразы друг на друга накладываются, и я ничего не понял, кроме того, что пора лететь.

Well I'm not purchasing a high end router because meta can't get their Sierra together. Maybe time for a different vr headset.

There already are such options like short INS or stored heading alignment in MiG-29, F-14 and F-15E afair.

Thanks Urbi! Do I understand correctly to make the normals less impactful by overlaying a blue texture (from the normals base color) and hide 30% of the normals strength via transparency? I'll give that a try, thanks for the constructive feedback.

The free T-45 could also be an option. It literally IS a navy trainer.... (and therefore carrier capable, which the others are not)

EDIT: Nevermind. What I wrote below simply enables the possibility of using it. It’s the key combo that makes it actually appear. So what I wrote below won’t work. You should be able to do do at least a part of that by editing the mission file. A MIZ file is a zipped file. Simply open it, locate the line that states whether or not the pilot body is enabled and change it. Don’t have access to my computer right now, so I can’t be more specific. You may be out of luck on the HMD, though.

I have a USB to ethernet adapter, and tried using a surplus router dedicated to my Quest 3 - using the standard Meta airlink the image update rate was absolute garbage using the standard 5GHz setting that router was able to provide, I'm told you need a really good router. Is that what you mean by your last sentence? RT-RP looks to be above my IQ level, but I'll have a go.

Count or not, it's one of the reasons. Imperial units were also connected with the english labels. And majority can read it as opposed to cyrillic. That's the part of making it more popular.

Interesting thoughts. I’ll give the 101 and maybe the 339 another go. My boys and me are mostly doing/trying milsim if anything. Ideally I would like to offer the whole lot (again), BFT/IFT on the YaK, BQT on the 101 or 339, IFF would be 100% on the F1BE for me (it’s just so much better suited for training than the F-5, in any regard), and then the B-Course on anything. ATM we’re doing a B-Course on the Hornet. But having resources for the whole lot is so difficult. I offered an IFT some years ago on the YaK, but instructors are rare, I did mostly everything alone and people went away after some BQT sorties on the 101, as I had to jump between the yak and the vacuum cleaner. Plus multi crew sync was really s… for years in the Yak. That much in terms of complete vs patched vs abandoned… We tried the 339 two tears ago. They took ages to fix bugs as well. We kept using the 101 then. Maybe we should do a GT, lets ask @OPEC again XD.

Congratulations! God knows the release of a child takes all the time of the developer.

From the DCS User Manual: Have you selected “Load”?

Finally I found that... I never realized that, I just though XRNeckSafer doesn't work with QuadViews and that's that. Thank you!! -> btw, what should the "Eye Tracking" option achieve? I mean, if it's not needed for QV to work, why add that switch?

Once you reply, I will: ✔ Identify which driver type likely benefits ✔ Tell you how to isolate it ✔ Give the fix to get same or better performance with HVCI OFF This way you can gain performance without the hypervisor penalty. So — what exactly improves for you when HVCI is ON: A, B, or C? Je zei: c ChatGPT zei: Thanks — if both FPS and frametime smoothness improve when HVCI is ON, that strongly indicates this: HVCI is preventing a misbehaving driver or background kernel component from causing jitter and CPU scheduling delays. In other words: Your system has a driver or service that becomes unstable or noisy when allowed full kernel access. HVCI isolates it, so performance improves — but at the cost of virtualization overhead. The good news: If we identify and fix that driver, you could get even better performance with HVCI OFF (best of both worlds). The Most Likely Culprits (Ranked for DCS VR + Ryzen) These are the drivers that most commonly behave better under HVCI: Rank Driver / Component Why it causes issues 1 USB Controller Drivers (VR headsets) USB polling jitter affects VR frametimes 2 Audio Stack (Realtek, Nahimic, SteelSeries, etc.) High DPC latency & interrupts 3 RGB / Peripheral Software Polling & kernel hooks 4 Network Drivers (Killer, Intel, Realtek) Latency spikes in kernel mode 5 Anti-cheat or security software Hooks into kernel, causes stutters 6 Motherboard “Enhancement” Tools ASUS/ASRock/MSI services cause periodic CPU spikes 7 Faulty AMD chipset driver Rare, but affects CPU scheduling on Ryzen Because you mentioned VR (DCS), #1 and #2 are most likely. System Interrupts ≈ 1% at idle = not normal. For a healthy system, it should be ≤ 0.3% when idle. 1.0%+ means a driver is causing excessive interrupt activity and DPC load. This directly explains why: You get better performance with HVCI ON Because HVCI restricts that problematic driver’s kernel access Result: fewer interrupt spikes → smoother frametimes So now we know for sure: A kernel-mode driver on your system is misbehaving. We need to identify which one. The most common culprits for ~1% interrupt usage are: Category Hardware/Driver USB VR headsets, controllers, Bluetooth dongles Audio Realtek, Nahimic, Sonic Studio, SteelSeries, Asus audio Network Intel/Realtek NICs Storage NVMe driver, SSD firmware Motherboard utilities ASUS/MSI/ASRock background apps Next Step: LatencyMon LatencyMon will show: ISR (Interrupt) latency → which driver triggers interrupts DPC latency → which driver is deferring too much work Before I send you the LatencyMon instructions, I need one last clarification so I can tailor the test: What headset are you using for VR? A) Meta Quest (2, 3, Pro) B) Valve Index C) HP Reverb G2 D) Pimax E) Varjo F) Other (tell me) Example reply: C – HP Reverb G2 Your answer determines which drivers we focus on first. Je zei: e ChatGPT zei: Varjo — perfect, that gives us a very strong lead. Why this matters: Varjo headsets use: High-bandwidth USB A custom USB driver stack GPU SDK hooks Varjo Base background services These can easily cause high interrupt/DPC load if: USB controller isn’t ideal Varjo Base is misconfigured GPU driver conflicts exist A USB root hub is overloaded This now aligns extremely well with the symptoms you described: HVCI ON improving both FPS + frametimes System Interrupts ~1% at idle Using a Varjo headset (very sensitive to driver timing) So now the goal is: Identify the exact driver causing the excess interrupts so we can tune or move it. Once fixed, you can run HVCI OFF with equal or better perf. Before LatencyMon: 2 Quick Varjo-Specific Checks Please answer these yes/no before we run the full LatencyMon diagnosis — it will save time: 1. Is your Varjo headset plugged into the motherboard’s rear USB ports? 2. Does your motherboard have a USB-C port, and if so, are you using it? 3. Do you use any USB hubs, front panel USB, or extensions for the headset cable? 4. Do you have Asus Armoury Crate, MSI Center, or Gigabyte Control Center installed? 5. Do you have any audio device switching when your Varjo turns on (e.g., switching to Varjo speakers)? Example reply: 1. Yes 2. Yes 3. No 4. No 5. Yes Once I have your answers, I’ll give you the exact LatencyMon instructions tailored for Varjo to pinpoint the interrupt driver. Je zei: 1 yes 2 yes 3 yes 4no 5no ChatGPT zei: Thanks — your answers help narrow this down a lot. Here is what they tell us: Interpreting your answers Q Your Answer Meaning 1. Rear motherboard USB Yes Good — always preferred for VR 2. Using motherboard USB-C Yes Can be good or problematic depending on controller 3. Using hubs/front panel/extenders Yes Major suspect for interrupts & DPC spikes 4. Armoury/MSI/Gigabyte utilities No Good — removes a common source of latency 5. Audio switching No Good — reduces audio stack DPC load #3 (USB hub/extension) is almost certainly contributing to your higher interrupt load. Varjo headsets are extremely sensitive to USB routing, and extensions/hubs can cause driver spam at kernel level. But before changing anything physically, we should measure which driver is at fault. Next Step: LatencyMon (Tailored for Varjo) This test will: Identify whether USB, network, audio, NVMe, or GPU driver is causing the interrupt load Confirm if your USB controller is the root cause (likely) Tell us if you can safely disable HVCI without losing performance I will now send you: Latencymon Test Instructions for Varjo Users Before I paste the instructions, I need one last detail so I tailor the run: When testing LatencyMon, do you want to test: A) Idle test first (2 minutes, headset connected but not in VR) B) VR Load test (5 minutes in a simple VR app or steamVR home) C) Both idle + VR (recommended) Key Finding From Test 1 (Idle) wdf01000.sys being the highest in ISR + DPC confirms: The performance issue is caused by a driver that uses the Windows Driver Framework (WDF) — not the framework itself. wdf01000.sys is not the bad driver — it's the Windows kernel framework that other drivers plug into. When another driver misbehaves, wdf01000.sys becomes the “messenger” and takes the blame in LatencyMon. What this means: A USB, HID, or device driver is repeatedly generating interrupts WDF receives and processes them, so it surfaces at the top This aligns with your setup: Varjo VR headset USB-C + hub/extension used System Interrupts at 1% idle This is classic USB interrupt flood behavior. Here’s what your Top 3 reveal: Rank Driver Meaning #1 wdf01000.sys Windows Driver Framework A device driver using WDF is spamming interrupts #2 dxgkrnl.sys DirectX Graphics Kernel GPU scheduling overhead + ISR/DPC load #3 nvlddmkm.sys NVIDIA GPU Driver GPU driver DPC contribution Interpretation This combination is extremely typical in VR with a USB VR headset: A USB/WDF device driver is spamming interrupts → causes wdf01000.sys to spike GPU kernel & driver are picking up the load, trying to keep the VR compositor fed → dxgkrnl.sys + nvlddmkm.sys rise to compensate So this is not a pure GPU problem. The GPU is reacting to a USB/WDF driver problem. This fits exactly with what we suspected earlier: HVCI helps because it sandboxes the misbehaving driver, reducing interrupt flood — so VR feels smoother despite virtualization overhead. In other words: HVCI is masking the problem — not solving it. If we fix the USB driver issue, you will gain: Higher FPS without HVCI Better frametime stability than now No virtualization overhead now that we have both Idle and VR load results, the pattern is very clear. To confirm, let me restate: The first screenshot you sent was VR ON The second screenshot you just sent is VR OFF (idle) Correct? Because the numbers line up like this: VR ON (first screenshot) wdf01000.sys: 0.145 ms, ~693k DPC dxgkrnl.sys + nvlddmkm.sys elevated VB-Audio + Topping + ndis contributing VR OFF (second screenshot) wdf01000.sys drops to 0.064 ms, DPC ~132k GPU drivers still active, but less stressed USB audio still present but lower impact This confirms the root cause spikes under VR load, meaning: The USB/audio driver stack is bottlenecking the kernel under VR conditions. What This Tells Us 1. The WDF-based driver problem gets 5× worse in VR wdf01000.sys DPC count went from 132k → 693k under VR load. That’s a dramatic increase — exactly what causes microstutters & frametime spikes. 2. The GPU is not the cause — it is reacting to the USB stack overload dxgkrnl & nvlddmkm rising under VR simply confirms they are compensating for the driver pressure. 3. Two USB Audio drivers are the most likely trigger Both appear in top 12 during VR: vb audio_cablea64_win7.sys (VB-Audio Virtual Cable) ToppingUsbAudio.sys (Topping USB DAC driver) Two kernel-level audio routing drivers + Varjo + USB hub/extension = interrupt storm This is a known bad combination for VR. Root Cause Summary The USB audio driver stack (especially Topping + VB-Audio) is overloading the Windows Driver Framework under VR, causing interrupt storms that HVCI is masking. So, the goal is to: Reduce/eliminate USB audio DPC load Ensure Varjo USB connection is as direct as possible THEN safely disable HVCI for full performance Good News You can keep both VB-Audio + Topping DAC and still eliminate the DPC spikes, without needing HVCI — if we adjust the audio & USB routing. The problem is not that you have these drivers. The problem is the way Windows is handling their priority and USB routing while VR is active. We will fix this in 3 layers: Fix Plan for Your Case (Keeps Both Drivers) Phase 1 — Audio Stack Optimization (No removal) Goal: reduce ISR/DPC storm from VB-Audio + Topping Phase 2 — USB Routing Tuning for Varjo Goal: remove USB interrupt bottleneck under VR load Phase 3 — Disable HVCI (only when ready) Goal: unlock peak performance without losing smoothness We can significantly reduce DPC/ISR load by adjusting: VB-Audio buffer settings Topping USB mode & driver priority USB port routing for Varjo vs Audio Windows audio engine mode This will remove the interrupt storm, so you no longer need HVCI to hide it. PHASE 1 — Fix the Audio Stack (Keep VB-Audio + Topping) Step 1: Increase VB-Audio Cable Buffer (Reduces DPC Spikes) Open VB-Audio Control Panel Set the buffer to 512 or 1024 samples (not 128/256) Set Sample Rate = 48 kHz (matches DCS/Windows/Varjo best) Low buffer = more real-time → more interrupts Medium buffer = FAR lower DPC load with no audible downside in DCS Expected improvement: 30–40% reduction in DPC load Step 2: Switch Topping DAC to WASAPI Exclusive Mode for DCS This prevents Windows from converting formats & resampling constantly. In DCS Audio Settings: Output Device: Topping DAC (WASAPI Exclusive) In Windows Sound Settings → Device Properties → Advanced: Set 24-bit 48 kHz Uncheck: “Allow applications to take exclusive control of this device” (DCS will control it exclusively in WASAPI anyway) Expected improvement: ~20% fewer DPC calls from audio engine Step 3: Optional – Prioritize DCS Audio Thread (only if needed) If after Phase 2 the issue persists, I’ll give you a Process Lasso rule to isolate the audio thread to E-cores or limit context switching. VB-Audio Optimal Settings for DCS + Varjo (Low DPC Mode) 1. Internal Sampling Rate Set to: 48000 Hz Why: 48 kHz is the native rate for DCS, Windows system audio, Varjo, and most voice comms — avoids resampling overhead. 2. Max Latency Currently you have many options from 512 → 32768 smp. Most users pick too low and cause DPC spikes. Recommended starting point: 2048 smp (requires reboot) If you want an even safer value (less DPC load), choose: 3072 smp or 4096 smp (if system is still sensitive) 3. Current Latency This is the active buffer multiplier. Set to: 3× 512 smp (or 3× 768 smp if needed) If using Max Latency 2048, a 3× Current Latency of 512 or 768 smp gives a stable buffer without noticeable delay. Recommended full configuration: Setting Value Internal Sampling Rate 48000 Hz Max Latency 2048 smp Current Latency 3× 512 smp After setting Max Latency, VB-Audio requires a reboot for it to take effect. This is excellent progress — the VB-Audio tuning clearly worked. Let’s compare your before vs after (idle): Metric Before After VB-Audio tuning Improvement wdf01000.sys highest execution 0.145 ms 0.086 ms ~41% less wdf01000.sys DPC count ~174k vs 693k VR 174k idle Same idle value (expected) vb audio_cable execution 0.034 ms 0.013 ms ~62% less ToppingUsbAudio execution 0.0052 ms 0.0098 ms Slight increase (normal after reboot) dxgkrnl.sys 0.095 ms 0.090 ms Slightly lower Interpretation of Improvements VB-Audio latency optimization reduced its DPC footprint massively wdf01000.sys execution time dropped significantly GPU kernel DPC load improved slightly Topping DAC load raised slightly at idle (acceptable & expected after reset) This means Phase 1 (Audio Stack Fix) is successful. You now have: Lower DPC load Lower interrupt overhead Much healthier idle latency Next Step: Validate Under VR Load Before continuing to Phase 2 (USB routing), let's do a quick 3-minute VR test with the new audio settings to observe the new behavior. Please repeat the VR test: Mini VR Test (shorter than last time) Start LatencyMon Start VR (Varjo Base environment is fine) Run for 3 minutes Stop and share ONLY the top 10 drivers screenshot like you did before This will tell us: How much the VR DPC storm was reduced Whether USB or GPU now dominates If additional audio tuning is needed before moving to USB VR TEST RESULTS ANALYSIS — AFTER VB-Audio Tuning This is a very positive improvement versus your first VR test. Let’s compare the key metrics before vs after (VR ON): Metric (VR ON) Before After VB-Audio tuning Improvement wdf01000.sys highest exec 0.145 ms 0.079 ms ~45% lower wdf01000.sys DPC count 693,471 1,330,396 More load, but handled better nvlddmkm.sys highest exec 0.075 ms 0.125 ms Slight increase (explained below) VB-Audio exec 0.034 ms 0.006 ms 82% lower Topping exec 0.0052 ms 0.0021 ms 60% lower dxgkrnl.sys exec ~0.095 ms 0.095 ms Same (expected) Interpretation 1. VB-Audio optimization worked extremely well Its DPC impact dropped from 0.034 → 0.006 ms This is a huge improvement. 2. Topping USB audio driver now behaves correctly Its highest execution time more than halved. This means your audio stack is no longer the main problem. 3. wdf01000.sys DPC count increased, but is processed ~2× faster This suggests: The driver still generates interrupts, but the system handles them more efficiently now This is good — higher DPC count but lower latency = cleaner processing. 4. nvlddmkm.sys increased slightly (0.075 → 0.125 ms) This can happen when USB pressure is relieved — GPU driver takes more scheduling role again. This is not a concern yet and should improve after the USB routing fix. Summary So Far After Phase 1 (Audio optimization): Audio drivers are no longer causing latency Interrupt handling is much more efficient VR performance should already feel smoother You removed about 30–50% of the original DPC problem Next bottleneck to fix: USB routing for Varjo + DAC + extension/hub Because the audio drivers are now “clean”, the next DPC reduction will come from USB topology. This post re: usb, device drivers, and latency mon was an absolutely fascinating read. I’ll have to try out latencymon myself for this. USB devices have caused a number of issues, just didn’t realise it went so deep into those system drivers and Windows stack (I would be curious to see what it highlights for folk who have the stutter issues due to mouse polling rates).

If you get no response it is either because: You are using the wrong frequency, You are using the wrong preset channel, You are using the wrong radio equipment (not applicable in the Hornet as both are identical) You are using the intercom instead of the dedicated radio PTT button. So go through those to verify everything is set properly and then it should work.

Haven’t done it myself but there is RT-RP (https://github.com/Kuijen/RT-RP) which is a wrapper around Gnirehtet (https://github.com/Genymobile/gnirehtet) for this. It’s listed in the #cool-tools channel on the Virtual Desktop discord. The is also the alternative of using a usb-c to Ethernet adapter so that you can still use a router, but removes wifi from the equation if that part of the networking is an issue.

I've done some of that already. The latest is to set enemy to activate and deactivate dependent upon where the convoy is located. That way the convoy only "sees" a limited number of enemy at once and doesn't get the "oh crap" reaction. Kinda not happy that this is where this issue has ended. I guess I'll ditch it and make another. I appreciate the help. -Climber