You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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
andP2
from the order the keys are specified in. Otherwise, the default prefix could be the key name.The text was updated successfully, but these errors were encountered: