Moezilla

OP's track still showing the same events in the debrief. Do tracks store and replay the previously fired events, or do they fire fresh events based on the stored actions in the .trk?

Since DCS version 2.9.8.1107 both executables should be the same, just on different paths. Maybe something is profiling the executables differently? Some people put the entire DCS installation folder and the folder in Saved Games into the exclusion list for Windows Defender (and any other AV solution) to prevent real-time scanning from eating CPU cycles. Also you could go to Settings -> System -> Display -> Graphics and add both DCS paths to the custom app settings with high performance ON. I see you are also running borderless fullscreen, so it could also be worth trying the Optimisations for windowed games setting in Settings -> System -> Display -> Graphics -> Default graphics settings to see if it helps improve any input lag. With Vsync ON it might be worth trying fullscreen mode in DCS, just as a test, and also using the nvidia CP to experiment with the low-latency mode there. Good luck, getting DCS into a sweet spot can take some tweaking, but it can run well.

Some things you could try: - disable hotplug devices in control settings, there are hotplug events in your log, including from your audio devices. - google how to turn off the power-saving features on your USB ports to prevent windows power management from putting them into low-power mode. - you have parked cores according to the log, you could try unparking them. there are free tools available online like Parkcontrol that can do this. I understand that DCS ran well before this time but it could be that some normal Windows/Dell updates have made some changes that may also have impacted how well DCS runs.

One thing that sticks out is that your motherboard BIOS is 5 years old and there have been 15 full releases, and a beta from less than a month ago, since your installed version. Apart from CPU microcode optimisations, power management improvements, and better device compatibility, there have been 5 security issues patched that may or may not fall inside your use cases. In Windows, it's probably worth doing some standard stuff if you haven't checked on them in a while: Windows Update, install latest AMD chipset drivers, ensure game mode and game bar are disabled.

Tested @tmz's scenic-bench in 2.9.8.1107 and it shows performance has returned to around 2.9.5 levels. I'm capped at 95fps on the carrier in the Hornet, or looking at the F-15 in the screenshot. I waited for, and watched, the scud strike on Khasab, and performance held up well for me. Hopefully it's the same for others. 2.9.8.1107

You are right that if you ask the CPU and GPU to work flat-out to deliver as many frames as possible there can be moments where the CPU gets a spike in demand that causes the GPU to wait, and then the GPU load drops, and FPS follows. It is better in general to cap the FPS at a level where your CPU has a small amount of headroom to absorb the smaller load spikes. There's nothing much that can be done if the mission spawns 10 moving columns right under you or a huge cruise missile strike lands. But something to check since you mentioned you haven't played DCS for 10 months, there is an issue with high-polling rate setting in mouse software. Until the issue is fixed the polling rate should be set to 500Hz or lower. The symptom of the issue is, as you described, looking around causing hitching.

It is a reported issue that I'm told has been fixed in an internal build, so it should make it into the next patch.

I'm not sure. I tried the FSR option when it first released and didn't like the TAA, so went back to MSAA.

If you are using the FSR upscaling option it will force TAA on.

Your autoupdate.log shows that the change to 2.9.5 failed because: 06493.957 ERROR: Can't delete F:\DCS World OpenBeta\Bazar/shaders/metashaders.edce: (32) The process cannot access the file because it is being used by another process. Possibly the DCS.exe process was non-responsive in the background and prevented the 2.9.5 update from happening, or if you have ever run DCS as admin it could result in a permissions issue with certain files. If it's the second option then things get a little more complicated, hopefully it's the first one. Reboot the computer and try .\DCS_updater.exe update 2.9.5.55918@release again, it should be able to use the downloaded files from before if they are still in the _downloads directory so it should be faster.

No, bin-mt is the correct directory. Use Skatezilla's tool to verify that DCS is detected as 2.9.5.55918, with the correct Sim Path and Saved Games Path. Then use the repair button on the left and run a slow repair. Then delete the contents of the Saved Games\DCS\fxo and Saved Games\DCS\metashaders2 directories, and try to launch DCS again. If that fails, then post your dcs.log.

Hold down shift before you right-click and choose Open Command Window here or whatever is closest to that. and do it on the bin folder not bin-mt

