@Kecske, you're absolutely right. I googled a bit and, as you said, the Crusher family of UGVs use skid-steering.

However, doesn't that mean the Stomper should have a turning circle of zero and behave more like a tracked vehicle?

Updated to match the actual problem.

Accidentally posted twice.

This problem continues to plague me and yet never occurs in other games, even similar high end graphically demanding ones.

It may be coincidence, but I noticed that it seems to happen more frequently when it's night time in-game.

This issue is still present.

I agree that this is an extremely minor issue, but you've already gone to great lengths to get the little details right, so why skip this one?

This issue is still present. Tested 2013-11-09, stable branch.

I don't see how this is fully resolved. Even if there's a workaround, the underlying problem that causes this still seems to be active.

I recently recreated my profile and had to recustomise my controls, as I use quite a few non-standard key bindings (e.g., double tap space to step over).
Even after recreating my profile this problem persists, which basically means any new player could face the same issue.

@Soppa, the video you posted really helped me. Thanks!

As a whole though, ARMA's performance when compared to other large open world games is pretty bad. I would prefer better performance over content, personally.

@rogerx Interesting point. As it happens, I am using HDMI for my monitor connection...

I have tried everything I can to resolve this problem, including COMPLETELY DISABLING the WDDM/TDR system that resets the graphics driver. Doing that only changed the error message I was receiving to VIDEO_TDR_APPLICATION_BLOCKED.

The thing is, even if this were not ARMA 3's fault, and it were the graphics hardware and/or driver, well-written software can be made to continue running after one of these resets occur.

Here's the MSDN article on the WDDM/TDR system:

http://msdn.microsoft.com/en-us/windows/hardware/gg487368.aspx

It explains what's happening and what software developers should do in the event of a DEVICE_REMOVED event, specifically:

"As mentioned earlier, some older DirectX applications may now render just black, and the user may be required to restart these applications. Well-written DirectX 9Ex and DirectX 10 applications that handle "Device Remove" continue to work correctly. The application must release and then recreate its Microsoft Direct3D device and all of its objects. DirectX application programmers can find more information in the Windows SDK."

I strongly feel that you should solve the underlying problem, but it certainly help matters if ARMA 3 was capable of handling device remove events.

Another independent developer wrote two blog posts on this particular problem; they can be found here:

http://www.shiningrocksoftware.com/?p=1368
http://www.shiningrocksoftware.com/?p=1459

@rimas123, I agree completely. This problem continues to plague me and yet never occurs in other games, even similar high end graphically demanding ones.

It may be coincidence, but I noticed that it seems to happen more frequently when it's night time in-game.

I'm experiencing this issue almost every single time I play ARMA 3 (stable and development branches). It doesn't seem to make any difference what I'm doing at the time, but so far it has always been when I'm actually in-game, not on a menu screen.

I've attached the RPT and dump BIDMP files as DXGI_ERROR_DEVICE_REMOVED - Winters.zip, and my dxdiag output.