Volk.

@DthFrmAbv Oh it definitely might not work for everyone's rig/curves. But at what range? And looking out the canopy or at the Shkval itself (also x7 or x23 zoom)?

@zerO_crash I must admit I got a bit lost in the beginning of that, and started disagreeing with your earlier paragraphs on FD. But. Totally agree. FD = Holding down the trim button and Trim release does nothing for Alt hold - for that you need collective brake or alt-hold AP channel off-on. I'm also convinced AP channels disengage and let you do your thing if you overpower them with stronger movements, but once your stick/rudder motions settle down to small levels the AP channels will try to 'correct' the erroneous parameters of your new flight regime unless you trim.

Dunno about the version ED modeled, but some of the maybe earlier Black Sharks did load what looks like Vikhrs in 2-shot launchers. Out of interest (for me) Vikhrs are the most useful and critical component of the Shark followed by Cannon rounds. Are you facing infantry and light threats more often that you feel you need to save that weight?

It's either left-Shit + F4 or left-alt + F4 to get a chase view. You can then adjust that view with either left-alt + F4 or left-alt/shift + F2, then pressing it again to keep that adjusted view. Right-control/alt/shift (I forget which and fumble around till it works) + Numpad/ and Right-control/alt/shift (I forget which and fumble around till it works) + Numpad* control the 'zoom' or camera lens.

If you mean the Scan mode where the Shkval moves in a pattern left-right or right-left, then yes. If you tap lock, it'll hook/snap/stop/lock onto targets, or 'objects of note' like fences and bushes it crosses for the next 3 seconds. It's not the most useful mode though - you're hoping it'll cross over something helpful. If you up the scan rate and it goes across a target it may not hook it. You're better served with the helmet sight and locking like that or the slew hat. The helmet I've found to be more reliable in slew-locking targets that the scan mode.

That's one of the things, at faster forward airspeeds, keeping level requires a little (~15-20%?) LEFT cyclic in the sim, not right.

@Bushmanni very interesting. I didn't see that post before, but I think the title buried it amidst a sea of general posts of 'whycome I die at 250kph'. Do you maybe have the title of the first NASA article you linked? The link's dead and the pdf title doesn't make it apparent what to search for. I'm strongly leaning towards it must be a downwash thing. But I'd imagine the downwash from the upper rotor, possibly slanted further back from the high speed would increase the induced flow of that "pushed" air, and that downdraft would essentially reduce angle of attack (relative wind now 'moving down' as it were through the blades) and thus lift. If this were to hit the lower rotor at the back that would mean a reduced lift there... Is what you're suggesting that the air flowing through the centre of the upper rotor, which now hasn't been accelerated by the upper rotor (which would normally be centred on the lower disk at near hover, or otherwise hit nearer to the blade root in forward flight) now hits near the blade tip, causing the lower rotor to get 'fresh' air without induced flow at the back resulting in lift/upflap (which takes effect only on the right 70-90deg later) not compensated for be feathering? But if that were the case they that would generate additional lift on the right, creating dissymetry and requiring right cyclic to retain level forward flight (which at least in the sim it doesn't)...

@Fri13 for you issue 3 possibilities spring to mind. The less likely one is I think sometimes scrolling off into the unknown (beyond 15km) makes it wig out at keep spiking up the range, but I doubt this is it. This can happen with e.g. ranging a helo, which your Shkval then loses track of and starts tracking 'infinity' and slow creeps up range - it's still tracking the inertia of the last time it'd locked the helo, so it's not flying of to the side crazy-like, but the ranging keeps growing. The laser itself only fires when you press lock, or after releasing uncage when moving the HMS at small angles with the laser armed. The Shkval in DCS doesn't contrast lock - so it means it sometimes doesn't acquire stuff in what appears to be clear daylight, but at the same time it's retained lock (not just memory-mode), but a lock on something briefly going through visually cluttering trees or passing by another target where contrast locking should have issues. Not sure if that's an issue with coding time, hard to implement or possibly a big FPS drain for ED to implement. What I have found is that there is an issue whereby if you range (with laser armed: lock or slow helmeting as above) while slewing AND the laser is currently firing (timer has appeared on the side), then it can corrupt the range, typically drastically reducing it - that point 0.2 sounds very much like this. I can't tell you if it's a bug in DCS, or a messed up aspect of the real system, but that's how that works. I've got a vid showing off that issue if this description doesn't make sense. You're most likely to experience it if you're slewing the hat and trying to tap lock on a moving target, slewing and tapping again if you do it too rapidly.

