[PR #1659] pad: improve messaging when UI config doesn't match savestate config, and document some edge cases #608

New Issue

claunia · 2026-01-29T19:08:46Z

claunia commented

2026-01-29 19:08:46 +00:00

Original Pull Request: https://github.com/stenzek/duckstation/pull/1659

State: closed
Merged: Yes

Adds 8x controllers and memcards into the savestate.
maintains backward compatibility
simplifies some aspects of the logic used to load states
renames NUM_SLOTS to NUM_DEVICES because slots are ambiguous (2 sio slots on a console, 4 slots per mtap, sometimes one or both are called 'ports' instead, etc)

This PR can be merged as it is, or choose to wait until the full multitap impl on the emu backend is finished (eg, Incremental strategy for better reviews vs. a monolithic commit that bumps the savestate version # only once). I'm expecting to have the multitap functionality part ready before 2/22.

testing

I ran lots of tests loading states from prev version that contained about 6x different variations of controller and memcard bindings on the host UI.

for discussion

One of the typical caveats of emulating mtap is mapping the controllers. Not all games enumerate mtap controllers in the same way. For example, if a user has an mtap on slot 1 and a regular controller on slot 2 of the console:

device 1 -> mtap 1 slot 1
device 2 -> console slot 2
device 3 -> mtap 1 slot 2

... or ...

device 1 -> mtap 1 slot 1
device 2 -> mtap1 slot 2
device 2 -> console slot 2

This shouldn't impact how savestates are handled in any case. It should probably be implemented as a game-specific remap setting that just changes how emu devices 1->8 are shown to the user in the UI.

**Original Pull Request:** https://github.com/stenzek/duckstation/pull/1659 **State:** closed **Merged:** Yes --- - Adds 8x controllers and memcards into the savestate. - maintains backward compatibility - simplifies some aspects of the logic used to load states - renames NUM_SLOTS to NUM_DEVICES because slots are ambiguous (2 sio slots on a console, 4 slots per mtap, sometimes one or both are called 'ports' instead, etc) This PR can be merged as it is, or choose to wait until the full multitap impl on the emu backend is finished (eg, Incremental strategy for better reviews vs. a monolithic commit that bumps the savestate version # only once). I'm expecting to have the multitap functionality part ready before 2/22. ### testing I ran lots of tests loading states from prev version that contained about 6x different variations of controller and memcard bindings on the host UI. ### for discussion One of the typical caveats of emulating mtap is mapping the controllers. Not all games enumerate mtap controllers in the same way. For example, if a user has an mtap on slot 1 and a regular controller on slot 2 of the console: device 1 -> mtap 1 slot 1 device 2 -> console slot 2 device 3 -> mtap 1 slot 2 ... or ... device 1 -> mtap 1 slot 1 device 2 -> mtap1 slot 2 device 2 -> console slot 2 This shouldn't impact how savestates are handled in any case. It should probably be implemented as a game-specific remap setting that just changes how emu devices 1->8 are shown to the user in the UI.

claunia added the pull-request label 2026-01-29 19:08:46 +00:00

claunia closed this issue

2026-01-29 19:08:46 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/duckstation#608