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

Allow button profiles to be specified as a collection #403

Open
m4-used-rollout opened this issue Mar 24, 2024 · 0 comments
Open

Allow button profiles to be specified as a collection #403

m4-used-rollout opened this issue Mar 24, 2024 · 0 comments
Labels

Comments

@m4-used-rollout
Copy link
Member

m4-used-rollout commented Mar 24, 2024

Currently, we handle dual runs by creating "dual" versions of our normal input modes. But this assumes that both sides are absolutely identical, and is inadequate if either side needs special configuration.

Instead, I propose we allow a "ButtonProfiles" config that can specify a dictionary of arbitrary sides individually. This means we could have entirely different consoles playing simultaneously, and paves the way for a possible future triple/quad/etc run.

ButtonProfile would still be supported for single runs, and the legacy dual input modes could also be supported through that, as most of the time we are using identical setups on both sides.

As far as how this would interact with !disabledualmode, it should probably feed all inputs to all sides, and as long as one side is able to parse to an input, it is counted as an input and added to the queue to then be sent to only the sides that could parse it.

Example config structure:

"ButtonsProfiles": {
    "left": {
        "ButtonsProfile": "nds",
        "TouchscreenAliases:" [ ... ],
        "GameAliases": "hgss",
        "MaxSetLength": 2,
        "MaxSequenceLength": 18,
        "ControllerPrefix": "P1 "
    },
    "right": {
        "ButtonsProfile": "gb"
    }
}

ButtonsProfile, TouchscreenAliases, GameAliases, MaxSetLength, MaxSequenceLength, and ControllerPrefix could be added to an interface that both InputConfig and this new structure would implement. Everything should have default values. If possible, infer P1 and P2 from the order the keys are specified in. Otherwise, the default prefix could be the key name.

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

No branches or pull requests

1 participant