SFJackBauer

Check the dtc-settings.json file inside your Documents\DCS-DTC folder. It will store whatever path it thinks DCS is installed in that file.

Version 7.2.0 https://github.com/the-paid-actor/dcs-dtc/releases/tag/7.2.0 See the README for install and usage instructions: https://github.com/the-paid-actor/dcs-dtc/blob/main/README.md Please report any issues on DTC Discord - https://discord.gg/saCACg99EZ by creating a post in the Bugs section. Features Apache added. Features included are: Waypoints, hazards, control measures, targets and threats input Routes TSD settings The in-cockpit upload button is the Defog button for both Pilot and CPG (hold it for > 1 second) [F-15E] Allow editing of Bullseye BE1 coordinates [F-15E] Added TGP laser code setting Bugfixes [F-15E] Fix input of first steerpoint as a target point [F18] Right click + Decrement sequences now decrement all the way to zero

Yes

There is an option now. Plans, yes.

Update - out were the macrostutters, in were the microstutters, which were again completely gone after I restarted the PC. So disabling E-cores is not the solution, but it definitely changed something for DCS. But I can say definitely the microstutters were as annoying and noticeable as the large ones.

I feel the same. I don't see only one core being used - there are always multiple cores. In my case, cores 2 and 3 are the "fastest" ones out of factory (as denoted by the star next to them in the Intel Extreme Tuning Utility), but I tried playing with affinity in DCS and it always end up worse or at least the same as before. BUT one thing I am testing right now is disabling all E-cores in BIOS, and it seems promising. System uptime is 2 days 15 hours and I have a relatively flat FPS line in DCS. There are still stutters here and there, but nothing like I presented early in that video. Still needs more time testing, in different maps and situations, but this is the first change that resulted in some different outcome so far.

I will admit that what I said about the clock is pure speculation. Could be anything really. Lets just go back to the raw facts I observe: - DCS MT freezes are non-existent after a full computer restart - They increase the longer the computer is running, to a point where it becomes visible, annoying and even game-breaking. - Restarting DCS MT only does not solve the problem. - At the same time DCS MT present freezes, if I fire up DCS ST it is buttery smooth. - Upon a computer restart, they are gone again and the cycle repeats. - I don't observe any anomaly in my system which shows such similar behavior, in any other game or app. Nothing on my system benefits from restarting it, except DCS MT. Given that DCS ST does not present the same issue, by appling Occam's razor I can only attribute it to the multi-threaded implementation in DCS MT. God knows what exactly causes it, again only the people with the source code would be able to tell, but in my case it is clearly something tied to the system uptime. Could be a specific Windows syscall that performs slower the longer the PC is running, but again, only DCS MT uses it?

For the record, other things I tried beyond what I already mentioned: - DCS is a fresh 2.9 install about a month old (including a new Saved Games folder) - Reinstalled graphics driver and reset all settings (both in DCS and NVIDIA CP - right now my NVIDIA Control Panel is 100% default settings, global and DCS-specific) - DCS entire folder is under Windows Defender exclusion - Restart video driver while DCS has the stutters (Win+Ctrl+Shift+B) - Disable recording of tracks in DCS - Unplugged all my USB devices except for keyb and mouse

Who the hell said I am not using my PC during these hours???? Even if I didn't, I pay for my electricity bills. They were given by ED personnel directly to me, otherwise I would have the freezing stutters 100% of the time in MT. Glad you don't need them though, but I don't see how that helps me in any way. That's partly internet lore. Windows run fine for days, weeks, months if you don't fill your computer with crap (until you have restart it forcibly due to windows updates...). No no. During the time the PC is on, I can play multiple DCS sessions (by session I mean, start DCS, fly for an hour or 2, close it). What I observe watching the Rctrl+Pause window is that these spikes in frame time grow over time - they start small and unnoticeable but then at some point becomes so large you can see the screen freezing without even watching the graph. @Pillowcat I tried now the powershell command to make MD5 hashes out of the Caucasus files, no change. It took 36 seconds to finish. But I will look into other ways of flushing windows disk read cache to see if they make any difference. Are your freezings manifesting like it appeared on my video? Is there a thread where you reported it or a video? If you are on ED Discord, we can go on VoiceChat there and compare our screens and settings. My Discord handle is the_paid_actor.

