Lixma 06

More or less identical to yours. They're not straining the GFX card; I prefer FPS over glamour. It probably didn't translate well to video but the choppiness was manifesting itself much like when you have V-Sync turned on and your FPS drops below the refresh rate - that's why you'll see me looking around the cockpit to try and show it. I know about the cockpit shake. Re: the boat - I wonder if the boat is trying to contact me in any way? The Moscow appears in the radio list (although I've never been able to get through) and the ship opens its 'petals' when you touch down on the pad - this suggests to me there might be some angry unrequited radio traffic berating me for not landing without permission. Maybe this is tripping it up in some way? Or maybe some kind of collision detection conflict - like the 21 is having trouble with? Dunno. However.....however....today it's been more or less fine. The occasional spike and stutter (it's DCS after all) but nothing out of the ordinary. I'll keep an eye on it.

i5-7500 @ 3.8GHZ Same story as yourself, my CPU usually hangs around 45-50% (unless I'm online) in every module I have (MiG-21 has its moments, mind) but the Mi-8 is just all over the shop. e: it was your video that convinced me to buy the Hip so technically this is all your fault.

When flying the Mi-8 I'm experiencing frequent spikes in CPU usage. I haven't been able to find the specific reason for it but I can show it happening. In this video I do a couple of landings on the Moscow in the Ka-50 and then a few more in the Mi-8. The mission has no other A.I. in it and while flying the Ka-50 the CPU doesn't break sweat. But when piloting the Mi-8 the CPU is regularly hitting 100% and causing very choppy performance. The CPU spiking happens even while flying the Mi-8 across the land with no aircraft, ships or anything around so I don't think it's a Moscow thing - I just used the ship mission to reliably capture what was happening. Is anyone else seeing the same thing?

Watch my video. FPS goes down and the GPU load goes up when there are less trees being rendered on screen. This is backwards. The DEFAULT shadows are being rendered with more or less detail depending on distance to the player - that's obvious enough. But when you can zoom in to just a handful of trees and bring your GPU to its knees....well that suggests the DEFAULT process of rendering shadows is just a bit over-enthusiastic at close range.

Then why is the GPU maxing out with only ten trees on-screen while using default shadows?

Here's a comparison screenshot from the video showing the relative GPU loads while zoomed into the side of a hill with about 10 trees maximum on screen.

Here we go. Three clips all identical area and graphics settings (1080p, no AA, 'High' all round) First is shadows 'OFF', then 'FLAT, then 'DEFAULT'. As can be seen the OFF and FLAT settings are more or less identical in their GPU load (avg. 45%) whether just looking around or zoomed in. On the other hand the DEFAULT setting averages at a higher GPU cost (75%) which is to be expected seeing that they're actual projections, but what is problematic is the massive spikes in GPU usage (95%+) the closer you get - e.g. when zoomed in to a tiny patch of ground with only about 10 trees visible. You would expect the GPU to be practically idling in a case like this....as if you were looking up at the sky. Is it possible the 'DEFAULT' shadows are being rendered more and more detailed without limit the closer the proximity to the player? This might explain why a scene with only a couple of trees can bring, in my case, a 1070ti to its knees?

I can sort of confirm this - it's not so much the trees but the shadows on 'DEFAULT' setting that seems to be the culprit. I've got a video on the way - sit tight.

You need to get into a hover by yourself and trim it, make sure you're not in Director Mode (so you can't see = = on the HUD) and then engage auto-hover. It's not a miracle worker, though. If you're poorly trimmed and drifting when you engage hover the autopilot will try its best but you'll likely carry on drifting into a tree.

There's a load of twisty knobs in the Mi-8 that are just crying out for axis control (e.g. gunsight range, brightness). Also there are many 3-position switches (e.g. landing/nav lights) but no 'rotary' command option in the controls.

This video shows the moment the accident happened. I turned on the control helper to better see what's going on. Just after you gain forward speed it shows a large uncorrected cyclic input to the right which rolls you into the ground. I also tried taking control just after you switched off auto-hover but everything worked OK. So the problem is/was an unwanted cyclic input to the right. Looks like a control input issue - maybe a conflict?

I remember a bug from the BS-1 days where if you had a racing wheel/pedals attached then the trimmer wouldn't work properly. Check if your'e not unwittingly resetting the trim as you exit hover mode, maybe with a duplicated control.

When will the T-Rudder Pedals be back in stock?

He can shift to the right OK but the range of movement to the left is only an inch or so; not great when trying to find somewhere to land. The co-pilot does not have this restriction when leaning to the right. Is this limit on the pilot intentional or is there a file I could edit to fix it?

Mirrors can cause it too.

If it's any consolation (it isn't) I get the same thing in IL-2 while DCS is fine. :joystick:

Get a chiclet one - when you're flying it's a thousand times easier to hit a control, enter chat, or shitpost without accidentally hitting adjacent keys.

Beyond approximately 2km from the player the MiG-25 (both variants) turns completely white.

Yes - but the impact is practically nil. I don't know; it sounds like a scripting job although you might be able to do it using multiple 'Layers' via the GUI.

I've been unable to split an axis in two it but there is a rough and ready workaround if you're using TARGET. https://forums.eagle.ru/showpost.php?p=3347787&postcount=2

....

As Gandhi once famously said.... Absolutely.