Chord/modeshifts or simultaneous inputs don't work across JoyCons
Consider the following configuration:
GYRO_OFF = ZR
L3 = LSHIFT # Sprint
ZR,L3 = MMOUSE # Open weapon wheel
If using a pair of JoyCons the ZR,L3 binding doesn't activate. I stepped through the code and could clearly see why. Each JoyCon is recognized as a separate device which is mapped to its own JoyShock object that maintains its own button set. Naturally, a button pressed in one JoyShock gets added to its chordStack which isn't accessible from the other JoyShock object when the second button of the chord mapping is pressed.
I was hoping to submit a simple patch to address this but it may require a heavy change which you may not appreciate. Perhaps, it may be necessary to think of a set of buttons separately as single object that can be shared by more than one device. However, such a change may require changes to the configuration language if multiple devices are to be supported in regards to a local co-op setting where different devices are assigned different button mappings.
Good catch. We're currently doing a big refactor (and by "we" I mostly mean @Electronicks ), so now's probably not the time for even a small change, but thanks for bringing this to our attention.
Thanks for the thoughtful feedback and for considering possible scenarios.
That's a very interesting problem. Maybe we can get the same JoyShock object to process the callback of both devices, thus using the same chord stack? With the addition of a pair of commands, say MERGE/SPLIT_JOYCON_PAIR we could get JSM to identify a single pair of different joycons (+/-) and consider them as being part of the same controller.
The cute cheat is that we map controller IDs to JoyShock objects using unordered_map<int, JoyShock*> handle_to_joyshock; So you just need to set the second joycon's pointer to the first's pointer and poof! that'll work! Memory management will require some scrutiny though.
Actually, instead of a whole new command, it could be an argument of RECONNECT_CONTROLLERS, which is convenient because it is where we update that mapping.
This Commit reads like it was meant to fix this issue, but this issue seems to still be present in 2.1.0. Is this a regression or simply not yet addressed?