G29 choppy centering force in Euro Truck Simulator 2

[kallestrop]

I have a minor issue with centering force in ETS2/ATS with my Logitech G29 wheel.

The ingame force feedback centering setting is a speed sensitive force, which means as faster i drive the stronger become the centering force.

But when enabled, centering force feels choppy and unsmooth (like the force is pulsed).

This effect persists in both Steam versions - native Linux and when using Proton. Windows version works smooth with the same settings.

As a workaround i set the ingame force feedback centering slider to 0 and use autocenter settings from Oversteer. But Oversteer setting is constant force, not adaptive like ingame setting.

So my question - are there any settings to adjust to have a smooth centering force like in Windows?

[berarma]

Have you checked that the in-game FFB settings are the same in all tests? This game is a bit hard to compare from user to user because of that.

I can feel some roughness but I think it's because of the other effects being played, mainly the truck engine.

Can you try disabling the friction force in Oversteer? It can cause some issues when played with other effects.

If you could use https://github.com/berarma/ffbtools to create a log file recording the issue and send it to me I would compare it with what I get.

[kallestrop]

I made the tests without loading Oversteer. My ingame ffb settings are:

Gain: 75 Stiffness: 50 Centering 75

I don't use other ffb effects so they couldn't interfering.

Here is a video which shows the effect:

https://www.youtube.com/watch?v=fOt7K-rUvjg

I installed ffbtools, but creating logfile running game with proton did't work. I got only logfile with the top 000000000000 # DEVICE_NAME=...... line. I use Proton-6.3-4

Then i tried with native Linux version and i got this logfile:

ets2log-20210527232538.log

My system:

Kernel: 5.10.0-6-amd64 x86_64 bits: 64 Desktop: Cinnamon 4.8.6 Distro: Debian GNU/Linux 11 (bullseye)

edit: it seems that is the same problem like #26 but after reading this thread, i didn't understand what was the solution to fix it.

[writequit]

I find with stiffness set to zero it gets rid of that choppiness and I can have some feedback for terrain and engine vibration.

Regards, Geoff

[kallestrop]

Indeed, by setting stiffness to zero, the choppiness goes away. But if it's possible, i don't want to do without this effect, especially for a trucksim. It is not very realistic to be able to turn the wheel with the little finger in a stopped truck.

[berarma]

Thanks. With all the information supplied I'll be able to test it and hopefully see what causes the choppiness.

Since I can't run the game on Windows I hadn't noticed the issue.

[berarma]

it seems that is the same problem like #26 but after reading this thread, i didn't understand what was the solution to fix it.

It's a firmware issue that only happens when the friction effect is loaded. Since this effect is rarely used I stopped loading it always and instead load it only when needed.

This is a partial fix because the issue will reappear if the game uses that effect. I couldn't find a better way.

[berarma]

I've tested your log file and looked at your video and I'm pretty sure it's #26. It's also confirmed by the workaround being turning stiffness (friction effect) off.

I don't know a way to use the friction effect while avoiding this issue. I'll try to have another go at it but I can't promise anything. The information I need could be hidden in the black box that is the device firmware.

It could be a firmware upgrade that happens when the Windows driver loads, although I haven't any evidence for this and I don't know if a reboot would retain the presumed upgrade. It might be implemented by software emulation rather than using the device firmware. Or maybe I'm doing something than the firmware doesn't like. It's hard to know.

A Windows dump of the USB packets sent by the driver could be useful to see how it's done on Windows. The problem is that I don't have any Windows machine around. I could use a VM with some simple application that can send requests to the driver and play the effects I need to test but it would require an indefinite amount of time to set it up. Maybe someone that is more Windows friendly can have an easier time doing it and beat me to it.

[kallestrop]

Thank you very much for your efforts!

In summary there are 2 options to avoid this issue at the moment:

1.) Set ingame stiffness to 0 and you have adapting center force

2.) Set ingame centering to 0 and use Oversteer with activated autocenter strength and having constant center force. Oversteer settings will be overwrite ingame settings by tabbing out of game and apply autocenter strength slider.

[isopix]

It sound like workaround, not proper fix. So why 'closed'?

[kallestrop]

I'm not very familiar with this github environment, i'm just a simple user and no developer, so i thougt because of #26 was closed i close this too.

If there will be further progress to get rid of this issue, maybe berarma can reopen it.

[berarma]

I'll leave it open since in this case the workaround isn't the ideal solution. #26 was closed because the workaround fixed the issue by not loading the effect when it wasn't needed and we didn't detect issues in other situations.

[berarma]

I've done a few tests and, honestly, I can't see much difference between playing a damper and friction effect in my wheel (Logitech G29). Maybe the damper effect is a bit stronger or ramps up quicker but both seem produce a force proportional to the rotation speed of the wheel, and contrary to the movement.

For some reason, probably hidden in the firmware, when there's a friction effect and some other effect type is playing at the same time, there's some rattling like the wheel is readjusting the force levels to the movement of the wheel at high frequency.

The Windows driver might be loading a firmware update at each boot to fix it, I don't know and someone verifying this would be great. If the supposed firmware update can survive reboots after booting into Windows and then rebooting to Linux it should be fixed. Some USB tool could be used instead to check firmware versions.

Without more info I can only think of two fixes:

• Turning the effect off, it can be done with Oversteer.
• Converting the friction effect to a damper effect.

In case there's no firmware update on Windows, the driver might be already doing one of these, or maybe some other unknown trick.

There's also a fair chance that I'm doing something wrong in my testing, so I'd be grateful if someone else could test it too and share their knowledge.

[berarma]

It seems the firmware can be updated, at least in the G29 and probably in older models too: https://www.simracingirona.com/tutorial/como-actualizar-el-firmware-del-logitech-g29/

The update seems permanent and has to be done manually. So if your wheel works differently on Windows than Linux it must be something else. I'm leanning towards converting the friction effect into a damper effect unless updating the firmware can fix it by itself.

[kallestrop]

I checked firmware version for my G29 wheel in Windows Logitech Gaming-Software. It shows version 89.0.25 which is the latest version.

[berarma]

I'm trying to see how the Windows driver works. I've setup a VM using Gnome Boxes and then with Virtualbox but I don't have a good way to try the FFB effects. The Fedit application from DirectX SDK 8 doesn't work.

I've tried a demo from the Logitech Steering Wheel SDK and it only shows effect types: constant, spring and damper. I've had a similar experience with an application from the Microsoft Store, Wheel Tester that only can test constant, periodic and spring. I've found no way to test the friction effect. I'm wondering if the effect exists on Windows.

Please, @Kimplul, @scarburato, do you know why doesn't Fedit work? I get errors in the console at the bottom of the application window, like: invalid parameters or error occurred. I've downloaded the SDK and uncompressed the file.

[Kimplul]

I just checked that FEdit still works on my VM with my T150, no issues. I don't think a Windows update has come along and destroyed any functionality, but I could always be wrong.

A number of things came to mind, none necessarily a solution:

• From where did you install FEdit? I remember trying to track down the DirectX SDK 8, but couldn't get the FEdit that came with it to install. The download I found on gimx.fr (https://gimx.fr/download/b882e209a0ac023d03abbf560dfc3f25fe6367ca/fedit.zip) worked.
• How many devices are listed under File > Select Device...? Is the wheel under the correct name?
• Do you have all Logitech drivers installed?
• If nothing seems to work, you could always try using the API directly. Requires installing Windows development libraries, Visual Studio etc. A bit tedious, of course, but here's an example project that you could probably fairly easily modify: https://github.com/microsoft/Xbox-ATG-Samples/tree/5b20a8ef16f1f13a0069eb27006f5986e23eb2b5/UWPSamples/System/InputInterfacingUWP

Friction is at least available on Windows, though I don't know how Logitech has decided to implement it.

[berarma]

I've tried Fedit from the gimx page and from the SDK. They fail the same on Windows 10.

There's three devices with the same name, or mostly, the names are truncated. The name is correct. One seems to be recognized as a FF device while the others don't but they all fail.

The Logitech drivers are installed.

I meant that the friction effect doesn't seem to exist on the Logitech drivers. At least the demo in their SDK ignores it.

I hope I don't have to start programming for Windows. I must be overlooking something.

[scarburato]

idk if you could find helpful:

Last year I wrote this hacked together program with SDL2 to test ffb on both Windows and GNU\Linux, it should support SDL_HAPTIC_FRICTION. If I remember correctly to compile it on Windows you need MSVC, CMAKE and python to run setup_win32.py and on Linux it should be sufficient GCC, CMAKE and libsdl2-dev.

To test it you can try to replace in file tests/spring0 the 128 with 1024 — the codes are from the libsdl headers — and use PowerShell pipes to re-direct stdin or write it by hand (second line is always ignore I think).

Of course if the driver does not support the effect it will fail so it will be a lost of time...

~I will check if I still have a Windows build~ I've attached the build, it should be safe, I hope

ffbtest.zip

[Kimplul]

I hacked together a similar program to the one @scarburato linked, but it's a bit more interactive, like your ffbplay but with SDL2.

https://github.com/Kimplul/ffbsdl

For convenience, I compiled the windows binary so you could just download it directly, it's in bin/win64/ffbsdl.exe. You'll still need the SDL2 libraries, of course.