It's definitely not a certain amount of time, unless you consistently used the laser in the same way every single time. Unless it somehow behaves differently in SP than MP. It does worse then longer the laser fires, ranging or vikhrs, but not in an entirely linear way (ie. not just seconds firing). Again locking and brightness/contrast/Shkval settings are unrelated to the laser. But yes, when it fails, ranging seems to work ok, but Vikhrs will barely have enough time. I did some, but not conclusive testing and playing around with this maybe end November. It failed somewhere at roughly after the 24th Vikhr. I've been able to fire almost 60 Vikhrs in some tests using laser-saving techniques, so there is some logic behind it, but not one I feel comfortable explaining yet. I'd imagine if one laser-ranged all the time (possibly using HMS uncaged firing it every time you release uncage maybe?) then it might be less than 24 Vikhrs. I've had at least 3-4 MP sessions somewhere November-ish where laser stops helping Vikhrs on 3rd-ish sortie, and a repair at a FARP did the job (no other damage, no fire extinguisher or hard landing tricks). The non-repair thing is weird though - do post bug+track if that's still an issue. EDIT: Just to clarify: I can't say for certain (yet), but I don't think it's to do with the amount of time the laser is armed/on, but rather linked in some (again non-linear/direct) way to the amount of seconds the laser is firing, which is a user-usage link rather than purely mission timer. I can't speak for ambient temperature in the mission.

@DthFrmAbv I started going down the laser burnout rabbit hole, but I haven't done nearly enough tests yet. So the burnout is a thing, and quite likely not a bug, but just what the laser was (I mean it woulda been easier for ED not to code burnout and save these headaches). What I have experienced as yet is when this happens, the laser fires for 2 seconds (02, 01 like you mentioned), but it still seems to range accurately. And yeah, generally less lasing time = slower time to burnout. However that 2 seconds means unless your Vikhr is like point blank beyond minimum range, which might anyway fail, your laser stops firing after only 2 seconds and the Vikhr loses track, possibly going wild depending where it was in the spiral and how far it's trying to swerve to find the where it thinks the laser went. I know a couple of years back that you needed to do stuff like a hard landing or popping the fire extinguisher to be able to repair, but that a repair always fixes it. About 2 months back doing a repair definately restored my laser a couple of times - so if it isn't maybe record that track and send a bug report. But the presence of the laser doesn't affect your ability to lock stuff. The only way it affects Shkval movement is that it can provide ground tracking/inertial stabilisation to stop drift/move along with a moving target's momentum even if lock is lost. If you say the Shkval moved weirdly, outside of those civvy vehicle incidents that may have happened but may have been my mistakes - the only thing outside of strong manuevers breaking lock I can think of, especially with rapid Shkval movement where you didn't change the tracking modes, is uncaging, which can go the HMS/scan mode/data link target/target point. Especially the latter two might be behind you which would then drop it to the floor maybe.

Just finished work on the first 3 episodes of a new series. Essentially the datalink, but also how to send a target with 2 buttons, how to when receiving a target have your Shkval on that target in 2 buttons and shennanigans like being able to snipe out 3 separate targets in 1 second using stored targets and neat little interactions with the various data-link-esque systems. Enjoy

Do you mean the "Trimmer Mode" settings? If so they're under the main menu's Options > Special Tab > Ka-50 category on left. If there was an autotrimmer setting in the gameplay options I can't help you there.

@Reticuli it's similar, but far better than what you're describing with the Shkval scan mode. That scan mode is clunky, has probably the lowest change of locking and just isn't that useful. But what you experience with that scan mode is that if you click Lock, and it moves over a target in the next 3 seconds, it might stick to it and lock. Your tracking gate (the dashed box middle of the Shkval screen) needs to be just large enough to get the borders of the target or smaller. What I'm recommending, is that you keep your helmet sight near the target. So to guide the helmet you're holding uncage the whole time, which I think you know. I'm saying you keep holding Uncage Shkval the whole time, and move your headtracking/VR onto the target, THEN you tap lock while still holding Uncage. If your helmet sight moves that Shkval across the target during the next 3 seconds (again with the right size tracking gate), then it you'll see it lock. The green circle on the HUD usually following you helmet sight stops moving and tracks the target, as does the Shkval tracking gate. Once you know it's locked you can release uncage, or press lock again and try to move the sight over the target again. If your laser is on when you press lock, you'll naturally get the laser timer which happens to be 3 seconds on the HUD. Keep in mind even this technique isn't perfect, and their are times off angles, fast moving things and background clutter breaks or prevents the lock. That totally makes sense for the Shkval and non-radar tech of that era. Locking onto a Hornet, or any jet, that isn't just traveling straight at you from relatively the same altitude will be difficult, especially if they're still small on your view out the canopy/Shkval, traveling perpendicular at speed and you don't have those labels on like Hobel has in that video. If the target is too far away or too close, or your headtracking/VR is shaky, then this is quite hard to do - you'll have to play around with your setup to see what ranges/distances you need to be looking out the cockpit (possibly the easiest), and when to look at the Shkval zoomed or wide field of view when doing this. That's about as well as I can explain it in words. I've put a video out in October which has exactly this technique in it, both vs. tanks and helos: https://www.youtube.com/watch?v=V5Q8bVwtZx0&feature=youtu.be Maybe check that out if this explanation doesn't work.

