Ryochan7
Rumble stops after ~5 seconds after 3.1.12
Describe the bug Rumble stops before game send stop data to the gamepad.
To Reproduce Noticed this while playing Death Stranding with x360 mode.
During ziplines use the rumble works in the entire trip. The new version stops it around 5 seconds after start.
Expected behavior Rumble as if there is no tomorrow (sorry for this joke. I couldn't resist hehe)
Screenshots and Logs NA
Desktop (please complete the following information):
- Controller Make and Model: Sony DS4 v.2 (CUH-ZCT2U)
- OS: [e.g. Windows 10 Pro Build 19045.2728
- DS4Windows Version [e.g. 3.1.12]
Additional context I think none is necessary as this isn't the expected behavior.
Not playing many games lately so I didn't remembered this until it happens again.
On the opening scene of The Last of Us Part I, the car scene when they enter offroad. Rumble stops after 5 seconds...
DS4win version: 3.2.9
No problem here.
Go to Profiles > Other tab and make sure you didn't input any rumble duration other than 0 seconds.
No problem here.
Go to Profiles > Other tab and make sure you didn't input any rumble duration other than 0 seconds.
Hum... this is a problem if one can't reproduce the problem. Also, isn't this setting just for testing? It's 0 anyway.
I'll try to install the last known version that I know worked to see if that version will work or not but I'm pretty sure this isn't a problem at my side...
This is how my settings are in that tab
Well, it's a problem on your side if nobody else can reproduce it ;)
"Isn't this setting just for testing?"
No, you can use it to auto stop the vibration after a certain duration. It was useful a few years back because of a bug that triggered infinite rumble in some games.
What is your version of ViGEmBus? The latest 1.21.442 is recommended. Not sure if it's automatically installed by DS4W.
Well, it's a problem on your side if nobody else can reproduce it ;)
"Isn't this setting just for testing?"
No, you can use it to auto stop the vibration after a certain duration. It was useful a few years back because of a bug that triggered infinite rumble in some games.
What is your version of ViGEmBus? The latest 1.21.442 is recommended. Not sure if it's automatically installed by DS4W.
That's the version I have installed here. Just checked.
I also tested DS4win version 3.1.2. Rumble works as long as the car is offroad then stops as soon as it's back to road. Then tested by opening the latest version and the 5 seconds then stop rumble problem is there.
I am using ViGEm 1.16.116 with the latest version of DS4Windows 3.2.17 for use with Windows 8.1. and the problem is there, you can easily reproduce it with XinputChecker and enter any value to rumble or even in the "Other" tab. The last working version I've looked at is 2.1.23, since 2.2.0 fixed the bug where the rumble wouldn't stop vibrating in some cases, but now that limit exists. I have a DS4v2 clone.
Not even sure what change made it happen but I can confirm that rumble is limited to the 5 second hardware limit. Not really worried about a pseudo-infinite rumble so the XInputChecker test does not matter for me in this case. However, even though I hate the game, it does affect rumble support in GTA 5.
Testing this with a DualSense controller. It looks like something is sending a rumble packet with (0, 0) through ViGEmBus which is causing vibration to stop; checking the data given in the notification delegate confirms this. The tester in DS4Windows works fine and vibration will continue until the test is explicitly stopped. The hardware rumble limit workarounds in DS4Windows seem to be in tact. The problem seems to happen most while switching windows. Is Windows actually sending the rumble packets out? Not sure when that started being a thing.
Going to leave this open for a bit but this might be intentional.
Testing this with a DualSense controller. It looks like something is sending a rumble packet with (0, 0) through ViGEmBus which is causing vibration to stop; checking the data given in the notification delegate confirms this. The tester in DS4Windows works fine and vibration will continue until the test is explicitly stopped. The hardware rumble limit workarounds in DS4Windows seem to be in tact. The problem seems to happen most while switching windows. Is Windows actually sending the rumble packets out? Not sure when that started being a thing.
Going to leave this open for a bit but this might be intentional.
I don't know for sure in what version this started but I can tell you at least a version that don't have this issue: 3.1.2. I tested this some time ago. This may help find what was changed or was ignored at that time.