Find your DCS install directory (not the one in Saved Games) through explorer and double-click it so you see the API, Bazar, bin, bin-mt directories Right-click on the bin folder and choose Open in Terminal In the window that pops up enter .\DCS_updater.exe update 2.9.5.55918@release I just tested this and it worked. It looks like the text box in Skatezilla's tool doesn't allow non-numeric characters in the custom version box, so it can't give the updater a version string in the form it's expecting.

There's a scud bombardment of Khasab going on and a lot of aircraft starting up and taxiing. Also @Pillowcat just confirming I'm seeing the same thing with the handles during a run of Scenic-bench.miz (5800X3D/32GB RAM/6750XT/Win11 23H2)

So pathfinding or LOS calculation, maybe? Both of which have constantly been changed and worked on since 2.9.0 due to bug reports from the community, and LOS/detection was specifically called out in the 2.9.6 changelog.

Checked all the logs that were posted for specs: tmz - R7-7800X3D 64GB RAM 4090 Win1123H2 Kahless_uk - R7-5700X 64GB RAM 4070Ti Win1123H2 Rene Coulon - i7-8700K 64GB RAM 2080Ti Win1022H2 A Hamburgler - i7-10700K 32GB RAM 3090 Win1123H2 DragonSoulkin - R5-3600XT 64GB RAM 3060 Win1022H2 Semaphore - i9-14900K 64GB RAM 4090 Win1123H2 Sveppur - R7-5800X3D 64GB RAM 4080 Win1123H2 Bounti30 - i9-9900K 32GB RAM 3090 Win1022H2 SignorMagnifico - i7-14700K 96GB RAM 3080Ti Win1123H2 The_Nephilim - i7-12700K 64GB RAM 4070Ti Win1123H2 mobot - R7-5800X3D 32GB RAM 6750XT Win1123H2 Doesn't seem to be any pattern for AMD vs Intel, RAM amount, GPU vendor, or Windows version. There could be something in the dxdiags, if GPU drivers, BIOS, chipset drivers, etc were also looked at, but that's a bit much. It's interesting that Semaphore with a similar spec to yours, was seeing issues, and had a Core Parking warning in their log. So it could come back to a core scheduling issue but I think this whole thread is in a holding pattern until the next patch.

Use Windows Key+Q to bring up the search bar and type: advanced Click View advanced system settings Click Settings... in the Performance section Click Change... in the Virtual Memory section Set your pagefile up similar to the screenshot, with your pagefile on your fast SSD drive, and no other pagefile on other drives.* Click Set each time after you make changes to a drive. Hit OK and reboot to allow the changes to take effect. * The drive needs to maintain 10% (at minimum) free space after this op.

Crash is due to being out of memory. With 16GB RAM you will probably need to adjust your windows pagefile to 49152 min/max on your fastest SSD to play on busy MP servers running heavy missions on maps like Syria. However, be aware that there will still be a lot of swapping to that SSD. If you can increase your RAM to 32 or 64 without spending a lot, it would be a better solution. Also in options drop your preload radius to 60000 or even 30000.

Using @tmz's miz from the first post I ran back-to-back tests in 2.9.5 and 2.9.7 with the same options.lua. The results were as described before with the 2.9.5 running as expected and spending plenty of time at the set fps cap of 95. The 2.9.7 run struggled to get out of single-digit fps. I then ran the test again with RTSS overlay running in order to use presentmon to gather frame metric data. I think the CPUBusy metric points to what many have already suggested, which is that whatever new "logic" was added in 2.9.6/2.9.7 has resulted in missions that were playable becoming completely CPU-bottlenecked and unplayable. 2.9.5 2.9.7

Yes, it does seem strange to show the Chinook lifting these kinds of assets in promotional material, and then seeing the L118's state in the current build.

