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:
+44
-4
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user