cow_art

I ordered the VPC Ace Collection pedals + damper kit on January 8,received them yesterday (March 1). The pedals are good, but I am not quite happy with the damper. It's easy to install, fits the pedals well and does what it's supposed to do. But for my taste it sadly has too much stiction (even on the lightest damper setting). Unfortunately it does not work too well for me with helicopters. I found it quite hard to do tiny, precise pedal corrections with the damper But YMMV. The damper does feel good in principle, just not for tiny movements. Everyone who bought the damper primarily for fixed wing will probably be very happy. Edit: Virpil Support told me to use the damper a while longer. They say after running it through a few cycles it will improve. So take please take everything I said above with a grain of salt. I'll try their suggestion and see how it goes. Edit2: I used the damper another 4 hours yesterday and it did indeed get a bit better. Stiction is still noticable but got less. But I discovered something else (that might be clear to everyone who has used this kind of dampers before). But it was new to me and might be interesting for other "damper newbs": a big part of my problem was, that I was using the damper on the minimal setting. The minimal damper setting makes the stiction issue very prominent: Once the pedals are moving, they move very easily. But to overcome the initial resistance of the stiction I need to apply much more force. So once I have applied enough force to overcome the initial resistance, and the pedals are finally moving, I am applying too much force to be precise --> overshoot. I have now selected a much stronger damper setting (about 50%) . Now the force required to overcome the initial stiction is more or less equal to the force that's required to move the pedals. For me that fixes nearly everything. Pedals + Damper work very well now. I might still apply some lubricant and see if it improves the situation further, but all in all I am very happy with the damper now!

