RPCS3 / rpcs3

PlayStation 3 emulator and debugger
https://rpcs3.net/
GNU General Public License v2.0
15.36k stars 1.91k forks source link

PS Move "Fake" Handler does not disable base controller that it's attached to #15362

Closed SeongGino closed 5 months ago

SeongGino commented 6 months ago

Quick summary

On PS Move enabled games, when using the "Fake" Move Handler to have a controller in Port 7-through-4 behave as Motion Controller 1-through-4, the base controller that's used is still receiving input from the base controller.

Details

Because the controller port (7 in this case) is receiving two different types of emulated input, games with multiplayer support will misinterpret it as two separate controllers - two players - on the same port. This leads to quite a few unintended consequences, such as inadvertently activating multiplayer in a session with only one controller just by pressing Start.

Tested with multiple emulated controller types on Port 7, from the basic Pad to Drums to Guitar to Dance Pad--even the PS Move Navigation type (pictured) will still show as a Wireless Controller in the same port, when that should be disabled by the parasite Move Controller.

It's been a while since I've used my PS3 (since I have a Move/Camera, as well as the game demonstrated) but from what I recall, normal Pad-type controllers should never be able to "share" a port with Motion or other types of controllers?

Pictured: Deadstorm Pirates, as part of TIME CRISIS: RAZING STORM [BLUS-30528]; current custom controller profile for the game on the right (ports 1-6 are set to Null, so only Port 7 as pictured is enabled--controller is the gamepad output of a lightgun, set to PS Move Navigation controller) 2024_03-26 205826

Attach a log file

RPCS3.log.gz

Attach capture files for visual issues

No response

System configuration

System: Arch Linux Kernel: 6.7.8 CPU: AMD Ryzen 5 5600X GPU: NVIDIA GeForce RTX 3060ti GPU Driver: 550.67 (proprietary) DE: KDE Plasma 5.27.10

RPCS3 version: 0.0.31-16236 (efbf0440e) | Official AppImage

Other details

EDIT: For what it's worth, when going to either of the Player slots and pressing a button to set what controller corresponds to which player, it will always map the in-game slot to the Motion Controller on Port 7 and not the Wireless Controller; but pressing start while in the gameplay proper, even when overwriting this, will cause the Wireless Controller to join in as the unassigned player slot.

Megamouse commented 6 months ago

You can test with #15365 please

SeongGino commented 6 months ago

You can test with #15365 please

Building from the fake_move branch, it does seem to resolve the issue.

pupdeg commented 5 months ago

Just wanted to note that this same issue appears for the new GunCon support. The fake pad you use is also connected, which makes it seemingly impossible to start TC4 as it defaults to "wireless controller 1" instead of "guncon 1" when you press the trigger, because they're both mapped to X on player 1. You can play 2P instead, but the trigger is still mapped to X so 2P keeps on ducking when you shoot.

Rising Storm at least defaults to Guncon 1 as player 1, but has issues as X/trigger activates P2, who is auto-assigned to "wireless controller 1".

Florin9doi commented 5 months ago

Try to press the left mouse button instead of X, without mapping the MB1 to X