TASEmulators
[Nymashock] U+D/L+R restriction incorrectly applies to PSX Dance Pad
Probably more of a Enhancement or QoL, but it would also match what upstream does.
Songs in DDR require U+D/L+R to be played, and because you're playing with a pad you expect it to work more or less "out of the box". It's more for those that don't read that you have to set "U+D/L+R" to "Allow" to actually more functional.
Upstream allows this when controller port is set to DancePad and not any other controller configuration.
These seem to use the same wire protocol[^1] as the gamepad/DualShock, so while I believe we could change the button names as a hack, it would mean the frontend (and API consumers) would have another set of buttons they'd need to handle for no reason.
[^1]: As evidenced by the fact that other tech has been tripped up by the unexpected L+R in the past: https://en.wikipedia.org/wiki/Dance_pad#Caveats
This would probably be nice, but I'm not sure if it's necessary to handle this in a special way. There are most likely other cases where supporting L+R by default would be nice (in general, in a TASing environment, you want this set anyway).
Last I looked into this it doesn't seem too easy to hack this in for a specific core+controller combination as the frontend does not usually, and also shouldn't need to know about that stuff.
As mentioned in #3453, this could perhaps be done by removing the UdlrControllerAdapter and replacing it with some kind of linked button concept similar to the existing AxisConstraint class, but for buttons instead of axes. That would probably be a clean solution, however it requires the core to define a proper ControllerDefinition with all constraints explicitly defined, which may be a lot of extra work for cores with generated controller definitions like nymashock is.
The UdlrControllerAdapter already hard-codes an exception for the N64 C-buttons, but that can't be done for the dance pad as those buttons can't be uniquely identified by name.