Bowman-011

As a day-one G2 user I'm also on the lookout for an upgrade. The Aero is ever so tempting especially with the recent price cut. But if I'm going for an upgrade it has to be something that outmatches the G2 in every way. For me the Aero is not quite far enough down that road despite having some unquestionable advantages over the G2 and Pimax never fully convinced me. What I would wish for: extended FOV, eye tracking, inside-out tracking, decent pass-through and hand tracking. For now I've decided to wait what the next months will bring. XR-4 has already been announced and maybe some other interesting candidates will enter the game. Until then I'll stick to my G2 with some quality upgrades such as a custom face gasket and leapmotion controller and rather do what Michael does: enjoy the immersion.

Picking up the A-10C after a longer time in the Viper I was trying to run one of the quickstart missions to see if I still remember all the buttons and procedures. Everything went as planned, even getting in touch with JTAC. I was going through the interactive workflow for nineline, remarks, readback until I reported "IP Inbound". This call, however, was unanswered. I'd expected a "Hawg11, Continue" but nothing happens. After that the other commands like "In hot" never gave me the expected feedback. The only thing that did work was when I reported "contact" on the target - and finally when I destroyed everything I received the "no further tasking available". Did I miss something? Has the procedure changed or is something broken? I'm running VAICOM 2.9.0.5 and the latest Open Beta of DCS jtac-fail.trk

nope, doesn't work unfortunately. See https://forum.dcs.world/topic/335325-spotting-dot-bugs-in-vr

Thanks for the hint! I totally overlooked this. Will try it out, tonight.

Honestly, I'm quite fascinated with the visuals and the new options this new version offers. Absolutely amazing! But there's one thing I haven't yet figured out with my G2: regardless of the settings (DLSS, MSAA, DLAA, even in everything set to "off") targets appear as rather huge black block of pixels between about 30 to 5 nm. Depending on the LOD slider when closing in at some point the blocks then eventually dissolve into something that looks like an aircraft. In 2.8 far away objects were at least the size of a single pixel if they were somehow in what one could call visible range. Has anyone else noticed this? It's difficult to show in a screenshot, though.

Ok, now I get what you mean. I tried the same thing with the A-10C II and there the TGP IR is broken as you guys already mentioned. IR Mavs however look good in both, MT and ST. And they look similar to my MT screenshot of the A-10A IR Mav display. Then I'd say that the ST Mav version is broken --> therefore no MT issue here!

No TGP in the A-10A. This is just the Maverick sight. And if you're asking me, I'd say that the ST version is broken.

When running a simple test mission to compare the performance of MT and ST DCS I noticed by chance that the contrast and brightness of the AGM-65D display looks completely different in both versions. MT looks bright and clear while ST is quite dark and has some strange black moving cloud-like artifacts on top of it. Track file and screenshots are attached: MT: ST: mt_a-10a_mavericks_issue.trk

Yes, problem solved!

Shame on me... After reinstalling and resetting my graphics driver without success I finally found the culprit: The maxfps setting was configured in the autoexec.cfg file in my DCS user profile! I've configured this a long time ago and it never worked for me in VR. Only with MT this somehow came into play.

Even with MR I should get 90 fps in menus. But I checked all the switches and set them all to disabled... at least all I could find: OpenXR toolkit and OpenXR Developer Tools. With the exact same settings that lock me at 45 fps in MT I get 50-80 fps in ST DCS. Next thing I'm gonna try is a clean driver installation which resets any existing settings... or I'll have to wait for the next patch.

Yes, the headset is 90 Hz, HP Reverb G2. I neither set a frame limiter nor have I enabled MR. It should run as fast as it can… which it does perfectly in non-MT DCS. Hence the confusion.

I'm quite puzzled with the new MT feature of DCS. When running ST (with OpenXR) I get between 50 and 80 fps depending on the situation. MT however locks me at exactly 45 fps. I checked any potential frame limiting software on my PC including the NVIDIA drivers and of cause the Motion Reprojection features of OpenXR and the OpenXR toolkit which I set to DISABLED. I even uninstalled the OpenXR toolkit. No joy... Any idea?

Every couple of months I try out how good hand tracking has become so far with LeapMotion which I own since a couple of years now. So far I have always been impressed initially and really wanted to make the switch but there's always been a catch which in the end made me jump back to my current standard (currently I use a combination of physical mouse and mouse buttons mapped to my HOTAS together with head movement) A few days back I stumbled across a Video made by Juan Pedro Fisanot and since then I've been testing his recommendations. This finally made me "take the leap". I'm really happy with my setup now. Still, the tracking quality isn't always the best and rotary buttons are a "no, no". But it really helps me to overcome the quirks. In a nutshell: use the mappings to enable / disable the hands to only show them when required. I didn't know these mappings existed. And he recommends to use it in combination with the open source tool "fingers" (https://github.com/glenmurphy/fingers/releases/tag/v0.9.3) mentioned some time ago in this thread so that you always have a proper tool for each situation. But see for yourself and enjoy trying it out.

Nope. Unfortunately not. I gave up and decided to opt for a combination of using the mouse, physical MFD buttons and mouse button binds to my HOTAS.

