I’ll try to give all details that may be relevant. When exporting to web somehow it seems that my input settings are changed. What I have is a brand new project with only the Cogito addon installed. The cogito addon itself comes packaged with the InputHelper addon.
In the project settings input map section it shows I have an action called “menu” that is set to trigger when the M key is pressed. Before exporting, when the game is run it immediately enters a main menu scene. In the main menu’s ready function if I print(InputHelper.get_keyboard_inputs_for_action(“menu”)) the output is: [InputEventKey: keycode=77 (M), mods=none, physical=false, location=unspecified, pressed=false, echo=false]. There is also an in-game key-bindings menu that correctly displays that the M key set to the “menu” action.
After exporting to web and playing it through itch.io’s website, the “menu” action is somehow set the escape key by default. I thought there might be some persistent config file that’s overriding my settings but it seems to happen even when trying to play it from a different freshly installed web browser. When testing from my main web browser I also tried clearing out all data in IndexedDB in case it was overriding the game’s input settings but still ran into the same issue.
Any help is appreciated and happy to provide additional details if needed. I was hoping someone might be able to at least point me in the right direction. I’m not sure how to even start debugging something like this.
I have a theory worth testing. I don’t think the export is changing anything, I think there are two sources of truth for your input map and the editor and the web build are reading different ones.
Cogito ships its own copy of the input map inside the addon. You can see it in CogitoSettings.tres under addons/cogito, which even has a Reset Project Input Map button that overwrites your project’s map with Cogito’s stored one. On top of that, InputHelper saves keybinding changes to a config file in user:// and applies them at runtime. So the likely chain is: on your PC there’s a saved config in user:// that has menu = M (from when you set it up or touched the bindings menu), and the editor runs are reading that. The web build starts with an empty user://, no saved config, so it falls back to the defaults baked into the addon, where menu is presumably Escape. That would explain why a fresh browser and clearing IndexedDB changed nothing, the ESC isn’t coming from stored data, it’s coming from the shipped defaults.
Quick way to confirm on desktop: Project → Open User Data Folder, look for a settings or input config file from Cogito or InputHelper, rename it, then run the game in the editor. If menu suddenly shows Escape on desktop too, that’s the whole mystery, your M was living in that file rather than in the project.
If confirmed, the fix is to change the default where the addon stores it. Check the input map section inside CogitoSettings.tres and search the cogito addon folder for where “menu” gets its default binding, then set it to M there so fresh installs (like every web player) start correct. Setting it only in Project Settings isn’t enough if the addon reapplies its own defaults on first run.
It’s a good thought, but I should mention that I modified cogito_settings.gd so that the “menu” action is set to the M key. Sorry, I should have been more clear about that in the original post. It slipped my mind. But in other words, the “menu” action was not set using the in-game key-binding menu but by the cogito_settings.gd script. When you say “Open User Data Folder” where would that be?
If it matters I’m using Ubuntu. I don’t see anything in my project folder that resembles a “User Data Folder” or is named anything like “user”. If it matters I enabled a show hidden files settings in my file explorer and still didn’t see anything. Am I looking in the right place? Thank you for the response.
Ahh ok, well if your M lives in cogito_settings.gd but a .tres resource also stores that binding, editing the script’s default won’t update the resource. In Godot, a saved .tres stores the property values from when it was saved, so changing a default in the script only affects resources created after that change. Existing ones keep their old serialized values. So the desktop and web difference could still be two sources of truth: something on your machine (a user:// config or the editor applying your script) giving you M, and the exported build reading the untouched .tres where menu is still Escape.
Two quick checks:
Open CogitoSettings.tres (or whatever resource holds the input map) directly in the inspector and look at what menu is actually set to there. If it says Escape, that’s your answer, fix it in the resource, not just the script.
rainerdeyke gave you the right path for the user data folder, it’ll be under ~/.local/share/godot/app_userdata/ in a folder named after your project. Rename any Cogito or InputHelper config file in there and run in the editor. If menu flips to Escape on desktop too, that confirms where your M was coming from.
I appreciate the detailed response.. So I was a able to find a “options.cfg” file in my project folder and renaming it caused the menu action to action to revert to being triggered by the escape key when run from Godot. I’m not sure I understand your point #1. I’m still reading over everything making sure I understand it before I try to change more code and mess something up.
On your point #1, I’m not sure I understand. If I open up CogitoSettings.tres in the inspector, I don’t see any where you’re referring to where the “menu” action would be set. There is a “Reset Project Input Map” button that runs a function within cogito_settings.gd. There’s a couple other export vars that can be set but aren’t relevant to input settings as far as I can tell.
Renaming options.cfg and seeing Escape come back means your project’s real default for menu is Escape. The web build was never changing anything, your M only lived in that config file.
And you’re right about #1, the input map isn’t in that resource, my mistake. Ignore that part.
It also means your cogito_settings.gd edit isn’t being applied on startup. Wherever that function runs, it isn’t running when the game boots.
Try to set the default where exports actually read it in Project Settings → Input Map → menu action → remove Escape, bind M. That may save to project.godot which ships with every export. Then try running in the editor with options.cfg still renamed, if menu shows M you’re done and the web build will match.
On second thought, again I’m not sure I understand what you mean. So far everytime I’ve tried to export the project it has had the “menu” action set to the M key in the Project Settings → Input Map section.
There’s probably a much better way to do it but as a workaround I used InputHelper’s serialize_inputs_for_actions method to get a string for my known working keybind configuration. Then in InputHelper’s reset_all_actions method call deserialize_inputs_for_actions passing that string to it. Then in main_menu_controller.gd’s _ready:
func _ready():
first_focus_button.grab_focus()
InputHelper.reset_all_actions()
var serialized_inputs = InputHelper.serialize_inputs_for_actions()
var config = ConfigFile.new()
var err = config.load(OptionsConstants.config_file_name)
if err != 0:
print("From main_menu_controller.gd, keybindings: loading options config failed.")
config.set_value(OptionsConstants.key_binds, OptionsConstants.input_helper_string, serialized_inputs)
config.save(OptionsConstants.config_file_name)
With that at least you can manually set the viewport size and add a fullscreen button and pressing M brings up the options menu without interfering with Itch’s mechanism to exit fullscreen. Not trying to be longwinded but hopefully it might help someone if they come across the same issue. Thanks for the tips, otherwise I wouldn’t have been able to narrow down what was causing the issue.