RealDCSpilot

Well, i chose the most lazy path. This way i also have a backup stick base. I'm sure you can get a much cheaper controller (Arduino/Leo Bodnar) to get any grip running.

The easiest approach would be designing and 3D-printing an adapter for the Virpil grip. Like what did for the G940 a couple of years ago: https://www.thingiverse.com/thing:3849592 You would need to buy a Virpil grip and a WarBRD base (to get the controller PCB). From there you will have a 2-in-1 device.

IRL NVGs are focused on everything outside the cockpit.

I think the Gauss FFB base will never be available outside of China...

Old trick: block that deadman sensor on the grip with a tape, this way you can let the stick hold the trim setting while letting the aircraft fly with hands off.

Basically every module supports FFB (except the horrible Gazelle module). In WW2 planes the stick reacts to forces on control surfaces, on ground it's loose - the faster you go the more force is directionally applied to the stick. In A-10C's, F-14B and F-5 it uses the realistic offset center trim. In the Mig-21 you get the SAU functionality where the autopilot controls the stick. In ED helicopters it's simply the best way to get as close to real helicopter controls as possible. The rest of the planes supports the trim functionality pretty well, how much, depends on the module and it's FCS capabilities. Pro tip: block the deadman sensor on the grip with a tape, to prevent shutdown of the motors if you let the stick go.

If you only want to play DCS the rasterizer only GPU might fit a bit better. If you want to play other games as well, raytracing and DLSS on dedicated cores aren't features to ignore.

AI driven image enhancement with raytracing on top is definitely the next gen step like pixel shaders was over a decade ago:

@5ephir0th My post was about that DLSS is not using RT cores, they are purely for raytracing tasks. It uses tensor cores, which also work with WinML and DirectML by the way... So Nvidia and AMD could surely benefit from FSR, but Nvidia will get the boost on top while AMD has to sacrifice some rasterizer performance.

As far as i remember, this was the case when DLSS 1.0 was introduced with 20XX cards. DLSS 2.1 doesn't need that anymore, developers can do it on their own. RTX cards have 3 different core types on the chip, rasterizer (for regular 3D rendering), raytracing and tensor cores (for AI operations). DLSS will make use of the tensor cores only, the combination of rasterizer and tensor cores will bring the performance boost. AMD's FidelityFX won't be that efficient, AMD cards have no special separate cores and their super sampling tech will take ressources from rasterizer performance.

I think it affects all processors in some way, it depends on what auto/standard settings mainboard manufacturers provide in their BIOS. In my testing sessions i found that these options worked against DCS's VR performance (high end system on extreme image quality settings). My recommendations besides classic OC: - Intel Turbo Boost Max Technology (i set it to Legacy) - Hyper Threading Technology (disabled) - Intel Speed Shift Technology (disabled) - CPU EIST function (disabled) - Enhanced Multicore Performance (disabled) - Intel Turbo Boost Technology (disabled)

I think it will have a huge impact. I'm really curious to test the NMS VR DLSS release (which should come out soon).

It's pretty awesome how much modern CPU's are customizable for very different scenarios and tasks. In DCS's case, stock settings definitely aren't the best starting point to just go and lift off in VR and hope for the best.

@Hoirtel Look at it this way, if you have ten cores and give each core the same equation to solve, they will run perfectly parallel and can easily be synchronized. If MCE detects such a task, it priorizes it against all other single threaded tasks. A game can never work like this, so MCE doesn't engage.

Yep, and it will never work like these applications with equal jobs that can easy run paralleled and synched, because it has very different jobs to run on each core.

