Random bouts of long rumble and connectivity issues after latest update #616
Comments
|
There were almost no changes made to DS4Windows for version 1.7.0 outside of changes required for ViGEmBus support. I don't have Monster World Hunter but I can test the problem in Retroarch. Also, are you using Retroarch 1.7.6? That is the version of Retroarch that I will be using for testing. |
|
Confirmed this. Also, testing rumble in DS4Windows makes rumble no longer work in games. |
|
It looks like ViGEmBus never returns a 0 feedback state so the rumble loop will repeat constantly. ScpVBus did return a 0 state for the rumble so rumble would stop at that point. |
|
This is definitely a difference between the two drivers. Other games, such as Rocket League, can report a 0 feedback state when using ViGEmBus but that Retroarch core does not. Maybe you would like to talk to Nefarius about this. You can post on the ViGEm forums or on the ViGEm Discord server. |
|
I can second this. In most games there is no issue, but in Dolphin specifically, any rumble remains constant until I go into DS4Windows settings and turn on and off the "Test Heavy/Light settings". I also noticed that in Okami HD, sometimes rumble would keep going constantly until I did something that activated rumble again. |
|
One force feedback related problem has been solved. Trying to diagnose this one would require debugging the driver. I have not gotten around to trying that. Also, I don't know if there was something in the code for ScpVBus that might have caused a 0 feedback state to be transmitted that was not performed by the application interfacing with the Xbox 360 controller. |
|
Getting a little closer. So far, it has been confirmed that ViGEmBus does receive the 0 feedback state from ParallellN64. However, it fails to transmit the state to the ViGEmClient library with the error STATUS_NO_MORE_ENTRIES. |
|
Update before I hit the hay. I have made a small change to the ViGEmBus driver to address the timing issue present with the normal event flow. A simple compromise to check for altered rumble data before attempting to forward a request was made and that was enough to get rid of the problem. Even though ParallellN64 does end up reporting a 0 feedback state at startup, it does some odds things beforehand. A better test case was rolling into a fence to see how that affected rumble. |
|
Does this need some fixes in ViGEm signed driver side (meaning we have to wait until a new signed driver version is released) or can it be workarounded in client side (maybe a timer to "force" 0 state)? I have seen similar "constant rumbling" in ETS2 simulator also. When a truck drives over kerbs and and the truck is steered back to a lane, sometimes DS4 controller seems to get stuck in rumbling state. I had to disable "suspension force feedback" in ETS2 settings. |
|
This problem is due to the way the driver relays rumble data. Unlike ScpVBus which store the rumble state that the client could retrieve later, the ViGEmClient sends a notify request to the bus. |
|
Phone decided I was done. Anyway, the client waits for the next rumble state update and then processes the rumble data. The issue is that a game can send rumble data before the client sends the next notify request. The client will continue to use old rumble data and end up waiting for the next rumble state update. The only workaround would be to rely on the DS4 hardware timeout. |
|
I took a look at the current upstream ViGEmBus code and it looks like this issue would still exist. |
|
Okey. This sounds like a nasty bug and difficult to track down. Timer type of "workaround" to force a zero rumble state in a client side as a backup plan may be good enough solution for now until the fix you prosed is included in ViGem driver and the new driver is signed. |
|
I am just going to disable force feedback support for now. I want to try to get an update out soon so x86 builds will be usable again. |
|
Just want to add that this bug also happens in Sekiro: Shadows Die Twice. Mainly when fighting multiple enemies and forces a lot of rumble, it will then get stuck and you need to disconnect/connect the port to make the controller work again. Setting rumble to 0% in the profile will fix it. |
|
I had solved a similar issue like that (for wiimotehook) for when an application (cemu) was never sending a stop command occasionally. I just put a maximum rumbling time; it's not like many games want to rumble for seconds at max intensity. |
|
Based on past reports, one game that seems more lax on sending long pulsing rumble events is GTA V. People had brought up the old hardware limit (5 sec.) being a problem with that game. |
|
This is a nasty issue and it is difficult to please everyone. The pull request I did few days ago uses 2secs timeout (plus the pull includes an improvement to LoadProfile special action to fix the "one level deep only" issue). If everyone needs to be happy then maybe profile specific config option to set the rumble watchdog timer (0secs = disabled watchdog timer, >0 secs max rumble time without updates from a game). The following pull request doesn't have that kind of config option but maybe the "Test rumble" part of the Options screen could have an edit field for that. Ideally the issue would be fixed in ViGemBus driver level but it may take time before an updated signed driver is available (or fix to that issue is commited in Vigembus code). |
|
Version 1.7.4 is now out and it should resolve the stuck rumble issue. I will keep this issue open for further discussion. https://github.com/Ryochan7/DS4Windows/releases/download/v1.7.4/DS4Windows_1.7.4_x64.zip |
|
Is this intended as a temporary fix? It's definitely better, but it has the effect of rumble lasting up to 2 seconds when it should be around 0.5 of a second etc. Personally I decided it was best to downgrade to 1.6.14 for the time being to fix this. EDIT: some more information: I tested the latest version in Retroarch (the new Mupen64Plus-Next core, in OoT with rumble pak on, rolling into a wall) and found there that rumble lasted longer than it should have. I don't know whether this has been fixed for other problematic scenarios though. |
|
I confirm the new rumble timeout period seems to be enforced in the few games I tested. In The Division 1 & 2 for example, the vibration of every shot lasts for about two seconds. It's not the case with version 1.7.2. In the DS4W settings however, the rumble test/stop option works as intended. |
|
So the fallback timer is still being hit? I will test this again. |
|
Crap. I didn't carry one change over for the ViGEmClient. In effect, only the first notify message in the queue is being used. I have been hopping around too much. I will give this another test and report back. |
|
I screwed up. Version 1.7.5 will just be a ViGEmClient library update. |
|
Version 1.7.5 is out. https://github.com/Ryochan7/DS4Windows/releases/download/v1.7.5/DS4Windows_1.7.5_x64.zip |
|
Everything seems to be working great now from what I can tell. |
|
Looks working on my end. (Phoenix Wright: Ace Attorney Trilogy) |
|
It looks like InputMapper 1.7 has probably suffered from this same problem for at least several months if not since inception. I don't know if IM 1.7 had force feedback support in the early beta builds. https://beta.inputmapper.com/forum/inputmapper-1-7/incorrect-force-feedback/ |
After updating to 1.7.0 I would have dropped inputs and disconnects occasionally. Plus there would be times where the controller starts rumbling for a prolonged time without any obvious cause. It would happen randomly when playing Monster Hunter World and immediately on startup of Ocarina of Time through Retroarch's ParallellN64 core. This is all on Windows 10.
I've tried three different bluetooth adapters, all with the same result. The same thing even happened on a friend's computer with both old and new DS4 controllers. Rolling back to 1.6.14 made everything work as normal again.
The text was updated successfully, but these errors were encountered: