EbonySeraphim

This was my issue. My binding was on a physical switch that held the button down the entire time, so I guess that also allowed the throttle position being zero to pull things back from idle in game despite the IDLE button not being pressed. I tested/verified last night but forgot to update until now.

EDIT: @Ramsay what you said makes me wonder and want to test something. My finger lift bindings are non-momentary switches. Maybe I'm experiencing these problems because the finger lift binding for that engine is being held down the entire time. I'll try pressing and releasing and maybe I get different behavior. I was probably being misleading, and allow me to be a little nit picky -- it is during startup that I'm having problems. After raising the finger lifts, when I need push into IDLE the following happens with my CM3 setup: The throttle axes at rest in the STOP detent is holding down on the "STOP" DCS binding; DCS sees 0% (technically below) on the throttle axes I start moving the physical throttle into "IDLE", which will settle the DCS axes at 0 Along the way, the physical axes moves to a position that comes off of the STOP button binding and activates the IDLE button binding Along the way, the throttle axes DCS sees will register above throttle = 0 as I push past the detent (probably over 3% but I haven't checked) because of the shape of the detent The IDLE button binding will turn off BEFORE I've pushed past the detent When I'm fully past the detent and pull back fully on the throttle, DCS sees throttle = 0 again Given this setup, during startup when asked to push into IDLE, when I physically pull back on the CM3 throttle such that throttle = 0 again, in game it disables the IDLE setting and goes back into STOP. I can see this happening in the in-game cockpit. I don't know if there's scripting around the 3% such that because I'm pushing past it, and then dipping below it during start up, this is happening. I'll double check but I think this (engine shutdown) does not happen mid flight if I pick a free flight mission. Maybe these words aren't clear and I have to post a video. If not for my monitor/MFD setup making the controls indicator difficult to grab, I could trivially do this immediately. I'll give this a day or two for suggestions. Part of the understanding is seeing the physical action; I'm quite happy with how I have the CM3 setup for all modules, and what I'm doing seems extremely straight forward and should be reasonably expected and supported.

I'm using a Vipril CM3 with a stop-idle detent that presses buttons as I move those axes up. Once I've moved past those "buttons", and full push down, that position is what DCS sees as "0" for the throttle axes in game. This setup works great for all fixed wing aircraft except the F-15E because (I suspect) of the special settings "Throttle cutoff detent" option. The lowest value I can set it is 3, and I cannot turn it off. I'm guessing this means that the module will see a throttle value lower than 3% and registers it as the throttle lever being set to idle, which is absolutely not what I want. Is there any way to disable this so I can pull full back on my detent without shutting the engines off? I'm absolutely sure this isn't actualy the IDLE or STOP button/binding being triggered because the detent is firm, and it's been well tested and long used for multiple modules. It's never shut down the A-10C or F/A-18.

If it supports DLSS 3.0 then it will help in terms of being able to AI generate a frame inbetween two actually simulated and rendered frames. So if a CPU bound scenario is a drop to 60fps (I know, pretty beefy PC already) you'll still have a visual experience closer to 100fps. But DLSS 1.0/2.0 is resolution upscaling. You'll be able to uptick your graphics settings and keep the same average performance. Whatever your CPU bound FPS was is still going to be about the same -- although likely DCS World 2.9 will run a bit differently in other ways as well.

Uninstalling VIACOM Pro, deleting the App folder within the VoiceAttack plugins folder in program files, plus removing the LUA import line in Saved Games / DCS.OpenBeta / Scripts / Export.lua and deleting the VIACOMPro scripts subfolder is all I did and everything is fine now.

Will try this. I thought it happened before I ever installed VIACOM Pro but in hindsight, those were when I didn't quite understand the right comms bindings. But since VIACOM Pro, it's been well out of whack.

This is actually not a new bug, but the comms menu pops up randomly for me in both MP and SP, and all modules without pressing anything. It seems to be, or might be correlated with mission scripting because it seems to happen more often when overlay text becomes active, either in a training mission or MP picture report. I do not have Easy Radio or the assist for radio activated in the special options menu, and I know what my actual radio bindinds are so that doesn't seem to be the problem. Even further, it happens even if I'm not touching anything. This isn't exactly a bug report, but I'm thinking this is a known and solved problem so I'm posting to see if there's an an easy and clear resolution before I deep dive. The frequency that the menu pops up for no reason is starting to get annoying. Normal bindinds are fine, but if I try to access F10 menu, or am trying to text chat in an MP server, having that menu up changes things.

