EbonySeraphim

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.

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.