EbonySeraphim

Make sure the whole imported content is OK. I wasn't hiding it before but noticed the quote formatting cut off the full content, and since it doesn't reference another post on the forum, it wasn't accessible. Or at least the expand button was broken for me.

I just watched Spud Spike's (speculation) video on YouTube titled: "What Actually Happened Between Razbam & ED!" I'm not sure if I'm allowed to link it here, or even discuss it here -- I'm fine having this post deleted if I can't discuss it as speculation. Anyways, I noticed a critical detail of his speculation-analysis that spelled it out for me pretty clearly as a software engineer myself, and if I assume some of the core relationships and facts about the entities are quite true. I'm just going to quote my own comment on the video mostly, but offer some context first: The core issue speculated is that RAZBAAM entered an agreement to make their own simulator (different aircraft) for another public/government customer. Spud (referenced) claims in the video that this agreement all on the "up and up" and kind of glazes over looking this scenario with proper scrutiny and that's where I vehemently disagree having a background with software engineering, and even a bit of gamedev at a hobby level. I'll summarize my full comment: any active DCS third party module developer, with access to the private SDKs shouldn't be trying to make their own simulator as a side hustle for any customer. Even without specific proof, knowledge of the activity alone is enough to slam on the brakes up front. ==================================================================================== 8:03 -- this is where you critically mislead your audience. Sure, you can consider the agreement itself normal, but the execution of that agreement is the issue and the problem is obvious to anyone who works in software and understands the nature of secret sauce being revealed when you have access to an SDK. If RAZBAAM has zero software engineers that have ever written their own original and large scale battle / simulation engine and the pieces to it, and after they work to deliver some products with an existing one[engine], and all of a sudden they are contracted to work on creating just that[another simulator] for another customer -- it SCREAMS a violation of IP. The RAZBAAM devs absolutely are using the engine modeling and integration methods of DCS's engine to create their own product and profit with another customer. Said differently, this is like if a game developer who's never created a video game console, makes a few games for Sony or Nintendo with full access to their hardware/software dev kits and turns around and suddenly is making their own. You can start to see the issue there. They didn't have the expertise, but they had access to a LOT of trusted detail about the internals of the console hardware and now they suddenly are capable of making their own and solving the problems associated with that? Messing with the major console manufacturers directly is going to get any company flattened pretty hard and quick, so ED and the DCS engine is a soft target in this respect, but I think ED has a strong case. If I were anyone at ED, the instant I discover or have an understanding of two things: 1) RAZBAAM engineers do not know how to make a simulation engine/environment and 2) somehow they have a contract to write one for a customer of their own. That is a lawsuit by default. But since lawsuits take time, why would I pay RAZBAAM all the while when they're almost certainly in violation. Getting money returned to you is near impossible; I'll pay up after/if you can prove you aren't stealing my stuff. That RAZBAAM had the audacity to claim ED isn't paying them and NOT offer this context upfront shows me how they like to operate. Am I suggesting that no third party module maker with DCS can ever make their own simulator? Literally no, but pragmatically, yes. If you want to peak under the curtains, you pretty much need to swear that you'll never attempt to create a competing product. At least not for a long period of time after that relationship ends. If a module developer ever tries to make their own sim while their products are actively available and recently developed, ED absolutely should put eyes on how and why they are capable of doing so. Did this company actually hire new devs who have a lot of industry experience with it, and those engineers provably do their own seperate work and research with zero access to the internal SDKs of DCS? Is the simulator/simulation engine being created by this developer significantly different or divergent from DCS's implementation approaches? This is the core proof of the legal-technical matter for RAZBAAM to prove they aren't stealing from Eagle Dynamics, or weren't intending to steal. Simply put, it would be a bad idea for any third party module developer to even try to make thier own sim ever while working with DCS. I'm sure ED would love for third parties to have as much unfettered knowledge and access to their engine as possible to make better modules. Even if ED doesn't hand over their complete source code, the SDKs workings, binaries, and design are still telling a whole lot of what is going on and third party devs could decompile the core engine or see debug symbols enough and use other tools to basically see everything. If you're a third party developer, you have to understand that if you have this access, your knowledge is IP theft if you're a part of helping create a competing product. That RAZBAAM would work on a DCS module while entertaining making their own sim is busch league level behavior. To me, it seems like they were hoping ED would not find out about their own side hustle IP theft, and if they could deliver a single aircraft sim project for this public customer, they'd be building up their own engine to come after DCS after some iterations. Thanks for posting this video. I respect you Spud for your contributions to the community. I think expert knowledge is always needed to be laid on top of facts. (I should have written speculation here) ==================================================================================== This is all my opinion and analysis offered on top of the speculation, and alleged info from Spud in his video(s). Spud to me, is just some guy on the internet. He doesn't know me, and I only consume his channel a bit.

