RealDCSpilot

Thanks for the hint. I'm pretty sure i've tested all options, but i will test again.

MP session, i'm the pilot: F-14B drops snake eye and AIR in high drag mode, F-14A drops both in low drag, like standard Mk 82.

Hmmm, look below your thread:

My hope is, 2.7 is a big enough engine overhaul that will get this covered.

Is it possible that @RAZBAM monitors aren't calibrated correctly? Are you guys running on gamma 1.0 to tune lighting intensity? Everything seems to be way to bright. i just need to turn the knobs one bit to instantly reach maximum brightness, if i go further the lights are already in crazy overdrive mode. Pretty bad in night missions, the HUD and radar screen can't be turned down to a suitable level. Same for the Harrier lighting and MFD's.

Also ran into this issue on a server yesterday, but it isn't caused by the module or the hotfix. Just choose another m-2000C slot to spawn correctly. In my case the known mp spawn bug was the issue, a player spawned before me in the same spot - another player spawned on top of him - result: both explode and their wreckage remained on the spot. After that i spawned in their wreckage and was stuck several meters deep in that mess. I simply choosed another slot and spawned in a clean hangar.

Justed tested this again. Mission editor, set time to 0:00, placed harrier at ramp, cold start. Loaded 2 SUU-25 pods from the bomb category. After lift-off choosed AG, ARM, stores: choosed the pods and pickle button drops always one flare on a chute at a time. It even switches to the next pod automatically everytime. I would say works as intended.

I just tested them, designated a target on ground via DMT and DESC, flew over it and dropped one by one in DSL mode over the area. Worked flawlessly.

What's the difference to LUU-2B pods in the A-10 and F-14? Would it help to just make it work like them?

@IronChancellor At what daytime did you play the mission? As far as i remember, the shkval's locking capabilities are simply bound to a fixed daytime/nighttime cycle which doesn't make sense sometimes, especially at summer dusk/dawn. The trick for now is using illumination rockets above the target during dusk/night/dawn.

Just as a side note, i'm flying with a FFB stick and have the advantage of the FFB trimming system. My pedals do not support FFB and trimming during flight can get confusing after a while, because they will still work like the none-ffb trimming mode. That's why i disable the rudder trimmer option and prefer to hold the pedals in position if needed.

Thanks, will try. What i find pretty cool, the engine sound details, never recognized this before (wasn't flying at these low temperatures before). You can actually hear if something is not right, a mechanical rattling noise will appear if you raise RPM too early. Seems to appear on all WW2 birds.

Ahh, what a relief. Everything worked perfectly this time, managed -6° celsius with cowl flaps closed all the time and readjusting the oil cooler shutter at 0-20% to hold the perfect oil temp. Many thanks for pointing me in the right direction.

Alright, will test this. Thanks. Cyl temp never reached more than 180/190 if i remember correctly, even after a long wait for warmup with cowl flaps already closed. I will definitely check the oil temp much closer.

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.