Thank you, this is something I haven't thought about. Will test it when it happens again. Why is this relevant? Its not a solution to the problem. Yes, I am not desperate for a solution because I have a workaround, but DCS is still misbehaving there for some reason as it can be seen on the video. The reasons for which I leave my PC running for a long time are irrelevant to all of this. Also, I already had to modify my system (disabling virtualization and hyperthreading) to get DCS to run properly in MT, and by now seeing this behavior, if we can get to the root cause, I may be able to get back to a normal config. If I took out a hardware feature of your system that you invested $$$ on it to make it run properly, would you be content and satisfied?

Thank you, I appreciate your response, you seem to be a thoughtful person. Yes I understand and agree with all you wrote there. And I am happy for the people who don't have any issues, but I ask you to put yourself on the position of the person that have tried all the solutions out there and nothing worked. 100%. But here is the thing - they can reproduce the problem in my machine with 100% certainty. In my work as a professional developer, I would never just cross my arms for a customer and say "well, I can't reproduce on my machine, so you are out of luck"... I would go out of my way to find and fix the problem, because they are paying customers. They could offer a debug build with extra logs and profiling. But am I willing to spend my limited time with DCS debugging that deeply? I've been flying DCS since the day it launched 15 years ago. I've seen things... What I don't readily accept is blame the user immediately without reasons. In my case, I already changed my system substantially to avoid stutters (by turning off virtualization) which should not have been needed in a normal situation. And frustrates me to see that the community accepts these "workarounds" as final.

There is nothing wrong. Don't read into what I wrote anything more than what I wrote. I didn't offend anybody, so don't try to act like I did. I just stated that I know the basics, already tried the basics and thats it. So this is one more post that contributes nothing to the subject in question, just deflects away from it. What is also frustrating is that people don't read what I wrote before replying to it. But thats the nature of the beast. This is what frustrates me. Instead of fighting the problem, you are fighting me in defense of DCS.

Tried core parking. No difference. Hot plug is already disabled. Made no difference anyway. Thermals are all good (why would termals make a difference after a reboot anyway) Power management is good. I can run any other game I listed before for hours and I have no issues. This PC I built last year, been running without hitches, bluescreens etc. Page file is not an issue, its on a SSD, set to auto and my RAM never maxes out in Caucasus in the F-16 in a free flight mission after a freshly booted DCS session. And I see no abnormal disk activity during these freezes that are on video. Tried disabling everything in Export.lua, didn't made a difference. Counterpoint to all of this is that after a restart DCS runs smoothly. With Export.lua. With the pagefile as it is. Without messing with core parking. All the cookie-cutter answers here are targeted at people that have not tested all that stuff before, and I would not open a thread before that. So to run DCS well I have to bust out every debugging tool known in the face of the earth? I don't know why the community accepts these things. Honestly this all feels like a waste of time. I'll probably open a ticket directly with ED and go from there. Or not... I just have to reboot every 12 hours and be conformed with that as a solution it seems. I bet next thing people will ask me is to delete fxo and metashader folders.

