Scaley

There is another similar thread here, and as I posted there I suspect (hope) this is intentional on the part of ED. The hornet exports are affected by the brightness, and it basically makes the exports impossible to use at night since once you turn the brightness down they are unreadable. You end up having to choose between incredibly bright in the cockpit (which blows out your NVGs) or unreadably dim on the exports. If ED fix the export rendering so it has the same day/night ambient light effects as the main displays then they can make the brightness work on the exports. Right now if they do that no one will be able to read the exports at night.

I suspect this is intentional, since the way DCS renders the exports is different to the displays in the main window. IN the main window there is some attempt at simulating the effects of ambient light, so the displays look much brighter in the dark. The exported displays do not have this effect. If the brightness knob affected both then when you turned down the brightness at night the exports would be way too dim.

I probably didn't explain myself well. I know you can't pick where you load points in the Apache, so I was wondering if the tool could have as setting to let you see where they are going if you know the starting point, or even just a function to start from 01 or 51 and show which point is going to go where. As a simple example, if you use the tool to clear the entire database then the first CM is 51. It would be great if the tool could label each CM sequentially starting at 51. Even better would be to be able to tell it "I'm starting from 55 because 51-54 are already used" and the tool then shows you each CM it is going to add from 55 onwards. Basically it would just be an incrementing field next to each point type (WPT/HAZ, CM, TGT) that uses the same logic as the aircraft. It would be the tool "assuming" where the points would go, based on what you tell it, understanding that the tool can't force the points into the respective numbered slots. I hope that makes better sense.

I doubt we will get anywhere with this while the DTC is being worked on. In the meantime I'd seriously recommend everyone just install @FalcoGer excellent coordinate convertor tool and use to it scrub the Apache database on mission load.

Just found this and it's a really great tool! One thing that would be a nice-to-have for the Apache would be the ability to set the waypoint/CM/TGT number for the first entry, and then have the app auto-number from then on. That way you could see ahead of time which entries from the app were going into which line of the aircraft database.

Indeed, but no one designs attack helicopter countermeasures systems to defeat AIMs in preference to MANPADS. The public sources that are available suggest these systems are in reality used in AUTO mode, and are effective against MANPADS. Whether or not they work against AIMs is speculation since there are no recorded modern jet Vs helicopter engagements.

This has been previously reported. Per many sources (and logic) if you pull one throttle to idle the torque on the remaining engine should double. Do this in the DCS Apache and the torque goes to double plus about 20%. That's why you can't match the SE performance number in the manual or the PERF page.

@NineLine It's been a few years since this topic was visited. I was wondering if it would be ok to bring back to the devs the possibility of changing a couple of digits of code (I know where one is, but the other is in complied code) to allow us to use the Apache automated flare dispensers effectively. As predicted in the original post, everyone I fly with online keeps the system in manual for exactly the reason predicted - there is no combination of settings that are effective and not wasteful of flares. It's literally a 10 second fix to change this to make the Apache CMWS system have an effective and useful AUTO mode.

Sometimes if you haven't re-centred the SAS sleeves (by holding down the FTR) you can have the yaw channel (or another, but easier with yaw) sitting right on the edge of the breakout value, so a tiny pedal movement puts you into the heading hold range, and a tiny movement takes you out. It seems to me like the aircraft can oscillate in and out of those modes. I'll try to make a video of what I mean, but if you fly in trim correctly you wont see the behaviour too often, and it's quite hard to deliberately replicate.

There is, but like most taxi/landing lights in DCS it's massively under-powered so in general you are probably better off taxiing on PNVS/NVGs.

No idea, other than that if you observe the behaviour there appears that the amount of brightness change in the FLIR image when you look up and down varies based on which map you are on, even with identical weather set. Why that would be the case I have no idea.

The DCS Apache seems to have a maximum speed it can maintain with the combination of ALT and ATT hold. Even if perfectly in trim in level flight at moderate power settings, if you set an attitude that corresponds to much above 110kts the two systems will enter a little positive feedback loop that lead to gradual collective increases, followed by gradual application of forward cyclic to maintain attitude, the combination of which leads to increased airspeed, thus requiring increased collective to maintain level flight above MaxE. This cycle then repeats and eventually as you say the aircraft will enter a dive and start descending. I have no idea if the real aircraft does this, but the ED one has for at least the last 4 patches. The solution is to slow down a bit (generally below 110). I'd guess the hold mode logic will improve as the module evolves.

It's clearly still WIP, and in the last few patches it appears they may have been some slight alteration. It's also variable by which map you use quite how bad this effect is. What I'm not sure I understand if why ED have implemented a WIP feature that mostly makes the system worse, when it was working fine at release. The code for FLIR with no ACM clearly exists (in the initially released module) so all we need is a single switch to work (or even a lua line to edit) and it should be easy to get it back in the current working OB. That would give ED as long as they wanted to work on it.

You can also try this which helps some people:

If you add the code below to skynet-iads-compiled.lua after line 443 at the end of the list of EWRs) you'll be able to use the generic radar towers. You can tweak teh HARM detection chance, but I've set it low on the basis that these aren't supposed to simulate military rara installations. ['EWR Generic radar tower'] = { ['type'] = 'ewr', ['searchRadar'] = { ['EWR Generic radar tower'] = { ['name'] = { ['NATO'] = '', }, }, }, ['harm_detection_chance'] = 10 },