RealDCSpilot

I have troubles with the engine dying or losing power on me during starts on a server with -4° celsius. I tried one with +2° without problems, but at below zero temperatures the jug doesn't seem to like it at all. If someone could provide a step-by-step guide and which one of the temp gauges is the most important here, it'll really be appreciated.

https://youtu.be/sZbR8wOLNJA?t=2157 Another good video, at minute 36:00 it perfectly explains the biggest issue, direct rotor control through cyclic input does not exist. If the Gazelle module would feature this correctly, like the other DCS helos, nobody would have a problem with it. We also wouldn't need to mitigate the problem with axis saturation, because if the Gazelle would feature correct rotor dynamics based on blade element physics it would start to act and fly just naturally by intuitive control inputs. @tugais I don't get from where you extrapolate your exaggerated depiction about my point of view about realism in DCS. For me it's very obvious that DCS features a very high standard when it comes to depictions of flight models. I only refer to what is there and what is not there in this particular module compared to already established standards of other modules. That isn't an opinion, it's a fact (proven so many times). You surely can have an opinion about a fact, don't mix it up please. As we all know by now, certain RL pilots share a very contradictory opinion about the same fact. In my opinion(!), it's a shame how this module was turned into a religious subject for the community by some people, splitting it up in "believers" and "unbelievers", "high priests" and "renegades". I, for myself, believe in physics and appreciate every simulation aspect that gets correctly modeled into any DCS module.

The title states "Kiowa pilot" doesn't it? And i wouldn't call Damcopter's honesty being negative. Sometime the truth hurts and another honest guy made this very informative video as a direct answer to the video you posted:

I always find it sad if someone who does only own the Gazelle module refers to DCS as a "game". You'll miss 90% of what DCS is offering as a simulation if you only look through Polychop's module. However, everything that is said is right in the last third of the video (20 mins+). The Gazelle module is in simple game mode 100% of the time, it's basically just a good 3D model replica of a Gazelle helicopter glued on an invisible something that only has simplified basic game capabilities, sufficient enough to be able to move it through 3D space in "airplane mode" instead of "helicopter mode" and if you want to "enjoy" it (whatever that means in a simulator) you have to get your head around a lot of things because this Gazelle module still doesn't behave like a helicopter after almost 5 years since release. Or skip it and fly the other helicopter and jet/piston engine modules which actually simulate their flight models with all the simulation features for aerodynamics DCS provides, one example -> air and realistic lift... It's almost 5 years now and Polychop still didn't deliver anything near of what other full-price DCS modules already have included right from the start. It's still just a fake, deep below DCS's general simulation standards while other developers invest a lot of effort and expertise into their modules aero/rotor dynamics simulation BEFORE they release it to the public.

Try to contact Damcopter or check this: http://www.checksix-forums.com/viewtopic.php?f=465&t=200331&start=50#p1678174

VRAM is memory on the GPU, it's always the limiting factor for everything that get's processed and rendered to monitors by a 3D game engine. It holds the screenbuffers - all the pixels you see frame by frame and all the asset data like geometry (3D objects made of polygons) and texture data (2d bitmaps) plus certain effect processing buffers (like heat blur, screen space reflections etc.) that are needed for these frames. RAM is used for fast access for the CPU to the assets and for holding processing information (whats going on in the game). The CPU has to manage all of this, besides processing everything that is going on in the game it has also to manage loading of assets from disk to RAM to VRAM. Because on PC we still have VRAM and RAM separated (not like consoles with unified VRAM/RAM or like the Playstation 5 with GPU direct storage) a developer usually has to keep an eye on how the game uses VRAM and RAM to avoid reaching memory limits. This is part of memory management in the game's code. A dev has a certain scenario for his game in mind and he also knows what hardware combinations are out there to render the game (our machines). It looks like that ED didn't target the game engine for massive online scenarios with all available modules back in the days. It's still good for "normal" missions, you hop into one aircraft, do your mission and finish (back to main menu - VRAM gets purged). In this scenario you will barely exceed any memory limit and there is usually no need for purging unused assets during mission runtime. But online mission makers started to develop more and more open world scenarios over time, because they can, the mission editor and script engine allows it. And well, we all know that ED has to do a lot of changes and improvements on the core engine to make it fit for how we use it these days and to what actual hardware is capable of. First of all using more of our CPU cores in a more efficient way, so that excessive memory transfers do not influence CPU frametime that heavy anymore.

