Moezilla

From a preliminary test with OP's test miz, it looks like Ugra has fixed this issue (possibly the patch note about the collision model hints at the real culprit).

Line 3 of your dcs.log: 2025-07-16 18:28:20.635 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores) The DCS UI elements can trigger either the core-parking or other efficiency features in Windows. It's recommended to disable core parking. There are numerous ways but, personally, I used a free utililty called Parkcontrol and it was a simple, one-time (so far) process.

Your export.lua is busy but I've seen others running similar setups. You could check if the MP servers you play on regularly have server-side tacviews. Some make them available for download.

From your log it's likely to be Tacview dumping a lot of data on busy servers with lots of air and ground activity. Try one of the previously stuttery servers with it disabled from your side. You could check Saved Games\DCS\Scripts\Hooks\ and move/delete anything you don't need (I didn't see a reference to the OH-6 gunner script in the log - it's a known stutter cause in MP - but you did have a script error from vpcDuelSpawnGUI.lua) Also you could open Saved Games\DCS\Scripts\Export.lua in a text editor and make sure that only expected items are in there.

Integrated GPU is being used (Intel UHD 770) - I'm guessing based on a quick search for the Corsair i7300 PC that you should have a 30 series Nvidia card in there. I'd re-install the latest Nvidia drivers and then check in the BIOS that the discrete GPU (dGPU) is the primary display device.

If you check out Quaggles' datamine, the commit for 2.9.17.11733 shows significant increases in mass, expl_mass, and piercing_mass for the Mk81-84 bombs. How exactly these numbers are used by DCS to calculate explosions is not generally known, but it would be a reasonably logical assumption to make that bigger number = bigger boom. Here's an example for the Mk83: [2.9.16.10973] _G["warheads"]["Mk_83"] = { caliber = 356, concrete_factors = { 1, 1, 1 }, concrete_obj_factor = 0, cumulative_factor = 0, cumulative_thickness = 0, default_fuze_delay = 0, expl_mass = 160, mass = 160, obj_factors = { 1, 1 }, other_factors = { 1, 1, 1 }, piercing_mass = 32 } [2.9.17.11733] _G["warheads"]["Mk_83"] = { caliber = 356, concrete_factors = { 1.35, 1.35, 0.135 }, concrete_obj_factor = 1.35, cumulative_factor = 0, cumulative_thickness = 0, expl_mass = 201.9, length = 1.956, mass = 446.8, obj_factors = { 1.35, 1.35 }, other_factors = { 1.35, 1.35, 1.35 }, piercing_mass = 89.36 } The new numbers for 2.9.17.11733 match the stated specs on the wiki page for the Mk83 of 447Kg mass and 202Kg of filling. Sources: https://github.com/Quaggles/dcs-lua-datamine/ https://en.wikipedia.org/wiki/Mark_83_bomb

[Player1] C:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff9e32321db 00:00000000 ... 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player2] C:\Program Files\Eagle Dynamics\DCS World\bin-mt\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff8d83b21db 00:00000000 ... 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE =================================================================================================== [Player1] C:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ff91d215522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player2] C:\Program Files\Eagle Dynamics\DCS World\bin-mt\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ffd4ade5522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player3] E:\DCS World\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ff9760e5522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE Update: I have collected crash details for 3 different players who are experiencing the Effects.dll (2 out of 3 players) and edCore.dll crashes (all 3 players). The crash traces appear to have the same signature for all players. Below are the specs of the players and the settings from the graphics config reported in their logs that are shared across all three players. Hopefully the team have had enough reports through the crash report tool to have begun to find the source of these crashes. Specs: [Player1] AMD Ryzen 7 9800X3D Nvidia 3080 (572.83) 64GB RAM Windows 11 [Player2] AMD Ryzen 7 5700X Nvidia 3070 (576.40) 64GB RAM Windows 11 [Player3] AMD Ryzen 5 7600 Nvidia 3060 (576.28) 32GB RAM Windows 10 Graphics settings in common across all three players: { ['lights'] = 2; ['canopyReflections'] = 1; ['useDeferredShading'] = 1; ['textures'] = 2; ['cockpitGI'] = 1; ['terrainTextures'] = 'max'; ['shadows'] = 4; ['sceneryDetailsFactor'] = 1; ['effects'] = 3; };

Issue still persists with OP's test mission in DCS 2.9.17.11733. Has there been any progress on the investigation into this issue?