No promises that it's bug-free, but works with my T150 on both a Windows VM and native Linux.

[berarma]

Thanks @scarburato, @Kimplul.

ffbsdl return similar errors to fedit: "Haptic error Unable to create effect".

ffbtest can't run due to missing dll's.

I think there's something flawed in my Windows VM system or in the Logitech G Hub software. I've tried Logitech Gaming Software too and the wheel isn't even detected by any software.

[Kimplul]

Pretty weird. I've usually ran my VMs with Qemu through virt-manager, never had any issues with it. I don't really see why gnome-boxes or VirtualBox wouldn't work, but I'd still recommend trying Qemu if you have the disk space available, just to be sure.

[jsalatas]

The ingame force feedback centering setting is a speed sensitive force, which means as faster i drive the stronger become the centering force.

I believe this is caused by the stiffness settings. My issue here is that supposedly the stiffness should be lower in higher speeds and not the opposite :\

PS: I use only linux, so i have no idea how it behaves in windows

[berarma]

The ingame force feedback centering setting is a speed sensitive force, which means as faster i drive the stronger become the centering force.

I believe this is caused by the stiffness settings. My issue here is that supposedly the stiffness should be lower in higher speeds and not the opposite :\

I think both observations are correct and work as expected in the game. Stiffness decreases with speed but centering increases.

I've tested the game and have confirmed the following:

• The stiffness force produces the unsmooth force, but mainly when stopped or driving very slowly. At higher speeds the effect seems to fade.
• Autocentering works the opposite, it increases with speed and dissapears with the truck stopped or driving slowly. Contrary to stiffness this force is smooth.
• All other effects seem to do what they should, although I'm not sure how to test the suspension forces.

The only problem I see, without having been able to check on Windows, is that the stiffness setting (friction effect) causes an undesired rough force. I can try to fix it by replacing with a damper effect, both friction and damper effects work practivally the same on my wheel so I guess it could be a solution. I may put up a branch to test this.

[berarma]

I would like to look at the commands sent to the wheel by the official driver on Windows to see what we're doing differently but I can't make the wheel work on Windows using VirtualBox nor Gnome Boxes. If someone can test the wheel on Windows while capturing the USB data with Wireshark, please contact me.

[jsalatas]

I'm just following up here. I guess in one of the latest games updates something changed and the stiffness I mentioned makes more sense to me now. I also set all the ff values except the engine's to its maximum values when that update happened (before it was too hard to steer in high speeds if I had everything maxed)!

Did someone else notice that change recently? I doubt that it is just my idea. If it's a not a game (or steam) update, then something else changed in my system :\

[kallestrop]

@jsalatas since the last update, they have changed something with the ffb. In the games binary folder is now a thrustmaster_bridge_x64.dll file. But i have not recognized any changes with my G29 wheel, so i guess the changes affect only Thrustmaster wheels.

I've done some tests over the past few days and found a setting for myself without need of using the choppy stiffness effect, which is pretty close to my Windows settings.

If someone wants to try out, here are the settings:

My ingame ffb settings which are stored in ~/.local/share/Steam/steamapps/compatdata/227300/pfx/drive_c/users/steamuser/Documents/Euro Truck Simulator 2/profiles/<profile-id>/controls.sii

 config_lines[41]: "constant c_ffenabled 1.000000"
 config_lines[42]: "constant c_ffgain 1.320000"
 config_lines[43]: "constant c_ffspring 1.660000"
 config_lines[44]: "constant c_fffriction 0.000000"
 config_lines[45]: "constant c_ffengine 0.000000"
 config_lines[46]: "constant c_ffsurface 0.880000"
 config_lines[47]: "constant c_ffdamper 0.000000"
 config_lines[48]: "constant c_ffcollis 0.000000"
 config_lines[49]: "constant c_ffg27 0.000000"

1. Start game and spawn the truck
2. Tab out of game (if tabbing out is not working for a reason, you can also switch workspace e.g. [ctrl] [shift] [arrow key left/right]
3. Run pyLinuxWheel with this settings and press apply:

4. Switch back to Game and play :-)

The pyLinuxWheel settings give you the feeling of stiffness effect which you can notice when stopped or driving slowly, while the ingame ffb settings control centering force while driving faster.

Only problem is, when loading a savegame or going into garage and change truck parts or repair truck, the pyLinuxWheel effects are disabled and you have to tab out and press apply button again.

I also have tried to use Oversteer instead of pyLinuxWheel, but Oversteer settings always disabled ingame ffb effects.

[berarma]

@kallestrop, you're setting a second autocenter effect that maybe it's too weak to move the wheel but creates resistance to your hands although only when moving the wheel off the center.