I'm seeing this too. I've seen it before but previous times it was resolved by a restart of the DCS application. This time around it's persisting across many restarts. If it's related, I also just purchased the Sinai map and was downloading it right as I was trying to login too.

When I fly this mission, during the time you're forced to listen to the narration in active pause, the carrier is not actually held still anymore. The carrier is slowly rotating in place. Easy to notice as by the time you actually fly the gates, the carrier isn't even close to the proper orientation. I replayed it again to look even closer and could see it rotate with my naked eye right at the start of the mission. This bug was introduced most likely with the most recent patch because I've played this mission 4 times a week ago (5/14) with no issue. Today (5/22) I have an issue. Attaching two track files that had the issue. Lesson 10-Case I Carrier Landing.miz_22052023_01-11.trk Lesson 10-Case I Carrier Landing.miz_22052023_01-14.trk

The stuttering may not be stuttering in ST because your FPS is considerably lower to begin with. I didn't notice stuttering until MT made the performance drop to my 1% lows massive. But as I did a ton of profiling, the performance issue was very much there in ST as well. Debugging performance stuttering is a difficult problem to solve, even for an actual software engineer. You might get lucky trying random things, and have a fix in a few days. Or take a steady and process of elimination path and have a confident identification of the problem with a solution eventually.

The ABRIS moving map scale feels kind of useless. The paraphrase of the training mission is that the scale is <centimeters>:<scale value> so "1:2.00KM" is 1cm on screen is 2.00KM in real life. At least the training mission subtitle is aware and also says "keep in mind that the ABRIS screen is 16cm wide." Unfortunately, nothing else on that screen helps you reference that size nicely along the width, and even worse the screen is clearly taller than it is wide so how to reference vertical distances with some accuracy is further lost. How do you properly read out distance on the AMMS in DCS? I've flown this module for over a long time now and am just realizing this because I'd like to fly more serious multiplayer servers and given the substantially reduced INS performance (errors) reading this map accurate versus reality is more important. I've gotten by this far because lasing gives precise distance.

I'm not an expert in VR matters, but how do you remove the idea that the CPU is the culprit? DCS stutters can be a lot; I found serious stutters coming from both DCS-BIOS and DCS-ExportScripts -- I had to turn those off. VoiceAttack, SRS, TacView, VPCLinkTool, and DCS ScratchPad were all fine. I know you describe it as "terrain stutters" but honestly, the stuttering I've seen in general with this game have generally been most observable on terrain to the naked eye but is most certainly the entire game. Without stats from a profiling tool like MSI Afterburner, you don't know what you have.

I can understand complaints about the flight model with respect to the flight performance and behavior in certain conditions, but there's a lot of "I can't control it" issues which is not really the flight model. I don't know what there is to talk about beyond a) calibrate your device however the manufacturer is says it should and b) check that DCS sees the full range of movement. Only after those two are confirmed should you then move to consider a) hardware adjustments or b) software adjustments. Hardware means, maybe get another device, maybe change up spring tension, clutch/dampener friction, or use an extension. Software adjustments involves deadzones, curves, and even saturation. EDIT: forgot to add one thing. Make sure you don't have any unwanted devices influencing the cyclic and collective axes. The latest patch seemed to change in nature slightly and I had plugged in devices that would be fine if untouched. Now, they seem to impact the axes behavior of the device I am using even if they're unmoving and centered (or in any position). I haven't tested in detail but the way it messes things up isn't obvious -- as in, it's not a clear override sticking the axis to the position of the unused device. So if you notice worse behavior with the latest patch, recheck that you only have one device with a binding for those main axes. If none of that makes the AH-64D flyable for you, then it's purely a "git gud" issue. Anyone who uses the term "squirrely" to describe the AH-64D is unfortunately telling on themselves. Hovering a helicopter is constant corrections -- a motor skill. If you call it squirrely, that means you're overcorrecting and/or not reacting fast enough when the heli is clearly accelerating in a direction so it ends up going all over the place. The thing about motor skills is that you can listen to advice all day, every day, about how to do it better and you won't have a eureka moment where things just click and it's easier. It takes pratice. Hover and fly for 15-30 minutes in the morning, and 15-30 minutes before sleep and you'll notice a huge difference over weeks. What takes your full attention to accomplish in week 1, by the end of week 2 you'll be able to do with 50% effort, then 25%, and eventually it'll slip into near second nature. What you're able to do with the extra focus is observe and deal with other factors: weather and atmospheric conditions, threat conditions, and overall operate some avionics while flying.

