Invisibull

When not caged, my understanding is that the dial should move to reflect the range to a target based on radar returns. I've messed around with this for an hour and have yet to see the dial move off of 1800'. When I cage it, it goes right to 600', but right back to 1800' when uncaged again, regardless of how far away the target is.

Support Ticket #143755 was put in on 8/27 and so far I've been asked to check a bios setting to see if my RAM was being overclocked (it wasn't). Very disappointing to be completely ghosted by ED on this issue.

I'm still getting this crash, but never when using the non-MT .exe. I have reinstalled DCS from scratch am using no scripts or mods, and I have done tests on my memory and it is fine. Could someone please help? I've attached the latest DCS.log and here is the Windows Crash Report from the Event viewer: Faulting application name: DCS.exe, version: 2.8.8.43704, time stamp: 0x64e3b9dd Faulting module name: VCRUNTIME140.dll, version: 14.34.31938.0, time stamp: 0x023b235f Exception code: 0xc0000005 Fault offset: 0x000000000000165e Faulting process id: 0x4e38 Faulting application start time: 0x01d9d62a3dcb6612 Faulting application path: D:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin-mt\DCS.exe Faulting module path: C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll Report Id: d8dd710f-9880-4cdb-a0d4-5a185a6ec61c Thx dcs.log-20230824-013901.zip

Thx for your reply. I've come to discover that the crash doesn't happen when I'm not using the MT exe. Further, even while using the MT exe it only seems to happen in that particular mission so far. Incidentally, those script errors have been coming up for years in some cases and have never manifested in any noticeable way in the game environment; I don't think they are involved at all. Thx again.

Aircraft used here is an F-16 in MP. Please find relevant logs attached. Thx. null dcs.log-20230606-193242.zip

You're welcome

Yesterday's update has resolved this issue. Thx for all your help, @c0ff

This did not help.

I've always run all DCS.exe's as admin and there is no Debugging Tools folder, so I'm still feeling the pain over here.

I should add that the server will run, but that it takes 3 or 4 hours of "loading" before it will. This was the case even before the hotfix and before I updated Windows.

Updating to 22H2 didn't help.

Trying that now. Thx. I'll report back here when done.

I guess the fix wasn't so hot. So, we wait until the next update and hope for the best?

@BIGNEWY Today's hotfix had no effect on my issue. The DCS Log is exactly the same and the DCS server is still stuck in the loading screen.

Hi, I started by doing all the things you've suggested plus a system restore and none of it helped. I then did a full uninstall, deleted all folders associated with DCS, including the DCS folder within my saved games folder and then did a reinstall from scratch. None of that changed anything either. As far as a "full" log - I provided the entire log in my first post. I'd imagine its brevity is due to the fact that DCS hangs up before a longer log can be generated. DCS is running fine on my PC, but I haven't been able to host a server using the dedicated executable on my server PC since the update.

Best of luck, but reinstalling did nothing for me.

Thanks for your reply. Since I did a full reinstall and others seem to be having a similar issue, I think it's pretty likely that today's update is the cause. Hopefully, there's a fix already in the works.

Unfortunately, this made no difference for me. Thanks anyway.

Hi folks, I updated my openbeta server today but then when i went to run it the first time, i inadvertently closed it before it had fully loaded. Now it gets caught in the loading screen and hangs there indefinitely. I have uninstalled/deleted everything and tried to start over from scratch, but it's still happening. The log it generates is not very long so I'll just paste it here: Any help would be greatly appreciated. Thx.

Frankly, when I compare the above hearsay (we certainly have no way of knowing exactly what "T-DAY" said and what the context might have been) to the account from the Semper Viper! article, it's not even close which of the two should be more heavily weighted as a useful source to answer our inertial roll question. Here's the relevant excerpt from that article: Currently, nothing I can do with my FSSB stick will "stop the roll rate completely" as described in the above article. Also, when I do try to stop the roll now, the response is anything but "rapid." No disrespect is intended here, but I spent the last couple of years really enjoying how well I could stop the viper's roll on a dime and now I'm being told that that behavior was incorrect all along even though we have direct quotes from the horse's mouth verifying that it was perfectly fine in the roll regime (at least from a FSSB user's perspective) before the FM update a month or so ago.

Did that internal build not make it into today's update? It def feels different to me. Maybe a placebo effect. I'm sure others will comment shortly. UPDATE: Upon further testing, I guess it hasn't changed as much as I first thought.

Today's update seems to have improved this issue.

This is exactly how it was with my FSSB until a couple of updates ago. I know it might sound a bit daft, but I really miss that aspect of flying.

If Wags is saying that, then I have faith that it's already fixed. thx.

Same here. I don't understand how ED can say "Correct as is" in 2019 with no roll inertia, but now say the same thing with lots of roll inertia? It defies logic.