Syndrome

Yup, this is another way of stating the restating a nuance about the same thing. There are definite benefits to slowing down the input. There also potential negatives as you gain more precision in your muscle movements with experience. It's a balance of two positives and two negatives. Precision vs responsiveness, and delayed degree of deflection vs twitchiness. Different pilots will have different sweet spots. There is no one-size fits all solution here. It like saying "cake is good" so more cake must be better right? If you want an extreme example of going outside this proverbial sweet spot, go ahead and set your curves to something way too high (like 50-70), overload on "cake" until you can't help but notice that response feels too slow about the center and then you will end up thrashing, drifting, and PIOing. Clearly there can be too much of good thing. The limit for "too much" will vary from person to person, and over time as well. When I started flying the Apache, my sweet spot was 20-25 curvature. After several months of hovering practice, my curvature tolerance is now down to 0-5 with the same 10cm extension. It's funny that you bring up thrashing, because after practicing hovering for a couple weeks, I noticed that the more precise I could get my hover, it became counterintuitively more prone to slight drifting and micro PIOs. That is actually how I realized that the source of the instability was the differential time delay from having too high curves for my newly acquired muscle precision. Around the same time, Casmo had a video that briefly mentioned reducing the curves as you improve, so as an experiment, I lowered the curves, and the thrashing, PIOs, and overcorrection, and drifting all but vanished. Iirc, Casmo didn't really talk about why you would want to reduce curves. I guess it should be intuitively obvious as to why, but had to figure that out on my own and it's why I'm sharing it here because I was kind of surprised how low the curves could be and still notice the negative side effects, and I only have maybe 100 hours on a simulated Apache, and 1500hrs in DCS. Not the best pilot by any stretch, so if I could notice this, then others surely will too.

The x and y refer to the x-y curve plot in DCS, but yeah you can label the variables however you want. In this case, x is the physical input displacement and y is the game's registered output displacement on that same virtual axis, as defined by the curve: x is the independent variable, and y is the dependent variable. This is not the same x-y axis labels on the cyclic axes (pitch and roll). It's true that if you have quick hands you can reduce dx/dt, however dy/dt will still lag behind it by design (unless you remove the curves). So it will always take longer to deflect dy the same amount as it would dx if the curves are flattened. Also, if you have faster nerves, then you'll also notice more time passing per second so while the lag may be shorter, you'll notice it more. And because of the nature of the curves, the smaller the deflection the bigger the % gap between input and output, so hence the longer the relative delay. See the post above this one for more details. You'll get there man. AA refueling for instance

I was actually choosing my words very carefully, hence why I said a "form of lag". You are correct that there is no extra delay in the initiation of a deflection, but there is a time delay to get to the end of a desired deflection short of 100%. This is true no matter how small the deflection, because you are defining a curve where below 100% deflection: dy < dx, and hence dy/dt < dx/dt, and hence dty > dtx for any Δx=Δy. This time differential delay is measurable as t=(Δty-Δtx). Again likely measured in mere milliseconds. Whether you notice a delay or not will come down to how fast your nerve conduction is. It reduces with age (by about 1m/s per decade) so it's possible that many people that play DCS won't notice. However, I'm no spring chicken and I still notice a pretty big delay at a curvature of 10. Now you might say that this matters less for small deflections, but actually the opposite is true. For instance at curve = 10 an input of 1% will result is a 0% output. To reach 1% deflection output, you'll need 2% physical deflection and 3% physical input to reach 2% output. So the smaller the deflection, the longer the relative time delay. 100% to 50% time delay within a deflection of 3% of the center of the stick. 3% is about is about the max you'd want to deflect in a hover correction, so a time delay of even 50% is pretty significant. Eg if it takes you 100ms to deflect the stick to a physical 2% and virtual output of 1%, then you could have deflected it the same amount in approx 50ms by removing curves. That's equivalent to a ~3fps input delay (or "lag" if you will). Keep in mind this example is using a very minor curve of 10. For higher curvatures like say 20, the resulting differential time delay for a 3% deflection will be dramatically longer. I would encourage you to test the different curvatures about the center of the axis in small deflections, and then compare them to the response feel of the default 1:1 or zero curvature. See if you notice the difference in time to get the output to read 3% from zero curves to curvature 10 and curvature 20. The degree of curvature that you don't notice a time delay is probably your sweet spot. Mine is between 0 and 5.

