Rangoon

Exactly. As I mentioned already in this thread, I only very rarely use the reset trim. That's not the point of the thread. The point is "why does the autopilot behave the way it does AFTER a trim reset, then a trim press and hold" which could also be stated "why does the autopilot behave the way it does FROM A DEFAULT TRIM position" like at the start of a mission, cold start on the ramp, if you don't pre-trim prior to taxi/takeoff. So the question isn't "why do cold-start missions start you with neutral trim" is it? It's about why does the autopilot behave the way it does from this condition. And, as I've come to understand it throughout this thread, it's because there is no such thing to the autopilot as a "reset trim" or a "default trim" such that it isn't always trying to return to the parameters of that condition (which it is). So the thread isn't about trim reset and whether to use it or not. That's relevant as a general discussion, but not exactly here since the topic is about further understanding the system. I'm sorry if the title doesn't make that totally clear, but I think the posts up to this point do. I think it's a very minute but fascinating detail. I certainly do agree the Black Shark is a smooth flyer and as indicated don't have any complaints about the bird, the autopilot system, nor the flying. It's always been about the behavior, which at first I thought was peculiar, but now makes perfect sense. I routinely fly with RCTL-ENT overlay up and constantly reference it. It's very valuable in this case due to the simulation being different from reality. In reality, you never wonder where your controls are, even with a behind-the-panels autopilot influence. But in the sim, where you can't feel the kinesthetic/postural feedback of your body and the airframe, let alone the control positions (without FFB), that overlay is a great tool. Why use the trim reset? First of all, to test this behavior. Also, from time to time, far from every flight, maybe every few flights, I find that it's useful (or simple, easy, maybe even a little lazy). The situations where this is the case, however, are odd and unpredictable. It's a nice option to know is there in this imperfect solution harmonizing simulatED with simulatOR.

