Raptor9

So I am a little baffled at the moment, since there is a good mix of users saying it's an improvement and others saying it's a regression. I would assume that some users are referring to different aspects of the flight model when making generalized statements as such, depending on what aspect they find most troublesome. Personally, I find the flight model to be more accurate on the stability side of things, however the tail rotor VRS is an outlier that has been reported already. There is obviously still a lot of aspects of the flight model and SCAS that are still being worked on, but I find the aircraft much easier to fly with the latest update. For the sake of being specific, I am using no curves and have a 90% Y saturation on my pitch and roll to make up for the fact I don't have a full length cyclic. A few of my keybinds needed to be re-binded after the update, so maybe some user curves/settings also need to be re-tuned? I'm just spit-balling possible solutions here trying to determine why there is a disparity in user feedback.

Feedback has been submitted by the SME team regarding the tail rotor VRS and has been reported. Not going into the details, but in reality the weathervane effects of the AH-64 vertical tail should force the nose into the direction of the relative wind (whether it be high-speed sideways flight or a strong crosswind) long before any VRS effects can manifest in the tail rotor. But as of now, I don't have any other news I can share on this matter.

All good @Akenar-99, that's what these forums are for.

I also had to re-bind my Symbology Select commands after the Open Beta patch. Coincidentally, I also had to re-bind my Pilot and Copilot/Gunner seat switch commands. They weren't removed, but they flagged a conflict for some reason. I re-binded them, restarted DCS, and it worked fine since.

It was intentional. However, not everything makes it into the changelog unfortunately. When you have something as complex as re-factoring of the flight model and such, it can be quite difficult explaining everything that has been done. Maybe a generic "Flight model adjustments/improvements" should have been included, but the individuals responsible for composing and posting these changelogs to the forums are doing so for all DCS modules. This is why all of us use these forums in the first place, so we can ask questions to other community members and some of the staff to seek clarification. This is a separate issue unfortunately. It appears that this is to simulate a "loss of tail rotor effectiveness" (or LTE) effect, specifically as a result of tail rotor vortex ring state. But this is being investigated because it appears to not be working as intended.

@Rongor, I just tested in Open Beta, and I could successfully arm the Chaff while the Master Arm was still Safe. I couldn't arm it while on the ground unless I enabled GND ORIDE, which was correct. And when the Chaff was Armed with GND ORIDE off and airborne, the Chaff automatically went to Safe when touching down to weight-on-wheels, which was also correct.

Those are the navigation direct-to symbols that are placed over the current waypoint. There is clearly something wrong. But before you submit a bug report, ensure you completely remove all mods from your DCS and test again.

