RealDCSpilot

I only would upgrade to 64GB RAM. After that you will probably fine for a long time when all those features are fully implemented: Vulkan, DLSS, Multi-Threading.

Hehe yes. I'm currently using Mi-24 hit and run tactics. Fly towards the target, check range finder for 4300 meters, fire HOT3 and keeping the target in the sights until the torpedo crawls into it's target. Then break away...

Not on Win11 and a Intel CPU with P and E-cores. Learned it the hard way. Win11 seems to have the much better CPU scheduling ability.

That was all wrong in the first place. The whole FM wasn't even helicopter-like. Be patient, wait for the fix.

With FFB stick for trimming and DCS helicopters, don't use curves on stick axis. Keep them 100% linear. The current bug on the Gazelle is something different, it kinda multiplies the axis offset everytime.

That's good to hear. I also had the CTD occasionally on hitting Shilkas. It's hard to reproduce, but will happen eventually during a longer session.

Hi, i need to change the laser code with bindable buttons. Thanks!

I hope this is the right image and makes it more obvious: .50 vs 20mm

I remember this being fixed a while ago, but with the release of the new helicopter flight model, it came back.

Maybe the best IRL demonstration, but only one guy in the cockpit and of course - no weapons loadout. Can't tell how much fuel... it's hard to see. Use the mouse to look around, it's a 360° video. You can clearly see the moment where he tries to find the trim position for lift off (left and aft) and does force trim to center the cyclic to that position. Also very good to see is pedal input and cyclic movements needed to have stable behaviour while hovering and maneuvering near the ground.

@Bio Okay, VRAM allocation shows full usage all the time. It's already maxed out, but this is showing allocation only. There is an option in Afterburner to set VRAM usage per process to see the real values like in this older post of mine: It basically shows that the F10 map needed almost an extra of 1GB VRAM to be rendered. I guess what's happening on your end is Windows going into memory sharing mode and never gets out again. It means that ressources are constantly swapped from RAM into VRAM and back at a certain point, when the limit is reached. This stresses the system on CPU and all data paths (BUS) very much. To get a bit deeper you should try to test a simple empty mission, like those hot start instant missions to see if you can start at a point where VRAM isn't used to the max. And also use the Afterburner option for VRAM usage per process. @Whiskey11 Yeah, that's strange with your GPU... But first, you should take TacView out of the equation. Just to clarify, i don't have that problem at all.

@shagrat If you mean Steam VR Home, you can disable it in SteamVR settings. From there you only get the simple 360° environment which is no ressource hog at all.

@mbucchia Hmm, well, if the Pico forum is the source it could also be a translation misunderstanding. For their Android SDK's they also had OpenXR API versions for Unity and Unreal devkits, but removed them recently. They were never been updated since September last year and only the native Android OpenXR API devkit remains. However, what VR runtime a user is running is not of ED's concern, they only have to provide VR API support.

What exactly did they say? Source?

Maybe it's the old VRAM overflow issue. People with more than 8GB won't be able to replicate this. You guys could monitor your VRAM usage and check what is going on when your are switching between cockpit and F10 map.

@BIGNEWY Oh my god. Please delete this poll. It's technically impossible. OpenXR is no runtime, it's only an API. A runtime is needed to access an API. This will only cause confused users getting even more confused. For a VR API you always need a VR runtime. There are three main runtimes: SteamVR / WMR / OculusVR and 4 VR API: OpenXR, OpenVR, LibOVR and WMR (same name as the runtime) - but only OpenXR is supported by every runtime. So technically, there is only one logical choice anyway for DCS's dev team and the future of VR in DCS, go OpenXR! Save time and ressources with taking support of the older APIs out (OpenVR and LibOVR). DCS or any other PCVR game provide support for APIs only anyway, right now these are: OpenVR (SteamVR's own VR API), OpenXR (new standard API for everything VR/XR) and LibOVR (the older Oculus/Facebook VR API for PC/Windows and for their older wired PCVR headsets). The question which runtime to choose is completely on the user side, dependend on your VR HMD and which runtime it supports. There is no choice for OpenXR alone! You always need a runtime besides that. @shagrat SteamVR is no middleman to avoid, it's essential as a VR runtime to access the API OpenXR. There will never be a VR runtime for Windows made by Pico. Virtual Desktop emulates OculusVR runtime, you can try to run DCS with OpenXR over VD alone, but it needs tinkering with the registry. I never tried it because SteamVR runs OpenXR just fine.

