Pitch/Bank controls occasionally "sticky" with MSFFB2/force feedback

[Katmandu]

The pitch/bank controls occasionally stick for a second, before warping instantly to the the current physical joystick position. See the short video below, paying attention to the green control box. Being new to the F-14 I thought the sudden snaps were the realistic nuances of the FM at first  My joypad is MSFFB2, no such issues in other modules.

 

Edited June 14, 2021 by Katmandu

[sLYFa]

Must be a joystick input issue. Never had this in god knows how many hours in the DCS Tomcat. FFB is known to cause issues with the Tomcat

[Katmandu]

Yep, I thought that FFB was at issue myself. It works great otherwise, analogue planes are awesome with the FFB in general and the F-14 is no different - apart form the sticky axes thing.

[Katmandu]

I've done a couple more tests. First with the F-14 and "FFB trim" option unticked in the F-14 options. I have also unplugged the MSFFB2 joystick power cable so there was no FFB at all, the stick was completely loose. The PC was freshly rebooted. The "sticky-warp" issue was still there (focus on the green control box):

 

The second part of the expriment was runnign the exact same simple mission with the MiG-29G as it's the closest to the F-14 flying dynamics wise - no fly-by-wire, two engine 4th gen fighter. Similar to the F-14 video, I have pushed the MiG to and beyond stall buffeting limits.

Both FFB plugged and unplugged give no issues whatsoever, the controls are always smooth, no "stickiness" followed by "warps". This demonstrates that it is not my system that is at fault.

Video (focus on the orange control box):

 

Another thought: could it be that this instant warping of controls leads to the rapid desync of the F-14 replays? Replays are deterministic, and, if there is no smooth control input between two joystick positions,  with instead one stick position instantly warping to another stick position, could this lead to the discrepancies in control recordings that are fed into the DCS client replay system? 

Edited June 14, 2021 by Katmandu

[WinterH]

Watching the thread because I also have the same occasionally, and also with an FFB2

[fat creason]

Please read this thread if you haven't:
 

 

TLDR; there's not much we can do regarding control input. It's all handled by DCS and we have no ability to influence what we're reading from the input layer.

[Katmandu]

Thank you for the link to the thread, I have not read it before. Will need more time to test with the autoexec.cfg edit that adds

input = { threaded_ffb = false } 

and allegedly kills fps. Quick test shows that it crashes DCS -on launch or shortly after- for me.

 

For now I've done a test with the AJS37 and it has no sticking issues during active maneuvers (with no autoexec.cfg modification).

 

So, if it was due to the DCS input layer then surely it would affect all modules, including Heatblur's AJS37.

Edited June 14, 2021 by Katmandu

[Katmandu]

Ran the FFB tweak above a few more times. Although the crashes are much more frequent with it, it can run. It's a different plane with the tweak active - so smooth and controllable, no pitch/roll sticking 

But!  the fps hit is real, even on the flat screen the picture is jerky. Here is a test of the same mission without the autoexec.cfg ffb tweak above (1 on the graph) and with the tweak (2 on the graph):

 

 

As can be seen from above, without the tweak the fps is pretty much locked at 60 (my monitor limit). With the tweak, the fps is never stable and oscillates between 60 and 45-50 fps. 

 

Just for comparison, here is Heatblur's AJS37 Viggen in the same mission (no FFB tweak as it works fine without):

 

Edited June 15, 2021 by Katmandu

[Katmandu]

@fat creason

I've done a bit more digging into the question. The autoexec.cfg multithreaded FFB disable tweak was actually proposed by an ED dev back in the 2013 when people were waiting for ED to create a workaround for the super-outdated Microsoft drivers for the MSFFB2.

 

https://forums.eagle.ru/topic/86544-msffb2-fps-drop/

 

gavagai (user):

Quote

Ok, here is the deal I've noticed with input delay: it exactly mirrors the original FPS drop I described at the beginning of the thread. That is, when you first spawn into a quick mission, there is no input delay and everything seems fine. However, start making some turns and pull some Gs, and then the input delay hits.

 

 

c0ff (ED team):

Quote

 

We tracked the problem down to the joystick driver.

Fixing this require a non-trivial work-around, so the nearest patch unlikely to include it. But the next one - most probably will.

 

Quote

The bug will be half-fixed in 1.2.5: i.e. half of the FPS loss will remain.

 

The complete fix, which turned out to be a serious rewrite of the low-level input code, is ready and will be out in 1.2.6.

 

Quote

This is definitely a problem in the driver. We'll search for a workaround.

Quote

Here's the thing: the Sidewinder's driver (or the hardware itself)

a) is single-threaded

b) has very slow FFB calls, up to 0.03 sec long

 

This leads to a couple of things

1) when an application updates FFB state it can't read from the joystick

2) if it works with the joystick from the main thread, the framerate caps at about 40 fps.

 

So either you have that FPS drop, or you have a input delay (depending on your FPS it may vary between 0.03 and 0.1 sec)

 

Right now, all joysticks with FFB are worked with from a separate thread, I may limit this to MS FFB2 only. Also, I'll try to play with FFB update rate to find an optimal scheme.

Quote

you may want to try openbeta of 1.2.8 RC3

Quote

you can disable "advanced" ffb-joystick code by creating or editing the file

Saved Games\DCS\Config\autoexec.cfg and placing the following line at the end of the file:

 

input = { threaded_ffb = false }

 

 

But you will get that FPS drop with MS FFB2 back again.

gavagai (user):

Quote

It is perfect now! 60 fps, no button input delay, no problems when I go to fly a second sortie.

 

Don't touch anything!:pilotfly:

=======================================================

History lesson's over  

From this it seems that the F-14 is not using the ED custom FFB/input subsystem, somehow it is using the older version that had this lag/stickiness. The Viggen on the other hand IS using the correct subsystem. The bug could be as simple as checking import library/package/subsystem version numbers. If the problem is not that, it would be awesome if @c0ff could lend us a hand.

 

PS I keep going on about it, but the control input layer discrepancies may lead to solving the rapidly desyncing replays problem as well, as DCS replays are just input control recordings

PPS How awesome were ED to implement workarounds for MSFFB2 1990's drivers, when it was so easy to say "go ask Microsoft" or "buy a new joystick". Much love and respect, Eagle Dynamics! 

PPPS SOLVED! See this post https://forum.dcs.world/topic/261036-severe-input-lag-with-f-14-when-force-feedback-on-with-ms-force-feedback-2-stick-in-use-edit-direct-input-solution/#findComment-4772136

Quote

All credit goes to user l3VGV from the Russian language IL2 forums. The solution is simply adding the linked dinput8.dll file to the DCS World\bin folder.

https://github.com/l3VGV/FixFFBStutterH/releases/tag/v1.02

No lag, no measurable negative impact to performance. Force feedback forces appear to all work correctly. Problem solved.

 

Edited February 24 by Katmandu