Lets Discuss FFB, Bugs, Fixes, Workarounds.

Thanks for writing this here. As I mentioned in discord, fyi the next hotfix v0.35.4 should include a fix for these issues. After that is released, if you find issues, anyone affected can reply back here, I'll be monitoring the thread

 

Again thanks for the feedback. In general, we are aware of general points of improvements for our FFB system (for example, I drift and race IRL, as well as having been simracing for more than 2 decades - others in the team are also drifters, or frequent track days, or simrace). The main obstacle here is figuring out how to get to the desired results without resorting to cheating with predefined effects.

To give one example, just so you understand better: the lack of understeer feel is not something we can fix by bumping up "understeer effect", since our steering rack has no clue what is the concept of "understeer", and our FFB system feeds directly from raw steering rack forces. And we prefer to not begin the route of "understeer effect", "oversteer effect", "peak grip effect", "burnout effect" and similar concepts.

We want to continue treating FFB as a direct measurement of torque from the virtual steering rack, and instead improve the physics simulation of the entire vehicle, with the goal of having that final element of the pipeline - the steering rack - output better forces.

In some cases the vagueness is 100% intentional. For example, our steering rack in the Bruckell Nine is designed with some play in the internal gearing simulation, which intentionally simulates these steering play issues in cars from that early era of automotive engineering. Other vehicles are boats with also intentionally vague steering response (newer cars from "only" 30-60 years ago, buses, trucks, etc). While in other cases we're trying our very best to get the most responsive possible FFB we can possibly engineer through our physics, through our suspension designs, and through better FFB algorithms (that do not resort to predefined "effects").

The unstable FFB at full lock is also known, and so far we have been unable to find a solution that is cross-manufacturer compatible. We could take a shortcut and develop a solution that depends on Logitech SDK, and which only would work on Logitech wheels when you choose to use the Logitech backend of FFB drivers. But we prefer to dedicate the time to doing a solution that works across the board, treating all users as first class citizens. The full lock oscillation is also only one of the many priorities we have (we do not have one person dedicated exclusively to FFB, this is something that me and a couple other devs have time to work on from time to time, but not on a constant basis, so we need to pick our battles very carefully for a greater benefit to as many users as possible).

And oscillations is something that heavily depend on the latency from input to physics to output (output as in ffb, not as in screen refresh). We have some ideas on how to reduce oscillations, some of which have been progressively implemented, and others that are still on our ToDo to try when we have time for it.

All that being said, sometimes improvements may be trivial to do due to bugs we didn't notice, or maybe unconventional tweaks to FFB settings that we may not have tried, enabling or disabling special behaviours from manufacturer drivers, or other "out of the box" approaches. So any potential hint is very welcome, for example your report about worse FFB in that recent update was key to figuring out we had a bug