Are you running ETS2 through Proton? I should know how everyone's running the game because the results might be different.

[kallestrop]

@berarma i use Proton because of significant better performance compared to opengl native version. And with my triple screen setup, every additional frame is welcome.

[jsalatas]

@jsalatas since the last update, they have changed something with the ffb. In the games binary folder is now a thrustmaster_bridge_x64.dll file. But i have not recognized any changes with my G29 wheel, so i guess the changes affect only Thrustmaster wheels.

The interesting thing is that Ihave a G29 wheel, not a thrustmaster :\

I run it through steam. My settings are stored in

~/.local/share/Euro Truck Simulator 2/steam_profiles/XXXXXXXXX/controls_linux.sii

where XXXXXXXXX is my steam profile.

The values are the following config_lines[41]: "constant c_ffenabled 1.000000" config_lines[42]: "constant c_ffgain 2.000000" config_lines[43]: "constant c_ffspring 2.000000" config_lines[44]: "constant c_fffriction 2.000000" config_lines[45]: "constant c_ffengine 0.700000" config_lines[46]: "constant c_ffsurface 2.000000" config_lines[47]: "constant c_ffdamper 2.000000" config_lines[48]: "constant c_ffcollis 2.000000" config_lines[49]: "constant c_ffg27 0.000000"

[jsalatas]

In the games binary folder is now a thrustmaster_bridge_x64.dll file.

Sorry for the spamming but @kallestrop that file doesn't exist in my system

[berarma]

In the games binary folder is now a thrustmaster_bridge_x64.dll file.

Sorry for the spamming but @kallestrop that file doesn't exist in my system

He has installed the Windows version.

[kallestrop]

FYI:

SCS Software has completely overhauled force feedback implementation in the latest 1.42beta branch. It seems, that the friction effect which causes the problems is no longer present.

[berarma]

FYI:

SCS Software has completely overhauled force feedback implementation in the latest 1.42beta branch. It seems, that the friction effect which causes the problems is no longer present.

Interesting. Are you still testing with Proton? Would you say it works better now?

[kallestrop]

My first impression is, that new ffb implementation works better than the old one. I haven't tried native linux and native windows version yet, i'll wait until beta ends in a few weeks and test it with all ETS2 versions.

[kallestrop]

SCS Software has released some detailed information of the new force feedback implementation. Maybe there is something of interest for you:

https://blog.scssoft.com/2021/10/force-feedback-faq.html

[berarma]

SCS Software has released some detailed information of the new force feedback implementation. Maybe there is something of interest for you:

https://blog.scssoft.com/2021/10/force-feedback-faq.html

Yes, that's interesting. Basically, they've changed some baked effects for real-time generated effects. It means they've stoped using the spring, friction and maybe some other effect type and now use a constant force effect instead. That solves this issue and it also means the ffb should work with the default kernel module, although still missing some effects.

[Espionage724]

A few weeks ago, I noticed with ATS in both native Linux and Proton that I had no resistance on the wheel when using either the stock driver or new-lg4ff. I didn't debug it back then to know why, and I haven't tried the new 1.42 beta yet (but will soon).

Is there anything special that needs to be done to have any kind of force-feedback and resistance for ATS in Linux?

[kallestrop]

So now as final version 1.42 of ETS2 is out, i tested new force feedback implementation on all 3 platforms (native Windows 10, native Linux and Linux Proton).

• No other force feedback related software was running in the background (e.g. Oversteer or pyLinuxWheel)
• new-lg4ff driver was active in Linux
• I made the test with default controller settings after pressing Reset to defaults button.

Result: I noticed no difference in behavior on all 3 platforms. The friction effect which causes the unsmooth force in the old ffb implementation is no longer present.

[alvarlagerlof]

So is this fixed?

[berarma]

So is this fixed?

The underlying issue isn't fixed but it doesn't happen anymore in ETS2.

[alvarlagerlof]

I see.

[motolav]

The issue isn't limited to the G29, my DFGT gets the same pulsing FFB/choppy steering too, tested on ETS 1.41 with lg4ff. When I start the game with autocenter strength in Oversteer set to 0 it works fine, but if I have it set on before the game is started then I get the pulsing FFB then if I set the auto centering to 0 while the game is running it still does pulsing FFB until I restart the game.

[motolav]

@berarma I just tested ETS 1.41 with the latest patches on master and it seems to be fixed, With auto center on in Oversteer my wheel turns smoothly with a constant force. Anyone with a G29 should try verify the current master tree fixes the ETS 1.41 issue so these patches could make it upstream an extra note: it was after 0.4.0 where the issue was fixed