Hi @BIGNEWY, Could you check if the database that is fed by the DCS crash reporting tool has picked up these two crashes since the 2.9.17.117333 (Corsair+Essex+MarianasWW2) update? If it has, is there progress on finding a cause and fix? # -------------- 20250623-053429 -------------- DCS/2.9.17.11733 (x86_64; MT; Windows NT 10.0.26100) C:\Program Files\Eagle Dynamics\DCS World\bin\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff8d83b21db 00:00000000 SymInit: Symbol-SearchPath: 'C:\Program Files\Eagle Dynamics\DCS World\bin;', symOptions: 532, UserName: 'user' OS-Version: 10.0.26100 () 0x100-0x1 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE 0x0000000000168fbf (Visualizer): smSceneManager::DestroySceneManager + 0x1136F 0x000000000016f79b (Visualizer): smSceneManager::regLua + 0x5DDB 0x000000000015444c (Visualizer): smCamera_Implement::getClipRegion + 0x1C17C 0x000000000013e4cc (Visualizer): smCamera_Implement::getClipRegion + 0x61FC 0x0000000000158ce2 (Visualizer): smSceneManager::DestroySceneManager + 0x1092 0x00000000000337b1 (edCore): ed::thread::_get_current_thread_id + 0x71 0x00000000000037b0 (ucrtbase): wcsrchr + 0x150 0x000000000002e8d7 (KERNEL32): BaseThreadInitThunk + 0x17 # -------------- 20250622-022701 -------------- DCS/2.9.17.11733 (x86_64; MT; Windows NT 10.0.26100) C:\Program Files\Eagle Dynamics\DCS World\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ffd4ade5522 00:00000000 SymInit: Symbol-SearchPath: 'C:\Program Files\Eagle Dynamics\DCS World\bin;', symOptions: 532, UserName: 'user' OS-Version: 10.0.26100 () 0x100-0x1 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE 0x0000000000168fbf (Visualizer): smSceneManager::DestroySceneManager + 0x1136F 0x000000000016f79b (Visualizer): smSceneManager::regLua + 0x5DDB 0x000000000015444c (Visualizer): smCamera_Implement::getClipRegion + 0x1C17C 0x000000000013e4cc (Visualizer): smCamera_Implement::getClipRegion + 0x61FC 0x0000000000158ce2 (Visualizer): smSceneManager::DestroySceneManager + 0x1092 0x00000000000337b1 (edCore): ed::thread::_get_current_thread_id + 0x71 0x00000000000037b0 (ucrtbase): wcsrchr + 0x150 0x000000000002e8d7 (KERNEL32): BaseThreadInitThunk + 0x17

According to the log from June 14, you have parked cores and are running Windows 10. The specs of your CPU indicate 6 P-Cores and 8 E-cores. I would guess that your freezes relate to work being passed to E-cores by the Windows 10 core scheduler, which is known to do this with hybrid CPUs. There are several ways to "unpark" your cores, but I used a free utility called ParkControl to turn off core parking for the power plan in use. If an upgrade to Windows 11 is possible, this will also help with general issues with core scheduling. Good luck.

ED are aware and working on it

@BIGNEWY has the investigation come up with any findings on this issue yet?

The error message seems to refer to an issue relating to temporary files. If you have plenty of space on your drive(s) then another possible cause would be a permissions issue. Is it possible that you installed DCS, or parts of it, as administrator and are running it as a regular user now? This can lead to some weird behaviours.

@BIGNEWY has there been any update on the internal investigation into this issue?

@Oberst Struppi there may be an issue with AI pathfinding on the GermanyCW map.

@Flappie I did a quick test with the miz files I had attached above in the thread and the issue I had seen seems to be fixed. Thanks.

With Optiscaler you can re-route DLSS calls to FSR 2 or 3 on non-nvidia GPUs (I have an AMD card) even in DX11. I haven't tested it in every scenario but it works as a proof-of-concept.

Thanks for taking the time to nail down the conditions to reproduce the dot limit. I hope ED will take steps in the very near future to address this issue, which has been raised before, but now, thanks to @MoleUK, has tracks and a solid set of conditions to show it in action.

Yeah, the OF412 is too weak, and too fast. The L118, as a howitzer, needs a dual purpose direct/indirect round, so currently, the 122mm ammunition from the 2S1 is probably the best compromise, even though it's slightly too powerful. Ideally, ED would add the UK L31A1 105mm shell, and the US M1 105mm to their arsenal, so that the ranks of NATO artillery pieces could be filled out to cover the Cold War period. M101, M102 and M119 would bridge the gap from WW2-early 2010s for the US and other operators.

Just noticed that I had client tracks turned off. Here's another run with the same miz. dcs._client.log dcs.log server-20241008-130454.trk swg_caucasus_dynspawntest-20241008-130625.trk

@Flappie @BIGNEWY Here's the mission, logs, and tracks from both client, and dedicated server. This track features the Seawise Giant tanker, but it also affects carriers and the Oil Rig with helipad. Using these objects as dynamic spawns results in the parking spot not releasing properly if the aircraft is destroyed, preventing further spawns until the mission is restarted. dcs_client.log dcs_server.log server-20241008-124632.trk swg_caucasus_dynspawntest-20241008-124732.trk swg_caucasus_dynspawntest.miz

You are right. Sorry for getting your hopes up. In my first test I took off with the Huey and landed on land, then it allowed me to respawn on the SWG. But this time I threw the Huey in the sea and it would not let me respawn. I'll make a track and grab a log.

@Chesster @shaji I checked the SWG and CVN-71 in 2.9.8.1214 and they seem to be working as expected now. Can you confirm? @Flappie the ARA Veinticinco de Mayo seems to still be showing this bug when placed as a dynamic spawn. You can spawn 3 times in a dedicated server (4 times in a local server for some reason) and then you get a "YOUR FLIGHT IS DELAYED TO START, PLEASE WAIT" message in the top right of the screen, after that if you try to select role again the spawn/parking slots message comes up, then you can no longer spawn there until mission restart. Test mission attached. vdm_caucasus_dynspawntest.miz

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.