Document exact controller types and the 4-controller case in README

Spells out what the three controllers_override values actually create
(Xbox One, PS5 DualSense, Switch Pro Controller - confirmed against
inputtino's own source, not just the enum names) instead of leaving the
reader to guess from bare AUTO/XBOX/PS/NINTENDO tokens, plus a note that
forcing a non-matching type only affects on-screen button-prompt
artwork, not functionality.

Adds a 4-controller section: Cemu's own Input Settings goes up to 8
slots and Wolf's wire protocol has no hardcoded 4-controller cap
(confirmed against control/input_handler.cpp), so the ceiling in
practice is the Moonlight client's own limit. With only 3 concrete
forced types available, a 4th controller can't get a guaranteed-unique
GUID - documents the one-at-a-time Cemu binding workaround for that
case, flagged as reasoned but not confirmed live.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
This commit is contained in:
Claude
2026-09-03 15:46:10 +00:00
parent 2005534b12
commit 866d895357
+44 -4
View File
@@ -4038,10 +4038,26 @@ cd $WOLF_DIR && ./manage.sh controllers
\`\`\`
Picks your paired Moonlight client (auto-selected if there's only one),
then asks how many controllers to configure and what type to force each
one to (\`AUTO\` / \`XBOX\` / \`PS\` / \`NINTENDO\`) — e.g. controller 1 =
Xbox, controller 2 = PlayStation. This calls Wolf's own REST API
(\`controllers_override\`, per Wolf's own docs' "Override the default
joypad mapping" section) rather than hand-editing \`config.toml\`.
one to. There are only **3 concrete types** (confirmed against Wolf's own
virtual-pad source, \`inputtino\`) — not one per real controller brand:
- \`XBOX\` → an **Xbox One** controller specifically (not Series/360)
- \`PS\` → a **PlayStation 5 DualSense** specifically (no separate PS4 option)
- \`NINTENDO\` → a **Switch Pro Controller**
- \`AUTO\` → auto-detects from whatever the physical controller reports
(this is what causes the collision in the first place — e.g. every
8BitDo pad set to "Switch mode" reports as Nintendo, so AUTO gives all
of them the identical GUID)
e.g. controller 1 = \`NINTENDO\` (matches an 8BitDo pad's native Switch
mode), controller 2 = \`XBOX\`, controller 3 = \`PS\`. This calls Wolf's own
REST API (\`controllers_override\`, per Wolf's own docs' "Override the
default joypad mapping" section) rather than hand-editing \`config.toml\`.
Forcing a non-matching type doesn't break any buttons — Moonlight still
translates your controller's actual button presses onto whichever virtual
pad type you pick — it just means that controller's on-screen button
prompts (e.g. "press ✕") won't visually match what's printed on the
physical pad. Purely cosmetic.
**Reconnect (or fully restart) the Moonlight stream afterward** — this
applies when Wolf creates each controller's virtual pad for a *new*
@@ -4052,6 +4068,30 @@ If \`./manage.sh controllers\` says the API socket isn't up yet, re-run
mount this command needs) and then \`docker compose up -d\` to recreate the
Wolf container.
### 4 controllers (Cemu / Wii U games)
Wii U hardware itself tops out at 4 local players, and everything upstream
supports at least that many: Cemu's own Input Settings allows up to 8
controller slots (confirmed against Cemu's own wiki — well above what any
Wii U game actually uses), and Wolf's wire protocol tracks controller
slots via a bitmask with no hardcoded 4-controller limit (confirmed
against its own \`control/input_handler.cpp\` source) — the practical
ceiling is whatever your Moonlight *client* supports (commonly 4 on
PC/iOS).
The catch: with only 3 concrete forced types (above), controller 4 can't
get its own guaranteed-unique GUID — it has to reuse \`XBOX\`, \`PS\`, or
\`NINTENDO\` and land back in the same ambiguous-GUID situation with
whichever one it matches.
**Workaround for the 4th controller: bind it in Cemu one at a time.**
Disconnect (or just don't touch) every controller except the one you're
currently binding, then use Cemu's own "press a button to detect" step
for that slot. With only one Wolf virtual pad actually emitting input at
that moment, there's nothing for Cemu's picker to confuse it with,
regardless of which type it's sharing a GUID with. This is a reasoned
workaround, not one confirmed working live — if it doesn't pan out,
that's useful to know.
## EA games (Battlefront II 2017, etc.)
EA titles require GE-Proton and the EA App to be installed inside the Wine
prefix. The EA App handles authentication — without it, the game launches