MoleUK

Glad to hear i'm not the only one at least. Definitely crashes most often on the 'loadTerrain' step. Have had it get stuck there for a minute + and eventually recover as well.

Also getting these events on some of the CTD's.

I am seeing the same freezes on server select screen at least, as well as some other freeze and CTD issues. Mine don't last entire minutes, but that may be due to the CPU recovering quicker.

Incase it helps narrow down any sort of solution, the CTD's when they occur often happen during the 'terrain load' step. When it's freezing on the servers coalition select, it's remaining connected to the server. Just at far less than 1 FPS. It will periodically update the chat feed with new timestamped messages. Seems to keep receiving/sending data from the server. 2 CPU cores remain locked at 100% usage while every other CPU core will just sleep with nothing to do. I have left it connected for over 10 minutes but it never recovers.

This is all on a fresh install of DCS, I nuked the old install to see if it would fix the problem but it had no effect. This is also using a fresh savedgames DCS folder, and a fresh install of Windows 11 after a reformat. No mods are installed, everything is running vanilla. I am on Nvidia drivers 566.36, BIOS is on the latest update, chipset is updated. Cores are not parked. Tried with XMP disabled. The game install is whitelisted in windows defender, so is the savedgames folder. Sometimes I am able to get into an instant action mission, sometimes it CTD's with no option to send off the error log. Every time I bring up server select, it will freeze for long periods of time until the server list is completely refreshed. On some servers I am able to get past coalition select, on others it will just freeze. Technically the game is still running, it is just running at less than 1 FPS. It will occasionally update the chat log etc. It appears to only be using 2 CPU cores when this occurs, both pegged to 100% load. Logs and timestamped videos included. CTD during instant action load.log freeze on MP join.log Able to get past coalition select on 4ya, but not contention.log DX Diag included. DxDiag.txt

Could be, but in past testing it can also happen when CPU and GPU load are fairly low. I might end up doing some test runs to reproduce it reliably if I can be bothered, but I am a lazy man. The thing is, I don't think this is microstuttering. It doesn't feel like it anyway, and it presents more like the frames for terrain literally being rendered out of order. They are going back and forward in motion while everything else remains smooth, that to me doesn't point towards it being a stutter or microstutter issue as seen in other games. The problem is there are a ton of actual stutter issues in DCS as well, which confuses things a bit.

Let me know if capping the FPS does the trick or not, doesn't seem to work for everyone but it's noticeable when it works. Seems to work better when capped under what you can achieve, eg if you're usually hitting 75FPS average try capping it at 70. Unfortunately any overlays can cause issues with game performance, the new nvidia app is just particularly bad for it atm. He's on flatscreen, the terrain jitter can happen there too as it's a problem with the game engine rather than something VR specific.

Good to hear something worked. The mouse polling thing is a bit of a DCS'ism that re-appears from time to time, very few other games are affected by it.

What trips people up is that afterburner monitors the power and power % by default, causing the problem. RTSS doesn't, so typically just disabling afterburner but keeping RTSS running is fine. But ideally it's to be avoided, unfortunately DCS doesn't seem to do too well unless an external frame cap of some sort is in place though. But that isn't entirely unusual in modern gaming. Yep. The list of 3rd party apps that really conflict with DCS only continues to grow, it seems to be especially sensitive to them. It does make sense given the level of strain it can put on the CPU, GPU and memory all the same time I guess.

Most of the issues I've seen recently have been related to MSI Afterburner far moreso than RTSS. Typically the voltage/power monitoring causing CPU issues. But yea ideally you'd want NVCP to do it.

I've been advising people to cap their FPS in NVCP to fix the terrain jitter for ages now, with mixed success. I'm wondering how many of those failures were due to NVCP not applying the FPS cap correctly in some instances, will have to keep that in mind going forward. Might be easier just to recommend RTSS or something.

If NVCP settings aren't changing much for you, it might just not be applying any of them. I did a quick check, I do have to reset the game after changing the FPS cap in NVCP but it works fine. You can also do some very significant tweaks with nvidia profile inspector as well. These things do have an impact.

