The keyboard shortcut for rotating the game view can be set to Enter or KP Enter, but not both

[jgottula]

OS: Windows 8.1
Commit/Build: 77f1905

---

Original RCT2 allowed rotating the view via either the normal Enter key or the keypad Enter key, interchangeably.

OpenRCT2, in its present state, does not allow this. If the keyboard shortcut is bound to "Return" (the default), then only the normal Enter key will rotate the view. If the keyboard shortcut is instead bound to "Keypad Enter", then only the keypad Enter key will rotate the view. There does not appear to be any way to allow both Enter keys to trigger the action.

---

I did look for duplicate reports on this, but didn't find anything recent. Way back in 2014, issue #651 was filed, concerning this same problem, and there was a fix for it in #653. But in the years since, my understanding is that basically all of the relevant code has been refactored and rewritten, making that moot.

I have no idea when this became a problem again, but I would assume that it was probably when the current keyboard shortcut system code was written up. I could have done a big bisect to pin it down for sure; but it doesn't seem terribly important, since the reason for the issue in the current code is quite straightforward.

In the current code, the keyboard shortcut system works via a series of simple 1:1 mappings between a single SDL scancode (possibly OR'd with a modifier key) and the function to be executed when that scancode is matched. And of course, since there are two distinct SDL scancodes for normal Enter and keypad Enter (SDL_SCANCODE_RETURN and SDL_SCANCODE_KP_ENTER), only one or the other can be assigned to the mapping for SHORTCUT_ROTATE_VIEW_CLOCKWISE; not both.

---

So... it seems that a resolution to this issue would probably either involve (a) a more complicated keyboard shortcut system that allows multiple keys to be bound to the same action (which would be plenty of work, and would make the UI a bit more complicated for users, but would ultimately allow for greater flexibility); or (b) some special-casing for the Enter keys (which might be a bit ugly, but would be simpler). The latter approach appears to be more-or-less what was done way back in #653.

Any special-casing, if done, I reckon would probably be put into keyboard_shortcut_handle and/or keyboard_shortcut_handle_command, essentially spoofing equality for SDL_SCANCODE_RETURN and SDL_SCANCODE_KP_ENTER. And then some additional code would probably be desirable in KeyboardShortcuts::Set and/or KeyboardShortcuts::GetFromKey to force user input of SDL_SCANCODE_KP_ENTER in the keyboard shortcut change window to be stored as SDL_SCANCODE_RETURN, lest users think they are mapping two separate actions to Enter and KP Enter when in fact only the non-keypad one will actually do anything.

---

I don't have a PR for this at the moment; if you want me to write one up, I can take a stab at it.

Really though, at this point, I'm more interested to know which direction you guys would prefer to take this (in part because it's potentially arguable whether the two Enter keys should be treated interchangeably for keyboard shortcuts, depending on preference):

• No fix
• Special-casing the Enter scancodes in the keyboard shortcut system, unilaterally
• Special-casing the Enter scancodes in the keyboard shortcut system, but only for the view rotation shortcuts in particular
• Enhancing the keyboard shortcut system to allow multiple keys to be mapped to the same action
• Something else

[ocalhoun6]

This is possibly related to #9684

[jgottula]

@ocalhoun6 Huh, that caused me to realize something interesting: the snippet of code that was added back in 2014 for the #653 fix (which created a SDLK_KP_ENTER <--> SDL_SCANCODE_RETURN equivalency of sorts) must have been applicable to all key input back then; but while that bit of code still exists in the game (albeit in slightly altered form), it is now only applicable to text input situations in windows in the UI, and explicitly not applicable to keyboard shortcut situations any longer.

Here's that snippet in the current codebase:

OpenRCT2/src/openrct2-ui/TextComposition.cpp

Lines 109 to 113 in 77f1905

	if (key == SDLK_KP_ENTER)
	{
	// Map Keypad enter to regular enter.
	key = SDLK_RETURN;
	}

A relatively recent commit, 5d5373b, added some new special cases of SDL_SCANCODE_RETURN <--> SDL_SCANCODE_KP_ENTER equivalency specifically for console and chat input situations, which are treated separately from the UI windows.

So it kinda-sorta sounds like there may have been an understanding back in 2014 that the #653 fix would apply to everything; but at some point in the intervening time, its effect was limited only to text input, and so now we have things like 5d5373b popping up to specifically catch instances where the equivalency is still desired.

Interesting...