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

Changing Input (Controller Pak/Rumble Pak) #15

Open
drakecaiman opened this issue Jan 7, 2017 · 3 comments
Open

Changing Input (Controller Pak/Rumble Pak) #15

drakecaiman opened this issue Jan 7, 2017 · 3 comments

Comments

@drakecaiman
Copy link

Some games (like Chameleon Twist) will display an error on startup because it is expecting a Rumble Pak:

chameleon twist u 2017-01-07 05 21 45

Is there currently a way to tell this core that a Rumble Pak is in the controller?

macOS Sierra 10.12.2
OpenEmu 2.04
Mupen64Plus 2.5.2

@clobber
Copy link
Member

clobber commented Sep 23, 2017

I'll fix this with a workaround, but just so you are aware Revision A/Version 1.1 ROM boots fine.

@drakecaiman
Copy link
Author

Thanks for the update!

@ssokolow
Copy link

ssokolow commented Sep 30, 2017

@clobber Good to know, but not necessarily a solution since some users prefer to use the ROMs they dumped from the cartridges they own using a Retrode.

(Disclaimer: I'm a Linux Mupen64Plus user who stumbled across this issue thread while looking up how to resolve this problem on Linux.)

EDIT: In case anyone lands here while looking for a Linux fix, you have to go into mupen64plus.cfg and set mode = 0 (Fully manual) and plugin = 1 for all four [Input-SDL-Control_] blocks.

  • Using the "Mempak switch" or "Rumblepak switch" keybindings ASAP doesn't work.
  • mode = 2 (Fully automatic) causes it to revert whatever changes you make as part of Mupen64Plus startup.
  • mode = 1 (Auto with named SDL Device) will probably also revert your changes on startup, but I didn't test that.
  • Despite only having one physical controller connected, Mupen4Plus's rules for pads 2 through 4 still have an effect in this situation. (You'd think that "Fully Automatic" would set plugged = False for controller 2 through 4 if there's no hardware present, but it doesn't seem to.)

Another thing I didn't think to test was whether setting plugged = False on controllers 2 through 4 was exempt from "mode = 2 resets everything" and whether doing so would avoid the need to set mode = 0 and plugin = 1 on them.

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

No branches or pull requests

3 participants