I have no idea why the cap isn't working for you then, I can set it to anything on NVCP and it caps it properly both for VR and flatscreen for me. I'm using VD on a QPro, so perhaps the software/headset comes into play. But if it isn't capping the FPS for you, it might mean no other NVCP settings are working for you either. You will have to test that out if it's a problem. I always thought the CPU bound in yellow was the default state and meant nothing, but I am more convinced it's actually flagging a slight issue now. Once it's green bound when running at full refresh rate, the terrain jitter goes away. Could be coincidental.

Tried restarting the game? I haven't tried seeing if it works to change the FPS cap without restarting. No idea why it wouldn't work on your system, but it may also mean no other NVCP tweaks are applying correctly for you atm.

Are you even hitting apply? Or just pointing it at the wrong exe? When properly frame capped with NVCP, you should also see the frametime graph list the game as GPU limited as shown in mine, not CPU limited as shown in yours.

I would start with 71, then 72 then 73 to see if there is a different impact here, as you don't want the other limits (VR software, headset, then VR specific mods) kicking in before the NVCP limit. VR just adds layers of extra problems on top re: frame pacing. And yeah capping frames is generally good advice, but I have never seen the same behavior exhibited in any other game. It's not stutter, it's literally like the frames are being rendered out of order. So you see the frame jump forward then back. But ONLY the terrain, the rest of the game will be rendering perfectly smooth. Much of the time this jittering can occur without showing any sort of movement on the frametime graph, unlike all the other various stutter issues DCS can have.

If the sky is jittering as well it might be a different issue, though perhaps I've just not noticed it before. To me it's always been the terrain/buildings that jitter while everything else remained smooth. There is only one thing that's ever helped reduce/fix the jitter shown in the video for me and a few others, and it's simply by capping DCS' framerate externally. Simply open up nvidia control panel (not the new nvidia app, avoid that), go to manage 3d settings, then program settings, and then find the DCS exe. Now scroll down and set "max frame rate" to 1 less than your headsets refresh rate. If running at 90hz, 89fps. Though I would recommend setting your headsets refresh to 72hz and capping it to 71fps personally, as that helps avoid some performance edge case problems. See if that helps or fixes it at all, if it's not the terrain jitter problem it might not. Additionally you can try also enabling vsync fast and low latency ultra in the nvidia control panel settings, though that might not be necessary.

Do you mean the terrain jitter as shown here?

Unfortunately there are a LOT of potential causes for VR stutters. It's one of the most frustrating issues DCS has. When you say the entire scenery, do you mean ONLY the scenery? Are the planes and everything else smooth in movement, but only the scenery jitters, as shown in the video here? If so, I have some suggestions you can try, they have worked to reduce or eliminate terrain stutter/jitter for some users but not all. Let me know. As for more general stutter problems that don't appear the same as shown in the video: roll back nvidia drivers to 566.36 due to recent nvidia issues. Be sure to do a proper DDU process for that rollback. Make sure mouse polling is at 125hz or less. This issue never entirely went away, and I think might have re-appeared for some users recently. Make sure CPU core parking is disabled, and potentially you may want to disable low power states in BIOS. Exclude the DCS install folder and savedgames folder from your antivirus. Make sure programs that cause issues are either not installed or not running. MSI afterburner, iCue, armory crate, Nvidia app (the new one) and anything that monitors CPU usage can/will all cause issues with DCS. As can any program with overlays. Then there is also DCS specific stuff like tacview, and various mods that even when deleted can leave leftover files in various folders (the Loach AI gunner file in the hooks folder in particular). If it's more like the terrain jitter shown in the video: Try using an external FPS cap and limit DCS to 71 frames (if running the headset at 72hz), I would suggest either nvidia control panel or RTSS. If that doesn't work, try running keeping that FPS cap and also using nvidia control panel to set DCS to vsync fast and low latency ultra. Let me know if it does anything, you may notice the FPS stats in DCS also start showing you as GPU limited when hitting your frame rate as well after those changes, rather than listing it as CPU render threat limited. The terrain jitter problem is years old and actually isn't limited to just VR, it's just either a lot more prevalent or a lot more noticeable in VR. Or both. I have 0 experience in game dev or coding, but I assume it's something to do with poor frame pacing or a mismatch between the CPU thread handling terrain rendering and the others, but that's just a guess. But it might explain why external FPS caps seem to help alleviate it for some users, if not all.