Just did some tests in the OpenBeta to confirm that we were seeing the same behavior. In the first image, you can see that with the Yaw axis and pedals centered that there is a little bit of positive pitch in the blades, which would produce thrust toward the right, inducing a left yaw of the nose. On the ground with the collective bottomed out, this would also manifest a slight right lean since the tail rotor is mounted high on the vertical tail, creating a slight rotation around the pivot point at the landing gear tires. In the second image, you can see the pedals are positioned so the right pedal is approximately two inches forward of the left. The tail rotor blades are very close to "flat pitch" where negligible tail rotor thrust would be produced. A good reference point in the Controls Indicator is placing the far left limit of the Yaw channel's SAS white shaded region (yellow arrow) in lined with the vertical red line above it. When in an IGE hover around 5 feet and torque in the mid-70s, I would expect the left pedal to be maybe a half inch to an inch forward of the right pedal (provided there isn't some other extraneous factors affecting this like crosswinds, poor heading control, or other environmental factors). I would be looking for the vertical red line on the Control Indicator to be somewhere along the outside 50% of the right-sided shaded region (indicated by the yellow bracket and yellow line I drew in this picture). So to summarize, this is correct behavior and in-line with how the real aircraft pedals would be positioned. As a side note, whenever the BUCS test is completed during real-life run-ups (it's like the F-16 FLCS test or the F-18 FCS BIT), the BUCS test returns the pedals to centered and even with each other like in the 1st image. Prior to starting the engines, I would always ensure the right pedal was forward of the left pedal as seen in the second image. This would ensure the tail rotor was slicing through the air without making any significant yaw motion as the RPMs increased during run-up.

One further thing I want to be clear on. The author of the article, who I have met, is a good person and a solid professional. My critiques of his review are because I disagree with some of his assessments of the DCS: AH-64D and the context that they were presented, not because I don't respect him or his experience.

Please create separate bug reports for different bugs. It makes it easier for the community managers to track which issues have been reported and such. Thanks.

Your conclusions are based on false assumptions. As I mentioned in another thread, the SME's involved with the DCS: AH-64D have noticed (including me). Further, we've also openly described a lot of these "quirks" on these very same forums ever since release, and have identified them in our own reports to the devs months ago. The BRU was identified for improvement as well (you can even find old posts from myself explaining how it should eventually appear later in development), but it needs to be weighed against other priorities within the project. Coincidentally, yesterday's patch got the BRU reticle closer to how it should be, but the accuracy is still not quite there in how the pattern is projected within the BRU itself. This has been reported internally, but again, it's all about priorities. Can someone use it to boresight their IHADSS? Yes. The appearance of it can be corrected later. The color of the BRU reticle itself isn't necessarily wrong, but it was a game design decision (recommended by the SME team themselves). When the naked eye looks at the BRU reticle, it will appear as it appears in game: yellow-ish in color. When viewed through the lens of the HDU, the BRU reticle will appear pink. The HDU's combiner lens has a color filter on its surface that allows it to reflect certain colors of light (namely the green symbology/FLIR underlay being projected onto it) while allowing the pilot to see through it. This filter is normally not perceived by the pilots as they are using both eyes, but if you are boresighting the IHADSS, the BRU reticle will appear very distinctively pink through the lens. However, since the computer monitor must simulate both eyes within the cockpit, the recommendation was made to not have everything seen by the player appear with the tint color. The same design decision was made when blending both visible lights and FLIR imagery at night, since both eyes are simulated on the computer monitor. So to reiterate, there are a lot of things that the SME team has and continues to comment on, flight model related or otherwise. But just as is the case with other DCS modules, everything cannot be refined or improved at once. Prioritization must be made. But if the assumption is that the members of the SME team are not as knowledgeable or have the same attention to detail as the author of that article, that assumption is wrong. I'm not throwing mud or shade at the author or anyone else; but due to confirmation bias, people will tend to believe the opinions of AH-64 pilots that agree with their own beliefs and observations, and discount any counterpoints to such assessments.

It is not. The Chaff should only be forced to SAFE if weight-on-wheels and GND ORIDE is off. I'll look into it when I get back to my computer this afternoon.

I am not involved with the development of the UH-1, nor do I have any real-world experience with the UH-1. I was only addressing the AH-64 since I can only provide real-world input on that aircraft. If you believe there is an issue with the UH-1, it will need to be placed in the UH-1 bug report section. But again, I cannot comment on that since it is outside my purview.

The AH-64 tail rotor pedals are rigged in such a way that if they are centered, there is anti-torque thrust being produced. The pedals should be placed so that the right pedal is approximately two inches forward of the left, which will place the tail rotor blades at "flat pitch". This will result in a need to apply right pedal to remove tail rotor thrust when no collective is applied producing torque.

Yeah, it's a beast for sure. Nothing can quite compare to a Hind going in fast and hard at 330 kmh with rockets and guns blazing.

Reversing the route simply reverses the auto-sequence order, which is represented in the RTM list. It doesn't change the position of the points themselves. W01 will still be at whatever coordinates it is at. However, the sequence will now go in reverse order when the points are overflown. ie W04, W03, W02, W01

I posted my own personal response to the article. I won't re-hash any of it here, since I don't want to beat a dead horse.

I read this article today as well, and this is my response because I know it will probably snowball: 1) This is one AH-64 pilot's impression of the DCS AH-64D. Multiple real pilots that have just as much experience flying it have (at great length) provided feedback on recommended improvements to the flight model and SCAS characteristics of the DCS AH-64D. Anyone that has been around this forum section for longer than two weeks has seen myself or one of the other SME's openly state that there are inaccuracies with the flight model that are actively being addressed by the dev team. This isn't some big revelation. But hardware does play a big role in simulation, so his own assessment is no less subjective than any other pilot's. 2) From what I gathered reading the article, the author did not seem to understand that the aircraft is in fact representative of a very specific avionics version and era, as stated in the FAQ section on the forums as well as the manual. His statement that the aircraft represents multiple aircraft versions across 15 years is 99.9% false (There is a discrepancy in the shape of the underside of the engine nacelles, but that is a known item). Beyond that, there are no known inaccuracies based on the configuration that is modeled. He does not identify any of these inaccuracies that he is referring to, which makes it impossible to judge what his assessment is based on. Further, he makes references to "equipment timelines" that were misunderstood or unknown. Again, without him identifying what he is referring to, the statement itself is probably not within the proper context. For example, there is no BFT antenna installed because this system is not planned for implementation due to sensitivity reasons. 3) In one instance, he admits that he doesn't know what systems are fully modeled and which ones are actually "inaccurately implemented". As an example, he mentions that the ice detector is cycling to random values, yet the stickied posts in this section list the anti-icing systems as "later in Early Access". But then he subsequently makes a series of very generic assessments on such systems, after admitting he isn't sure which version of the AH-64D is being modeled, although he does say it seems to be based on an older version of the software. Without knowing what version is being modeled (which, again, is listed here and in the manual), how can he assess the accuracy of the avionics? If he is incorrectly assessing that this aircraft is a mash-up of many AH-64D versions (which it is not), than I can see how he may incorrectly see inaccuracies if he is expecting something different than what the DCS: AH-64D is modeled after. Elsewhere, he makes very generic statements about the pages. I get that he may not be going into detail due to sensitivity concerns, which I respect and support. But in doing so, it makes the credence of his assessment on the accuracy of the module in question if it is driven by generic statements and not quantifiable data. And before it happens, I want to stress this does not mean that it is ok to post real-world documentation on here to credit or disprove his assessments, nor mine. The reason I am posting this here is to bring awareness to the fact that his review is based on a broad misunderstanding of what the DCS: AH-64D is, or what it is not. There are additional things that I feel are questionable in the review, but these three items are the big ones. The author is very direct and honest with his review, so I will be equally direct and honest with what I am about to say: I suspect many people reading this post will probably interpret it as an ED team member that is speaking on behalf of Eagle Dynamics and their interests. I can assure you, this is not the case. I joined the ED team this summer because I wanted to contribute to DCS. This drive comes from the perspective of a player and as someone that is passionate about aerospace and bringing such experiences to those that might never have the opportunity to fly themselves. If anyone has read my posts in the past you know that I will be brutally honest about what is accurately modeled versus what needs improvement/refinement (short of restricted documentation/information or what is not appropriate for discussion of course). If I don't know something as fact, I will simply say I don't know or identify my statement as an opinion or as a "reasonable certainty". Overall, I get the impression the author did not not do his homework prior to writing a review, based on his own misunderstandings of the DCS: AH-64D. Therefore a lot of the content within that article should be taken with a grain of salt from the lack of specific context that was not provided.