@Hobel, yeah that's helmet slew locking. Where with HMS holding uncage you click lock and for the next 3 seconds it attempts to lock something your sight moves over slowly. Just two things to note - I see you flick on the "Weap Arm" switch between the red jettison switches. This is unnecessary - all it does is make if you were to jettison the Vikhrs that they're armed/hot/will explode. It doesn't affect normal launching at a target. I'm assuming the small blue ranging it shows on that dot is from one of those label things from the general menu - but you can comfortably wait until the target is within 9.5km before you start attempting to get a lock - that Shkval has about that range before it starts getting crimped by low light/fog/dust haze. Otherwise totally agree with that technique, including firing off to Vikhrs. @Reticuli just note it is of course harder if the target isn't traveling dead straight at you or if there isn't just clear sky behind them. Also if a jet is actually looking for you, the odds are strong at that altitude that any of their missiles will be more accurate and hit first before your Vikhr - that's just the food chain. Your advantage is being low and hope they circle often, which also makes it tricky to nose-up enough to catch them. If they're unawares, then the playground is yours of course.

If one compares the speed of turns to footage of the real thing, then the turning (yaw & bank) do seem right. Putting off that Heading AP is great for quick yaw turns in hover and setting the new heading without retrimming causing a potential bucking. For the way it flies, outside of the rotor intersection bit which this thread is partly about - not meant to be clickbait, just a discussion on why - and *maybe* why the Shark can occasionally go into a full spin in stronger wind (ie. weather vane into wind, but then keeps spinning instead of streamlining into the wind even if one slowed it from overshooting the oncoming wind direction) I have no issues with the way it flies. The printed takeoff weight limit number precludes doing vertical take-offs with Vikhrs + rocket pods loaded, but I've seen footage of Sharks doing a nose-down vertical take-off, Shkval practically scraping the ground from very little forward speed fully loaded. So yeah, how it flies, appears right to my layman's eye. It's just the forward flight stick position and the location of the smallest rotor separation that I'm curious about. @cw4ogden I'm totally enjoying the back & forth as well. I *think* we're saying the same thing atm in term of how it behaves. Question though - do you think that if one had to trim cyclic forward left for fast forward flight so lift were equal, that the rotor disc would be tilted down at 11 o'clock and then raised up high up back and to the right? Would it be mostly that or more some airflow thing on the lower rotor.

