-
Notifications
You must be signed in to change notification settings - Fork 0
Add mapping for Nintendo Switch Pro Controller #4
Conversation
Added mapping for Nintendo Switch Pro Controller.
Updated to add mapping for Nintendo Switch Pro Controller.
This is a tricky one. Generally, in xinput/PC land, the xbox layout is king, and the buttons are strongly associated with their positions on the controller. What I'm saying is, when a developer assigns an action to the "X" button, they explicitly mean they want you to press the button on the left side of the diamond to perform it, regardless of what the label may be. You generally don't look at your controller while playing a game, so this is reasonable. Your desired configuration is valid, of course, but I believe that it would be less preferable overall to the greatest number of people. What I would recommend is getting used to the idea of the xbox layout being associated with its button positions, then if you really want say, the "A" action to be performed via the button on the right of the diamond, remap it in the game's options. I appreciate the effort here, but the issue is that this would apply to everybody using the switch pro controller, who would most likely prefer to use the xinput layout directly because they'd be familiar with it from playing PC games. It is also worth noting that the default html5 gamepad layout for the switch controller works via button positions, rather than labels, which I believe are more important to keep consistent across controllers, since you're generally not looking at the button labels as you play. In essence, in xinput and the html5 gamepad API, "A, B, X, Y" are just aliases for "Bottom, Right, Left, Top". Just memorize that mapping and you should be golden. I do understand your frustration though because it always messes me up when I play games on Nintendo systems. Eventually it feels natural enough after playing for a bit. This also puts me in a difficult spot because this gamepad mapping library has been causing us nothing but trouble lately, and since the native html5 gamepad api mappings have essentially standardized to match xinput, I was planning on removing it altogether. That would make this change impossible. |
But, if you REALLY want your labels to match, there is a utility you can use. It's called x360ce. You can configure it per-application to remap any button letter to any other real button. Then your button labels would always match up, even through Rainway. |
However, you make a good point in that we should have a system to allow user-specific overrides of certain button mappings. The problem is just that at this point, we are unable to accept a global mapping change such as this, which would affect everybody using the application. We will definitely be working on that in the near future. |
Thanks for your feedback. I'll try x360ce. I know in my case I have played only minimal amounts on Xbox, and most of my controller experience is from Nintendo. Because of this, I am used to the layout of the switch controller. Whenever I go into menus, for example, I will hit the A button to select, which is cancel on the Xbox layout. This causes my friends no end of trouble when I am actually playing on an Xbox, as my muscle memory makes me press B. It is certainly understandable that this may not be for everyone. I like what steam input did, having a toggle for Nintendo layout, and if this was possible to impliment it would be the ideal solution. |
I'll close #3 and this issue now. |
I have created a set of mappings with https://ericlathrop.github.io/html5-gamepad-configurator/ on firefox on windows and them put them in there own .json file under /mappings/ and added them to /mappings/index.js.
My aim here is to create a mapping for the switch pro controller that has the results respect the lables on the controllers buttons, where compaired to an xbox controller, the A and B and X and Y buttons are switched.
I am unsure about quite how this project works, so I have created this PR after looking at previous commits. Please have a look at my commits before merging them.
This PR should fix #3 that I created.