It's hard to make out, but going by the speed of transition it looks similar to the HDR effect during daytime. By HDR I don't mean the type of HDR supported by monitors etc, it's also used to refer to the lighting technique in gaming where things gradually dim/brighten like that depending on conditions. Daylight example here. Particularly when zooming in/out at around 19 seconds it's a noticeable transition. I always hated it personally, wish it were a tickable option. It might just be misfiring at night.

I'll put up some more later if it helps. The first log/pic here is of a core 100% being locked solely due to mouse movement. I kept the mouse moving in a small circular motion and it kept 1 core pegged to 100%, when mouse movement stopped it simply started passing that 100% load from 1 core to another over and over again, which is what I typically see. I rarely boot into the state where mousemovent keeps it pegged at 100%, but it's repeatable if I boot the game enough times. Hence why I think that old mouse polling problem might be related at least tangentially. 2nd pic/log is of the more typical behavior I see, where 1 CPU is pegged at 100% at all times but the load simply hops from 1 core to another over and over again, while core #14 stays steady. If I start DCS enough times, I will get an instance where that 100% load simply stays on 1 core instead of being passed from 1 core to the other hot potato style. dcs 1 core locked to 100% usage only while mouse is moving.log more hot potato.log

^ From 104thMoney's post a few posts above mine, this is the same 'hot potato' behavior that happens on some boots for me as well. No idea if it's actually a problem or related to the 100% load on 1 CPU issue or not.

Ditto here with a 5800X3D on Win 11. Most of the time DCS starts fine with no core pegged to 100%, but sometimes it does start with only 1 core stuck at 100%. Using task manager to disallow the DCS process from using that core then re-allowing it seems to fix it and distribute the load properly afterwards. No idea why it only happen on some startups and not others, I can literally start the .exe 10 times in a row and see it 2 times out of 10 with no changes inbetween. On some boots it seems to also hop a load between two cores, spiking one CPU to 100% then switching that load entirely to the other core in a neverending hot potato loop. I wouldn't have noticed except for keeping an eye out for the 100% load problem. I've said before that sometimes mouse movement is causing CPU behavior changes in these instances as well, again only on some boots not others.

I have noticed the same. But on my end, it only happens infrequently when starting DCS. Sometimes it will start with a core pegged to 100% usage, sometimes not. When it's pegged to 100%, it seems to react to mouse movement. While the mouse is moving, that core will drop below 100% usage. The moment the mouse is idle, it pegs to 100% again. Conversely, when the game doesn't start with 1 core pegged at 100%: Moving the mouse keeps a core pegged to 100%. As long as the mouse is moving even slightly, the core is stuck at 100%. The moment the mouse is idle, CPU usage on that core drops again. It may be a different issue, but I would guess it's related to the mouse polling bug that came up previously. The polling rate may have just been reacting badly with whatever underlying bug there was idk. Again this may be irrelevant but I suspect something is off with mouse polling/movement again.

To put it bluntly: MSAA has never worked very well in DCS. The jaggies/shimmer are pretty bad, the problem is far far more noticeable in VR as well. I don't think it's some bug of MSAA not working when it should be, but just that it doesn't work very well and never really has. DLAA is pretty much the only thing that ever worked better for me. It annihilates the shimmer/jaggies, with minor ghosting as a tradeoff. This unfortunately leaves AMD customers mostly left out, at least until ED implement XeSS if they choose to do so. If however this ends up being a bug rather than simply a poor implementation (or one not suited to DCS), then it's been around for as long as I've been playing.