Amarok_73

Very accurate summary, I'd say...

I know, that's why I apologized for this source. I've asked GPT specificaly for RPM, but having in mind his famous confabulation tendency, he could "assume" that I wanted to ask about the maximal speeds.

@NineLine It's still an issue. After unsuccessfull launch (no reaction from the ground crew on my plane on the position), the deflector got up, and never get down, even if I left the server. The track is from the moment after re-entered the server. Sand Devil 67_9(n)-20230606-213635.trk

Like I said, from ChatGPT, did not asked about his source. But i know what You refer to with 192 and can't argue as no any more reliable sources could find.

...at which point the pilot begins to appreciate the creativity of the designers, who foresaw the need for the ejection seat.

There's another important factor - retreating blade stall. The faster the rotor spins, the higher speed he can get without getting into RBS. Of course olny to some extent, as too high speed of rotor advancing blade will cause it to get to transonic speeds, where the blade will start to deform. According to the ChatGPT (sorry, couldn't get more reliable sources), the maximal RPM for copters are: AH-64 - 265 Mi-8/Mi17 - 260-300 Ka-50 - 350. So it seems, that Kamov should be able to go way faster before getting into RBS, especially, taking in account, he's coaxial, meaning that avearaged forces at this state are equalized, so he's still relatively stable.

Track or didn't happened.

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.