Toge

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).

I have the Virpil ACE pedals, and also had old Saitek Pro Combat pedals before. The difference of course is like night and day, plastic imprecise toys vs the smooth precise professional experience you get with the Virpil pedals. Of course, I expect it to be similar with MFGs or TMs too, and can't compare to those as I've never tried them. But I'm very happy with the Virpil pedals, and can't find anything to improve or complain about. They indeed don't come with a damper, but you can remove the spring without touching any tools, and install any basic hydraulic damper simply by screwing it on. I did that with a damper I bought from Amazon a while ago. No drilling or anything like that needed, it fit nicely to the existing screw holes that you can see in the picture (just had to buy some longer screws and nuts from a local hardware store). Virpil stuff are so popular they rarely have anything directly in stock. When you order something, your order is placed in a queue and get your toys in the order they get them in stock. Sometimes this takes a couple of days, sometimes a few weeks, depending on what you order. You can get an idea of current lead times in their forums (https://forum.virpil.com/index.php?/topic/1946-new-ordering-process-live-community-discussion/), where people post what and when they've ordered something and when their order has been shipped.