EbonySeraphim

Yikes. I might be seeing a very similar issue with a 9950x3d and I'm on the latest patch. This is quite game breaking as DCS is software that needs supportive background software like SRS, Buttkicker/SimShaker, and VoiceAttack. I'm using a new build and haven't done anything other than enable EXPO memory settings (6000mhz) in BIOS. Everything else is pretty standard with no overclock; PBO isn't even enabled. Clock ratio is set to "all core" and not "per CCX" (most likely will be changing to this): CPU temps are great with an AIO cooler that gets me CPU idle at 45 degrees C; while all of the below is happening maybe CPU goes to 73 degrees C). My observations: I can usually see one or two cores fully at 100% during these lockups. DCS itself will become less responsive in menus. Windows itself is largely unresponsive. Most apps won't even render updates not to speak of responding to interactions Mouse keeps moving (woo!) Background app specific behavior: TrackIR doesn't seem disrupted in the background; if the main window is up rendering won't update ButtKicker Hapticonnect DCS integration is sluggish and 2-3 seconds delayed per effects SimShaker remains responsive VoiceAttack is crazy unresponsive. Though the mic level response is there and shows, speech recognition is delayed more than several seconds. Sometimes even up to 15 seconds later before seeming to recognize speech and confirming a command This behavior does not always instantly start as soon as DCS opens, and I may be able to run inside a mission for a few minutes before this happens. But when it starts happening, it doesn't matter if I exit outside of the mission and try to access the basic menus of DCS itself. Everything just bogs down until DCS is closed. At times, it feels like I can alt-tab out and maybe eventually my system is more responsive, but usually not. I have to do more testing around that. I hope this gets fixed very soon, and the only reason I'm pretty unbothered is because I have a ton of input configuration and tool set up before I actually start trying to refresh my flying, procedures, knowledge, and play missions in earnest.

I think people should understand that when there's an ongoing dispute between a company you work for and a business partner company and group, things can get to a point where you're not allowed to talk to them directly. Or at least you're told not to. It doesn't necessarily mean the entirely relationship is over, but it does represent a gravity of the legal issue that needs to be worked out. Anyone can assume ED wants RAZBAAM modules to continue to work and get updated/fixed in DCS. ED themselves are probably able to take on such work (scaling up with devs being the key concern), but the problem is that RAZBAAM has to turn over / sell their code. How much is that code worth when RAZBAAM is literally sitting there willing to just let it die? Of course ED should pay something for it, but understand that such code has no value outside of integrating with DCS, and might even be illegal to open source as the SDKs/APIs into the DCS engine are probably under NDA or other closed source licensing. If RAZBAAM cares about the community, but is basically at a point of "we go no further" they shouldn't have a problem with someone else carrying the ball from then on, but it would clearly look bad if If ED is a super evil platform creator and overlord, the substantial proof would require serious transparency into what agreement module makers have to sign up for and the financial realities of it are. Good luck finding a neutral expert on the subject matter because such a relationship has never existed anywhere else, ever. It's harder to believe the agreement is that bad when other modules of high quality are able to be made and maintained. Ultimately, I can understand why a lot of missions and campaign's don't keep up with the core engine updates and are often found broken over time. I can accept that and it pretty much means the reality for purchasing missions is to ensure it's up to date with current DCS before purchasing and downloading if it's old, or recently created so you know it's new. People also don't consider something else: software engineering costs can be wildly different depending on the quality, skills, and processes of different teams/groups/organization and available tools. What developer A can take on and complete within a year and a budget of $2 million, another developer might need two years and $6 million to create. 10x developer is largely a myth, but development efficiency for what seems to be the same work can vary wildly. I say this to mean that I don't necessarily need to believe that RAZBAAM is lying, but maybe their costs are high because of their own fault. Maybe ED's financial modeling and contracts for how much it costs module makers to keep up with updates and integrate changes doesn't work for them while it works for others. This is where things can get highly speculative -- I used to be in government contracting -- and it wasn't always in a contractor's interest to accomplish dev tasks as effectively and cheaply as possible and show that off as it meant a cut budget. This is a constant state of labor, if the employer knows you can do work for X dollars, and still do a bit more than just KTLO (keep the lights on) and you're mildly happy, why would that pay you 2x? RAZBAAM could be doing derpy things inflating dev costs and ED might be thinking "no...we don't want to increase your share. How did it take an engineer 80 hours to integrate the engine update to atmospheric effects when it took an engineer over at ____ 10 hours?" Separately I generally dislike larger entities in a capitalist economy because they often are the bullies, so that inclines me to validate the idea that ED does set up agreements that make it near impossible for a module to be profitable on their platform, but I have no knowledge of that in this case. Anyways, I'm not here to push anything either way in terms of who's evil or in the wrong, but the point is all of the information that is leaking or being hear, from devs is either complete trash or highly speculative, or even both. The conclusions being reached from inconclusive, often irrelevant evidence; it is super annoying and fuels trash communities like /r/hoggit over on reddit which constantly seeks to say "BMS > DCS, ED sux." Very silly from a forum that is supposed to be fans of flight sim in general. Nothing in this world is that guaranteed. If you think that way, you allowed yourself to be spoiled by the fact that DCS is a free sim platform and some modules you purchased (from ED) have been nicely updated even since DCS 1.5: BlackShark, Warthog. Just like any app you purchase on the iPhone that suddenly stops working isn't guaranteed, the same is true for DCS. I've purchased an iPhone app or two that I can't even redownload anymore, is it refundable? No. Nor should it be. I paid for something, I got something for it that wasn't about the future of it. Those are the only safe purchase in capitalism. There's only a mildly better argument for EA F-15E because the "EA" label does come with a reasonable promise of non-EA occurring which it clearly didn't get to. That part about BMS makes me think you come from, or belong to /r/hoggit. Go play BMS exclusively. I'm sure there's nothing about DCS you'll miss. Bad AI, terrible ATC, "incomplete modules" blah blah blah. This sim is soooo bad. Delete DCS now, install BMS if you don't already have it installed, and only scratch your sim itch with BMS for a year or two. Come back and then tell us how much better it is. Even in the (unlikely) event that this goes worst-case scenario to the very end and all RAZBAAM modules stop being updated and fail to work with DCS engine beyond a certain version, how does that affect you today? Why would you stop playing DCS however you're already playing it today?

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 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 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.

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.

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.

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!