Yeah, that's what I just learned yesterday. Or at least when trimmed for stable level flight. I don't believe that's commonly understood. In my mind the lift produced = torque produced. ie. in a conventional tail-rotor helo more pitch the main rotor pulls with normal RPMs, the more the tail rotor has to follow suit. Same with coax, in that normally the lower rotor is always pitched slightly more than upper rotor. My (rampant) speculation is that maybe in some circumstances the torque isn't always balanced by the system, thus the right bank that needs to be countered. Another possibility maybe transverse flow having the top rotor generate more lift on right than left (cw rotor), that needs left cyclic, but I've also heard transverse flow should disappear at some point in picking up speed, so shouldn't be a factor at 250kph. I'm welcome to correction - I just hope that correction makes sense. I was trying to justify that the disc is in equilibrium because of the feathering from the slightly left cyclic input. That without it the disc might be producing more lift on the left from the top cw rotor producing more lift at that regime despite other measures like flapping. The way I was explained, is that lift is generated immediately, but the affects are only felt 90 degrees late from gyroscopic precession/phase lag. In a coincidental, but not quite related note, the maximum upflap is also 90-ish degrees later from second order system excited by resonance (measure in frequency). ie. if you push forward cyclic, it increases blade pitch on the left side (cww rotor) and decreases it on the right. That left side lift only kicks in 90-ish degrees later at the tail, thus tilting you forward in conjunction with the reduced lift at the fore. Simultaneously that increased lift on the right makes the blade flap up, which culimates 90deg later (again at the rear). It could be less that 90 in a fully articulated system. I know there's also a bunch of math American scientists (and others - couldn't find too many of the Kamov papers with detail) about the ideal separation, and how the airflow develops or funnels beneath the top rotor, so that's probably also a factor in their distance. I was wondering if the Ch-47 would start twisting in RBS...good to know.

Sigh. Turns out this stuff is even more complex actually - by that I mean more correct rotor dynamics and flapping even. Was planning on making a vid anyway on rotor dynamics, first in conventional helos then coax, but now I'm even more convinced that's necessary given my own misunderstandings from the 'usual' source guides. But my (personal) running theory is that the separation possibly is narrower rear/rear-right for coax, because of the forward-left cyclic (not 'flapping from dissymetry'), if any only if the net lift overall is dominant on the advancing side of the top rotor which then needs to be countered in fast forward flight.

That specific bit I don't think is fully correct. The blade is 'pushed up' by the amount of air. If it has full pitch but it's not biting into any air then there's no reason for it to flap up, only settle down. It's because the higher pitch leads to increased lift that it goes up. For an advancing blade that's been trimmed for forward flight, ie. it's flatter pitch, it still wants to flap up even though it has minimal pitch because of that lift. I guess ideally you're of course trimmed so cyclic feathering compensates for any dissymetry in combination of flapping so that the flapping doesn't appear excessive. The first part of that sentence is exactly it. It's springy. The reduced angle of attack - the very thing helping with the dissymetry of lift is the motion of traveling upwards, not the state of being fully up. As it hits the relative wind harder, the advancing side is pushed up, like your arm-out-the-window analogy. It's because the blade's moving upwards that the lift is reduced, not because it happens to be angle up (although I'm sure there's some small effect of that as well). Once that increased lift reduces as it moves past the 3/9 position (whatever is advancing), that upwards movement doesn't immediately stop dead - but it stops adding to that momentum meaning that upwards flapping slows down until it reaches the apex, and then travels back down again. My physics is sucky in terms of telling you that the downwards motion is more from gravity, centrifugal force, springyness/torsion of the flapping hinge/elastomeric bearing etc. But essentially the up-down motion is slowest at the point when the blade's about to flap highest or lowest, and fastets midway around the 3/9 o'clock. Now because of gyroscopic precession or it being a second order system excited at resonance, that max upflap is not at the 3/9 but delayed as that momentum wanes off and the blade flaps up fully or back down - which is typically 90 degrees later, or somewhat less in fully articulate systems. Check out that image again in my 2nd post - you'll find more like it on guides for single rotors. What I can't explain is the upflap on the coax stuff at speed. Before I saw your reply I was literally writing a reply offline saying that might be the case. ie. agreeing that it's not the a torque difference like in EinsteinP's article, but rather specifically the advancing side of the top rotor...but that actually also doesn't make sense - that increased lift from the top rotor's advancing side wouldn't manifest immediately on the left - it would manifest ~90 degrees later only, ie. more at the rear. Unless that 70degree angle mentioned earlier means the top rotor advancing lift kicks in mostly at the back (ie. pitch forward), but that some of it still applies a lift a little on the left as well, which would produce right bank and need left cyclic. I can't comment on the right rudder...it might make sense but usually it's not needed. Then again I don't recall flying the Shark at 250kph with AP channels off, so maybe the Heading Hold channel is able to compensate for that element. I have seen some research papers (in addition to cw4ogden's) since posting suggesting on Kamovs the separation is narrower on the 3-ish position, but they never go into why. Might be induced flow related of the air fed into the lower rotor from the top at the rear left. Or maybe a really hard stall on the 9 position leading to reactive flap up on the right. Dunno.

I've found the ABRIS's wind codings to be doubled in both the 33' and 1600' sections, but fine thereafter. But odds are that's completely separate from the cannon - given you said it's fine at 1600. I can't say I've really tested the cannon in wind - it seemed to hit just fine when I was testing it in Nevada, but maybe that's the 4500k ft. But if I had to guess - and this is a guess - the cannon wouldn't know your current wind. I mean the Shark only appears to correct flight for wind by sensing your heading etc is off and then reacts to that. The only thing I'd guess it has to work off is the Wind setting on the PVI-800 which was hard-coded at startup, and seems to be programmed for whatever your altitude was when your craft spawned. So if you spawned mid-air or on a higher altitude runway of 1600' ASL, that would be it's setting, whereas if you spawned at sea level it would be set closer to the 33' wind, and would have a different blended setting if you were between bands. Again I haven't tested - but maybe these are factors/influences?

Responding to @DthFrmAbv's issue specifically on the Shkval dropping down when attempting to lock - I might have experienced this once before - just trying to lock up civilian cars. Somewhere along the line (usual automatic tracking etc switches) it seemed to 'hop' back to a previous target, rather than lock the new thing. I thought it might have had to do with the civvy vehicles often despawning and respawning, and maybe sharing some kind of behind-the-scenes target ID. That said, I didn't pay enough attention to record that, and I don't know if I had a target point brought up or DL ingress on, though that should only affect uncaging, not locking.

Thanks for the extensive reply Ranma13. I might have to disagree on a few finer points though - hope these make sense: This might just be weird terminology, but no. The shaft, mast head (in fully articulated system) and aircraft is not going to tilt. It begins to tilt as result of the lift generated and the centre of gravity being offset then swings it. The tilting cone is not something the helicopter or your controls did directly either - it's the increased pitch from you wanting to generate lift in a direction that causes the blades to bend or "flap" near the root that makes it look like the rotor system is tilting (again fully articulate system - not talking UH1 here). There is flapping, purely from cyclic feathering as well, even when there's not dissymetry of lift from fast forward airspeed or upward coning from a lot of lift being generated. I don't think the ball-string analogy works - there it angles because you are angling the way it rotates, whereas most helo designs can't willingly angle the mast/hub directly. Dissymetry of lift, or rather the faster incoming airspeed would hit the lower blades the most at the 3 o'clock. That's when, in part to counter this dissymetry, the blades would be flapping up the fastest - ie they're still moving upwards at that time (or somewhere near it). As the blade passes through the 3 o'clock and being perpendicular to the incoming air, it would generate less lift, and the blade's still flapping up, but the speed at which it's doing so is reducing. It then typically reaches the maximum up-flap somewhere to the front of the helo. So the increased lift generated, and the place where you can see it flap up isn't synced with when the lift is the most intense (on the advancing side in fast forward flight), but rather 'delayed' by almost 90 degrees. Same reason that one the ground, moving the cyclic forward makes the disc appear to flap down, as the lower rotor increases pitch on the left to produce more lift at the back, making it appear to flap upwards fully near the back (see #3 below for more). If the being flapped up fully was an instantaneous reaction to the increased pitch/lift, then it would be appearing to rise on the left with forward cyclic on the ground. The ingestion of turbulent air by the lower rotor probably is part of the reason. But to my understanding the amount of flap is determined by the amount of lift generated - in simple terms the dissymetry of lift + cyclic pitch. So reduced lift from turbulent air would mean less lift - and if it did dynamically counter that by pulling more pitch, that would theoretically increase until it achieved enough lift and the flapping would be normal again. The flapping should otherwise only maybe be more pronounced if the blades were slowing down, but given both rotors are interlinked, then the entire system would be slowing down if rotor RPM was an issue. Additionally, this seems to be trying to generate more lift on the rear side, which then culminates in the full flap-up near the right, instead of more lift on the right culminating on the front. If the top rotor's lift is greater, and it's torque more, you'd need to do the opposite. The top rotor moves clockwise, so it's torque alone would result in the fuselage turning left. To counter that you'd need right cyclic. I'm starting to suspect (at least as far as my other physics might be wrong), that it has to be related to the airflow coming off the top rotor and specifically interacting on the lower rotor at the tail end, or close to it, which then causes the extreme flap on the near 3 o'clock. Maybe a condensed flow of air hitting specifically the lower rotor at the back cause the unexpected max upflap? If it were RBS or Advanced tip compressibility, then given the rotor speeds are linked, surely it would affect both rotors equally?

Most likely. And Hopefully. That said it doesn't even appear to be default training / knowledge for operational Ka-32 pilots - just you've got your limitations, don't exceed them. On the Mi-8 - far as I know it's the most produced helo, so would be more than just Russians if it crashed that often. I still have to troll through a lot of lore before I can get to grips with the Ch-47, but I imagine most of it's quirks come from making the rotors dissimular in lift with pitch, maybe some dissymetry of lift coming from the rotors not being right above one another and causing a yawing motion and lastly vortices from the front rotor disturbing the other. I'd imagine a pitch-up brake the wash from the front, which has had time to form vortices rather than just 'turbulent', might mess with the back end and then also cause torque issues.

Hmmm... I'm not aware that it ever flashes off unless you (a) have damage or (b) put on Hover mode when you were low/doppler not warmed up yet. So I don't think there's an indication in the cockpit for what you're describing. What you're describing may well exist. I've run a number of tests on banking/rudder with the various modes, FD, Hold-Trim, not touching trim and just moving stick/pedals and the AP channels off. The first 3 appeared identical in timing - but that's with large 180 to 360 turns. Just from trying out during flying, I must say in terms of response time, it seemed like when I wanted to maneuver, if I wasn't holding trim, then it did move - it didn't feel like I was 'fighting' the autopilot. That said, once I'd settle in on the new course, and reduced my control inputs to tiny amounts waiting for inertia/airflow to settle, then one could feel the AP channels trying to kick in again as it were and point me back at the former heading. I do recall reading somewhere that there are mechanisms whereby either your cyclic/pedals are in control, or the AP channels are (in terms of correction maybe), so maybe there's a small threshold where for really subtle motions the AP channels are still in full effect, and sensing that the heading is now off from your small rudder input they attempt to correct it, whereas with the larger motion they immediately recognise the pilot input and stop interfering... I think you know, but the speed of yaw does increase gradually as it picks up momentum. It's also a bit slower initially if you have a bank in the opposite direction and faster on the onset if you've got bank in the same direction - and a small difference in banking angle can have effect. If you're finding on larger movements that the AP is interfering, or that switching off AP channels doesn't yaw you faster from a hover then something is wrong with your setup - maybe just go into axis tuning for the rudder and see if your inputs go smoothly along the line (assuming you're using a linear line and not a curve / deadzone). The presence of the AP channels should also be fairly subtle - not a drastic 'threshold'. ps. on that gust of wind - I don't think your issue is with that, BUT, if you did trim out a hover facing a certain way, then ruddering over while there's wind will have an effect - you've been trimmed into bank/pitch that fights the wind, but that no longer applies to the new facing, which then also weathervanes the Shark's facing. I think somewhere in another thread or wishlist someone requested that the AP channels or such, either their activation, influence or setting would be indicated on that controls indicator (right-control enter). pps. if you want to yaw over in a hover, it's sometimes easier to disengage heading hold, rudder over to the new facing/target, then press heading hold back on which automatically trims in that new heading - it can be more accurate than Heading Hold, doesn't leave you overshooting and doesn't cause any pitching moment like purely ruddering over and tapping trim would (since that also records the new bank etc induced by the yaw motion which isn't all on flat plane). You could also tap Hover mode off-on, but that has a slight jolt.