This is somewhat of a question too because I don't even know if these are functional in DCS other than the visual and audio cockpit behavior. If these switches don't do anything them I'm fine not binding them.

Also confirmed working for me. Now my UI is back to sensible. Only thing I need to be able to do is move (or choose placement of) the controls indicator.

Do you mind sharing numbers of your 1% and .1% lows or a screenshot of your performance within DCS (Right CTRL + Pause)? The 'lag spikes' you show in the OP don't look like anything out of the ordinary.

General suggestion to ED: DCS should log a warning when scripts cause very poor performance. Not every time it happens as it could happen every frame, but once every 5 seconds or so when the same script offends more than one time. More than one because external system stutter could randomly catch any script perhaps, but twice on the same script is likely no longer a coincidence. I just solved my stuttering issues which were giving me 1% and .1% lows of 16/17fps on an MP server with a 90 fps average; and even free flight SP was giving me maybe 110 fps average, but 30-40fps on 1% and .1% lows. The stutters were happening both every 2/3rds of a second, and bigger ones once every 2 seconds or so consistently. My solution was disabling DCS-Export and DCS-BIOS. I dove deep into profiling DCS on my system while trying many of the common suggestions and nothing had any impact on performance. I spent a couple of days on the task so some advice: Use MSI Afterburner (you probably already are if you know you have microstutters) so you can actually see what changes matter and which dont Test the same map, mission (or one MP one SP) with the same module. Different DCS modules have different baseline performance even if they're sitting on the same airfield I only delete the fxo/metashaders folders if graphics drivers or options (in game or driver/DirectX control panel) are changed; spare yourself the shader compile time. Most of those dealing with this have end systems we know should average 60fps+ on quite high settings. Despite this, set your graphics options to low, minimally texture quality visible range, and preload radius, and verify if you still have the stutters. If you do, set your graphics options back to what they should be because that isn't your problem. RAM speed isn't going to eliminate stuttering assuming the dips are super super low, well below what you know your system usually does. I have PC32000 DDR4 RAM (not the fastest), turning XMP profile off/on made a substantial difference but given this is a 2x speed swing and it didn't half my 1% and .1% lows, it shouldn't have been my focus. My 1% and .1% lows went from 17-ish to 12 on an MP server. With 5950X and 64GB of RAM, no background service or other running program made a difference. Even ones that I personally can see take up a little too much (ElGato Audio Service or something). I could have many Chrome tabs open, many with YouTube, and even playing a YouTube video during gameplay. This made no difference. DCS full repair, with removing extra files found did nothing Disabling hot pluggable devices in DCS did nothing for me Disabling Microsoft Root Device Enumerator (and a reboot) did nothing Disabling fTPM in UEFI (Trusted Platform Module 2.0) did nothing for me Closing nVidia GeForce experience had no effect The problem persisted across multiple nVidia driver versions Setting a higher PBO max boost didn't help things I tried various combinations of G-sync, V-sync=game setting / fast. Though I knew the issue wasn't graphics, frame presentation/sync still changes game loop behavior I dove deep into profiling with: Process Explorer, Performance Monitor, uProf (AMD specific). I noticed page fault and presumed that maybe I was dealing with unecessary disk access (my RAM is fast enough, even an nVME SSD could cause hitches). This was not my problem DCS was showing me page faults happening in a sort of spiky way but reporting on page faults / hard faults are generally every second so it's impossible to line it up with the fluid frametime graphs within DCS or MSI Afterburner uProf is a non-trivial tool to use, and was showing me a miss rate on L2 cache that I thought was somewhat validating my suspicions. 5950x has an L3 cache though but I couldn't get uProf to profile L3 cache hits/misses (likely a bug with the tool right now). Arbitrarily, I considered maybe the DCS log might be a culprit of something were being logged (disk writes) excessively eventually forcing a very slow IO sync so I opened up the log to see what was going on during actual simulation. I noticed a frequent (but not excessive) message about a DCS-BIOS script failing to compute or construct the F-16 DED line right (this was my test scenario) First step I took was to update it in case there was a performance problem. That didn't fix it Next step: now I'm reminded that I have a bunch of DCS scripts that could be the culprit so I disable them Plugins that caused no performance hit in terms of the stutter: SRS, Tacview, SimShaker, VPC Link Tool (vpcGameGUI.lua), DCS ScratchPad Problems: DCS-BIOS, DCS-Export Again, each of those plugins created massive microstuttering down in an unacceptable way. Everything I tried that didn't work, I have turned back on and I get no stutters, great performance. They also lowered my average FPS noticeably too, but I would be totally fine with that cost given how I use them with my StreamDeck and I'm well above 60fps anyways. Removing both plugins my .1% lows went up to 73 from 17 in MP, and from 35 -> 85 in the SP free flight Syria mission. My 1% lows are even higher, and sometimes surprisingly close to my average frame rate. So now I have to overhaul my StreamDeck profiles to operate through hotkeys instead of the DCS-StreamDeck plugin...bummer.

