Amarok_73

The Cat You're flying with heart not numbers. This is not the flying computer as F/A-18 does. There's constant work on all axles including the throttle, You can't set it to specific position/value and expect the plane will keep the parameters You expected from this setting. And about the HUD symbology, when I started learn this monster, I discovered, that CASE1 is way easier to me to perform with HUD totally disabled, just by reckoning visually the situation outside (yes, same way as the GA pilots do) and AOA indexer. Nowadays, I use HUD, but it's more because I am lazy enough to reach to the HUD brightness rheostat, than I find any indications usefull to me. Of course everything changes in CASE3, but it's different story.

Check the throttles (left side levers with yellow handles) if they're in propper position. They should be at the second from the top for normal operations, or at the top to override the RPM governor, that is there to be used in the case of engine failure.

For that reason I am using the AB cut-off switch.

FLIR and possibility to map knobs to the rheostats is all I need to feel complete with this module.

There's other, way more valid point of view - how much the real thing cost? Something like 28 millions USD, way to much to spare like few hundred thousands more on decent stabilisation system, leaving it in the pilot's hands and legs. Even if this is Boeing, it's still not the 737 MAX As Casmo said in his video, the long stick does the job, however the current model is still too touchy in his opinion.

I couldn't agree more. The Kamov hover hold is the unsurprassed example of how I'd like the hover hold in Apache work like.

It doesn't matter, there's still some inertia on this subsystem, causing dependent systems to follow it, but eventually it fades away when the heli stabilizes on the course. Only thing that makes me wonder is this 180 degree. I couldn't force my heli to oscilate so wildly, no matter how sharp turns I made. EDIT: observe one more thing - when it happens, check if the Doppler sensor located on the tail have line of sight with the ground. You can recognize it by digital speedometer on the HUD, that gets stuck on the speed You've had at the moment the sensor lost the contact.

The yaw stabilisation is INS dependent, so if the INS is not stable, the heli will have tendency to oscilate. Similar behaviour can be observed when enabling the route following mode, while the INS is still not stabilized, so the heli flies in slalom that eventually straightens up.

I agree, that possiblity to change curves, would to some degree improve FFB users life, so I've already posted this issue about year ago, but so far, there's no any response from the ED regarding this issue.

All right, so there's two of us.

Is there option to point me to the unofficial ones, please?

Hello, Is there any way to configure server so either some specific files will be excluded from IC verification or even better, to set server so some customized files will be forced as the version from the server?

Hello Gunslinger52, sorry to say, but I have no experience with any other FFB stick than my own, Logitech G940. Funny thing, I can see, that year ago I've raised this issue, and still the problem with it exists, so the there's no fun with curvatures for FFB users... Anyone from ED could confirm, that this point is on the "to do list" for the Apache?

Roger that.

I think You're talking about harmonization of multiple parameters, as just increasing the rotor damping coefficient didn't gave the wanted effect, while noticeably decreased stability of the heli. Now it's clear to me. Thank You for the information.

Thank You for this clarification. At least now I know, that my way of using the Forces Trim is correct. Apparently it seems, that for some users, the 2.25 % margin is way too small, especially, when the one is using the FFB stick, where usually the center is quite wobbly and loose. For me it's impossible to keep the stick steady within this limit as I am using rather small centering forces in FFB settings (about 15-30 percent) and the Logitech G940 is known of his relatively large area around the point of forces center, where no resistance is noticeable. For sure it's bigger than 2.25% of the axle range. Because all above, and what You've said about the differences and specificity of the controllers, I'd suggest (not to mention really appreciate) to provide the parameter in Special parameters, that will let the user to set the satisfying margin instead of use the hardcoded 2.25%.

I keep AT enabled all the time, but working with the Force Trim Up and when I am below 5 knots, I am releasing it so the FMC should get it stabilized. This was already working like that (correctly as I assume) before the end of the year patch was released.

Nah, even if I am not touching the collective, trying just to position myself to get into hover, the heli is way too twitchy. In general, if I am coming into the hover, as long as controls indicators (those available with Ctrl+Enter) stays within gray area, the heli should be stable and with the AT/AL enabled, the flight computer should dump all inputs and hold the parameters of flight according to the speed that heli has at the moment, the Force Trim Up button/hat was released. And this is not happening since the End of the Year Patch I've mentioned before. I think we all would appreciate if someone from ED would clearly state what is the ultimate behavour model they're trying to achieve, otherwise all this thread is just a guessing game leading us to nowhere. As an example of this empty efforts in guessing whether it is as it should be can be the @Apache 64's post from May 4, when he stated that after last patch the the heli is more predictable with shifted CoG and the @BIGNEWY's answer, that the patch have not brought any changes to the Apache's FM and there were no any information about changes in Release Info. After the last patch I feel opposite, like EDs sits and observe, like we're circling around the subject, with conflicting opinions, because in Release Information there was communicated changes in FM, while in fact there were nothing of any substance provided. Observing how we all loosing in the assumptions, and guessing, I think we would benefit from the honest dialogue with the tester(s) working with Apache's FM, otherwise, with every patch where the changes in FM are announced, in many of us the frustration increases with feelings that the things goes wrong way and in the end, we will be left with the product that offers no fun for many of Apache Lovers, especially the ones, that have in mind how the Kamov behaves, and appreciating the way the FMC works in that module. And yes - I _know_ that the FM between these two have to differ, but still I don't believe the real Apache require from pilots so much attention and focus to tame the heli as the ED's implementation do in current version. This feeling is even amplified with the statements like from Casmo, who in one of his movies confirms, that the DCS' Apache is too sensitive.

Thanks for confirmation it's not only me...

I can't see, or feel any "wonders" after the last patch when it comes to the hover stability. Still it's impossible to me to get in the hands free hover as it was possible before last Christmas patch. I am flying this machine since the release and I have good memory of the changes in Apache's FM, and there was the time it was much better. Perhaps it's the specificity of the FFB hotas? Is there anybody else with FFB that could share his feelings about it? When I enable the AT mode, all maneuvers i do with the Force Trim/Hold Mode Switch - R/Up depressed, releasing it when hover criteria are met, but FMC seems to be unable to keep authority even if the joystick position is within the gray area on the controls display. I am starting to get really frustrated about it seeing as others praise, how the behavior of the helicopter has improved. Here's some clip I've recorded showing how it looks when I am trying to get hands free. By the way, my Special settings are as follows:

Hi @MYSE1234That was the issue. I've no idea why I was pressing the B8 instead of 8. Possibly too long not filed the Viggen. Thank You!

Hello, Is it something wrong with plane, or me that I can't set the BX waypoints? Mode set to ANF, weapons delivery mode to Attack, radar is on, using the BX followed by B8, then T1, slewing the cross to the target location, then TV, but waypoint is still B1 instead of Bx8. AJS and BX waypoints.trk

Why the dot at some (close) distance is not blending into the plane's silouette, but just dissapears causing rather unpleasant transition effect?

Thanks, I've put these files using the structure from package, and effect is still the same. I think we done all we could. I'll open the ticket...