Scaley

Check what skill level the AI are set to. My impression (after a LOT of testing) is that when DCS AI are set to the top skill level essentially ALL random miss distances/random imperfect behaviour is removed. In the air to air arena, for example, the top skill level AI jets will react immediately to being shot by a missile, and go to a perfect 90degree notch against the missile, even when said missile is not active and therefore would be impossible for them to detect. Similarly, in the Apache, if you hover in range of an RPG infantry at max skill level he will shoot you immediately, with one round, through the pilot's head. He has near 100% hit rate, regardless of wind. Clearly that shot (at 400m) would be insanely hard with an unguided RPG, even before you start accounting for wind and inbuilt variations in the rocket, launcher and sighting system. Turn the AI down to the lowest skill level and you'll find it much more sensible I suspect. I think people think the top skill level may make the AI "smarter" but it doesn't it just makes them more like terminator...

This is really good advice. Personally I'd suggest learning to fly/hover the Apache without the IHADSS display, and just look out the window. The flight model is certainly work in progress, and will inevitably change as the module develops, but right now it's certainly absolutely good enough to learn to hover and fly well. The flight model changes are likely to be iterative and so there will be a little bit of "update" required with each patch, but it's really not that big a deal each time a patch comes out. If you learn the basics then they will carry over pretty easily.

Yeah, that server/ME bug has affected DCS for years. Anything done server-side by a script may not have all it's properties replicated locally to every client. More specifically, the properties will often only show up to clients who are connected at the time the operation is performed (think scenery removal, spawn units, etc)

This is now the default behaviour in DCS after the latest patch.

I did try adjusting the durations, but it wasn't behaving predictably. If you set the duration to zero (for example) it plays for the same period, but just in tiny looped clips so you get a slight puled nature to the sound. Commenting out worked much better.

So done a bit more testing with this... Commenting out the line suggested by lefunete01 above does indeed get rid of the annoying long SAS saturation tone. Interestingly it replaces it with the (as I understand it) correct "short" tone, but only when the SAS is actually saturated, so it only plays in sync with the EUFD messages. All the erroneous warnings are removed. HOWEVER... if you only do that edit then every time the autopilot modes are switched off (either attitude or altitude) the master caution tone plays on a continuous loop and can't be cancelled. To fix that you need to comment out the master_caution line (see screenshot). Even more interestingly, when you do so the master caution tone still plays when the master caution light comes on, but no longer loops until cancelled. null

Personally, if I were ED right now I'd either remove the SAS saturation tone, or at least tell the user base which of the encrypted sound files it is so we can delete it! I've just flown a fairly uncomplicated gunnery range pattern and had (from counting on my screen recording) an average of one saturation tone every 18 seconds for a solid 5 minutes. It's beyond annoying at this points. I don't understand why the warning tone for a system that isn't finished has been implemented before the logic that correctly drives it. It's a few-lines-of-code job to temporarily remove it until the SAS is sorted out, and then an equally simple edit to put it back.

There is not. The minimum interval is 0.1s.

I think it's fairly clear that the ED devs are unlikely to take feedback on this. There were a number of highly reasoned and well articulated arguments made in the forums as to why it was a really bad idea for threat rings to be auto-populated. Now, instead of listening to the feedback for threat rings to be something you can add only as required, they have essentially implemented the same system for control measures. Even better they have added a threat ring to every generic target the CPG stores... Right now you basically are going to have to BOTH switch off threat rings AND delete everything in the database at the start of each mission. Personally I have a macro written in Voice Attack that scrubs the database completely. It's annoying, but it only take a minute to run and it save a lot of annoyance.

Nice video. The incorrect behaviour in autorotation was reported about a week after the module launched and as far as I know the most up to date reply from ED is "work in progress". Right now all you can do is not autorotate.

As post, it looks like (at least on the Syria map) like the ground clutter is completely absent from the FLIR picture. Screenshots below of exactly the same view. Not very relevant to fast jet, but extremely annoying in the Apache when you changer night vision device and suddenly the entire world changes.

Yeah, this has been true forever in DCS but I've never seen anyone from ED discuss it. Two bits of note: 1) The bottom of the DCS atmosphere is 10m, so surface wind is at that altitude (AMSL). I'm guessing that's the offset you are seeing 2) All AI altitudes set in the mission editor are in vertical straight line distance from this plane, regardless of altimeter setting. Some aircraft avionics also use this magical altitude rather than the altitude set by the pilot.

I think Brad means the real aircraft. DCS hasn't but it looks like it's been updated to match they way it is supposed to work.

Just to add some more data for the devs: In multiple tests I can reliably fix the stuttering by switching the PNVS off for a period of time (sometimes 10 seconds off is enough, sometimes it needs 60secods or more). Any means of not having the PNVS on screen works, including external views, ALT-TAB out of DCS, alternate night vision device (NVG and TADS both work). After doing something not using the PNVS for 60+ seconds, go back and it is smooth again. Also noted - time from mission start to first stutter appears to shorten the more you adjust the FLIR controls.

I think they are an attempt to model this kind of landscape: Stock photo of Mt Tumbledown

To be fair there are a lot of customisation options that would make george as CPG a lot more useful: Sort order (range / threat / axis) Filter (Air defence only / armour only / all) Auto scanning and reporting of targets (within realistic limits not the all-seeing-eye george we have now) Auto return fire / auto engagement (again within limits, likely only with gun - basically the door gunner logic) I suspect one of the issues ED will have is they set some pretty tight internal limits on how the interface was allowed to work, so some of this might get a bit complex given the current way it functions.

No worries. To be fair, it wasn't like this in the first few patches (you could just pull the handle and it worked) but then it got corrected, so a lot of people who had the module from early on got used to the old behaviour.

This now works (at least for me ) on both SP and MP. It has never (as far as I know) been broken in SP. Just to check, you are holding the toe brakes full-down BEFORE applying the handle?

Yep, absolutely possible using a modifier inside DCS, or externally using any number of free external programs to do control re-mapping.

Whether a pedal curve will help will depend on what trim mode you are using for pedals. If you have it set so you trim and re-centre the pedals (as in, with a spring in place) then a curve MAY be useful. If you have it set to that you do not re-centre your physical pedals (aka no spring) then a curve will NOT help since, like Floyd has said, you won't be at the centre position when you are in the hover. Personally I have 90% Y saturation on pedals, and 80% on cyclic. No curves. This in on Virpil pedals with the spring removed, and virpil CM-50 base with the softest springs and a 10cm extension. The biggest tip I have is actually to do with control settings, but more physical control layout. Try, if you possibly can, to put your stick somewhere you can rest your forearm on a surface while flying, so you only move your hand/wrist/fingers. This normally means getting the stick mounted down low not on your desk.

Unfortunately in DCS laser spots appear to be literal point objects, with no physical dimension. If you are precise enough you can range and/or designate a telephone wire. Clearly that isn't like a real laser, but it's what we currently have in DCS. I guess previously with fast-jets it hasn't mattered much, although to some degree it's been annoying in the Ka-50 forever.

Have you tried the trim mode called "Instant Trim (FFB Friendly)". From the name I would guess that's the one designed for FFB joysticks.

ReShade is the workaround. The fact that ALL the ED in-house developed modules have had bugged exports at night for years, and none of the the third party ones do probably answers the first question...

Currently RAD ALT hold works, BARO ALT hold does not.

Not sure that actually works - my DCS is locked at 40FPS using Nvidia control panel, and my monitor is running at 60Hz. I still get stutters in PNVS.