What's your RAM clock speed? Whatever it is advertised for is also the XMP profile enabled speed which may not be happening if you didn't place the RAM correctly on your motherboard, or your BIOS/UEFI settings don't have it enabled so double check that (likely between 2800-3800mhz). If you don't have XMP2 profile working it will be half. I'm pretty confident this has to be your issue because with a 5900x/3080 combo you should have better performance. If your RAM is underperforming, it'll look like the CPU is slow to DCS or any normal process. Only super fine grained profiling/instrumentation can observe memory access times being an issue. If for some reason you are having problems getting XMP profile to work 1) definitely fix it. #2 is only a possible work around for balance 2) try reducing the number of cores DCS sees. I'm not sure if setting the # of cores (affinity) after DCS starts up works or if you have to do it in your BIOS/UEFI or Windows settings, but try cutting the # of cores in half. There's no need to disable SMT if you only let DCS see every other logical processor number.

It is likely temporary so the short thing to do is try again later; another day at least, another week at the max. The fact that you're able to access these forums (presumably on the same machine?) means DNS (name resolution) for your internet is working in general. If you're experiencing this consistently, then something is wrong with your network configuration -- as in, your computer, or your home router. Someone from ED could comment about what host names are used by the DCS world installer/patcher and a temporary workaround to get DCS installed and updated would be to add those hosts / IP addresses in your system's host file. Back up the original file before saving any changes; though royally messing it up shouldn't prevent boot, but it can cripple your internet. Also, assuming this works, I would try to remove such edits as soon as possible as they shouldn't be necessary for normal people. You can also try restarting your home router; or less disruptively you can try DHCP release -> renew in your router administrative UI if you know where to find it.

Also working correctly for me. I can't remember if there was a further release of SimShaker to detect the MT binary, but I doubt it since SimShaker seems to work through Lua exports that both versions most likely handle identically.

It's absolutely a good idea to turn off as much stuff running in the background as you can if you're trying to squeeze the most out of a game's performance. If you aren't using GeForce Experience for ShadowPlay or streaming, close it. That being said, drivers and GeForce Experience are very unlikely to be a substantial issue alone. If GeForce experience open or closed made more than a 5% difference in performance, likely the small amount of vRAM that it uses up is just enough to exceed your particular system+GPU configuration and make the caching situation far far worse. You could close one or two other things that would have gained the similar benefit possibly, and there are a lot more programs out there using GPU acceleration especially in Windows 11. CPU resources is also somewhat indirect in that I think even DCS MT doesn't truly saturate most 8+ core CPUs enough for background processes to have an issue. A background program could have bad behavior and nastily be causing Windows to let it pre-empt DCS in terms of scheduling a little bit too much despite not really having high demands itself. Good way to test that out a bit is to try setting that process (right click the process from the details tab in the Task Manager) and setting the affinity of that other process to 1 or 2 cores, and below normal priority. Likely that background task runs just fine and quietly.

