RealDCSpilot

Most of my current settings.

@Extranajero :) Oh, i really hope you attend to that. For you it's free of charge!

Thats what GPU-Z shows. Idle, loading DCS to menu (6GB), loading Through the inferno mission (over 13GB) choosing A-10II (24GB) after that choosing F-14 (2 little spikes for each plane). After that leaving to menu, 24GB kept getting allocated. At the end, quit DCS. Keep in mind that i'm driving very high ingame settings and double panel resolution SS for each eye. A huge part of VRAM is allocated for the display buffers. The last graph shows RAM usage, around 32GB from 64GB.

I'm currently running the 3090 with forced low latency on Ultra and prerendered VR frames at 1. This seems to minimize the side effects of Steam VR's motion smoothing a lot. The 3090 is extremely beefy compared to a 2080ti and seems to have a real advantage here. The strange thing is, i see 40 or 27 FPS in DCS internal FPS info, but the "27" FPS feel much much smoother on a 3090 than with a 2080ti.

About the POSCAP issue, the latest Nvidia driver introduced a better algorithm for boosting clocks to prevent spikes: Atm, my card is stable boosting up to 1980 MHz, but i have no comparison to unstable behaviour because i started with the most recent driver.

How about a workshop? The agenda would be: 1. Public relations: - How to find better ways to communicate with our customers and the community - Who are our customers and potential customers? What do they want? - Professionalism: what to communicate and what not - How to keep always being honest, keep telling the truth 2. About learning and being a professional developer: - Analyzing fails and mistakes from the past 4 years - Deep analyzing other dev's modules: what are their strongpoints? - why are we not able to reach their level, even on core features? - What is DCS? What makes it different from other software/game/simulation platforms? What are our responsibilities if we take part in such a longterm development platform? - What are standards in DCS? How can we meet those standards? - Get an overview of todays available hardware and features that are supported by DCS (huge list) - Leave the bubble we created for ourselves and are stuck into 3. Rebuilding company reputation: Rethinking strategy to regain the trust of customers and the community A. take all we've learned from 1. and 2. B. Fix the Gazelle first? May bring back trust from existing customers C. Invest time and concentrate on marketing this "new" gazelle (from B.), be honest about mistakes and show A/B comparisons in detail: What was bad and why - what is fixed and better now (show proof on youtube, social media...) 4. Release of the Kiowa module - take everything you learned from 1. 2. and 3. - have a good time, finally get the sales you deserve if you release high quality products for DCS

+1 on the collective behaviour This is standard in every other DCS module, the simulation defines how fast you can move primary control inputs, not the user.

I have the same card as in the 8auers's video. Gigabyte 3090 Gaming OC with the "worst" capacitor config, i personally banned Afterburner now from my system because it isn't needed anymore. 10K of CUDA cores boosting up to 1980 MHz, stable with the latest driver. It's a big punch and enough for me for now.

Yep, DCS does not clean up VRAM properly, makes it look like a memory leak. If VRAM is full, your system starts to cache the rest to the harddisk, that additional data transfer activity adds load to the CPU and GPU and kills frametimes. That's no problem for normal single screen usage, i doubt that you can fill up 11GB while playing flat. But VR turns it all around, we are driving it to the extreme with VR. For 2 highres panels and AA + post pro effects, you need larger buffers in VRAM plus enough space for geometry and highres textures.

You can't imagine my big fat smile yesterday when i tested this, i was happy like a little boy. Extreme highres for both eyes, very high visual quality settings + 4x MSAA on top and still a smooth and pleasant flight experience. This GPU generation is the first one that has enough steam to tackle high quality VR for real. Imagine, if DCS's engine wouldn't be that badly CPU bound, what would be possible...

I suspected DCS's VRAM usage for a while now for causing occasional framerate drops and stutters, especially in MP when switching aircrafts. Typical scenario was: entering the server, choosing an aircraft, play a while, choose another aircraft (F14 on carrier for instance) and bamm! VRAM overflow - huge FPS drop. Got my 3090 (24GB) today and this problem is gone. My good old 2080ti with 11GB wasn't enough. Rule of thumb, the higher the panel resolution and/or SS setting, the more VRAM you need on top of textures and geometry filling your VRAM already. Steam VR beta just updated and adapted to this: "Maximum automatic render resolution limit is now calculated based on gpu dedicated memory; it was previously hardcoded to 1.5x the headset driver recommended resolution. This should have little to no impact on existing headset and video card combinations, but will scale better as displays become higher res and gpus more powerful."