Yeah, your mission is a saw-tooth pattern between 6-60 FPS for me in SP, pancake, on 2.9.7.59263 (5800X3D/32GB RAM/6750XT) but when I hit Esc, pausing the simulation, the framerate immediately jumps to my cap of 95 and is flat. I opened the miz in the editor and, apart from the carrier group, there are no moving units that I could see, so it kinda points the finger at the target detection/LOS calculations that saw changes in 2.9.6, rather than route path-finding issues: The log portion for the mission run has several ANTIFREEZE ENABLED lines and one SAME MODEL TIME entry: null 2024-08-28 08:46:27.027 DEBUG LuaGUI (Main): ----onSimulationResume--- 2024-08-28 08:46:27.692 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:46:28.863 WARNING LOG (2964): 1 duplicate message(s) skipped. 2024-08-28 08:46:28.863 WARNING BACKENDCOMMON (15172): Need to reprocess [DDS] image '/textures/Deck_Normal.dds'. Reason: Conversion requires - expanded pixel size, setting alpha to known value. Source is an 8:8:8 (24bpp) format 2024-08-28 08:46:28.964 ERROR_ONCE DX11BACKEND (15172): texture 'wet_map_map' not found. Asked from '' 2024-08-28 08:46:29.446 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:46:29.902 ERROR_ONCE DX11BACKEND (7732): texture 'carrier_miniboss_roughmet' not found. Asked from '' 2024-08-28 08:46:30.763 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:46:34.469 WARNING LOG (2964): 2 duplicate message(s) skipped. 2024-08-28 08:46:34.469 WARNING BACKENDCOMMON (15172): Need to reprocess [DDS] image '/textures/Deck_Normal.dds'. Reason: Conversion requires - expanded pixel size, setting alpha to known value. Source is an 8:8:8 (24bpp) format 2024-08-28 08:46:34.938 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:46:34.942 WARNING WORLD (Main): ModelTimeQuantizer: SAME MODEL TIME 2024-08-28 08:46:36.488 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:47:41.096 WARNING LOG (2964): 20 duplicate message(s) skipped. 2024-08-28 08:47:41.096 INFO EDTERRAINGRAPHICS41 (16476): SHM_TERRAIN_SHADOWMAP 2024-08-28 08:47:41.096 INFO EDTERRAINGRAPHICS41 (16476): SHM_TERRAIN_SHADOWMAP 2024-08-28 08:48:10.712 INFO EDTERRAINGRAPHICS41 (16476): surface5 gc() LOD 0 21 squares 2024-08-28 08:48:10.712 INFO EDTERRAINGRAPHICS41 (16476): surface5 gc() LOD 1 38 squares 2024-08-28 08:48:10.712 INFO EDTERRAINGRAPHICS41 (16476): surface5 gc() LOD 2 37 squares 2024-08-28 08:48:10.712 INFO EDTERRAINGRAPHICS41 (16476): surface5 gc() LOD 3 73 squares 2024-08-28 08:48:10.712 INFO EDTERRAINGRAPHICS41 (16476): surface5 gc() 1.180100 ms 2024-08-28 08:48:12.100 INFO EDTERRAINGRAPHICS41 (16476): SHM_TERRAIN_SHADOWMAP 2024-08-28 08:48:12.100 INFO EDTERRAINGRAPHICS41 (16476): SHM_TERRAIN_SHADOWMAP 2024-08-28 08:48:12.311 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2024-08-28 08:48:20.181 DEBUG LuaGUI (Main): ----onSimulationPause--- 2024-08-28 08:48:26.854 INFO Dispatcher (Main): Stop 2024-08-28 08:48:27.110 DEBUG LuaGUI (Main): ----onSimulationStop--- false nil nil 2024-08-28 08:48:27.110 DEBUG LuaGUI (Main): ----DCS.isMultiplayer()--- false 2024-08-28 08:48:27.519 INFO TERRAIN (Main): lSystem::CleanScenes()

Crash is from running out of memory. Dxdiag shows several of this type of crash in DCS. One thing to try as a test is to drop visibility range to High, terrain textures to low/min, and your preload to 60000.

Server is single-threaded only, so you will see it load up one core. However, in the latest patches it seems that something such as pathfinding, or unit detection seems to adding more load than before 2.9.6. So missions that ran with medium load in 2.9.5 are now maxing out the core the server is running on.

The mouse polling issue has been here since 2.9.6, iirc. Anything over 500hz can cause the effect you are seeing. Check your mouse software for polling rate (not dpi) and drop it to 500hz or lower and see if it makes the mouse spikes go away.

That one is your decision obvs, but one more data point is that I took your SP_Testing2.trk, renamed it to .miz, and ran it on my machine which does have SRS but does not have Tacview, LotAtc, or pw-dev, and I get smooth fps when I go to F2 view and move the camera around the Hornet.