When you flatten the curves you reduce dx/dy but you increase dx/dt. Which is to say that the physical motion to get from 0-10% is larger, and hence it takes longer to get from 0% deflection to 10% deflection. This increased length of time (to get to 10% for example) is a form of input lag, and can be on the order of 100ms. This may seem small, but most people can notice input lag of 16ms (about 1 frametime of lag on a 60hz monitor). If you flatten the curves by lowering the saturation, then the response is as consistent as default. However if you have a non-linear curve then the degree of spring tension won't be related to the virtual deflection when using centering trim. This will confuse muscle memory training, and is likely a major reason why so many people using curves go cattywampus when using or holding trim, since the bird isn't responding how they would expect at a given deflection. You are correct that the large range of input hardware makes it difficult to give advice on which setup is "best". Personally I don't believe there is a best setting. There are simply positive and negatives for any kind of setup. I was pointing out the downsides of curves for more the common spring loaded hotas stick of any length, but there are also upsides to curves for sure. I use them on certain warbirds that are difficult to aim precisely without them, and I suck up the input lag and make do with the trim issues.

Curves can help when you're starting out. They can however exacerbate any input lag you may have. They also create a non linear response to inputs which kinda messes with muscle memory. I have gradually reduced my curves to zero, and now I have far less wobbles, no PIOs, and the axes all move and respond in predictable linear ways.

Still having this issue with MT. Only thing that works is reduce textures to Med on a 4090! Otherwise VRAM overusage tanks performance. Carrier looks kinda bad at med texture, so does cockpit, which kinda makes the SC feel like a downgrade over the regular carrier.

Tipping typically comes from people not managing their pedals properly when pulling collective. The wheels have suspension and as you pull collective it loads the suspension on one side or the other when the ball is not in trim, looks like the chopper is rolling, and will tip from static friction in the wheels. You need to counter this with pedal movements. First to the right in the early part of the collective pull (from Zero), and then move over to the left pedal as the collective nears a hover check. You also need to add a little left stick at the hover check, but then remove it after lifting off, that part may or may not be a bug, the SMEs don't all agree on the physics here. Another fix to illustrate the point is to turn off both the parking brake and the wheel lock, and then instead of loading the suspension and rolling the chopper, the apache will just spin in place. This is actually good training for hover lifts if you use the pedals to keep the unlocked wheels from rolling by countering the torque with tail rotor. Or if you're feeling lazy, you could just yank up the collective, skip the hover check, and wobble a bit at lift off. That works too, but it's uglier and you may get an RPM warning.

It's tough because I really am enjoying the new Apache FM and 1200 ammo, but on the other hand, can't read the MFDs at 1080p without the dot mod. Really looking forward to the internal version of the dot mod, it's gonna thoroughly change WW2 and make it so much more fun and accessible for everyone.

Performance seems a bit juddery with any cities in the near distance. Apache flying over Punta Arenas FPS was tanked down in the 40s? Yikes. Surprising seeing as there isn't much going on in this tiny city in terms of visuals. Just rectangular pastel buildings. Def needs optimizing as the Normandy 2.0 map has way more going on and runs much smoother over London which is gigantic by comparison.

April 2023 same bug still not fixed eh?

No it's mapped to fire the minigun. It initially wasn't mapped to anything. I finally got the left click mouse fire button to work by resetting the mouse control profile to default and mouse button 1 was automatically assigned to the minigun. But all the mouse does now is fire and move the camera around. The minigun is still frozen in place pointing straight out. I tried resetting my track IR profile to default as well but that didn't help either. Its not my hardware I'm pretty sure because I can fire and aim the door miniguns on the Huey without any issues and they use the same (similar?) basic keybinding options to toggle been mouselook and mouse cursor views. I even tried uninstalling and reinstalling the mod, but no luck.

I think I remember seeing those settings under Special options a couple years ago and yeah that worked. There nothing there anymore though. I do remember having to fiddle with it initially to get it to work, but atm there are no work arounds in the axis settings, game settings, misc, etc. Seems to be a defunct module. Hope they are still working on it. One of my favorite choppers and that minigun used to be extremely fun when it worked, even though I had to fly left handed before.

That option isn't working for me. LALT+C only enables mouse look for the camera. The gun is stuck and won't move. The gun won't even use head tracking to aim anymore. I read the minigun update and tried using the mouse wheel 2 clicks followed by 1 click, and that only enables head translation and then mouse look, but the gun stays stuck and motionless the whole time. The only thing I can with the gun is fire it, but not with the left mouse button because that doesn't even work either.

In any case, it looks like the Apache won't be getting the stingers after all, so if the BS3 gets the Igla, it will have a potential advantage against apaches which may need a mistral equipped Gaz escort or be very quick on the draw with guiding hellfires.

Pure speculation here, but my guess would be that when they add features to the Apache (in an update after release) that parallels the features they were going to add in the BS3 update (A2A missiles etc) then we may see info on the BS3 release in order to maintain functional parity between redfor and blufor. Of course I'm probably biased since I'm really looking forward to an Igla equipped black shark.