Steam VR beta just updated: "Maximum automatic render resolution limit is now calculated based on gpu dedicated memory; it was previously hardcoded to 1.5x the headset driver recommended resolution. This should have little to no impact on existing headset and video card combinations, but will scale better as displays become higher res and gpus more powerful." Perfect timing.

Got my 3090 today and it really makes a difference. The most important feature are the 24GB VRAM for VR in DCS. I had the occasional stutter problem in MP sessions, mostly after switching aircraft where i already suspected that it breaks the 11GB barrier of my 2080ti. Now everything is pretty smooth at 2880x3200 per eye on the Index, most settings maxed out, even MSAA at 4x. No more stuttering, switching aircraft goes pretty fast (geometry and textures load sooo fast!). It's still throwing money at the problem, but this time i'm really happy how it works out.

I'm put off by the Gazelle's unrealistic handling and flying, how bad controls are and even how unrealistic the 3D model is animated during flying and auto hover. Never expected this from a DCS module. If ED's shop system had a refund option, i would have used it a long time ago.

@shagrat I don't get the point of any of your posts, SAS is a subsystem. AP will use it, because it would be senseless not to. Still there is enough real life data and videos that show that the controls + SAS + FM of the Gazelle module are extremely far from everything real.

@Shagrat Autopilot modes are separate systems and make use of SAS, yes. https://en.wikipedia.org/wiki/Autopilot "Many helicopters have pitch, roll and yaw SAS systems. Pitch and roll SAS systems operate much the same way as the yaw damper described above; however, instead of dampening out Dutch roll, they will dampen pitch and roll oscillations or buffeting to improve the overall stability of the aircraft." In a helicopter SAS is basically just a dampening system, it smoothes everything out. The pilot in the video makes a lot of quick movements and the chopper reacts a bit later, so it looks like SAS is active.

@shagrat that magical auto control thing in the Gazelle module isn't anyway near how the real SAS works. It makes it even worse and adds unnatural, physics defying effects. Like the continuous roll with just a bit steady holding of left or right stick input. This is mechanically and physically impossible in a helicopter. Like a real Gazelle pilot already said and real video footage shows, they always hold and move the stick. Even for making her steady and ready to land, you always have to work with the cyclic against the natural unstability of a helicopter. The SAS only acts as a input dampening system if the pilot is in control.

The good thing about vector based symbology is that everything is scalable now. Nothing is limited by fixed pixel density anymore. This will improve HUD and MFD readability and improves the quality and reduces efforts for dynamic/animated symbology.

The transition from bitmap texture based HUD and MFD graphics to vector based SVG is part of DCS 2.5.6. It is publicly known for months and is already implemented in some modules (F/A-18...). Making such a drama post on FB makes no sense. The change didn't come over night and is just a part of DCS's always ongoing development.

@Extranajero I can only imagine your struggle and i'm really sorry for you.

@Barundus Do you see the axis indicator in the left corner? Do you understand what it means and what he is talking about? He even shows original data on real controls input for the Gazelle. Do you see that this: isn't anywhere near an inch of movement? It's just millimeters for a heavy bank! And how many inches do you see here? Do you state here and now, that what we see in the Kiowa video is realistic for all the maneuvering he does? We should see that inch of 90% "normal" movement 1:1 in the axis indicator movements, within a 30-40% range left/right/up/down like in every other DCS module without messing up saturation - on a 100% linear input setting for each axis. For stick extensions, saturation should be reduced about from 20% to 40% to compensate input from a the longer stick and show a line with a steeper angle not that ridiculous flat one that is needed to make the Gazelle less crazy.

@Adam SteamVR SS settings are "global + application setting = final SS".

You may need to closely watch the review video of the Gazelle by Eric Scott and real footage to see that realistic cyclic movements for normal operation are within 40% to 50% in each direction of the full axis range from the center. In the Gazelle module this is already a problem for years now. In DCS:Kiowa videos you can clearly see that it has the same problem as the Gazelle module: only 3%-5% of axis movements off the center are needed cover the whole range, even for hard maneuvering: 1. this is absolutely unrealistic, 2. makes no sense in helicopter or aircraft design in general, 3. introduces pointless over-sensitivity and unrealistic flight model behaviour for the helicopter in DCS.

@Relic The input axis indicator in the Kiowa video is actually pretty concerning. Whatever is set with saturation or curvature for axis makes no sense or is bugged the same way as in the Gazelle. Why would someone need to narrow inputs down that much? To fractions of millimeters for movements that are hundreds of times larger in reality?

Alright, so in short this means same, normal(!) cyclic deflections, but less lag in airframe reaction in the real OH-58D.