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.

Having the same issue with a 9600k. Only 6 cores, but often all 6 can be easily maxed out at 100% causing huge stutters and FPS to drop to 30, even with nothing happening except a couple AI planes taking off in the distance. I typically get 120 FPS or more with my 3080 with the settings all turned up. But the game will turn into a slide show on simple free flight instant missions. And no matter what I'm doing or even if the settings are on LOW, I still have 99% GPU utilization which can also cause stutters when anything new pops on screen. In a way, my 3080 actually is performing worse than my 2070, which means this seems to be a scaling issue. It's almost like DCS sees your hardware and just uses EVERYTHING no matter what else is happening. So there is no point upgrading your hardware. In fact, you might be better off sticking with lower end specs in many cases.

Well said. Would be nice if they had more "over g" modeling in terms of things like pilot fatigue and maybe even flight envelope changes from the chassis strain, or control surface malfunctions. I hear the F-14 can get damage to flaps when used in those situations to reduce turn radius, and more famously, the wings will just snap off if the over g is rapid enough.

This pretty much sums it up. Unless you're just doing BVR, in the current state, I would not recommend it just yet since you'll be dogfighting everything else with a disadvantage (unless they're also in a Viper), but luckily thanks to the new 14 day trial, anyone is free to try it out and see for themselves. Maybe the beauty, speed, and bubble canopy will overcome the BFM performance issues for you? BVR is great. Anything else, not so much. Honestly though if you're looking for a great performer that can do everything a Viper should be able to do (and more), hornet is much more solid buy atm. Or maybe a Jeff if you don't use the gun.

Yeah, it was pretty disappointing. I check it every few months, but stopped flying it for these reasons. It's been so long, I forgot how to do even simple stuff in the cockpit.

That's interesting. I kinda experienced it as the opposite from a perspective of freedom of motion and agility. The blackshark flight assists makes it more stable without inputs, but harder to control since you can find yourself fighting against the flight assist until you learn when to shut off certain functions during maneuvers. By comparison, the trim options in the Hind are way more intuitive and make it much smoother and more agile, except in a P/W ratio sense, here the blackshark wins. The Hind almost handles like a WW2 fighter bomber, except in a hover, where it handles more like a cross between a bit of twitchiness of a gazelle and a bit of the translational drift of the huey.

It's an interesting question. Probably depends on what you're trying to train. The Mi-8 probably trains best for dealing with VRS, which the Hind is very susceptible. The Huey trains against hover drift and PIOs, important general chopper skills. The Blackshark trains for CAS tactics. And even the much maligned Gaz trains on how to deal with twitchiness and over correction, which the Hind kinda has a bit when in a hover. I have to agree with the assessments above though, if you've flown the other DCS choppers, then the Hind FM is very well done, intuitive, and enjoyable. Definitely my new favorite.

Yeah I've noticed the lag, which is why I put it into CAT III as a stop gap fix until the FCS / FM are patched to remove the input lag and apparent center deadzone, or at least given an option under SPECIAL settings to remove the curve/deadzone for people not using Force Sensing Sticks. I have also noticed the dim director lights can be invisible, especially the ones at the ends, definitely makes it harder than it needs to be, and it's good to know I haven't been breaking the fuel boom. Mudspike's manual recommends using SILENT mode during AAR, but that seems like it would limit SA without Link 16 enabled. Radio comms & RWR might cover than under most normal situations, and it's not like I should be looking down at an MFD anyways.

1. I'm guessing the 120 deg solid angle AN/APG-68 slews with the horizon to correct for attitude, otherwise regaining lock after dodging initial missile volleys would be much harder than it needed to be. 2. Make sure you're in the localizer and glideslope antennae beam patterns for the ILS signal. You can see the beam pattern in mission editor for the Caucasus map heading off to the west from Kutasi. Make sure you're not too high up, or too far away. If you are, use the TACAN to get you in range of the ILS. 3. Yes... well, sort of, by firing them. Otherwise, no.

Reading this made me feel a little better about AAR woes for the F-16 in DCS. It also made me realize that I've been irradiating the poor KC-135 crew. When they have babies with 3 eyes, they know who to thank I guess. It looks like you can safely radar lock them to find the relative air speed up to a half a mile, but the radar needs to be shut off inside that radius. The other thing I saw was the there is a "disconnect button on the stick" that you're supposed to hit when your tank is topped off. I looked it up and the "disconnect" is the NWS button, which makes sense as they both show up on the same NWS light. I've just been ripping off the tip of the nozzle each time I guess? Also... and this is interesting, the "flight controls dampen when in refueling mode". I haven't noticed a "refueling mode", but I have been putting the Viper into CAT III when refueling and it helps. Original Article Link: https://www.sandboxx.us/blog/fighter...ial-refueling/

Ahh, I see. When you suggested to desaturate the "X axis" I had assumed you meant the "Roll axis" of the stick, since otherwise it would mean that you were putting a big deadzone at the end the stick travel. The thing is that the unmodified "curves" of the F-16 already act like an inverse sine function (eg a positive 10 to 15 curve in DCS). So adding a negative curve flattens out the native curve for spring stick users (eg non force sensing sticks). A negative 10 curve btw gives about the same center correction as a 75% desaturated X axis, with the added bonus of not creating a big dead zone at the end of the stick so you have better control at the end of the travel for things like rate fighting.