You had the problem with the A10C_2? Mine never had any issue so I wouldn't even know what file to examine to attempt a fix. If you changed something for the A-10C2, I'd say try changing it back.

Workaround: https://forum.dcs.world/topic/320832-exported-mfd-issue-with-new-mt-beta/?do=findComment&comment=5169599

You went off some sort of deep end. Remove everything you've already done with DCS-ExportScripts and install fresh. You shouldn't need to touch those scripts as the defaults for the plugin already properly communicates DCS-ExportScripts properly. I'm a software engineer, but even I'm not willing to "code review" what might be messed up because it could be literally anywhere. So again, do a clean install of DCS-ExportScripts, and use the defaults of the StreamDeck plugin to talk to DCS. Don't run either StreamDeck software or DCS as admin, that is not your problem.

Are you calling the imperfect gradiation of the shadow darkness on the nose cone of the jet a bug? If so, that's not a bug. It's called limits and realities of real time rendering and that is the quality of the lighting model interacting with the finite aircraft polygon count. Every game you play will show limits like that. Even a pure ray tracer, with the underlying geometry being polygons/triangles, will display that kind problem.

Can confirm that my F-16 and F/A-18 MFD/DDI export issues were fixed by changing the picture.additive_alpha = false line of code in the aforementioned files. I have 2xCubeSim screens and a normal secondary monitor that displayed the AMPCD for the F/A-18 which was also corrupted. For those who it didn't work for, be careful because there is a similar line earlier in the file which does not fix anything if you change it. The correct one is pretty close to the bottom. I can also confirm that I didn't need the fix at all for the A-10C_2 or the Ka-50 (ABRIS + Shkval). Those worked just fine as-is included in the patch.

@NineLinethe vertical "tear" reported here is something I've observed consistently. I don't see an dedicated thread to the issue so maybe it should be split out? To my eyeball, the "tear" is more like a delineation where the lighting model on one side are incomplete (hence darker); possibly because the renderer thinks I'm not looking, or not able to look in that direction. It's very noticable and tends to happen when looking at some off plane boresight direction and angle. In the prior post's screenshots, it looks like it's happening in an external view, so I wouldn't suggest it's dependent on plane direction. Maybe it's a compounding issue with MFD exports? My guesses are probably unhelpful. I've seen the issue on multiple maps (Syria, Persion Gulf, I think Caucuses) and visually, it looks screenspace/viewport dependent rather than world space. Here are additional screenshots: My specs are: 5950x; 64GB DDR RAM; RTX 4090 latest GameReady driver (531.26), fxo + metashaders2 folders cleaned post-patch and post-install of latest driver; 2x normal monitors, 2x CUBESIM displays (USB3 connected); Samsung 980 pro drive.

Assuming those are processing times, what that's showing me is a clear picture: your GPU is the bottleneck. With those per-frame processing times, your CPU is finishing at 111-113fps, and your GPU is at 90fps for Caucus (fastest); and 60fps for Channel (slowest). The GPU numbers alone look too slow as I have a 4090 as well, but I truthfully don't know how much VR changes things. What is more suspicious to me is that even though your CPU times are fast enough, they still seem on the slow side of things for what others have gotten out of this patch. Can you direct me to one of the heavy AI populated instant action missions so I can compare? I'm fairly certain 113fps is a 1% low for me with a 5950x; and I'm guessing you have a comparable or better CPU if you also have a 4090.