Ok so here are two videos for the non-believers of this thread: First one I took today after my computer was running for 34 hours according to Task Manager. I closed everything on the PC, including Steam, TrackIR, GHub, Discord, Voicemeeter, even stopped Windows Audio services (which is why the first video doesn't have sound). I booted up DCS and went straight into F-16 ready on ramp, and this is what I see: Second video, this is what I see after restarting my PC. Didn't touched anything else, it autostarts steam, GHub and Voicemeeter but I left all these usual apps running in the background (as I usually do) and its smooth as butter. dcs log first video.logdcs log second video.log Attached are DCS logs for both videos as well. So what @Hiob is this nonsensical?

Then you are as surprised as me for this behavior. Let me explain again: - Lets say I just turn on my computer now. I start DCS, go into any single player/free flight mission. It runs buttery smooth, no hiccups other than the usual while loading the terrain around you. - I fly DCS for an hour, I close it. I keep working on other stuff, go to sleep, leave my computer running overnight etc. Next day, I boot DCS, same mission, it gives small freezes/stuttering every couple of seconds, like other people have reported. - I restart my PC. Boot DCS again, it runs smooth again. In the meantime, I can run any of the other applications I listed before, and they do not present any performance issues out of the ordinary. Even if my PC has been running for multiple days. Also this only manifests in MT. I started using MT because of 2.9, before I was running ST only. Immediately I had issues with stuttering, so ED personell on Discord asked me to turn off virtualization in BIOS (which I did, even though I need virtualization for other tasks, and had it on since... ever). This solved the stuttering happening immediately on running DCS, but now what I see is that it comes back as I described... and I have no clue why.

I can handle myself in the applications I write. Do you mean I should be debugging DCS with gdb? No, that is for the devs. I am here as a customer to report what I am seeing, thats all. It has relevance. Bytes are bytes in the end. However people so far have either not read what I wrote or offered surface-level advice, which is welcome but ones that I have already tried. And saying "you should restart your PC every 12 hours" is not useful advice in my case, nor in any case.

Who said its Windows thats changing its behavior? Its DCS that is doing so...

Then maybe you are not the target of this thread. Many have this issue and nobody has able to figure out why it happens so far. Restarting DCS does not fix it - obviously that is one of the first things I've ever tried. As I said in the OP, after a windows reboot DCS runs fine for hours. Only after the computer has been on for a while DCS starts showing freezes. ALSO this behavior does not show up in any other application, including heavy games like MSFS, Cyberpunk, Squad, ARMA3, Tarkov etc etc. Thats... exactly what I wrote in the OP. Thank you for your advice. I run Windows for 20+ years as a software developer. I don't have to "restart for best performance" once in a while for anything else other than DCS. Granted, I don't install crap as most people do, and keep the number of apps and background running services to a minimal. Trust me, I've checked all the basics. My gut feeling is that is something related to how DCS uses the computer clock. Timing is very important on graphically intensive apps like DCS - when I say clock, I mean APIs like https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter. But who knows what it may be, only the devs can help pinpoint it. I also forgot to mention that when the freezes start, I see more and more these messages in DCS log: 2023-12-26 12:45:52.005 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED

This is more of a dev bugfix request, but you know the box around the selected field in the Smart Weapons page? Would it be possible to expose it in the list_indication() function which field it is highlighting? This is the box I am referring to: Many thanks!

Do you run your PC for long? I leave my PC on for extended periods of time due to reasons, and I found that if I run DCS MT after my computer has been on for a long time, it gains that every-5-second freeze. However after I restart my PC, it runs buttery smooth, until my computer hits a certain number of hours on (I haven't spend time figuring out how long), and then the freezes come back again. The effect is extremely striking for me as it is the only thing that clears the stutters, and it never fails. I figure that the people who don't have those freezes may just turn on their PCs to play DCS and shut it down afterwards. Windows 11 here, 13900k 3080ti 64GB DDR4 3200. I have turned off hyperthreading and virtualization in BIOS.

Hornet radaralt.trk Track attached. You can type in the numbers but it still shows 0, even after you takeoff. Only after you takeoff you can input numbers that then are accepted by the system.

Bumping this up as still happens in latest OB

In NAV mode, you can select any FCR mode (CRM, ACM, GMT, GM, SEA) and CRM submodes (RWS, TWS, VSR) and if you leave NAV and go back, it keeps the same mode and submode you had selected. In AA or MSL Override modes, the same happens for both the FCR mode (you can select only CRM or ACM) and submodes - if you leave and go back to AA or MSL Override, it retains the mode you had selected. The same does not happen in AG mode - it always reset back to GM, even though you had GMT or SEA selected. This doesn't make sense from the overall ergonomics of the jet. Note that it always resets to AGR (air-ground ranging) when a visual submode of munitions is selected, and this is correct. However if a pre-planned submode of munitions is selected, it should retain whatever ground mapping mode it had before (either GM, GMT or SEA). Track attached. F16 does not persist AG radar mode.trk

Thanks for the clarification! This is great and a step in the right direction.

Do you acknowledge the inconsistency presented by Killshot post and tracks above? Why is it engaging GBU-38s, which is not a "large bomb"? Furthermore, why is it engaging GBU-38 but not Mk82s, which are literally identical in size?