That article is quite fascinating - haven't seen that one before. I did stumble across those Langley tests on the flow of coax vs single before. It mentions : "Figure 17 shows the blade separation for the Ka-32 (presumably from flight test). At low advance ratios, the minimum distance occurs around _ = 270 ° (_5), and around _ = 90 ° at higher speeds (_2)." That copy paste fmoves the azimuthal position of rotor blade symbols, but that might indicate the smaller separation is indeed near the right. I don't think it ever goes into why - just that the consensus is it's more efficient at hover and lower/medium speeds. I wasn't clear earlier - but the lift is equal across the disc in normal forward flight regimes (away from Vne), because of the flapping, and that the flapping happens 'naturally' or rather automatically because of the extra lift that would be generated. I did make me wonder though if this separation distance angle is somehow related to at fast speeds - that flow from the top rotor hits the rear of the lower rotor which then takes effect on the right I've seen that second diagram on the Ka-50 as well, just in Russian. Yeah, no explanations given. The 2nd and third images make sense in terms of equal separation (for forward flight or sideslip, not a drastic turn of course). But why it would contract at that position going fast... might be RBS...

@DthFrmAbv outside of extreme bank/pitch throwing out the lock there are two other events I can think that might do that - if you have a Target Point (Nav TGT) lit up on your PVI-800, or Datalink set to DL Ingress lit up, then when Uncaging the Shkval will always default to trying to target that point first... Although you're describing Locking/Designate not Uncage, so not sure what that's about.