Skip to content

Wiimote to GunCon3#18154

Open
SomeoneIsWorking wants to merge 10 commits intoRPCS3:masterfrom
SomeoneIsWorking:wiimote-to-guncon3
Open

Wiimote to GunCon3#18154
SomeoneIsWorking wants to merge 10 commits intoRPCS3:masterfrom
SomeoneIsWorking:wiimote-to-guncon3

Conversation

@SomeoneIsWorking
Copy link

@SomeoneIsWorking SomeoneIsWorking commented Feb 6, 2026

So I could play Deadstorm Pirates 2 players with DolphinBar + 2 Wiimotes
99% of this is AI assisted development.
I reviewed the code and the functionality.
There is this logic where you might find it weird.
It maps first available player with GunCon3 to slot 0.
So if you have P4:G and P6:G, you'll have P4:0, P6:1
This is intentional because I couldn't figure out why P2 is reserved and I needed to map to P1 and P2.

Has a GUI so you can see your Wiimotes and remap them.

Enabling PS Move cursor overlay will also show GunCon3 IRs on the screen.

NOTE

On Linux you'll need udev rules (same as Dolphin) for this to work.
Put THIS FILE in /etc/udev/rules.d/

Copy link
Contributor

@Megamouse Megamouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll do a proper review at a later point

@RipleyTom
Copy link
Contributor

I really do not like the overall structure of this.
Guncon3 handler was simple, someone chose their pad in pad handler and set it to guncon3.
What this project should do is have a wiimote pad handler and maybe some special handling if you need more than just the translated to ps3 inputs. The pad handler should still be an authority for the pads and we shouldn't have a special wiimotemanager apart from everything else.

@Megamouse
Copy link
Contributor

I really do not like the overall structure of this. Guncon3 handler was simple, someone chose their pad in pad handler and set it to guncon3. What this project should do is have a wiimote pad handler and maybe some special handling if you need more than just the translated to ps3 inputs. The pad handler should still be an authority for the pads and we shouldn't have a special wiimotemanager apart from everything else.

The author is trying to emulate a mouse, not a pad.
So a pad handler would not really make sense for this purpose

@SomeoneIsWorking
Copy link
Author

SomeoneIsWorking commented Feb 7, 2026

What this project should do is have a wiimote pad handler

I agree with you. I actually tried this first but couldn't succeed. I might try it again.

It was very confusing for me to even work on this because:
There are devices and emulated devices menus at the top.
There are devices in I/O settings.
There are device handlers and device classes in pad settings.
I couldn't make much sense of the most things.

@RipleyTom
Copy link
Contributor

Like Megamouse say it's probably fine. I now realize wiimotes have like their own overarching IR usb thing that reports positional data so it's more akin to a separate device than a normal wiimote.

@SomeoneIsWorking
Copy link
Author

wiimote_continuous_scanning was a mock/fake, I removed it

@SomeoneIsWorking
Copy link
Author

SomeoneIsWorking commented Feb 7, 2026

My last update didn't fix IR reconnection. Trying again
I'll tie connection state to IR health and add IR checks to ask the Wiimote, "are we IR connected"

Update

Works much better now albeit code might be a little bloated.

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

Successfully merging this pull request may close these issues.

4 participants