Question: Base SimHaptic software supports DCS out of the box; if I've already purchased a license for SimHaptic, is there a reason to purchase a license for DCRealistic? Does that improve on the DCS experience and integration any or is it just a way to isolate DCS functionality if MSFS, BMS, and XPlane don't matter?

tldr: gaming mouse for DCS isn't a good investment. DCS does not benefit much a gaming mouse compared to standard cockpit/sim. Get a trackball or two (one for each side), and it doesn't have to be fancy -- more so if you're in VR without PointCTRL. Being able to cockpit click from either side (hand on either throttle of stick while you operate something else in the cockpit) is far more useful and to always have it findable in the same spot. While you could put random mappings on a mouse with extra buttons, whatever those mappings are, are better served on whatever other devices you have. I say this having a mouse with extremely high productivity/gaming functionality too: SwiftpointZ. I use it for every other variety of PC gaming from MMOs and FPS, but for DCS or any flight sim that mouse is parked away in favor of double track balls. If you're already clicking around for cockpit controls, why are you further mapping in-depth buttons to your mouse? Using mouse buttons is an extremely marginal gain in those scenarios compared to what I have from Virpil panels, MFDs, and VoiceAttack. I used to use StreamDecks, and those can take up a bunch of functionality too. And like others have said, high polling rate mice can be a problem. I imagine it has to do with the actual rate being dynamic or not -- most high polling rate mice aren't actually polling at their highest advertised rate if the mouse is sitting still. It will increase when there is a lot of movement and high amounts of it. If for some reason it's always going 100% polling rate, I can see how that's a bog for systems. Definitely cut that out.

There's a solution to this: adjust the contrast first, then brightness, etc settings in the cockpit like a real pilot would. There's no telling what the real lighting conditions are in the plane and the defaults are not always going to work. Players need to stop expecting that the moment they switch to bhot, whot, or even CCD imaging that it should automatically be of a certain contrast quality and factor. Sometimes, it is hard to spot a vehicle beause it is hidden. To compllicate things even further: everyone's main monitor has settings for contrast and gamma (brightness) as well and it's different for those auxillary monitors some of us have (CubeSim, WinWing) for these MFD displays. On top of display link brightness, contrast, and saturation not being explosed by default in Windows 11 (you need specific software to give you access to change it), DCS also acts differently with these exports and it's impossible to get both the main-onscreen render of the display to match your actual export. You can make one good, but not both at the same time. It's not that big of a deal to face the reality: in game that screen is (should be) subject to the in-cockpit lighting conditions as a real pilot might have difficulty reading with the sun overhead and behind them a bit. How should it should that glare out your export as well or wouldn't that perception be frustrating because no such lights are present in your room. Force DCS to render that cockpit display twice and fully, and you might not light the performance hit. Just pick which one you want to use and use it. Again: contrast is the biggest factor that allows FLIR imaging to come through in DCS. Adjust it first, likely raising it, then likely you have to knock down or brightness afterwards. I promise you, this will create pop otherwise. It'll never be a cheat code. And YES you are supposed to have to figure this out per each mission, per each set of conditions, per each module. Even if you've figured out how to make bhot pop, whot and CCD imaging may no longer be that great so if you're changing between the two it's per each. There's no set it and forget it. If you're finding missions hard because you can't find stuff, it's because you don't know how to use these knobs and probably don't know how to JTAC coordinate and find a general area, or scout in your module. Hope the bit of advice helps!

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. EDIT: I managed to resolve my issue. 9950X3D solution: I changed my BIOS clock ratio setting from "AllCore" to "PerCCX." It was mostly VoiceAttack(2) misbehaving the worst in terms of system unresponsiveness, but in a way that was affecting my whole system. It has a setting to auto-adjust CPU utilization, although before making the PerCCX change turning it off didn't seem to help. My best guess is that when the core clock speeds are locked to be in sync with each other, it's very bad for one process to try to make an explicit adjustment to a single core or CCX.

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