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.

For me it seemed to be related to forward speed. I did multiple rounds of testing, approaching targets at different distances at about 60-70 knots and George consistently missed all shots, the missiles hitting behind the targets. When hovering or flying at 10-20 knots, all shots seemed to hit. Maybe something is calculated/compensated incorrectly when moving, or the delay between lasing for target data and firing the missile causes some kind of drift in the target location information or something. Just wild guesses, I have no idea how they actually (are supposed to) work.

Ok, thanks, that makes sense. Of course in real life you wouldn't have everything armed on the ground, especially during rearming. I sometimes put and leave the GND ORIDE on, as that way I can arm the chaffs already on the ground and have one less thing to reach for in MFDs while flying.

Check the weapon page, if your hellfire launchers are set to safe. You'll see a white box around them. This happens after rearm, and George usually doesn't arm the launchers, so you'll have to do it manually. In the util part of the weapon page, somewhere on the right is a "launcher arm" button (available in both seats), which arms the launchers, and then they work normally.

Check out VR Reality Mixer in Steam: https://store.steampowered.com/app/1844610/Reality_Mixer__Mixed_Reality_for_Vive_and_Index/ and Costs 4 euros and allows you to use the cameras of some common VR kits for mixed reality. Just set my Reverb G2 up with it (beta version supports WMR headsets). It works beautifully and allows me to see and use my physical MFD buttons etc. The picture quality of e.g. the G2 cameras is blurry black&white, so you won't be able to read small text etc, but will find your buttons and switches. For now it only supports SteamVR though.

The thing you don't seem to realize is that for many people real and obvious changes did happen in the previous patch. I'm not talking about people not knowing how to take off, but all weird sudden rolls that are happening during e.g. slow, trimmed forward flight, that certainly didn't happen before the previous patch (not the latest one), or rolling related to collective changes (which is logical, as you explained, but still different than before the patch). We believe you didn't intend these changes and did not change the "core flight model" that you're so stuck on, but you yourself said that the FMC collective channel and center of mass did change in that patch. Why is it so hard to believe that perhaps these or some other unintended (or internally undocumented/uncommunicated?) change did cause this behavior for all these people, even if you don't see it in your own testing? I'd understand your point if you really only changed e.g. some textures or pilot models or such... Even Casmo said in his video a short while back that the apache behaved differently for him after the patch, that he found it doing unexpected things when he tried to repeat what he had done before. I'm inclined to think he knows a thing or two about helicopters, so it's not because he doesn't know how to fly it. So here you're basically calling your customers stupid, that's just great. Really makes me want to pay you guys more money.

They have already stated facts about the topic, and as we're discussing the flight model which hasn't changed, I believe we're all just wrong and imagining things.

I see, and agree with you there. My point was more to the direction that if players give feedback that the thing flies/behaves weirdly, there might be a reason worth investigating even if the player can't give exact technical details or know how you differentiate what is flight model and what is not internally, instead of just falling back to "no changes were made to this specific part of the whole". And even if the player specifies some technical name of a system, you have to understand that we don't necessarily know what we're talking about or what it means to you in a technical sense. Following your example, a customer in a restaurant might generally complain that the taste of their favorite dish has changed, instead of being specific about which part or the way it was cooked, and then it would be the cook's job to figure out if they really changed something and if it's for the best, perhaps by asking the customer for more details if needed. And yes, working in software dev with customers myself, I perfectly understand that "this feels more twitchy and erratic" is not something that you can really work with. And I see you're already asking those more specific questions to get to the root of it, so kudos to you for being patient and trying to figure it out. The first reply by NineLine to the comments about the latest patch seemed more dismissive to me, and that's where my reaction comes from. To answer your questions, I don't really use the holds almost ever (but if I do, I try to trim as perfect as I can before engaging them), and mainly use the trim for level flight only. During combat maneuvers I generally don't touch the trim at all.

Exactly this. I don't know what happens internally at ED (communication issues or something?), and don't really care about semantics regarding what is "core flight model" etc, but in my experience the apache handles very differently now. Rolling a lot more than before, especially when lowering collective, so maybe it's due to the collective changes, maybe not. I'm not saying it's bad - if it's closer to the real thing, that's awesome. If there was some unintended change, that's fine too, it's WIP and will change in the future probably many times still, and we'll all anyway get used to flying it again. I still love it and you for developing it, and I'm happy to see all updates and improvements. But ED, please don't disregard and ignore people's feedback with a simple "nothing changed" when it's really obvious to us that something changed that has an effect on how it flies.

The VRS effect on Apache doesn't seem to do anything. I tried disabling all other effects and flying the Apache into VRS every way imaginable but didn't get any output. Other effects appear to work. Does anyone else have this problem / is this a known issue / am I missing something?

This would be cool. From the point of VR, some bumps or other tactile features on some buttons might be nice to make it usable "blind" (with VR headset on).