I agree with Brad. Why wouldn't I simply use the manual stab control that my thumb is already near and have an ability to tune the stab to the precise angle I need? Instead of reaching up to the MPD to go to a specific sub-page to toggle a mode that uses only one stabilator angle. In either case, the stabilator will revert to automatic scheduling when I go above 80 knots, but at least with the manual stabilator control I can time when the stabilator slews down when I go below 80 knots, and how far it goes. Now if you are out of buttons on your HOTAS to map functions to, then maybe the NOE/A mode is your only option to get a different stabilator angle in play. But again, of limited usefulness.

Please avoid posting videos, or links to videos, showing real people being killed. Let's keep the S in DCS based in simulation. The IAT/MTT is being worked on, and will be released when able.

See the previous response to the previous request for such a feature.

I'll echo the confirmations in here that the Black Shark is certainly worth the money. I've been playing it since it came out in 2009 and it is still in my top 3 favorite modules, the AH-64D and F-16C being the other two. I say top 3 not because the Ka-50 is in 3rd place, but because the Ka-50, AH-64 and F-16 are my favorites for different reasons because of their own unique qualities. To me, the Ka-50 and the AH-64 are like two sides of the same coin, with their own unique strengths and weaknesses. What makes the Ka-50 so interesting to me is how the aircraft avionics automate some of the piloting and targeting tasks to compensate for the lack of a second crewmember. It can still be a handful to operate at times, like most attack helicopters; but once you get the flow down and develop the muscle memory for flying, targeting and shooting, the Ka-50 can feel very natural. Even though the module is the oldest in DCS (excluding the Flaming Cliffs line-up from LOMAC), I'm still looking forward to Black Shark 3 and whatever enhancements it will bring to an already fun and polished module. (Full disclosure, I've only joined the ED team in the recent months, so my views on the Black Shark are from using it as a DCS player for well over a decade. Not trying to advertise a product, just being honest)

To clarify, the ABRIS only displays a selected PVI Target point or a PVTz datalink point. There isn't actually any PVI or PVTz points residing in the ABRIS itself, but the ABRIS receives these locations from the PVI/PVTz memory for output on the NAV or ARC pages. So whenever you interact with the PVI-800 or PVTz-800 systems, the ABRIS is just outputting visual feedback like a computer monitor to show you which points you are selecting for Ingress mode, where they located, etc. If you were to turn the ABRIS off (like turning off your computer monitor), you could still select these points using the PVI and PVTz panels (like your keyboard and mouse), have the autopilot fly to these points, or slave the Shkval to them; it would just make it more difficult without the ABRIS to provide the visual display of the selected points in relative location.

No, it shouldn't be rolling. This has already been reported to the dev team.

That is precisely what you should do. If you press the bezel button to the next waypoint, it will then cycle navigation to the next waypoint, but it doesn't remove the previous waypoint from the route if that is what you are expecting. The criteria for automatically cycling to the next waypoint is lacking some of the condition-based logic. It just hasn't been a priority yet given other things that are being rectified/improved.