Toge

I have the same issue with Q3. Reverb G2 was spot on for me, but two other headsets were not. Also, on Q3, the whole monocle is too far forward, so the tube/lens blocks a lot of the lower right view.

This happened to me too, with the VR1. I used https://github.com/fredemmott/OpenXR-Tracing/ to debug the issue together with the tool author, and his diagnosis was the following: "this appears to be a DCS multithreading bug. DCS is literally making calls in an invalid order. This is funnily enough very similar to the Falcon BMS U5 + XRNS issue. probably affecting you and not others because multithreading bugs are often just plain luck. "Works on my machine but not yours" is normal there's a reasonable chance that the performance issue you're seeing is just the overhead of logging these failures it's not failing every frame, just sometimes. Specifically, games should go xrWaitFrame, xrBeginFrame, xrEndFrame in a loop. DCS is sometimes choosing to do xrWaitFrame in another thread - this is fine - but sometimes it's doing it after the BeginFrame, so the order ends up being (frame n) xrWaitFrame, xrBeginFrame, xrEndFrame, (frame n+1) xrBeginFrame, xrWaitFrame, xrEndFrame, which is invalid. The game and runtime recover, but it's not going to be flawless." Edit: Fred (the author of the tool) provided a corrected explanation below. So seems not to be a DCS issue after all. Thank you Fred for the debugging! Screenshot of the trace below, full .etl file (zipped) and dcs.log attached: null dcs.log MyTraceFile.zip

As mentioned in the title. Adjusting the brightness of the MPDs and TEDAC works normally in the cockpit, but the brightness of exported MPD and TEDAC displays are not affected. E.g. if I turn down the brightness of the MPDs so that they're completely black (or very bright) in the cockpit, the exported MPDs stay on "default" brightness and don't change at all. The day/nt switch doesn't do anything to exported screens either (mono setting turns them green however, as expected). This was discussed also in the multi-display forum, but didn't get any reaction from ED, so now posting here as well.

This was discussed in an earlier thread, where it was proposed to not render the head at all, as in other helicopters (as there's no situation where it should be visible like this). No explanation was ever given why this would be intended behaviour.

+1, for what it's worth. I'm interested in the module, but I'm waiting for this before buying.

It's correct behaviour.

Not to dismiss your bug report, but just to add that this is not universal. I have the TCS Plus base with Apache grip, and have flown hours in the Kiowa without any issues. Considering that DCS simply listens to input from Windows basically (so it shouldn't affect the controllers in any way), and that you had the problem also with the Mi-8, I'd guess you have a connection (or some other) problem on the base itself which just occurs randomly.

This has been beaten to death already, but just to add my humble opinion: I'm honestly not seeing any difference in the model or texture quality between the Kiowa or for example the Apache. I've tried looking at different screenshots and videos to see the difference, but no. And in game it's all the same and anyway looked at from quite a distance. I see a few people here commenting things like "unbelievable", "overpriced", etc, and really have no idea what these people are talking about. It's your opinion of course, it's as valid as mine and you're welcome to voice it, but to not scare away anyone who hasn't bought the module yet: People are different, someone's eyes apparently hurt when looking at this, whereas I'm very happy with what I'm seeing, and enjoy the module in other ways too (you know, flying it and fighting in it). If PC ever chooses to update the model and/or textures, I most likely won't notice the difference.

There are axis binds for the MMS. I don't remember exactly, but something like MMS slew vertical and MMS slew horizontal.

Manual page 20 says it can be set in the mission editor, there's an option to "Install Pilot Display Unit".

He has 14 knots of airspeed, George is hovering. Big difference in lift.

It was reported here about 8 months ago, and confirmed by many people since. No real news from ED, seems like they at least originally couldn't repro the issue. This happened to me too many times over the last few days while doing some Liberation missions (single player) where I had to fly quite far (60km+) to the targets. Same symptoms as everyone else in the linked thread: the RF hellfires miss targets at a consistent offset, always hitting the exactly same position (and yes, I've been using George to fire them from stable hover, stable forward flight, all sorts of other situations, on many occasions, immediately after lasing). I've never before had any issues with RF hellfires missing targets (except the very early days when there were other bugs), so I don't think I'm suddenly using them wrong. After INU reset, the missiles hit the targets perfectly. No mods installed. I tried to repro the issue for a track file on a smaller mission, but couldn't repro. I tried saving a track of the Liberation missions two times after it again happened there, but the track files didn't work at all. I'll try again when I have a couple of hours to spare, but hopefully ED could prioritize this a bit, as there apparently already were real track files showing the issue in the original thread. While not game breaking, it's really annoying to do a large, complex mission and just when you're supposed to start shooting, wait a long time for INU reset.

It's part of the loadout selection now, the leftmost box allows you to select the MMA (mast mounted assembly).

Try changing the "Res of cockpit displays" to 512 or 1024, if it has an effect. There was some earlier discussion also about some people having similar problems after an update, and clearing the shader cache helped some. Not sure if that's a thing still, but you can try deleting the fxo and metashaders2 folders in "C:\Users\[Username]\Saved Games\DCS".

What would even be the point of having the head there in the cockpit (1st person) view in the first place? You're never supposed to see it anyway as the camera is always supposed to be inside the head (as @BIGNEWY mentioned "head moving boundaries"), if I understood correctly. Is there some specific case when recording videos for cinematic purposes or something that I/we don't realize? Otherwise I find it absurd that anyone even considered (let alone spent time) adding the head there, or that movement boundaries would be an easier solution than removing the head from the model in the cockpit view.