Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SeongGino opened this issue Mar 27, 2024 · 4 comments · Fixed by #15365
Closed

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

SeongGino opened this issue Mar 27, 2024 · 4 comments · Fixed by #15365

Comments

@SeongGino
Copy link

SeongGino commented Mar 27, 2024

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
Copy link
Contributor

You can test with #15365 please

@SeongGino
Copy link
Author

You can test with #15365 please

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

@pupdeg
Copy link

pupdeg commented May 7, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants