-
Notifications
You must be signed in to change notification settings - Fork 757
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
Inconsistent mappings in-game vs menus #5467
Comments
D2R uses the |
This is now fixed, I'm guessing the remapping PR fixed this somehow |
@EvilToasterDBU mentioned this is still an issue in #5506 for PlayStation/Xbox controller layouts. I figured I'd reopen this issue rather than wait for another write-up. |
Honestly, this issue is deceptively complicated. The madness stems from the options SDL gives us for identifying controller buttons via the When not using button labels, SDL assumes Xbox layout. In other words, devilutionX/Source/controls/game_controls.cpp Line 304 in c71eb0f
Note that the section which was recently added to the wiki talks about what's most intuitive for PlayStation users, but there actually is no consistency on PlayStation because Sony adopted Nintendo layout in Japan and Xbox layout in the US. It seems they recently made the decision to adopt the Xbox layout in Japan on the PS5 menus, but games apparently still use Nintendo layout. Also, some PS1 games released in the US use the Nintendo layout. However, because the padmapper is entirely configurable by the user, it uses the positional button mapping defined by SDL. So even if the game detects that you are using a Nintendo layout, the bottom button will register as the A button when mapping your gamepad's buttons to actions in the settings menu. This has the advantage of being positionally consistent even if the user changes the type of gamepad they're using. But it has the disadvantage of making the mapping, and by extension the defaults, completely independent of the layout of the gamepad. Fundamentally, the inconsistency occurs because the menus are layout-aware and the padmapper is not. Astute observers would be quick to notice that I mentioned an advantage as well as a disadvantage to the current approach. Unfortunately, this means that changing the behavior would fix one problem and introduce another. Since the padmapper is configurable, I'm inclined to leave the behavior as-is, but I can't deny that the inconsistency in the default mapping is kind of frustrating to deal with. At this point, I'm open to suggestions. |
I think that my proposal will be much more difficult to implement, but I think that there should be a PS1-like control layout, or rather a cross between the one that already exists and the one that is offered in the PS1 version of the game, because such a layout has a logical sequence (after all, it is logical that the main control buttons are closer to the finger and it is illogical to perform a more important action by reaching for the next button) + those who have played diablo on PS1 will not be confused in the management. Regarding the problem of determining the physical layout of the buttons, as a last resort, you can probably come up with some kind of crutch. For example, if it is determined that the gamepad does not correspond to the "*known reference", then the user will be asked to manually identify the ABXY buttons in some setting. (Sorry for the poor-quality language, I'm not a native English speaker) |
Have you tried using the latest test builds? Padmapper lets you change the control layout in the Settings menu. I'm unfamiliar with the controls from the PS1 version of Diablo so if there's some reason you aren't able to set it up the way you like, it would be helpful if you could elaborate on the reasons why.
Currently, we are automatically detecting the layout using devilutionX/Source/controls/devices/game_controller.cpp Lines 237 to 279 in c71eb0f
However, I had considered making |
Yeah probably wouldn't hurt to have it auto/nintendo/xbox |
Would that be possible to select between most popular layouts (ps/nintendo/xbox) + have the option to customize these, or even provide a custom mapping from scratch? |
TBH, that sounds like an overly complicated setup for a single game. It might be nice to have profiles for couch co-op, but we don't have couch co-op. More realistically, for 1.5.0 we will have remappable controls that are saved in the INI file. Mappings can be modified through the Settings menu, and different control schemes can be saved/restored by copy/pasting the |
As mentioned in #6923, looks like A/B are not getting swapped in the main menu on the Switch. |
I had assumed that people were trying to switch the buttons because they are often switching between consoles and want to use a consistent layout across systems. However, I tested 1.5.2 in Ryujinx just now and confirmed that the game appears to be using the generic layout instead of the Nintendo layout. Good catch. |
Without making things overcomplicated, maybe a simple "Swap A and B buttons" somewhere in the settings could be simpler? This leaves the freedom for the player to choose his favorite navigation method, without forcing him to adapt when changing gaming device. For example, since I play mostly on the switch, I've swapped those buttons system wide on both my Xbox and Playstation. But someone else could prefer to keep all consoles in their default settings. |
We should just ad hear to the platform standard like all other games on the systems. |
Fair enough. |
As of #5464 the buttons in the main menu and in-game menus are now consistent.
However, they are both inconsistent with the buttons in-game, e.g. inventory management.
The "cancel" button is used as the primary action, the "confirm" button is used to bring up the spell menu, close inventory, etc. Should be the opposite for consistency
The text was updated successfully, but these errors were encountered: