Phantom711

@Rufuz64 @Harker Alright...it all starts to make sense now. I didn´t read rufuz´post as providing an example of the problem at hand but rather another unrelated problem. And my thought process was more like, if the system saves 33ft to be 33m, then the MK point would be above the previous designation. But as I said, it makes sense now.... My bad for causing more confusion. (Even though I believe, nothing I said is actually wrong, it just isn´t the cause of this particular problem).

@Rufuz64 If you are actually doing this in relatively quick succession, I think the error should not be as big as it apparently is. Which would then probably make this a bug. Well, yes, it can be inaccurate. Google "DTED (Digital Terrain Elevation Data)". This is now talking real life...don´t know how that is reflected in DCS.

This could be a bug. But it could also be „correct as is“ if it is meant to portray some inaccuracies in target location if looking at it from an angle and also slight inaccuracies in terrain elevation data.

You mean the external lights on your Hornet? You probably forgot to turn on the „External lights master switch“. It is a pinky switch on the throttle. As for your Air Refueling: Sorry, that‘s a skill issue. I fly in a virtual squadron and we do this almost every mission…there is really not witchcraft involved… But please, let‘s not start the umpteenth „How to AAR“ thread. Use the search function here in the forum.

I can‘t help you with the main issue here. As for the other question: I don‘t know if it‘s documented, but if you want to use QVFR with DCS you now need to tick the respective box. For whatever reason the eye-tracking works without the box ticked.

Kind of… There is a mod called DCS-DTC. It basically actually starts pressing the respective buttons, so it is advisable to keep your hands clear as long as it‘s doing it‘s thing. Google it, it‘s on github and discord. Unfortunately JDAM PP programming is currently bugged and the developer is taking sone time off at the moment. EDIT: There is an unofficial fix to that JDAM PP programming now.

That is correct. It‘s just that QVFR specifically puts a little more stress on the CPU in some situations. I myself, flying the Hornet mostly, I find it still beneficial for my usecase.

@slughead Even with a 4090 I feel that there still is a lot of benefit and performance gain with QVFR.

As someone who flies in a virtual Squadron that puts a lot of emphasis on Carrier ops, I can only recall one instance in the past few month(!) where someone damaged his gear on a trap. Otherwise it‘s really not an observed issue really…

@VR Flight Guy in PJ Pants Well yes, the passthrough of a Q3 is was better than that if the QPro. But how many people have setups with like even just the front section of a cockpit and can make use of those early adoptions of an AR cockpit? You only take that one aspect to call the QPro „rubbish“ while disregarding the performance advantage of eye-tracking/DFR. As far as I can tell my USB-C connection is better than my WiFi6. DP would be superior though.

No. OpenXR is the default. and also that „—force_enable_VR“ extension might cause issues when you use the new DCS launcher.

Do you mean the OpenXR tools for WMR or the OpenXR toolkit companion which lets you make some adjustments while in VR with the blue-ish window popping up. In any case neither of them need to be started prior starting DCS. And you are more than likely running DCS in OpenXR anyways because it us the default, and arguably best way of running DCS in VR. But yes, the ORX toolkit companion is not being updated anymore and might(!!!) cause issues.

@VR Flight Guy in PJ Pants Can you elaborate further on that? Because I don‘t understand your reasoning here.

Trust me, the pancake lenses of a Quest 3 or Quest Pro are just so much better than the fresnel lenses of a G2. You simply can‘t just compare VR headsets by their resolution. The Quest headsets can also be used at refresh rates of 72 or 80Hz without flickering. Indirectly that also helps in performance compared to the 90Hz of the G2. Now since you also look for a headset that your son can use for other standalone games, I out of the 2 I would recommend the Q3. If it was only for DCS, I would argue that the QPro is the overall better choice due to it‘s eye-tracking feature. I‘ll die on that hill.

@Justin1Ntime Be aware that the game will be smoothest when FPS match the refresh rate. So usually 72FPS at 72Hz will appear smoother than 90FPS at 120Hz. And yes…as already stated, in VR your FPS can not exceed the headset‘s refresh rate.

Hey, yeah…same problem here. Started like 3 weeks ago. I also went ahead and turned off hand-tracking. Still need to evaluate if that solved it. But good to know, that it seems to be a common problem. At least that increases chances of it getting fixed.

@BIGNEWY @Nealius Sorry to bring this up again... What I discovered now is, that when I use the "Quit to desktop" option to leave the game (multiplayer), a nicely working replay is created. Same applies to other brute force measures to end the game (i.e. Task manager). If I leave via "Quit" or "Leave server" the replay comes up with "Mission Load Fail". Sounds good, right? Well yes, but unfortunately replays that worked up to like 2 or 3 weeks ago (until September update?) now still load, but no clients spawn. ED...this is sabotage....

1. OpenXR toolkit might not work properly any more. 2. Turbo Mode is enabled by default in QuadViews and you should not enable it additionally in OXRTK. That might actually also be the source of your problem here.

Ok. I rechecked now. I hope you have a seperate monitor for OBS because that helps a lot, but should work regardless. So start the game you want to capture. In OBS select "Game capture". In the dropdown now select "capture specific window" and then select the respective game (window) in the next dropdown. That should be it. (You don´t need to repeat those steps next time you want to capture). At least that´s how it works for me with DCS, I don´t know, how IL-2 behaves. But this is a DCS Forum.

Try „Game capture“ or something like that. Can‘t recall the exact name right now.

@Lord Vader Thanks for taking the time to answer. As I said, I don‘t claim that it is definitely(!) wrong. I just felt it might have been overlooked or misinterpreted. But if that‘s what you research came up with, I believe you.

@Cali Sounds like you have it assigned as buttons. You must assign it as an axis in the DCS controls options. There is a dropdown menu on top where you can select all available axis commands.

@NineLine Are those maps not just GeoTIFFs? Where would they need to go?

The keyword is „scan volume“ here! I do not question the fact, that EXP3 requires the scan volume to be limited to 90deg. This has probably to do with providing a higher update rate. What I do question is if or why the radar is not „willing“ to slew those 90deg of scan volume all the way to the left or right. In the above case, scanning from 70deg right to 20deg left would still be the 90deg of azimuth scan that you are referring to. I don‘t have anything to prove my case, I am just deducting that from how the radar behaves in A/A (i.e. TWS AUTO). It simply doesn‘t appear plausible to me, that the azimuth scan in A/G needs to stay centered around the nose.

@BIGNEWY But this would still be within the physical gimbal limits of the radar. Wouldn‘t it make sense that the radar adjusts its scan pattern to the right if the selected target is there? I mean it took a while until ED implemented A/A radar slewing to the left and right…maybe this feature should also exist in A/G…? I really don‘t know and hence don‘t have any publicly available evidence.