I nearly have this fixed for my personal monitor layout with the following change in my MonitorSetup Lua cfg/script: UIMainView = primary GU_MAIN_VIEWPORT = primary LEFT_MFCD = left_little RIGHT_MFCD = right_little CENTER_MFCD = center_little Viewports = {UIMainView} Is now: UIMainView = { x = 0; y = 0; width = screen.width; height = screen.height; } GU_MAIN_VIEWPORT = Viewports.Center LEFT_MFCD = left_little RIGHT_MFCD = right_little CENTER_MFCD = center_little Screenshot in simulation: This solution is still very imperfect though as the menu/GUI windows render across everything and depending on your monitor arrangement, you might have very important areas of your screen inaccessible if there are no real monitor display pixels present. If your left side, and too much of the bottom section of the screen is inaccessible from the main menu, you won't even be able to access missions. The UIMainView table is key here. In theory, UIMainView should be set to my primary monitor's view which starts at x=2560, with a width of 3840. However, if I move over UIMainView.x to 2560, everything else about the UI is fixed from the prior screenshot -- loading screen is only on the main UI, dialog windows are entirely on it, etc -- but the UI overlay text (dark area) disappears again. For some reason, in MT that text absolutely doesn't respect UIMainView.width and still sees screen.width. This is as @Saruman said. It appears I could fix this if I swap the left and right sides, but I'm trying to avoid that for now due to sanity in Windows. I kept messing with things and decided to remove setting GU_MAIN_VIEWPORT while setting UIMainView.width to 3840 -- UIMainView = Viewports.Center UIMainView = { x = 0; y = 0; width = 3840; height = screen.height; } GU_MAIN_VIEWPORT = UIMainView -- actually, the same result occurs with or without this line. LEFT_MFCD = left_little RIGHT_MFCD = right_little CENTER_MFCD = center_little and I achieved a most interesting result: The prior attempt rendered everything relative to the full resolution area, which messes up main menu window boxes (they are centered between screens). This attempt actually has the proper UI area dimensions (4k), with the overlay; text appearing in that 4k area in the right place and on top; but it is just not at the location of my 4k monitor's display. If I don't set GU_VIEW_MAINPORT and try to adjust UIMainView.x = 2560, the overlay text disappears again, and I my MFDs stop working.

This could be right. I noticed A.I. flight / AWACS communication message text (like in your screenshot) appeared further to the left than normal with my intended export configuration. That would make sense because I have a lower resolution monitor to the left of my main monitor so for some reason that text is being rendered where it needs to be in the corner of that screen. I haven't found a way to fix it using the normal viewport/export Lua files, but I have noticed that DCS interacts with a file in DCS.openbeta/Config/appSettings.lua which also appears to be defining layouts of monitors attached in a way that seems almost identical to exports. appSettings.lua seems to be modified unnecessarily every time DCS starts, even if I change nothing and is safe to delete if you mess it up. DCS will create it new somehow. Anyways, despite doing everything to make the top left corner of the left-most monitor be 0,0 to both the display driver(GPU) and Windows, DCS seems to generate/modify this file with negative X values for my non-main viewport monitor. Not sure if this influences that overlay/GUI/subtitle text rendering. EDIT: No difference removing all negative numbers from appSettings.lua. One run in and DCS very overwrote it. I can't even be sure DCS considers what's there.

@trevoC is spot on that most people should not mess with their system-wide settings. When it comes to a setting that impacts the entire system, I strongly commit to keeping things default. Mess with an individual program all you want, but if you change things that affect just about everything that runs on a machine, something will break and you will spend hours trying to understand what is broken is how to fix it -- more likely days or weeks. If you can just wipe/rebuild your system from scratch anyways, then less of a problem but most people can't or won't. @Spectre1986 it's valid that when you have a very high end and common CPU people will want to be able to exploit that, but take a step back: isn't that what this multithreading enhancement already is? DCS expanded what a performance cap at around 60-90fps for most chip's single core performance limits, and expanded it up to 150+ fps for capable systems, and you're taking issue because maybe you should be running at 165? Is the performance gap optimization even that high? Experimenting with how to optimize performance is useful for ED to consider the entire picture of improving things for a lot of people. The findings shared here may be useful to ED testers and engineers to familiarize themselves with and likely improve auto-detection, but complaining that ED is dropping the ball just isn't fair. If you need that performance right now configure the heck out of your own system. Share what works here for others, and for ED -- keeping in mind that even if you can target optimized performance for this particular CPU, that is still a smaller part of the solution ED has to deal with in being a part of 'DCS.exe.' Be warned though: when/if ED solves this particular problem with auto-detection, whatever you did to explicitly fix it for your system, will likely become a break for that auto-detection giving you worse performance at that time.

Nice. I didn't even notice there was a new patch today. Hopefully this also fixes the overlay text/UI so I can actually use MT for multiplayer!