The faulty trimmer is the same for everyone. He is talking about the VPforce software option, you can apply force trim from the "outside". But you have to disable FFB in DCS or override and activate this option everytime you want to hop into the Gazelle.

Already tried everything, instant trim should be the right choice for a FFB stick. It simply doesn't work right.

@vsTerminus Yeah, the Long Wait is over now. I'm also really happy that this dark chapter is going to end. The Gazelle is such a cool aircraft, it's former depiction in DCS was very disrespectful against the real one. Yes, that is exactly what is happening.

@daemon1808 You may have to review your testing conditions. In the video i see the M variant with the big Viviane system mounted on top and 100% fuel? The Viviane sight alone comes with extra 800 pounds. In this configuration you are already operating at the borderline (over 4000 lbs) and no wonder the engine is under so much stress. In this config i need ~60% collective to get the skids of the ground which totally makes sense. Please try something totally different, select the L variant and 50% fuel and check for "Civil Version" in the mission editor. This brings her down to ~ 3000 lbs and that is much more how she likes it. Don't forget that the module was a overpowered, weightless abomination for 7 years, basically everything was completely wrong the whole time. In this configuration i need ~ 45% collective to get her off the ground. This looks very good for me, the more i test it the more i like the new Gazelle... General tip for all DCS helicopters: always take the amount of fuel you really need - weight is the enemy of every helicopter. 50% fuel is enough for almost everything unless you need to keep it in the air for hours or have to travel huge distances. After looking into the weight thing more deeply i saw that removing the doors has no effect on weight, would be cool if this could make her loose some extra pounds...

Yes it moves with the trim hat and this works somehow. The big problem is trim release, it's hard to describe but the stick "runs away" from every new trim position. Everytime you trim it for a new position it kind of multipies the x and y position value of the position you intended and the stick snaps further away from the intended position. It seems to have the exact same offset from the position before the trim. It's either a bug or a wrong concept.

You should simply forget about this. You accumulated a lot of false muscle memory and have to get rid of it. Start fresh like it's a completely new DCS helicopter module (which it basically is now). For the first time in 7 years this thing acts like a heli and i highly doubt that the engine is to weak. However, FFB trim is still badly broken, i hope this is going to be fixed quickly.

Simply turn off MSAA completely and work with higher resolutions (Supersampling). See how your system can handle resolutions over 3Kx3K pe eye. MSAA is a stoneage method, very inefficient and demanding. I'm also eagerly waiting for DLSS as the next feature to tune performance and image quality.

@Gunfreak Hi, this problem is totally on Brunner's side. There are only buttons in the grip, all the decoding has to be processed by the controller board and software in the base. In my case i have used my 50CM2 grip on a VPC base and now on a VPforce Rhino and never had such a problem. However, Virpil's grips do go through iterations with internal changes. A 50CM2 from a couple years ago isn't internally the same like a 50CM2 from 2023, because they also go through optimization processes. So Brunner has to re-evaluate the latest versions and tweak their drivers.

This is the worst "procedure" i've ever seen. It's totally wasting ressources with launching a VR app (Steam VR Home) and use it to launch another VR app (the wired PCVR version of Virtual Desktop on SteamVR) to finally start the VR game you want (DCS). It's much better to go this way, to directly(!) launch DCS MT with SteamVR: 1. check SteamVR settings, if Steam VR Home is enabled -> set disable. Now SteamVR should only show the 360° environment with the ground grid on start. 2. bring up the SteamVR dashboard and click the second button on the bottom left that says "desktops". 3. simply click the DCS shortcut you prepared for running multi threading and VR (wherever you placed it, on desktop or in the start menu) @Thinder Your CPU clock speeds at 3600 MHz look very odd, maybe the worst clock speeds i've ever seen on a 5800X3D. They should be much higher under load. As others and myself already assumed in other threads, there are certain things pretty messed up and not working well on your system.