@Gunnars Driver The stuff you mentioned are technical capabilities, they don't help if a developer chooses to use massive amounts of polygons for 3D objects and huge textures for shaders. This will fill up VRAM in no time. As a dev, you always have to watch on VRAM consumption and implement routines to clear up free space in VRAM as soon as possible. Like when you are in MP flying one aircraft and decide to choose to fly another one. The former aircraft's cockpit model and textures do not need to stay in VRAM anymore. DCS has very poor memory management atm.

A GPU never manages VRAM. It's solely on the dev of the application that uses the GPU to implement memory management routines, up-to-date texture compression techniques, keep track of unused assets and purge them from VRAM and RAM to free space. Most "common" games do that because they are designed for current available hardware (and consoles).

Hmmm, i posted this: https://forums.eagle.ru/filedata/fetch?id=6677134 over a month ago. It shows dedicated VRAM usage of the DCS process from 0 to 24576 MB on very high settings and Through the Inferno Syria in DCS on OB from that time (mid of October). You can clearly see the difference between allocated VRAM and real usage.

From the same page: "Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the system commit charge. Both considerations are unique to each system, even for systems that are identical. This means that page file sizing is also unique to each system and cannot be generalized." DCS commits 39GB on my end if i choose to fly on the syria map for instance. I would recommend to set a minimum=maximum of 64 GB for the pagefile because of DCS high peak usage.

The recommended size for maximum setting is actually 4 times the RAM capacity. https://www.poweradmin.com/blog/pagi...usage-counter/ You only set it lower if you have not enough space. Setting min and max to the same value minimizes disk activity during OS's page file management because the allocated size is fixed. The less RAM you have, the more important a large pagefile becomes.

@Stal2k Any changes on your end after the patch yesterday? Terrain: improved background preload for less stutters Terrain surface textures: improved details at altitude for HIGH terrain texture option Terrain: improved loading resources and memory management Terrain: fixed excessively curved paths Terrain: fixed leak after destroying scene object

I've also had this off since it was introduced, tested it back then and found no real benefit. The occasional Steam VR crash still happened on my old 2080ti until i replaced it.

Just WOW!

Process Lasso has a couple more options besides cpu affinity like system priority class, I/O priority and an exclusive application power profile. @Dangerzone disable_write_track = true in autoexec.cfg minimizes extra disk activity, might be worth a try.

+1 Proper VR support would be great.

It's more depending on user's hardware and knowledge to get the best out of it and to get DCS run pretty good in VR. Another thing is that no HMD runs VR game resolutions at it's native panel resolutions (it's always higher, example Index: 2016x2240 per eye). I suspect the streaming (over WLAN or USB) itself as a performance trouble maker, because it has to use CPU power which could conflict with DCS's own CPU usage. Maybe he needs to try to assign separate cores to the streaming process to get a better result. That's part of "tinkering" and trial and error.

The amount of VRAM will definitely make a difference for DCS in VR.

I also use the tool "Process Lasso" to make sure Window's CPU usage runs at highest performance for DCS.exe and exclusively set separate cores to run SteamVR processes (vrcompositor.exe).

@divinee Okay, 7,7GB means that your VRAM usage is maxed out. But can you please be more specific about your page file settings? Did you just change the size from XXXmb to 800mb or did you disable it? Did you also try to change the size to 32000mb or more (best practice for the windows page file is having it set to 1.5x your RAM capacity and prevent dynamic size changing by setting the same size for min and max)?

Well, it's not DCS's fault. I would expect a lot of tinkering needed, if i try the game on a HMD that isn't even designed for PCVR in the first place.

Within the next 'two years'. And i've seen a lot of changes during the last 11 years...

Works now, thank you!

Oh no, they don't need to reduce the quality. Just more efficient usage of textures (resolution) and better memory management will be enough.

Yep, this will be very interesting...