Stop rumble when game ends

[beaudry]

Fixes #327

I'm not sure if the header should be placed alphabetically, or with the other common headers

[JLaferri]

I don't think doing this in Dolphin is correct. This should be handled by the game. We tried to fix it at one point and it didn't work. Also I was never able to repro this reliably. If you can find a way to repro it 100% of the time that would help us fix it for sure.

[beaudry]

I found the ASM repo after having done this PR, and I agree that it would be preferable to have the game handle it.

My way of testing was by doing L-R-A-Start while hitting a blastzone.

Should I start learning asm? 😛

[beaudry]

I just tried and I did it 20 times in a row without any problem (using LOCAL_TESTING)

Update: for the first L-R-A-Start, the rumble stops correctly, but the rumble stays for the rest

[JLaferri]

Can you explain your repro steps exactly? I know you posted it in the issue but the more specific the better.

[beaudry]

Here's everything I found about the Slippi rumble bug 🙂

In summary:

• Never happens on the first LRAS
• Never happens on port 1 and 2
• Happens each subsequent reset on port 3 & 4
• [Not shown on the video] Disconnecting from the opponent changes nothing
• [Not shown on the video] The same behaviour happens in teams

Hypothesis: The "stop rumbling" signal is sent to the in-game player port, and that port is never redirected to the actual port. Hence why it works when plugged in port 1 & 2. Maybe the port redirection is destroyed before the rumble signal is sent?

[JLaferri]

Here's everything I found about the Slippi rumble bug 🙂

In summary:

• Never happens on the first LRAS
• Never happens on port 1 and 2
• Happens each subsequent reset on port 3 & 4
• [Not shown on the video] Disconnecting from the opponent changes nothing
• [Not shown on the video] The same behaviour happens in teams

Hypothesis: The "stop rumbling" signal is sent to the in-game player port, and that port is never redirected to the actual port. Hence why it works when plugged in port 1 & 2. Maybe the port redirection is destroyed before the rumble signal is sent?

Excellent research and thanks for the super detailed video! I think your hypothesis is likely. It also explains why I was never able to repro it since I play in port 1/2 generally.

I'll look into it more closely.

[beaudry]

Great! Can you keep me updated too? I'm really interested on how to fix it, and espescially why the bug doesn't occur the first time. 😃

Happy Holidays too 🎄

[JLaferri]

Okay so I "fixed" the issue. I write fixed in quotes because it isn't exactly the most fulfilling fix. In truth I worked around the issue. I unfortunately don't know enough about how rumble goes from game state -> controller rumble update well enough to be able to debug the issue directly.

Unfortunately we just did a release so likely it'll be a bit before this fix goes live.

You can find more info about the "fix", along with some of my debugging notes in the PR: project-slippi/slippi-ssbm-asm#85

[JLaferri]

The fix for this was released yesterday but it seems like this issue can still happen. Might need to figure out steps to reproduce it with the new changes now...

https://twitter.com/Fizzi36/status/1491227558343737344?s=20&t=ngd_Lh9lZ5bt7c3RGwL-1w

[beaudry]

Hmm, maybe the fix worked only when the L - R - A - Start happens on the client side. We'd have to test with two real players.

Also, Axe was playing on port 1, which is different from before

[JLaferri]

Hmm, maybe the fix worked only when the L - R - A - Start happens on the client side. We'd have to test with two real players.

Also, Axe was playing on port 1, which is different from before

Yeah I noticed that too. I haven't heard anyone report it since then though... we had some minor issues right after launch so I wonder if it was related to that.