Raptor9

Strictly speaking as a DCS player because I'm a recent addition to the team and I don't make any such decisions regarding the project, I'm not surprised it is as vague as it is. After watching several forum meltdowns in recent years over feature plans and timelines changing in other modules, I wouldn't want to list every individual MPD page and datalink function either. Because heaven forbid one button on one page isn't added that was projected on the planned feature list. I've read all the arguments and debates many times about promises, early access, etc etc, and I understand that as well. But at some point, the word for word disection of the forums goes a bit too far and is actually counter-productive. It feeds a self-perpetuating thought spiral where a small group of people end up convincing themselves of anything based on a few words they read or didn't read. It can be rather amusing to read for some (like me), but it can also become very counter-productive for others.

This list of Early Access features can be read here:

There is a misunderstanding on the use of these systems and datalink types and how they apply/don't apply to the functions you are describing in the cockpit. This functionality doesn't work how you think it works.

Page 107 and 108 of the manual describe it. But instead of the pilot doing a fuel consumption check over the span of 15, 20 or 30 minutes to calculate average burn rate, the fuel check function does it for you and then let's you know when it's finished. The aux tank doesn't have any effect on the fuel check itself, but since aircrews are normally running periodic fuel checks anyway, it can double as a reminder to turn on the aux tank later after you've burned off some fuel from the main tanks.

The current behavior is correct. Technically, it was common procedure to fill the aft tank and IAFS at the same time, and then when the aft tank was full the flow would be switched to the forward tank while the IAFS was topped off. In fact, it was specifically not done the way you suggest to avoid the risk of complications within the fuel system. But since there is no way to selectively fill individual tanks in DCS, the method of refueling all the tanks in the AH-64D would result in the behavior that you see in game. This would also be how it would manifest if refueling personnel were told to "stop short" from filling up an aircraft to a maximum amount. The AH-64D wasn't originally designed for an internal aux tank. This was a later product offered to fit in existing aircraft with minimal modifications. As such, the options for managing how the fuel was loaded and offloaded were limited.

This was inaccurate behavior, that was corrected in a recent patch. This action shouldn't open the COORD page. I observed this in the track, but I couldn't reproduce this issue. The TADS slaved immediately to a pre-planned waypoint as expected, as well as a new point I created during the mission.

I misunderstood what you were saying because I'm not seeing the behavior you are describing. It sounds like it might be a controller input issue. Bring up the Controls Indicator overlay [default is Right Ctrl + Enter] and see where your input position is. It might be offset for some reason.

This isn't the case in the AH-64D. The pilot compensates for translating tendency by applying left cyclic, which tilts the rotor disc to the left, resulting in a slight left bank.

I think there is a misunderstanding of how gyroscopic precession affects helicopters. If I apply forward/aft cyclic, the input is not applied to the rotor system in the forward/aft portions of the rotor system. If it was, this would indeed cause a rolling motion, rather than a pitching motion. However, rotor systems are intentionally designed so that cyclic inputs are applied to the rotor system 90 degrees prior to the desired effect, negating the effect of gyroscopic precession. You're probably seeing the translating tendency of the AH-64D, which is caused by a combination of the tail rotor thrust and the torque of the counter-clockwise-spinning main rotor. The aircraft wants to slide to the right as it is getting light on the wheels, but there is still some friction from the wheels on the ground that is holding it in place. You can see a visual explanation of this here: https://www.youtube.com/watch?v=Jr_t9JGlPEw

Gyroscopic precession is indeed a thing in rotary-winged helicopters, but this is not the issue.

......What?

At any speed. The DCS AH-64D should not be doing what it is doing when exposed to the conditions described in the 2nd post in this thread.

Any.

This has already been identified to be an inaccurate behavior of the flight model. It has nothing to do with the trim ball position. If you push forward on the cyclic at higher airspeeds, there should not be an aggressive left rolling motion as is currently in the game.

The over-the-top editorializing notwithstanding, your statement below isn't totally accurate: US Apaches operating in the same region as UK Apaches could have also carried FCR's if they chose, however it would have come at a great cost to station time and endurance. The choice to carry a reduced weapon load in theater was a function to increase fuel endurance. Otherwise, Apache crews operating in Iraq wouldn't have been using the same reduced weapons loads. The UK Apaches had different external fuel options available to their fleet, whereas the US Apaches only had the internal auxiliary fuel system (IAFS) to extend their range/endurance. Further, aside from the external fuel options, the stores loadouts of both forces were quite similar, and would be increased or decreased as necessary based on the expected fight they were going to get into; but again that had to be balanced with the required station time for the mission. On another note, UK Apache crews operated in the southwestern regions of Afghanistan, where the elevations were overall rather low (<4,000 feet), despite the high temps in the summer. Had they been operating their AH1s in the North, Eastern or Northeastern regions of the country, where US crews were routinely flying between 8,000 to well over 10,000 feet with a weapons load, I am very confident they would be asking to take their FCRs off as well. I don't care how much power a helicopter engine can produce, nothing is getting around the fact that the air densities at those altitudes reduce the maneuverability of all helicopter types, and flying around with a sensor that was designed to fight armor but weighs several hundred of pounds is at the wrong end of the cost/benefit equation.

There is some condition-based logic that governs whether it can be switched between SAL and RF, but I meant to say that there is no reason why any player should not have it on SAL since there is no other missile type available. It's like if I were to tell the OP they need to switch the missile type to AMRAAM.

That is the only type it should be since that is the only type available.

@Caldera There is some erroneous MSL NOT RDY instances that have been reported.

If you are asking for it's real-life range, that is a sensitive topic that isn't appropriate for discussion. However, if you asking what the maximum range within DCS is, I've been able to strike targets at 9.9 km, the limit of the AH-64D laser. However, you need to launch it LOAL with a HI trajectory for it to have enough kinematic energy to reach that far. And you need to have a very precise aim point in maximum zoom, to ensure you aren't lasing beyond the target itself, something that George isn't 100% perfect with, which is to be expected since he isn't supposed to be a perfect targeting system, just like a human. This is a very poor comparison, and also subject to a lot of player frustrations when the AH-64D initially came out. That's not just me speculating on that, I observed it first hand when playing online with friends. When you are dropping an LGB from a fighter, there are two key differences between this and engaging a target with a Hellfire from a helicopter. First, when dropping from a fighter, you are lasing from a very high angle to the ground, so if the TGP is not directly on the target, the laser will probably still be within a few meters of the target. When you are lasing from a very low altitude, you are firing a laser across the surface at a very shallow angle. If you move the crosshairs ever so slightly up or down, the designation can move several hundred meters. If you or George let the laser drift ever so slightly beyond the top of the tank, you're designating the ground anywhere from a hundred meters to a full kilometer beyond the target (depending on how extreme your lasing angle is at low altitude). Second, the Hellfire is not a 500 pound bomb packed full of explosives, it's a 100 pound anti-tank missile; where most of the mass isn't explosives but rather the rocket motor, guidance unit, and seeker. If you don't actually hit the target with a GBU-12, you're still probably going to blow it up, depending on how hardened/armored it is or how close you hit. If you don't directly hit a target with any anti-tank missile (of any type), it's not going to have any effect.

I've made a point of these two behaviors (exceeding it's authority as well as it's behavior without ALT hold on) as well. It seems to try to maintain the VSI position when ALT hold isn't on.

@skywalker22, the azimuth and elevation settings adjust the total volume of airspace being scanned by the radar as the radar antenna itself is mechanically moved back and forth and up and down in sweeping motions. These settings do not change the output power or the sensitivity of the radar antenna to radar reflections, they only adjust how much physical airspace is being scanned within each scan pattern. The only effect on "detection range" that these settings have is not the range at which the aircraft can be detected, but rather when they are actually seen by the radar. If an aircraft is in a block of airspace that is scanned at the end of the radar search pattern, then yes that fighter won't be seen until later in the scan compared to an aircraft that happened to be in a block of airspace that was scanned at the beginning of the search pattern. But it's not because the aircraft wasn't able to be detected at that range compared to the other aircraft, it's the fact the radar hadn't physically looked at that area yet. If you scan using 1 bar of elevation and +/- 10 degree azimuth, that is a very small chunk of airspace that is rapidly scanned again and again within moments. If you set the radar to 4 bar elevation and a +/-60 degree azimuth scan, it will take longer to scan that much airspace; but these settings do not affect detection range.

I couldn't tell you, I haven't played with it in a long time. My memory on this isn't clear.

You should always start a new bug report thread when posting about another bug. It helps the community managers keep the bug reports organized based on what is already reported, being investigated, etc.

If [A] and [+] are pressed at the same time, it displays the LED test pattern, which allows maintainers to see if the KU scratchpad display is functioning properly. In real life, it should generate an "A" on the display as soon as the key is pressed by itself. But, I guess the follow-on question is, under what circumstances in game are you all encountering this to be an issue? I'm not being pedantic; I'm asking because in my mind I can't see how this impacts gameplay, since I'm never intentionally holding keyboard buttons down during KU data entry. If there is some aspect of gameplay I'm not aware of or haven't encountered that is being affected by this, I'd like to hear it.

I want to add that in testing the various EUFD advisories that are generated by the fuel system, you need to ensure the FUEL page is not displayed. If the FUEL page is displayed, you shouldn't get EUFD advisories like "CTR TANK EMPTY", "EXTERNAL # EMPTY", or "FUEL CHECK COMPLETE" since opening the FUEL page acknowledges these advisories and removes them from the EUFD. It should still show them in on the WCA page of course, but to ensure their EUFD functionality is also working, close the FUEL page before the messages are triggered. Having said that, I did perform the same test without the FUEL page open, and I can confirm this advisory is indeed missing from the EUFD and the WCA page.