Scaley

Per the title - at low speeds the IHADDS airspeed changes from showing airspeed to groundspeed. This effect blends in gradually below about 40kts GS. At single digit grounds speed the GS and IAS readout are identical. The flight page airspeed appears to be unaffected and always shows IAS. This bug existed early after release and was previously fixed once.

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 },

Yes, as far as we know there is no detection limit other than line of sight, although I assume each system/aircraft could model that if the coders chose, and some may indeed do that. The laser beam itself in DCS is 15km long, and terminates at the end of that line or on the first object it intersects with. If that point is in mid-air because there is no object/terrain that will still function as a laser designation, and detectors will still pick up the point in space as if there was a designated object there reflecting laser energy. As far as I know nothing else is modelled on a DCS-wide level, although the Apache appears to have a few things other modules don't such as backscatter modelling of some kind.

This has been discussed at some length in several other threads. It seems the consensus is that there should just be an option somewhere (maybe in the settings for the AH-64, maybe in the ME) that stops this auto-population happening. It's especially annoying right now since if you spawn an object dynamically using MOOSE/MIST/etc in a mission the "hidden on MFD" option does not always inherit from the template so even that workaround doesn't work reliably. Also this option then affects every aircraft, so you have to have the same threats loaded into an Apache as you do into an F-16 on the other side of the map. Clearly that's not realistic or useful... Personally I run a script to clear the entire database at the start of every online mission and then add back any points I want, but it's long-winded and annoying.

As far as I can see from testing, this is true of all of DCS' netcode, and the track system. All of DCS uses input syncing, meaning (like Swift says) once you are are out of sync unless there is a method to drive the system back to a fixed status, you will remain out of sync forever. There are a few ways round this, which can include changing to a status based code, or can be using intermittent state-updates (like, say, every 30 seconds) that ensure that if a system de-syncs it it automatically brought back into sync at some point. The only way the current code works is if you have such a good connection that there is never any desync, which is practically not possible with current technology on bigger servers or with significant ping times. I suspect that's why most of the MP sync bugs only start showing up in the public beta on bigger dedicated servers with more complex missions and geographically distant players. If you test on a locally hosted MP session with 2 players you'll probably find most of the code works perfectly much of the time.

Bug still present, and still only appears to be happening on MP servers and after at least an hour of flight time, rendering tracks basically useless. Screenshots below show the TADS being slaved to 2 points that have been entered into the aircraft via the KU. No lase/store was involved, so there can be no error created by poor techniques when storing points. In both cases the TADS is slaving a point that is different to where the point is displayed on the HDU and on the TSD. The horizontal offset in both cases is identical (around 200m), and different target ranges and azimuths create a slightly different angular offset in the TADS. This leads me to believe it's a coordinate error. Given the aircraft clearly know where the point is, and can display (accurately) the difference between where the TADS is pointing and where the target is this also isn't a TLE error. If it were the TADS would point at the location the aircraft thought the target was, but the actual ground object might be some distance away.

At the risk of getting more points for encouraging google searches of "things that shall not be googled" - there are quite a few open source, legal, officially release and vetted, references on how the CMWS works. Any cursory inspection of said sources will tell you the system we have in DCS is (deliberately, I assume) different. Given that we can't use or refer to any references for the system (it's too new to be allowed) then it's probably best to work with, discuss, and develop tactics for the system as it's been implements in the DCS Apache by ED, rather than comparing it to how we think it should work in reality. There have already been a few threads about possible changes to the CMWS (on big one started by me) and the upshot of those is that the ED team are pretty happy with the implementation they have now. I don't think we are likely to see any significant changes, so if the Apache system as we have it in DCS has a delay, then I'd just take it as read that the system has a delay. If that renders it less useful then so be it.

There is an intentional delay coded in the lua files. I don't know the reason ED decided to implement that obviously.

This is a known (although maybe not acknowledged, don't know) bug. The only way I've found to fix it is to edit graphics.lua and change the line lodMult = 1.0; to lodMult = 1.7; or similar increased number. There is one version of this line for each visibility setting, so you have to change the right one for the visibility setting you use (or change all of them). What it seems is happening is that the new Apache LOD maps render at odd distances, so at some distance & zoom combinations on level has stopped rendering, but the next one has not. You can get distances where you can see the aircraft zoomed in, then as you zoom out it disappears, but then you continue to zoom out and it reappears. I thought this would be fixable with the LOD distances in the Apache module itself but I've not been able to make that work.

@Raptor9thanks for acknowledging that this is known. I've added and removed sentences to try to further the discussion but ended up removing them all for obvious reasons. Many thanks again.

Absolutely. It has been being complained about by everyone since it was release, but as far as I know no one from ED has even acknowledged they are aware that the whole playerbase think it's a terrible implementation.