TM T818 Force Feedback interference when controllers input plugin is enabled

[pachuka]

Hello, I recently got the new Thrustmaster T818 wheelbase and am using it with the SF1000 and TX Leather wheels. I was having a lot of random oscillations 0-1 degrees (not just on center, at all rotations) and it seemed to be random and also my wheel would just drop down with no resistance rather than center after startup. This also prevents the Test FFB button in the T818 control panel from working (button does nothing).

I realized I had SimHub on auto-start with windows and as soon as I close SimHub, the wheel automatically recenters and stops oscillating (other than a very small amount around the center) and feels much more like I was expecting.

After realizing that, I started back SimHub and disabled plugins one at a time and restarted SimHub each time until I narrowed it down to the Controllers input plugin. With that disabled the wheel still behaves properly with SimHub running.

I saw a post on Reddit with another user experiencing this same behavior on a different TM wheelbase, but they had thought it was from the Thrustmaster FFB control plugin, but having that enabled didn't affect the behavior of the wheel.

[SHWotever]

Hi !

Thanks for the report, I will check it as soon as possible.

What I can say is that there haven't been any significant changes on this side in recent versions, but indeed once this plugin is enabled it does read the values from the device (and so the wheel is kind of opened in the system from SimHub) to be able to read the values. I feel this is more an issue about how T818 handles idling with no FFB inputs (simhub does not send any of course and let the game do it's work). I still have a TS-PC at home and I will look if it does the same.

If the issue is indeed about how the 818 does handle idling when an applications is only reading inputs with no ffb values being sent the only way is to disable the plugin in the wait of a thrustmaster fix for now. I will look in the wait if I can add some devices exclusions too so it's possible to still use other peripherals.

Can you confirm it's not something new ? And you are experiencing it on all simhub versions ?

[pachuka]

@SHWotever thanks for the quick reply! Not sure with the versions, I observed it on versions 8.3.5, and on 8.3.7. I have the TX from before which had seemed fine to me this whole time (on 8.3.5) and I don't recall anything weird with idling. I do think the idling behavior makes sense as a theory however just given the behavior I've observed.

I can try to uninstall the latest and try out a few of the older versions to see if that helps at all. Is there any particular version you think would be worthwhile to test on?

[SHWotever]

I would be curious indeed that would help to reduce the possibilities: All the past versions are available here : https://www.simhubdash.com/official/

In 8.3.X I did introduce a little 3 second delay to make simhub start faster, and only catch controllers later in the process (controllers are not needed in the first seconds of simhub startup, no need to wait for it) , that's the major change, but I doubt it's the cause .

[FullPace]

There are reports on the discord that disabling the controllers plugin also fixes ffb issues with the simucube. something unintended seems to make some trouble...

[SHWotever]

I think I found the guilty part, retrieving how many povs and buttons the controller had was initializing the FFB on thrustmaster, maybe on simucube too. Looks like this api has some weird side effects. I removed it everywhere and will only use the maximum povs independently of how many buttons/povs are available, it's not ideal but this will remove any interferences, better stay stealth and not mess up with FFB.

NB : Control mapper plugin was affected too but way less because the joystick was only instancied for a very short time, time to grab thoses informations then released, reducing this effect, but as a security measure I removed it too.

[pachuka]

Wow, nice find/thanks for the speedy update! Will give the latest version a try today.

[SHWotever]

Actually I had reports with simucube and I couldn't reproduce it. I had been hunting it desperately in the wrong place (control mapper). But I still had a tspc in my drawers (big drawers :D) and the symptoms were indeed way more obvious, once connected the ffb was getting initialized unlike it was before, in my case the thrustmaster control panel was still working fine but I guess it's model dependant. After some steps by steps debugging I could point the guilty addition (reading pov count to process all the available povs).

Let me know! 🤞

[FullPace]

Thats great! One guy on discord mentioned the problems disappeared after uninstalling vjoy. just as another hint. I don’t know if this is connected to your solution in any way

[SHWotever]

Vjoy is a bit different, there have been many variations of VJoy, with or without FFB, some versions have FFB enabled maybe the game was sending the FFB to it instead of the wheel, but overall that would not be triggered by a simhub update. That's also why I added an arduino "driverless" device for the "control mapper" feature, I really like Vjoy, but it can add some struggle sometimes :D.

But overall about VJoy I guess the troubleshooting method was not "organized" changing many things at the same time until it works ,just a feeling of course :D.

[FullPace]

Yes, I thought maybe it could be a reason that people installed vjoy with the simhub update when control mapper was introduced and then it‘s of course hard to tell what causes certain problems.

[pachuka]

@SHWotever - Sorry for the delay! Got a chance to test this out - I re-enabled all the controller plugins and confirmed that it fixed the issue I was experiencing on the TM818.

Thank you for fixing this so rapidly. I can go ahead and close this, or if you want to do that after other folks confirm, that's fine too :)

[SHWotever]

Thanks for your feedback ! I got also some side confirmations that it's OK now. I close it ;)