Error: Request for nonexistent InputMap action: [ui_defaults]

[AniMerrill]

Godot version:
Version 2.1.4, it is a custom compile but nothing was altered and projects written in it can be opened in the stable release and vice versa (it was mostly for getting experience with the compiling process).

OS/device including version:
Ubuntu 16.04

Issue description:
So in my primary project I've been trying to prototype a good controller rebind boilerplate that will handle some exotic controllers myself and my friend has and in the course of it, I figured out how to do some really clean menu controls that work with just about everything. You see there were two major problems, one common and one bizarre. The common one is using an analog stick to navigate menus which nearly any player might decide to use an analog stick for that. If you have your primary ui controls set to an axis, for whatever reason the focus just FLIES across the screen and it is basically nonfunctional. The bizarre one, but which elucidated a possible common problem, is that my Retrolink N64 controller apparently has the A Button as an axis. Apparently when you have ui_accept set as an axis, the default controls will not work. This may seem like a weird issue to fixate on since it's a really bizarre edge case but A) there would be some cases that it would not be completely unreasonable to set L2 or R2 triggers as accept and those are almost always analog on modern controllers and B) being the egalitarian that I am I don't want anybody to not be able to use their controller just because the bootleg factory that made it decided to wire it weird.

So basically my fix was to create instead of ui_left, ui_right, ... etc just Left, Right, ... etc. I can have absolute control over them and program them exactly how I want, plus they are appropriately named so I may even be able to remove the middleman array that holds the "proper" names of the controls to show to the user on the rebind screen. Originally I had merely deleted from the InputMap in the editor every single ui default control binding (using the little trashcan icons) thinking that would work, but apparently at runtime it still propagates the controls anyway. So at runtime at the beginning of the project when initiating all my custom control code I just used InputMap.erase_action() on all of the default ui inputs. And the code works like a charm except it throws the error at the top about 2,000 times a minute and basically breaks the error log from being used to discover any actual game breaking errors.

And I'll fess up, this issue has been brought up twice- once by me and once by one other person -but the answers provided are just straight up unsatisfactory:

• QA Post: https://godotengine.org/qa/30268/nonexistent-ui_defaults-alternatively-suppress-warnings

• Issue: Request for nonexistent InputMap action: ui_cancel #17210

In both cases the question/issue is being answered essentially "well if you aren't using it, why do you need to delete it? why don't you just leave it alone?" Because the ui defaults actually BREAK the way menus work for me. I will not criticize Godot or it's developers because it's good that it has default functions like this and I'm glad that Godot at least HAS a way to manipulate the InputMap from in game (both GameMaker and Unity I could never figure that out, probably had to have access to the paid license to do it idk). But the ui default input, imho, really only works in the narrowest cases where you either do not have rebindable controls or your controls can only be keys anyway. Like rebinding a control to an analog stick or an analog trigger is not a trivial edge case, these are things that I imagine a random player base would do frequently.

Whether or not I am "using" the default inputs, the default inputs get used anyway- and in priority before any custom behavior I may have programmed.

Steps to reproduce:
It is probably easiest to understand this problem through the sample project I created below. All it has are three rows of buttons, and you use the arrow keys to move between them and space to select them. In the editor, pressing the buttons will produce an output to let you know the correct button was pressed. What my fixes did was make it so that when you press up, down, left, right, or space the menu will ONLY accept that input ONCE and will not allow you to move the cursor again until released. This fixes the analog stick issue and the code allows even an analog input to work for the accept button (you're welcome to rebind in the editor menu I guess).

The problem occurs in the _ready() function of the script on line 37 with the function delete_ui_defaults(). Obviously this deletes the relevant default inputs to the menu code so that it works. If you comment this line out, you will see how leaving them in is not a choice. How even though I am not using them or referencing them or anything, they bug out my menu navigation and completely break it. And you will see, in the InputMap, that the controls are the same between ui_left and Left, ui_right and Right, etc. Sure, and the way I've fixed it in my personal project is to bind them to Ctrl+Alt+Shift+Numpad Keys because that was the only combination I figured nobody would ever accidentally rebind to AND press all at once during any gameplay scenario, because even if you map them to just something completely random you run the risk of the player rebinding to that key or just accidentally pressing it during a tense section or something. Unless there are scancodes for keys that just literally don't exist that I could use, every modifier plus the Num Pad is the best that I can do and it's ridiculous and extraneous that THIS is allowed but I can't just delete them without getting 10,000 errors.

I could even understand not allowing their deletion from the editor menu so noobies can't delete them and accidentally break their menus etc. but if someone has gone to the length to delete every single default input via code they probably have half an idea of what they're doing.

Minimal reproduction project:
Default UI Glitch.zip

Thank you for taking the time to read and consider my issue. Like I said above, I am using 2.1.4 but I'm sure this exists in the 3.X branches too.

~AniMerrill

[Calinou]

If you have your primary ui controls set to an axis, for whatever reason the focus just FLIES across the screen and it is basically nonfunctional.

This was fixed by #31880 a while ago. The fix is available in the 3.2 betas.

The rest of this issue is a duplicate of #17210, so I'll close it.