Sorry that you don't see an improvement. You're correct, OpenXR will have an impact on performance. But this accounts for many other things as well like viewing distance, texture resolution, NVIDIA settings or the resolution I use on my headset. Personally, I don't consider OpenXR as a mod since in the meantime it leaves the DCS installation completely untouched. It's a part of my current setup and I mentioned it, to give anyone else a chance to put my results into context. My claim is just that with the first release of the map I got potato performance and now I get at least acceptable performance. Same system, no setup or config changes. Let's not forget, this is the first patch after the map release. Just think about how long we're already waiting for things like multithreading, Vulkan API or a fix for the flickering clouds in VR . Best hope: RTX 4090 is only a couple of months out .

You guys really made me wonder if I'm looking at a placebo or not . So I did some additional testing and tried with different planes and on different locations on the map, as some of you have reported different performance on different spots. My setup is "calibrated" to get solid 45 FPS on the Syria map when flying over Beirut with some clouds (OpenXR, no reprojection, locked at 45 FPS using RivaTuner). Low level flying for me works great in the region of Ushuaia. I'm even able to land having 45 FPS with some occasional drops. Over the Falklands however, I can still see drops in FPS but less dramatic than before. On the northern part over the Argentinian mainland and especially over the bigger cities performance still drops to 25-30 FPS. But still, this is much better than the slideshow mode I used to get in the previous version where at low level I was down to unusable 10-15 FPS. Bottom line: you can already have fun on the map in VR especially if you fly high. Some regions seem to work better at low level then others, but there is definitely progress. I already fell in love with the region I'm looking forward to see this map continue its journey.

wow! The latest patch pretty much fixed the fps issue below 800ft (for me). Thanks RAZBAM

Hello everyone, Since the initial releases I've completely switched from SteamVR to OpenXR and I'm quite happy. However, there is one tiny thing that bothers me: I don't own PointCtrl and I'm using the Reverb G2's hand controllers which is an 'ok' solution for me. Under OpenXR they work slightly different than in SteamVR. For example the thumbstick deadzones are very small and force feedback is triggered when I touch the thumbstick, which makes no sense to me. Instead, haptic feedback when pressing cockpit buttons isn't working under OpenXR. There are so many components involved (OpenXR, OpenComposite, OpenXR Tool Kit and finally DCS) and I'm not sure where to fix this, if even possible. I was browsing through all the options and config files of the listed tools and I couldn't find anything. Is this hardcoded somewhere? I'd appreciate if someone could point me to the right direction, since I wasn't yet able to find an answer.

Ok, now I think I'm one step closer in understanding the matter. Wags' video on the FIX page got me thinking and I really do think now that it's related to the INS. When I checked the mission where I get the deviation from the intended position I saw that the date was set to 1983 which would make it a pre-GPS era scenario. Hence, the INS starts to drift as soon as I move the stick. Just out of curiosity I changed the date to 2011 and suddenly the drift and the offset are gone. I'm not an expert. So if anyone comes up with a better explanation, let me know

No, I didn't. In fact this happens even when I'm in active pause and I place a waypoint right in front of me.

Hey everyone, I made a quick test because the other day I thought I saw a similar issue but in that moment I didn't pay attention. In my first test everything worked as expected: taking coordinates (lat/long) from the map view and entering them on the ICP did exactly what I intended. The waypoint was spot-on the target as shown in the "_no_issue" track. However, I wanted to run my favorite "Lets-try-out-new-DCS-versions" mission in Syria where I first observed the waypoint offset. There placed a waypoint right on the intersection of the two runways at Ramat David l Now look at this: It is close but not where I wanted it to be. With this particular mission I have already reported an issue end of last year which I assume is related to the behavior that we see here. Hope this helps getting to the bottom of this. IA-F-16CM-Canyon Run Attack_strpt_issue.trk F-16C_Syria_Waypoint_no_Issue.trk

"its not a bug, its a feature!" DMS down long is indeed the answer to that problem. Thanks for clarifying. Could you please update the table on page 51 of the Viper manual. I first thought that this is a bad case of RTFM but I couldn't find this feature in the documentation.

Behavior: After repeatedly running into this issue I finally caught it on a track short enough to submit. In an A/G dummy air-start mission I play around with the TGP and the HTS with the HMCS turned on. After some time I realize that the HMCS symbology disappeared. I was unable to recover it no matter what I did. Turning the HMCS off and on with the know didn't make any difference. Neither did playing with the HMCS config settings. Since I wanted to preserve the issue in a track I didn't bother to wait if the issue would "self-heal" after some time. Observed in: DCS 2.7.12.23362 Open Beta At track time: 545s ++ hmcs_disappearing.trk

SOLVED: As mentioned below by FUNK, pixel density deeds to be at exactly 1.0 in DCS. Strange... I'm getting good results with plain OpenXR and wanted to try out the OpenXR-Toolkit but as soon as I activate it, DCS won't start anymore. Tried already some variation of starting or not starting WMRP but the result is always the same. Not even an error message in the logs?!? Any idea?