Bring back `get_joy_axis/button_string()` methods to `Input`

[YeldhamDev]

Describe the project you are working on

A game that allows the player to change the inputs used via a settings menu.

Describe the problem or limitation you are having in your project

My game has an options menu that from many things, also allows the player to changes the inputs used to play. One useful thing to have when making those is to show them the name of the input that's being used or is about to be set. For keyboard inputs, I use OS.get_keycode_string(), and for the joypad ones, I used the combination of Input.get_joy_axis/button_string(). The problem is that those last two were removed in #godot/43591.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

As said before, those were very useful for building a menu to changing the input mapping for your game. They were a quick way to help display which input is being currently used, or was just set.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Not really different from before, just bringing them back as they worked before. Currently, those input names reside in editor/input_map_editor.cpp. It would just be a matter of bringing them to core/input/input.cpp and reinstate the functions.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This feature was useful for any game that implemented the option for the player to change which inputs to use in a joypad. And while it could be workaround, it's the sort of thing that makes your life a lot easier if it's already implemented and already tied up which the corresponding indexes in the enum.

Is there a reason why this should be core and not an add-on in the asset library?

Again, this was already core before.

[KoBeWi]

The button names mapped to the constants are different depending on the controller. The method would need to support different naming schemes, otherwise it wouldn't be very useful.

Also for this use-case, it's more common to use icons instead of names. Guess who has an addon that provides such feature😏 https://github.com/KoBeWi/Godot-Action-Icon

[YeldhamDev]

The button names mapped to the constants are different depending on the controller. The method would need to support different naming schemes, otherwise it wouldn't be very useful.

It would still remain useful, even if just for the first generic name (like "Bottom Action" and etc).

Also, one could easily implemented a simple scheme themselves with the help of Input.get_joy_name().

[anvilfolk]

I feel that's true for the axes for sure, and I've seen a lot of games just displaying "Button 1", "Button 2", etc, which isn't the most helpful (it's one of my pet peeves, hehehehe), but it's a baseline to go off of! :)

I do think if it's going to be in the engine itself, it would make the most sense to have a fully-featured implementation allowing for multiple schemes as @KoBeWi says, rather than a barebones one only supporting the "Button 1", "Button 2", etc.

It doesn't seem at first glance that this implementation would be particularly complex, and it can always fall back to the simple naming scheme if the controller isn't properly identified :)

[KoBeWi]

I think the method could be get_joy_button_string(id, scheme), where scheme is an enum with controller types, defaulting to AUTO_DETECT.

[elvisish]

How is this going for 4.3?