I fly professionally in the US, these days most of my time is crop dusting in Robinson R44s and training students. Helicopters in general is one thing. The Black Shark, combat flying, sim flying, and sytems management in complex aircraft are very different from what I deal with IRL, so you're still the expert in this conversation :) Newer R44 Ravens have hydraulics, but the older Astros typically had (still have, in many cases) this electric trim. It has two motors, one for each axis, which always drive to alleviate any pressure and effectively keep the control in place. I sometimes use the hat to anticipate what I'm about to do, or else just to "tell it" what zero force feels like if it doesn't seem to be getting it right for whatever reason. Sure, try this: Flight Director off. Pitch/Heading/Bank channels on (with or without Altitude). No task (nothing on PVI, no waypoint function, no target point function, no airbase function). No route mode (switch to center position). Now if you trim the aircraft, it will put a heading bug on your HUD. Reset the trim and the heading bug goes away. It does on mine. I'm using the most up-to-date version of Black Shark 2, DCS World 1.2.15. Indeed, and so you can understand that in most flying, this jostle is very subtle but it's still a jostle on even such small terms. Of course you can make it a large jostle by flying sloppy or not paying attention to what you're doing (or intentionally applying disagreeable inputs!). I try to fly in harmony with the autopilot, too. And most of the time things are going along pretty well. I just still tend to get to 98% correct inputs and then release the trim and/or engage route mode knowing that autopilot will take care of that last 2% for me. Maybe in time I will get everything spot on (as I have to IRL, since I have no autopilot). It really makes me appreciate what the Ka-50 pilot has in this system. You still have to fly the Black Shark, but when you're task saturated, how brilliant having this system just take care of that busy work of balancing the machine in whatever flight mode you happen to be in. So, good thing for me IRL that I'm not in combat! Crop dusting can be a handful, with many systems at play in addition to flying, but it's not combat. ;) Hear, hear. I'm still savoring the start-up videos little by little (hard to pull myself away from the Ka-50 cockpit these days unless I'm reading the manual (over and over). Okay, I figured as much. It makes sense that this autopilot input is all happening behind the panels. Still, the pilot *is going to know* what the autopilot is doing, I'm certain of this. You can't fly a helicopter and not know someone or something else is influencing your controls, even if the levers aren't physically moving in your hands or underfoot. I just can't fathom a pilot not feeling this in the aircraft's movement of course and precisely in what ways it's not doing what you're inputting however subtle the difference might be. It's a subtle machine, to say the least. That's why I wish I could see what the autopilot is doing (same reason it's so nice to have that control input box RCTL-ENT just for my own inputs). Of course the pilot know his own inputs, yet why is it helpful to have that graphic depiction? Because it's a sim. Maybe someday we will get it officially. as DCS doesn't seem to be going anywhere soon (I hope!).

Essentially I do agree with this. I'm glad he's giving me a hint at least (not to mention engaging in a little self-preservation). But I also worry that he's needlessly broadcasting our position with those flares! Flares are not very camouflaged! And beyond that, I just would really appreciate him letting me in on his little secret. What does he see!?!? But as you said, at least he sees whatever is out there and is letting me know in his own quirky way.

Thanks for taking the time to write all of this out and put these videos togther. Also, by the way, I really like your sim setup! I am using very light rubber bands, and no springs, in both cyclic and pedals. As a result, the controls have very high precision and a very light feel which is akin to the control feel I am used to in real-life flying (light civil helicopters with and without hydraulics). So there is no spring-back action in my HOTAS controls. In order to zero out my cyclic and pedals, I have a button which activates a script and zeros all three axes instantaneously. Releasing trim and neutralizing my controllers happens in well under 0.5 seconds (as quickly as I can move my thumb from the release of one button to pressing another about one inch away - it's very easy). And the issue of this post is not one of smooth or accurate flying while managing the autopilot/trim systems. It's a question about why the same behavior was taking place after a trim reset as predictably happens during any other trim button press. It's a question about the real system and the sim implementation. It's about exactly what happens when you press (and BEFORE YOU RELEASE AGAIN) the trim button. Not what happens AFTER YOU RELEASE the trim button. And I *think* that I have always understood both of those aspects. What I wasn't sure of was specifically what happens when you press the trim button from a default/neutral trim position or after a trim reset. The title of the thread was a bit incomplete, since I wasn't considering initially that the conditions of default/neutral were the same as after a trim reset (I just never thought about that), and I feel that the answer from Yurgon was right on in that the trim can never really, truly be "reset", so the autopilot is always trying to get the helicopter to fly the attitudes implied by and resulting from the cyclic/pedals positions, whether neutral or otherwise. Simply put, in helicopter flying, pitch attitude is airspeed control. Of course collective input also influences pitch such that up collective generally pulls the nose up and down collective drops the nose (both of which affect airspeed as you would expect, just also an accompanying increase/decrease in overall lift). In the Ka-50, as far as I can tell, neutral cyclic is a positive pitch attitude and rearward flight (or deceleration from forward flight). So as long as the pitch channel is turned on (and no task/route is set), the aircraft tries to achieve that pitch attitude. I wrongly assumed that in a neutral/default/reset trim condition the autopilot would stop trying to influence the controls except for dampening of pilot inputs (again assuming no route/task). I guess I'm a little confused now because I think what you're getting at is basically what I described in post #6 of this thread. Are you saying my description in #6 was incorrect? I feel pretty confident that I had it right in that post, but of course I might very well still not understand 100%. I have never doubted the implementation of the system, especially considering the limitations of the simulation and controllers (other than FFB). I have always found ED's solution in this case to be quite elegant and certainly adequate as I sit at my computer desk. :)

That might be, but I never said my cyclic or pedals have springs. Neither my cyclic nor my pedals have springs. And I do understand the value of a force-feedback stick (unfortunately, there isn't a FFB stick/HOTAS now that measures up in every other way BUT the force feedback aspect). I am only very rarely using reset trim in actual flight. I use the condition in this thread as an example to understand better the autopilot authority and behavior, since the behavior from a neutral trim seemed inconsistent until it was explained that "reset trim" is really just "trim to neutral". It's not any different from how the aircraft starts out from a cold start. You have neutral trim. So we *all* start with a "reset trim" condition, really, unless the mission starts you in the air and generally also has a pre-set trim by the mission maker. I don't have trouble flying the Ka-50 smoothly. I'm asking about the behavior of the autopilot's authority from a neutral trim position, and I think it makes sense based on what's been discussed so far. I just wrongly assumed that neutral trim was "no trim". And that the autopilot was not trying to do anything beyond dampening at that point. But it clearly is still at work.

I've heard him call a few things out, true, but it's mostly about actual action events (engagements mostly). I don't recall yet hearing him call out contact reports on enemies merely spotted or suspected. And certainly I haven't heard him call out whatever he's popping flares about in these cases. It's just *flare*.... *flare*...*flare*... for minutes on end. Like he's taunting me. Maybe it's a hazing ritutal for the new flight lead. And right; I'm not expecting the AI to be logical under all conceivable circumstances (when has AI ever been). This one just throws me because he's obvioulsy reacting to something. Though maybe it's like you say about the AI just continuing a routine because of one fleeting glimpse of a ZU-23 barrel poking through a bush as we crested a rise into the next valley.

So I'm in a hover, scanning, scanning, scanning, and I can hear my wingman popping flares (and see it in the mirrors). He's obviously concerned about something (my dog sometimes gets concerned about harmless statues). I feel relatively safe, since nothing is engaging us, and we've been here for a minute or two. I don't want to tell him to scout ahead, I'm not ready to leave my position, and I'm not about to just turn tail and dive out of paranoia even though sometimes I know that's what I should do. Is there some way I can get my wingman to tell me what he's seeing? Even if he just *thinks* there might be something way off in the distance but he can't quite make it out, I'd love to hear about what he's squinting at. Just a bearing, maybe an estimated range, or a clock position, anything. But he just sits there popping flares and I can't find an appropriate radio command. What's a flight lead to do?

I have a question and a wish: Does the autopilot physically move the controllers? Or is this all happening beneath the floorboards? I don't see the controllers move in the sim as a result of autopilot inputs, but then again I'm not staring at them while this is happening. It would be really nice to have a option to view what inputs the autopilot is making; have a black overlay on the red indication box - RCTL ENTER - or something along those lines, as an option. The red diamond and lines could have black lines with a dot at the end showing how the autopilot is modifying the pilots inputs. It might really help new pilots get a handle on the trim and autopilot systems. It also might give an experienced pilot better control prediction when changing parameters. I would expect there is some way for a pilot of the real Ka-50 to feel "tuned in" to the autopilot and know what it's doing. With the electric trim that I'm familiar with, you can feel what it's doing even if it doesn't physically move any controls (again, this is different from the Black Shark's trim system, fundamentally, but similar in that you have two systems acting on the controls).

I think it's now safe to say that we're talking about two different jostles. I believe this is exactly where it comes from... I did a little more testing. I also found mention in the Ka-50 FAQ about how errors accumulate in the autopilot, but I think what I'm experiencing neither results from system errors nor from pilot imprecision. I think it does have everything to do with Yurgon's observation that there is really no actual trim reset as far as the aircraft systems are concerned. To demonstrate: if you reset trim, three autopilot channels engaged (all but altitude hold, though it wouldn't matter really), then accelerate from a hover, holding negative pitch (holding forward cyclic), then press and hold the trim button (without releasing), the aircraft pitches forward. In another example, if you hold forward and left, then press the trim button, the aircraft banks left and pitches forward. So even though trim is reset, it's really just trimmed to a neutral position (which is rearward flight, at least with a standard combat load and the accompanying center of gravity; maybe even at basic empty weight it's the same). Therefore, when you're accelerating with forward pitch, the autopilot is trying to to slow you down because it thinks you want to fly backward (neutral cyclic). So it's putting in its 20%-authority aft cyclic while you're overriding with forward. Then when you hold the trim button down, it stops trying to get you to slow down, and only dampens, so your inputs are no longer impeded and the helicopter pitches further in that direction. Of course this makes sense when I think of trim reset as TRIM TO NEUTRAL CYCLIC POSITION. Maybe none of this is of interest to anyone but me, or it was obvious to everyone but me. But I'm quite sure that answers my question about why it was behaving this way after a trim reset.

Okay, that I understand, sure. You're just updating a trim position to closer to neutral rather than resetting per se. I have about 4000 hours of civil helicopter time, and one of the models I have time in uses an electric trim system to remove pressure from the cyclic and there is a hat which is used to fine tune the exact position. Otherwise motors just continuously work to zero out the forces. There is definitely no "reset" on that, but it's also by nature a different approach to trim than the Black Shark. But there is one other small confusion on *not* having a trim reset in reality. In the sim, not only does it simulate re-centering the cyclic and then trimming to that point, but it also actually removes the heading cue from the HUD (and from the autopilot). So is there no way to do this in the real Ka-50? I mean other than turning off the heading channel and back on again I suppose? But whatever, I'm a bit off track. Here is where I understand the jostle to come from if I'm trimmed, or in route mode, and then I hold the trimmer (to re-establish new trim/autopilot parameters): While flying on route mode, the autopilot is inputting above and beyond what you have input and how you have it trimmed. So when you hold down the trim button, the autopilot ceases to try and make the aircraft do what it thought you wanted it to do and within its 20% control authority. So if you had left cyclic input past the trimmed point, but the autopilot was inputting some right cyclic to keep you flying straight, and then you hold the trim button down suddenly that right autopilot input is released and the aircraft lurches to the left (the jostle). All that should remain is the dampening system for each channel, but no attempt to fly particular angles or a particular trajectory. Sound right so far? Yet when I have no trim (trim is reset), and I am not in route mode (no trajectory set), why the jostle when I hold down trim? Other than dampening, the autopilot should not be trying to do anything for me, right? However, perhaps this comes back to your point that there is really no such thing as a trim reset. So when I think I've reset the trim, and removed the trajectory and 3-dimensional position targets from the autopilot memory, in fact what I've done is RE-TRIMMED to a "neutral" cyclic position. So the autopilot is still doing more than dampening and thus the jostle is expected. Whatever the answer is, I absolutely love that DCS models systems deeply like this. Not just modeling symptoms of surface-level systems, but, within reason, the systems themselves. Also, thanks for linking to the Leading Edge videos in my other thread. I'm just getting back to the Black Shark after about three or four years off from it, and relearning all of this stuff. I think I recall those videos (they seem so familiar as I watch them now). Good stuff. EDIT: also, the jostle I'm talking about is very subtle, but it's there. I'm not talking about some major airframe discombobulation like what happens if you just reset the trim in forward flight without following with immediate and correct inputs which equate to the trim setting you just tossed. I just mean those little sways (a couple degrees of pitch, heading, etc.) you get.

Of this I have no doubt :)

I think I understand the trim/autopilot/dampening system. I have Pitch/Bank/Yaw autopilot channels engaged. I have the trim reset, so no trim is set, no heading bug on the HUD, etc. Yet when I hold the trim button down, the airframe still jostles. Why? Is dampening also cancelled in this case? That's the only explanation I can think of for this behavior, but I thought dampening was not cancelled as long as the button was depressed for that axis. When I have a trim input, I realize there are inputs by the autopilot which are attempting to maintain parameters, plus dampening. So when I hold the trim button (as if to establish a new trim position), I understand that it's no longer trying to maintain or re-establish parameters, suddenly it lets go of the controls, is no longer fighting me, and the airframe jostles. But I thought the system was still dampening while holding the trim, is it not? So when there is no trim, and no parameters the autopilot is trying to hold, and if dampening is in effect before and after depressing the trim button, why this little upset? The manual references that holding the trim button cancels position signals, but doesn't mention dampening. It only mentions dampening to state that it remains in effect while in Flight Director mode. Maybe I was just wrong to assume this about the dampeners. I just don't feel like the aircraft moves while the trim button is depressed the same, loose way that it does without any autopilot channels engaged. Is that all in my head? 6-6 "Trimmer) button – Cancels all force on cyclic with the trimming mechanisms. When released, the autopilot will stabilize current angles of pitch, bank and yaw [T]." 13-3- "Pressing the “ТРИММЕР” (TRIM) button on the cyclic stick cancels the autopilot’s position signals for bank (K), pitch (T) and yaw (H) and releasing it places the angular position of the helicopter in 3D space in memory."

Yurgon, you are right about the Fire Extinguishing System check. I wasn't holding down the button, and indeed now when I do the Fire light illuminates. Thanks! On page 9-15 it says "Slowly move the throttle levers from the IDLE position until the “n ст ПРЕД ЛЕВ ДВИГ” (LEFT ENG PT OVRSPD) and “n ст ПРЕД ПРАВ ДВИГ” (RIGHT ENG PT OVRSPD) lights illuminate. This should occur at rotor RPM around 86%. Simultaneously, a “Раскрутка турбины левого двигателя” (Left engine power turbine over-speed) and “Раскрутка турбины правого двигателя” (Right engine power turbine over-speed) voice message will be heard."

I found "Keyboard.diff.lua" in G:\Users\*\Saved Games\DCS\Config\Input\ka-50\keyboard, and its properties were not Read Only. If that's the correct file, then something else is going on unfortunately. Of course it can be argued that I shouldn't care too much about some of this, but the whole spirit of DCS is the study sim. The high level of systems detail is everpresent throughout the documentation and the aircraft at the very least, and something which clearly ED takes pride in, so when things don't work, especially this many years after release, it's either overburden/complacency on ED's part, unintended consequences from other updates which haven't been noticed, or else my install is uniquely messed up. What's happening with the keybinds seems really fishy.

I realize with something this complex, things are going to inadvertently get derailed during updates, even though the actual Black Shark aircraft simulation is several years old, but I'm wondering if these are bugs or if something has gone wrong with my installation. 1. Cockpit switches are broken, keybinds reset themselves, disappear, etc. For example (and there are several), the back panel lighting switch doesn't work regardless of what you set in the keybindings. No keypress will activate it, only a left mouse click. This is the same for the IFF switch. Cover works fine, but not the switch. Sometimes I can get a function to work by assigning it a non-default keybind, but other times not. 2. Cockpit lighting brightness/PVI panel brightness. The PVI brightness knob doesn't do anything, and the cockpit panel light only affects the PVI panel (not the cockpit lights). 3. Comms seem to break if you interrupt someone (or maybe change channel?). For example, if you speak to the ground crew, and then change the channel (or maybe ask them again...need to retest this as it's happened various times/situations/ATC/ground crew) then you will never hear from them again. I have My intercom on, channel set to ground crew, and I can see them doing things (ground power on/off), but they don't speak to me. I even tried this with the cockpit door open, so that no radio/intercom problems could be interfering. 4. ATC at Mozdok clears me to runway 09 even though the winds are 270ish at 2 m/s (both what ATC said and what PVI says). I realize that is a very light wind, but wonder if Mozdok would put me on 27 evne if the wind was 270 at 10m/s? 5. Hover check is unavailable from ATC after requesting taxi to runway even though the manual references more than once that you request taxi, taxi, then request hover check, hover check, then request takeoff, takeoff. 6. Changing the inverter switch doesn't affect the light (contrary to manual). 7. During hydraulic system test, turning off main hydraulic system power illuminates the back panel lights but no EKRAN message appears (contrary to manual). 8. When checking the fire extinguishing system, lights on the wall panel function, but there is no fire light on the forward panel (that light functions fine in a lamp test) (contrary to manual). 9. When performing a Rotor RPM readjustment check, the RPM changes but the zebra light doesn't flash (contrary to manual). 10. When performing an EEG GG test, the warning lights illuminate, but no voice messages are heard (contrary to manual). So is my DCS install borked? Just some bugs that need to be reported and/or worked out? Or am I doing something wrong here?

I've been wading through the various posts on exporting displays, and recall that I did do some of this with Black Shark 1 long ago, but times are changing so I'm seeking a bit of advice. I'm running DCS (mostly Black Shark 2) on a 2560x1440 display, with TrackIR 5, so I do get good results in terms of seeing the cockpit instruments/screens when I need to, but of course can imagine some improved situational awareness being able to export a few things out for easy glancing. When you set up the new total resolution, for example if you have a primary display and a smaller display to one side or below, you will likely have "dead space" in that resolution area which is not actual screen. Does this dead space create additional frame rate loss because DCS thinks it has to output those pixels even if those pixels are null? Or does it only work at the pixels for what is being physically represented? And similarly, does DCS output to a part of a 2nd display which has nothing sent to it? For example, if my 2nd display is only receiving information to half of its area, does the inactive half still have to be calculated each frame? I am trying to maintain framerates and don't want to use my full 1920x1200 2nd display if it's just going to wreck my framerate in order to get the ABRIS/Shkval up there. So that brings up another question: I see people are having success with Helios and these small USB LCDs (Lilliput). Do these USB displays affect framerate much? I would assume there would not be a real graphics hit since they are processing their own video, is that correct? So that would leave CPU cycles as the variable, but how much of an impact is there? With these USB LCDs, do people recommend the touch-screen versions? Or not? I have an extensive HOTAS setup, so don't *need* touch screen, but maybe it's foolish not to go that route for the best experience. I just have read that it takes some effort getting those displays working properly with Windows, and that the touch-screen aspect is a specific matter beyond just the display function. So that leads to the future which I assume is going to happen, which is app support through tablets and Windows. Obviously there is already some of this with iControl etc., though that doesn't support Black Shark so it's not applicable to me. I assume that the way of the future will be official DCS apps over wi-fi for touch-screen interactivity. But I haven't seen any news from ED about official DCS apps. It just makes so much sense for a study sim like DCS. So what this last point comes down to is, is anyone just waiting for the future and getting by with single display, HOTAS and TrackIR like I am currently? Or is it worth it to invest in these small USB LCDs with/without touchscreen?

Does this work well with Black Shark as well? Does it work well with an iPad Mini? I see comments in the thread about CDU only, but not sure if that is out of necessity due to the level of support or since in this setup the Mini is the "extra" iPad... Thanks!

Thanks for the reply, but my 2nd display is actually configured to be below my primary, which is why my Y has to be 1080 or more. I figured out my problem, though: What I was missing was entering my TOTAL RESOLUTION in the resolution field in the Options screen. 1920x2280.

Does anyone the actual aspect ratios for the Shkval and ABRIS? I would like to avoid any distortion in the display of these screens on my second monitor. Thanks!

Any idea why I'm not getting anything on my second monitor? I have both active in my nVidia control panel (Vista 64), desktop extended. My primary display is 1920x1080 and secondary is 1920x1200, which is physically to my right, but below in my display configuration. I have used Notepad++ to edit one of the default .lua files. Simply: _ = function(p) return p; end; name = _('JK_Custom01'); Description = 'right side 1920x1200 for MFCDs' Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1080; viewDx = 0; viewDy = 0; aspect = 1920/1080; } } LEFT_MFCD = { x = 0; y = 1080; width = 960; height = 1200; } RIGHT_MFCD = { x = 960; y = 1080; width = 960; height = 1200; } UIMainView = Viewports.Center I have Full Screen unchecked. I get nothing at all on the second display. I can see my mouse cursor flowing between the two screens just fine. What am I doing wrong? Thanks! EDIT: I got it working! What I was missing was entering my TOTAL RESOLUTION in the resolution field in the Options screen. 1920x2280.

ryuzu is right at least from my experience as well. The rumbles from ETL and VRS are different occurrences. Transitioning into and out of ETL is the shuddering due to the disc moving into and out of clean air. Once sitting in a zero airspeed OGE hover, outside of ETL, there is another shudder felt with the onset of VRS. It's generally a deeper vibration, but it can really vary from occurrence to occurrence.

Well that's true, we don't have the feeling in the seat of the pants. At the same time, most times it happens for real, it happens so quickly that all the pilot feels is the floor drop out beneath. That's just based on the stories I've heard from actual accounts where the pilot survived the ensuing crash. If you're in a profile where you expect it *could* occur (such as OGE hovers, steep approaches, and downwind approaches), you're much more aware, sensitive to it, and ready to react. If you're in combat, you could well be thinking about other things. In training, we enter it intentionally, slowly, feel every little (then large) vibration and then the rapid increase in descent rate followed by the recovery. But the stories I hear all involve the unexpected entry and it comes as a surprise until the helicopter is either wrecked or saved through luck or altitude, then the pilot goes "oh yeah, I shouldn't have done that." I can imagine in combat, with a heavy aircraft that it could happen more easily due to distraction and the fact that descent rates will build more readily. Although much of the effect of weight is relative since it has more to do with % of max gross weight since higher gross weight requires more power, more pitch in the blades, which leads to more significant vortex rings.

Keep in mind also that recovery from Vortex Ring State, or Settling With Power (term mainly used in the U.S.) generally is getting the disc into clean air, which can be airspeed in any direction - forward, sideward, backward. If your best option is NOT forward, any direction will do. And if you have enough altitude, you can technically lower collective enough that you effectively enter autorotation. This will also solve the problem because vortex rings will not form with air moving *up* through the system. But 99% of the time airspeed any direction is the recovery (and lower collective a bit if altitude permits). I wonder if the Black Shark is more susceptible only in the sense that it's heavier than a typical civilian helicopter. For that reason I can see things happening more quickly if the pilot is distracted.

I disengage it whenever I want to fly for the joy of it. When I want to feel the helicopter like a helicopter rather than a single-pilot rotory-wing combat vessel. It's not wild, just highly sensitive. Like a helicopter. :)

Another thing that really helps hovering in real life is peripheral vision. Inner ear, peripheral vision, and also keeping the eyes focused distant rather than up close (in actuality shifting focus between points). Early in my training I could not get my eyes out to the horizon because I was so fixated on holding a spot. Things got easier when I moved my eyes out front more and let peripheral vision do more of the work. In the sim, peripheral vision can really only be utilized with multiple monitors or, to some extent, FOV increased with a 'fisheye' effect. Not sure if FOV can be adjusted in DCS, so I just wind up TrackIRing all over the place as I slow to zero gs. As for flight path vector (the circle showing the path the helicopter will "fly through"), that was modeled in Longbow 2, IIRC. That was a great tool. Not sure it that's part of the real HUD in the Longbow or Apache, but assume it is.