The CAS turning off when FTR is depressed may very well be part of the problem. But as far as I understand there is another problem, which comes from the interaction between the CAS logic and the "flight model". (Disclaimer: I am sure we have some SME here who can explain the problem far more accurately than me. But I'll give it a try, based on my limited understanding) AFAIK one job of the CAS is to provide a more immediate response to pilot inputs. In the real Apache there are delays in the control system. The CAS attempts to eliminate these delays by leading the inputs the pilot makes. The problem seems to be, that the delays, which the CAS is trying to eliminate, are currently not simulated in DCS. As a result the CAS in DCS needlessly exaggerates control inputs. Hence the twitchyness and instability.

I use a VKB MCGU, springs removed, dry clutch, 20cm extension. I bought it specifically because I thought it would maybe fix my gripes with how the Apache handles. It doesn't. Don't get me wrong, I agree with you that such a setup helps. Its an awesome stick, it makes every helicopter better (including the Apache). But the issues I have with the Apache's handling (and that others have mentioned in this thread) are not just due to suboptimal input devices, they are caused by the WIP FM/SCAS logic.

Nah its not just the input device. Of course better devices help a bit. But if you can fly the other DCS helos well and expect the same level of finesse and control from the Apache, it really is a frustrating experience at the moment. The flight model / SCAS are just not there yet and it seems these problems have all been reported by SMEs a long time ago. My current resolution is that I am not touching the Apache pilot seat again until Brad says he is perfectly happy with how the FM/SCAS behave.

Interesting, thanks! After I read your post I also tried some things with process lasso. My findings so far: Unfortunately I can't reproduce the exact fix you describe. Changing the I/O Priority has no effect on the used E-cores on my system. But I can use process lasso to just forbid DCS to use any E-Cores (set dcs.exe CPU affinity to P-Cores only). And this has the desired effect for me: DCS assigns all P-Cores to common/rendering and does not assign any IO cores. And then the game runs much better right from the start (without forcing a restart via a settings change). This leads me to think this problem really has to do with DCS using all the E-Cores for I/O. At least on my system (Intel 14900k) that just drives up the CPU load without any benefit for FPS or perceived smoothness.

Thanks for the feedback! That's very valuable information! So far I suspected this could somehow be related to the Steam Version of DCS, but it seems that's not it. Must be something else (because it's obviously not happening for everyone). @BIGNEWY What additional info can we provide to help you track this down? Thanks!

Possibly related?

Well, there is one solution already implemented that makes flying the Apache super easy: jump into the front seat and let the AI helper ("George") be the pilot. Random youtube video for demonstration A lot of the CPG (=front seater) controls can be fit onto a gamepad. For example : You'll still have to do the front seaters job. But that's perfectly doable without a joystick and you'll not have to directly pilot the aircraft. Perhaps this is close to the kind of gameplay you are looking for? And, as mentioned above, it already works today.

Yea I second that. I am also on an i9-14900k and I am very much CPU bound in DCS (my 4090 is only at around 60-70% in VR). I mean: everything runs nicely and all, but your CPU is not bad and I guess the (theoretically!) 12% faster CPU won't make a noticeable difference in practice. So IMHO the upgrade is not worth the price tag until ED optimize their engine.

I think you are mixing up two very different things. MP = Multiplayer means playing with other (human) players over the internet. MT = Multithreading means DCS is using more of your CPU cores to calculate stuff. Modern CPUs usually have a lot of cores and unless you run the MT version of DCS, most of these CPU resources are unused. In theory using MT should thus give better game performance (more FPS, smoother gameplay) and it allows you to use some cool new graphics features such as DLSS and DLAA. In practice, the DCS MT implementation still has some problems. The thing we are talking about in this thread is one such problem.

TLDR: After launching DCS MT (in VR) my CPU load is high in the menus and in the game. Any graphics settings change that triggers an enforced DCS restart fixes this. I usually just toggle the full screen checkbox on or off (it does not matter in which direction - the only thing that matters is that it is a change that makes DCS restart) The same observation has already been documented here by @durp but the reporter there could not find anything different in their logs. I can find something different in my logs, so here it goes: First Run (bad) I start DCS MT via Steam. DCS loads into the main menu and then I load an Mi8 InstantAction mission and fly around a bit. My CPU load is ridiculously high: The DCS log shows this during startup: I go back to the main menu. I go into graphics settings. I toggle the Fullscreen checkbox (as mentioned above, it does not matter what setting I toggle and which value it is set to. The only thing that matters is that it triggers a DCS restart). Second Run (after restart, good) DCS restarts. I load the same mission again and again fly around for a bit. My CPU load is significantly lower now: The DCS log now looks like this: See the difference? After the restart DCS assigns no IO cores. During the first start it assigned ALL my E-Cores as IO cores. I'm not sure if this is the root of the problem, but I can consistently reproduce that behaviour. My current workaround is this: Every time I start DCS I go into settings and toggle the full-screen checkbox. Afterwards my game runs much smoother. Details about my system: Intel i9-14900K NVIDIA 4090 Windows 11 (fresh install, about a week old) DCS (Steam Version, fresh install, no mods but I installed the mt.lua from https://forum.dcs.world/topic/337829-intel-hybrid-cpu-getting-stutter-please-try-this-in-multithreading-dcs/ ) Varjo Aero (varjo-foveated installed) DCS Logs attached. If I can provide any additional information or run some tests, feel free to ask! badrun_dcs.log goodrun_dcs.log

Interesting, both PCs where I encountered the problem also used the Steam version of DCS. Maybe it's somehow related to that?

I have observed the same behavior as @durp on two separate PCs now. One of them a completely new machine with fresh installs of Windows 11 and DCS: Sometimes after DCS starts, the CPU frame time is very bad for no apparent reason. In such cases, switching a setting that causes a DCS restart usually fixes the problem. @BIGNEWY perhaps that is useful information that you could pass on to your devs? Thanks!

Yea, 1000 thanks to mbucchia for implementing this! The ability to keep the focus area at 100% resolution and reduce the render quality of the periphery is a great way to squeeze some FPS out of older systems.

I very recently switched from an Index to a Varjo Aero. It is a massive step up. The screen-door effect is completely gone and the clarity is just amazing. I can't say anything about the performance with a 3090. But for what it's worth: as my new PC is still not here, I hooked the Aero up to my old PC (i7 6700k @4.2 Ghz, NVIDIA 2070 Super, 16GB RAM) and got DCS to run somewhat decently in Single Player, even on this ancient hardware (VR Preset with a few settings lowerd and DLAA added). Foveated Rendering makes it possible to have a pretty playable experience on older hardware (https://github.com/mbucchia/Varjo-Foveated ). My old PC is currently mostly CPU bound when I am using the Aero, so I guess if you have a decent CPU and are willing to turn down some graphics options a little, you'll be just fine. If I was you I'd definitely get one, that increase in visual quality compared to the Index is insane. I am sure you will love it.