I only stumbled over this because my mainboard was finally getting a BIOS with ReBAR feature. So i had to flash the new BIOS and go through all my almost 2 year old OC (4.8GHz) and mainboard settings again. For some reason i forgot to disable certain features and my DCS VR performance had changed from extremely good to crappy as hell. First i thought ReBAR was the culprit, but then i found that i didn't change some important settings. I was always wondering why some people, especially with equal hardware to mine, were having a stuttering experience while i had a blast on my end with very high to extreme graphics settings, especially in massive MP missions in Syria. TLDR: disable any so called "enhancement" and power saving features of your CPU and, the old news, if you OC - try to get as near as 5 GHz as possible, at least with 4 cores (and set affinity for the DCS.exe). DCS needs as much as raw power as possible, we all know that. So if you have a pretty decent gaming rig and performance issues, look for CPU settings like "Enhance Multi-Core Performance", "Intel Turbo Boost Technology" and everything else that might be related to power saving instead of lifting the limits. Yes, these features are actually power saving mechanics, they limit and restrict. If you don't need hyperthreading, disable it too. These features are meant for different scenarios than gaming, a game is a very dynamic scenario with lots of sudden changes in core usage, in DCS's case on a maximum of 4 cores for instance. It's the opposite of a 3D rendering scenario, where every core is basically running under the same conditions. In my case i forgot to disable Intel Turbo Boost and my CPU performance was crippled. I couldn't detect it first, because frametimes and FPS values looked ok, but inside the headset i had stuttering and motion smoothing was going crazy most of the time. What i assume is that Turbo Boost was way to slow to react to DCS's per core fast switching thread demands. It tried to chase core usage and readjust, but always to late and missed the perfect clockspeed anyway. On my end, everything is working well again. Every component, RAM, SSD and GPU, runs perfectly optimized with highest possible bandwidth through the CPU.

Did anyone else notice this? Is this a bug or an adjustment for realism? Edit: found some more info about the BMP-3M upgrade, only the front end armor seems to protective enough against 30 mm AP rounds. I guess it's the missing directional damage system, because i hit it from the sides and back.

When DCS Black Shark was released in 2009, after a lot of years without any hope for a new helicopter sim on the horizon, ED brought something completely new into the sim world. They were the first developer i can remember, who started to work around the self-centering stick problem which does not fit for cyclic controls. I was a normal desk simmer back then and i decided it was time for a HOTAS and got very lucky to go with a G940. This combination totally changed my view on helicopter controls back in the days, for the first time i really understood how this is actually working. Those trimming options totally made sense once it made click in my head and after that, i was really hooked for anything else that came later for DCS as it turned into what it is today. One of the biggest mistakes Polychop ever made, was to not understand how DCS helicopters work. They not only started with zero knowledge of helicopter flight models, they also missed analyzing that the Ka 50, Huey and Mi-8 were designed to fly with springless and force feedback joysticks or had to have a workaround for standard joysticks. They just did what everyone else did before them, working with simple spring-centering joysticks and simplifying controls for desktop use, thinking that making the thing fly somehow is enough. They didn't even consider to have a FFB joystick for FM development and more than a year after release of the Gazelle, they only started to realize what really makes the other DCS helicopters so special. They tried to implement FFB and failed pretty hard "This would need us to completely rewrite the FM...". What happened after that was their next fail, the thought they can make the problem go away by trying to ignore it or sweep it under the carpet. Didn't work out very well. I completely understand that some guys fall for the Gazelle module because of it's simplified controls. They totally don't get the angle of the discussions and criticism about it, that this is not what helicopter flying in DCS really means and that it is a degradation of what the other helicopter modules stand for.

This is not what i meant. After startup, go into hover and try to hover to the left/right - any direction... The smallest cyclic input result is a linear continous roll, this is just as wrong as it could be for a Gazelle type of helicopter.

@zerO_crashI had the same reasons to wait (and wait and wait). Finally, i chose to go the modding road. Please keep taking care of your MSFFB2 stick, regardless if you are going with a Brunner base. Someone might be very interested it it. A guy on reddit tested the motor heat/force protection of the Brunner base: reddit

@v4ri4bleI have similar troubles with FFB (G940 mod). The Y axis definitely has to much force, stressing it's motor with heavy duty all the time, while the X axis motor is on much less power...

I ran into the same problem, but found out that you can completely modify the desktop mirror now. You can set it to a very small window if you want, this way it will not interfere with the taskbar.

What are those round edges in every corner? Could it be that this is the VR mask, but the screen is still cropped to much so you can't see it?

@STONE SKYPM me, i have lots of spare parts now.

Please, never ever press "stop" on the internetbutton. Parts lists and information is all there: https://github.com/o-devices/bldc-ffb-joystick-base https://github.com/Flashgod-VR/G940-Total-Conversion-Kit