Jump to content

cow_art

Members
  • Posts

    131
  • Joined

  • Last visited

Everything posted by cow_art

  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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!
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. Interesting, both PCs where I encountered the problem also used the Steam version of DCS. Maybe it's somehow related to that?
  12. 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!
  13. 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.
  14. 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.
  15. Don't worry OP, it's not just you. The flight model is still work-in-progress and there is at least one known issue with the CAS that likely causes the Apache to feel more twitchy than it should.
  16. I've only had a short time to try the update yesterday but my initial impressions were similar. The Apache feels great now while the FTR is being held down. But when the SCAS does its thing (without any hold modes) the helicopter feels kinda unpredictable and wobbly. WIP I guess?
  17. I see! Great, thanks for taking the time to explain it in such detail!
  18. Thanks, all of that is good advice and you are of course right! Just to be sure: I am pretty decent with the FTR depressed. At this point I can pretty much fly the Apache with all the FMC channels turned off (although it's not pretty *lol* ). I'd just like to better understand what quirks are DCSisms which will probably be patched out at some point and what are properties of the actual aircraft that we'll need to get used to
  19. Yes you are 100% correct. That is a solution. It works well but it has some obvious downsides (no stabilisation while FTR is pressed). And there is a lot of semi-official advice going around that only ever mentions clicking the FTR. So what I am trying to find out is basically if press&hold FTR is the only true solution to this problem, or if it is just a workaround we currently need until the SAS logic is more refined (for example waiting 0.1 seconds before the SAS sleeve starts to center would likely fix it)
  20. Thank you for inputs everyone, much apprechiated. @Raptor9I am really sorry if I am being dense here, although the information you have given is very welcome I am not sure I completely understand how the three points you mentioned are related to the problem GremlinIV described. I have made a short video to demonstrate: (sorry for the crappy recording, I am not exactly a professional youtuber ) As I said, I would really appreciate your feedback on this behaviour! Does the real Apache also behave in this way? Does the nose jerk when FTR is pressed while the pedal position is not perfect? If not and this is a problem that will still be addressed, how are the three WIP points you have mentioned related to this problem? (Sorry I am not trying to be annoying, I am just trying to understand). Let me explain: Does not apply (the problem happens exactly when the FTR is pressed) Does not apply (the FMC channels are on) I don't think this is an aircraft stability problem. The problem is that the SAS (green line) is changing when the FTR is pressed. The SAS input goes away for a second and then comes back. That's what's causing the right-left motion of the nose.
  21. Yes I also get that. Heading hold gets turned off when you click the FTR and if your pedal position was not perfect the yaw corrections from the SAS also go away for a moment. It makes the nose jerk to one side (depending on the pedal correction of the SAS). It's quite noticable. No idea if its realistic or not, but it's definitely there (and I also find it annoying)
  22. Well, my joystick is springless and has dry clutches, so it pretty much stays where I put it. So that's a non-issue for me But to answer your question: No, actually I currently use the FTR a lot. Heading hold works well in many situations (namely, when I actually WANT it to hold a heading). In these situations I klick the FTR a lot to update the reference position. But every once in a while heading hold starts to get on my nerves (usually when I am slow and want more fine control). I now have a simple way to temporarily turn it off (I mostly play single player and can just do active pause ON, pedal right, klick FTR, pedal back to original position, active pause OFF, enjoy helicopter without heading hold for a bit). Sure, that works and I am fairly decent at this. But holding the FTR completely disables the SAS including ATT hold. Very often I dont want that and it makes things more complicated than they need to be. I just want heading hold to go away, I don't want to sacrifice all stability assistance.
  23. Disclaimer1: I realize this might not work for all input devices, but it works well for pedals without springs. For anyone who is annoyed with the current, overzealous heading hold of the Apache: I figured out a simple way to temporarily turn it off, without deactivating the yaw SAS channel or editing LUA files: - While on the ground (or in active pause) - Push pedal all the way to the right - Klick the Force Trim Release (FTR) - Bring pedal back to a reasonable position and wait 1-2 seconds for the SAS to settle The heading hold is now off and will remain off as long as you don't touch the FTR again. It will no longer "help" you hold a heading, but the yaw SAS will still provide damping and help countering torque. And, surprisingly, the Apache becomes a lot more intuitive for me. The SAS no longer violently opposes small heading corrections at slow speed. Suddenly the Apache is just a regular old helicopter doing regular helicopter things. As a bonus, this doesn't even break the other hold modes: if you trim the cyclic correctly you can for example still use the ATT position hold submode, but now you can easily do tiny heading corrections without fighting the system. Disclaimer2: I know this is not a realistic way to use the Apache and real pilots will probably facepalm at this suggestion. I am sure, the SAS will get tuned at some point. But for now I really like the Apache's handling a lot better this way. I have a lot more fun flying it and thought I would share.
  24. So much this. It's not that it's hard. Some things are just annoying. For example: 1.) Doing pedal turns when in position hold mode. There are two options: either you just put in pedal in the direction you want to turn. But the heading hold aggressively counteracts your pedal inputs, so you need to put in a LOT of pedal to break free from heading hold. And when the heading hold finally comes off, you rotate far too violently because now the pedal input is too big for a slow,precise turn. or you press and hold FTR during your entire turn. That makes the heading hold go away and you can do more reasonable pedal inputs (although still really tiny ones, because the Apache yaw is insanely twitchy). But holding FTR also completely disables all other hold assists, and now you have to do a completely unassisted hover+turn. Both of these options are extremely suboptimal. Is the Apache really meant to be this way? 2.) Retrim and SAS desaturation The instant the FTR is clicked, the SAS starts to desaturate. As a result, all assists the SAS is giving briefly go away. This often makes the helicopter jerk when the FTR is clicked. For me this is most noticable on the yaw channel: if I try to get into a hover but my pedal position is not 100% correct, the SAS adds some yaw input. I now get in a good and stable position and click the FTR. As a result, the SAS briefly takes out the yaw correction and the helicopter nose jerks to one side. Unless I get the pedal position exactly right, this happens every time I retrim. Yes, not a big deal but I find it extremely annoying. And I wonder if this also happens in the real Apache? Perhaps our gaming controls are too different and the real SAS logic just doesn't work well for them? For DCS why not add a 0.1 second delay before the SAS starts do desaturate, so we can click the FTR without compromising stability? (For reference in case that matters: I use a VKB Gunfighter with 200mm extension, springs removed and dry clutch. And VKB T-Rudders with springs removed and a friction mod. No curves. Apache control special options set accordingly).
×
×
  • Create New...