Scaley

9999 and the BAL limit suggests that the range that's being returned is more than 10km. If you fire a pulse train (with the 1st detent) and are set in "LAST" the system will return the highest range from, any of the pulses fired. Is it possible you are ranging something that's not solid like trees? It does seem a little odd that you get a 9999 range with 1st stage trigger, and then a valid range with 2nd stage.

So far in my multi-crew flights I've had one flight were DIR to points are synced, and about 10 where they are not. Both PLT to CPG and CPG to pilot are affected. In all these flights the CPG has spawned and is in the aircraft before any switches of any kind are touched by either crewmember. No pattern to observe when it's near 100% bug. All these point will have been ones created in the cockpit, not ones entered by the mission editor, which may be why it's not being re-produced by the test team I guess.

The controls one the right side of the TDU will adjust either the TDU screen OR the HDU depending on what sight and/or sensor you have selected. It's explained in the manual and the -10.

Two hold modes (altitude and speed) exist, but neither is yet implemented in DCS.

Absolutely agree with what's been said above. That vehicle is shooting at you with something similar to the chaingun on the Apache, only from a static firing platform. Would you expect to be able to kill another hovering helicopter with the gun at 1500m? People learning to fly attack helicopters need to realise that modern armoured vehicles possess highly sophisticated fire control systems (as or more sophisticated than the TADS you have on the front of your aircraft) and they fire projectiles that travel at up to 2000m/s and are designed to penetrate thick sheets of composite armour. They will make very short work of your helicopter if you present them with a target that is both in range and they can track easily. Hovering or direct nose/tail on flight inside the engagement envelope is a very bad idea. There is a reason the Hellfire was designed with an 8km range...

This topic comes around in other aircraft as well, and it seems is basically caused by the odd fact that the NVGs in VR fill the entire field of view. I have no idea why ED chose to do this, but if they fixed that it would solve similar problems across a lot of airframes, rather than specific fixed per aircraft (like SDU for the Apache)

I think so. The Apache is the first module that's had proper INS drift, and at the moment unless you manually re-cycle the INUs that drift builds up quite fast. It also varies during flight with some periods where the INUs sort themselves out. I'm regularly seeing position errors of up to 30m (which is totally fine, but worse than other DCS modules that have unrealistically good INS). If you combine an 8 digit grid (10m accuracy) with a moving platform that has velocities that might be a few kts out and a position that might be 30m out you'll easily generate some errors of tens of meters, and maybe hundreds on a bad day if everything lines up against you.

I don't know if this applies to you, but ne way for this to happen is if you start DCS with the controller not connected. When that happens the modifier isn't registered, and it seems it's then removed from the lua automatically even if you don't go into the controls editor. When you then re-start DCS your modifier is gone, even with the controller now connected. My solution to this has always been to run the modifiers via a vJoy remap, so DCS sees the (virtual) vJoy button as the modifier, and since it's software it's always connected even when I've unplugged my HOTAS setup.

First detent fires a single ranging set of pulses. 2nd detent is continuous while held down. Thus is practice you could just hold the 2nd detent for a second and then release to get the same effect (at least in DCS) and save a button.

Short answer - no. This bug has affected all ED flagship modules since the Hornet released. It affects both Hornet screens, all Apache screens, and I understand one of the Viper MFDs (although that may be fixed). It's something to do with the way ED render exported displays and despite it being bug reported and acknowledged since 2021 there has never been an update from ED on a projected fix. The Apache is worse than the Hornet (as in, the exported displays are darker). The current best workaround is to use ReShade to MASSIVLY boost the brightness of the DCS rendering on your second display. The Apache is so bad you may need to stack up multiple layers of brightness-boosting! I'm planning on making a video of how to set this up since this topic is coming up multiple times per day in various forums.

\DCS World\Scripts\Aircrafts\_Common\Cockpit\Scripts\TEWS\indicator\RWR_ALR67_init.lua Reduce the settings below to some very low values, mine are: Line 10: shaderLineDefaultThickness = 0.02 Line 11: shaderLineDefaultFuzziness = 0.01 NOTE - the same variable names are at lines 18 and 19, changing these won't do anything. Also, if you do the above change it will make the RWR screen in the cockpit unreadable, so you will only have your exported version.

Is there any way to get this looked at? It's been in "reported earlier" state for a year or more, and affects the Hornet (badly), the Viper (a bit, from my understanding just one screen) and now the Apache as well. None of the 3rd party aircraft do this, only EDs "flagship" modules.

Interestingly this bug, which is marked as reported since Jan 2021, is now present in the Apache as well.

Just switch off pre-flight checks in the preferences panel in helios control centre. The error will stull show, but you will be able to start the profile.

Still present in 2.7.11.22041

The other thing that is probably currently causing issues is the way the SAS sleeves re-centre vs the trim function. If you are not using the "central position" trim function then the trim activates instantly, but you have to hold the trim button to pull the SAS sleeves to the correct position, and that takes time. All the time you have the trim button held down, because it's instantly activated, you effectively have a 200% control gain function, where every stick input move the trim AND the cyclic in the same direction. The simple solution would be the SAS sleeves start re-centering on "button press" but the trim only hits on "button release". If that were combined with the blending function that brings in the trim over an amount of time (like the UH-1 and Ka-50) then I suspect the handling would be as easy as the Huey. Alternatively add two other commands "trim only (no SAS)" and SAS Only (no trim)" so people can create the mapping themselves. In the meantime the amazing "pause on button press" via joystick gremlin applied to the trim button is nearly as good, since while the SAS sleeves are moving your cyclic is fixed, but you retain the quick-press function to get at the trim if you don't need to re-centre the SAS. Looks like this has been fixed in the first patch.

This is a DCS problem where DCS uses up 100% of your Graphics card VRAM and leave nothing for helios. Process Lasso can help by making Helios a high priority process, but the best best fix is to cap your DCS framerate at something slightly lower than the maximum your PC will achieve in DCS, making sure there is always a bit of spare capacity for Helios. There is quite a lot of discussion about this in the Helios 1.6 thread starting here:

I wholeheartedly agree, and this was SOP stuff back in the early 2000s (the last time I got to read a real SOP). A modern MBT fire control system is perfectly capable of achieving over 95% hit rates well out beyond 000m. The kinetic energy contained in the APFSDS rounds in crazy compared to any normal air to air weapons system. I'd suggest the chance of an attack helo surviving being hit anywhere by one is near zero. Muzzle velocities north of 2000m/s certainly help...

You say you installed the profile. Did you also install the interface file DCS.AH-64D.hif.json ?

Helios isn't, unfortunately, 100% plug and play. It does require a tiny bit of setup stuff. If you put Helios DCS setup into youtube you'll get the basic bits. Beyond that for any aircraft you need two things; a profile and an interface (or a profile that uses the basic helios interface). AH-64D interface is in this post, and it goes in \Users\YOUR USER\Documents\Helios\Interfaces\ Most recent version of Bunny's profile is here, and it goes in \Users\YOUR USER\Documents\Helios\Profiles\

It might be worth trying a new profile from scratch and seeing if the interface is available to choose from when creating a profile. I assume you've tried the obvious fixes (re-dpwnlaoding the file fresh, update Helios to latest, check antivirus permissions)

I'd definitely second this. Both axis and button would be useful. The missing toggle for on/off is also especially annoying. I get the impression quite a lot of control binds that are present in the more mature modules are missing (like all the joystick special one for toggle switches) so I think it's a safe bet that these will come eventually.

It would help, but obviously the range of motion would be increased, so you might found the location you have it in currently becomes less suitable, especially if it's on a desk mounted high up.