Godot: Default InputMap action events can't be easily removed

Created on 21 Feb 2016 · 18Comments · Source: godotengine/godot

Steps to reproduce:

open any project in the editor
open the project settings and delete one of the events from ui_accept
save
close the editor and re-open again
The deleted action is still in the InputMap and engine.cfg

The only way to delete those right now is to add a new temporary action after the removal (which can then also be deleted)

bug core editor

Source

27thLiz

Most helpful comment

This is not really a bug, Godot UI needs these actions so you can't remove them. You can change what keys are used though, but there is not any benefit to removing them.

reduz on 18 Jul 2016

👍5 👎2

All 18 comments

just to share a scripted workaround :

func _ready(): #{
    for action in ["ui_accept","ui_select","ui_cancel","ui_focuse_next","ui_focus_prev","ui_left","ui_right","ui_up","ui_down","ui_page_up","ui_page_down"]: #{
        if InputMap.has_action(action):
            InputMap.erase_action(action);
        InputMap.add_action(action); # <-- to avoid reading complaints about  "Request for nonexistent InputMap action:ui_xxx"
    #}
#}

SuperUserNameMan on 6 Jul 2016

👍2

This is not really a bug, Godot UI needs these actions so you can't remove them. You can change what keys are used though, but there is not any benefit to removing them.

reduz on 18 Jul 2016

👍5 👎2

Should we forbid deleting them (by hiding the delete button)? Ping @akien-mga (I think we once had a discussion about this).

neikeq on 18 Jul 2016

If they're not meant to be removed, then yeah I guess it would be the most sensible (if not the case already).

akien-mga on 18 Jul 2016

Oh, I got it wrong. You cannot delete default input map actions, but you can delete its default events.
The question should then be: Should we forbid deleting its default events? If so, how would we know that an event was added by default?

neikeq on 18 Jul 2016

Based on what @reduz said above, I think it's ok to be able to remove/replace the default events. But the action names themselves should stay at all times.

akien-mga on 18 Jul 2016

Just appending here based on my own recent experience for the reasoning this being not a bug. You're only changing the live program's script, not the editor's settings itself. I agree with reduz in that it's a feature for it be static. I wouldn't want my input map all changed out based on some code just like I wouldn't want a character deleted from my map just because a script removed it from memory in the actual program.

agameraaron on 2 Jun 2017

Well, I screwed up on the wording a bit in the original post... what I meant was not deleting the default actions, but the events associated with them. Which is a totally fine use-case IMO. Hence why I reopened the issue.

27thLiz on 2 Jun 2017

👍1

Ooh okay, I see that you mean you can't access them easily. That is very true. There should be more InputMap functions for accessing data such as the events. I shouldn't need to do for loops over an action's event list to find a specific event's integer and match it up with a string, for instance. I think that was one of the issues.

Considering they are changing Input in some fundamental ways, however, I think we will only be able to make much headway after 3.0 is released. I have no clue how different it will be or what it will affect.

agameraaron on 15 Jun 2017

As mentioned in the linked duplicate issues, it seems to be fixed in master.

I think it wasn't fixed on purpose though, but just by chance when @groud added logic to convert 3.0 project.godot files to the new InputEvent serialization format, which enforces saving all default actions to project.godot (and they are then editable).

I'll close this issue as "fixed", but will open another one to ensure that we have a conscious fix and improved UX for this new input actions system, as it's a bit messy currently.

akien-mga on 14 Aug 2018

Actually as discussed with @groud, it's a "bug" that this issue is fixed, and we're about to fix it, so this issue will reappear.

Currently it's fixed because all ui_* actions get saved to project.godot, due to their new 3.1 format differing from the 3.0 format still used in ProjectSettings' constructor. Once we fix the constructor, those ui_* actions should no longer be saved to project.godot in new projects.

From there, there will be two options:

Add logic to enforce saving ui_* actions to project.godot, even if they match their initialization. That will bring back the current status, but it's a lot of noise in the project.godot file when you don't want to edit those (most of the time), so it's annoying.
Add logic to allow editing events of ui_* actions from the project settings dialog, and then save only the modified ui_* actions.

akien-mga on 14 Aug 2018

👍1

I'm not sure why, but it seems that with #21008, this problem is solved

groud on 14 Aug 2018

I'll do some local testing to confirm.

akien-mga on 14 Aug 2018

I confirm that #21008 keeps this issue fixed, so basically this seems to be implemented already:

Add logic to allow editing events of ui_* actions from the project settings dialog, and then save only the modified ui_* actions.

akien-mga on 14 Aug 2018

🎉1

Hi guys, have the same issue : everytime I delete a key in the default ui_xxx it disappears well, but the key is still mapped to this action ... And when I re-open the editor the key pops up again under ui_xxx.
This is not a OK behaviour, when you delete something and it disappear in the view you do not expect it to be still active and to pop up the next time you open your project.
I spend 30 minutes trying to figure out why my button was activated, and found out it was Space key which was the culprit : tried to delete it from the default mapping but impossible :sob: