Key bindings are not saving?

I encountered a weird problem when I tried to change some keybindings last night: I changed bindings in ship controls, applied the setting and moved over to SRV settings. When returning to ship controls, the changed bindings were gone. I retried a few times, restarted ED, restarted my machine, replugged the HOTAS, changed bindings for my mouse. Every time the same result: the changed binding is shown, after applying and revisiting the setting, they are gone.

Background: I use a custom bindings file (virpil4.bind). The file change timestamps did happen exactly at the time when I applied the settings.Previously (January, it was no problem to reassign bindings with exactly that file)

Any ideas?
 

rootsrat

Volunteer Moderator
I encountered a weird problem when I tried to change some keybindings last night: I changed bindings in ship controls, applied the setting and moved over to SRV settings. When returning to ship controls, the changed bindings were gone. I retried a few times, restarted ED, restarted my machine, replugged the HOTAS, changed bindings for my mouse. Every time the same result: the changed binding is shown, after applying and revisiting the setting, they are gone.

Background: I use a custom bindings file (virpil4.bind). The file change timestamps did happen exactly at the time when I applied the settings.Previously (January, it was no problem to reassign bindings with exactly that file)

Any ideas?
Check that your custom bindings file is not set to read only :)
 
Is your USB power strong enough to power all devices?

Try using other usb ports
Yes, the throttle and 2 MFD Cougars are on an active USB, they stick is directly connected to my PC - a setup which I am using since 3 years. That's why it is all so strange.
The whole phenomenon is odd. No change in ACLs, nothing - only U17 and 18 since I made the last change.
 
Check that your custom bindings file is not set to read only :)
thanks for that suggestion, checked that first. (And Windows wouldn't write a timestamp if the access would be read-only).
Maybe I have to rebind on a new and empty file. Something which I really hate because of the chaotic settings menu.
 

rootsrat

Volunteer Moderator
thanks for that suggestion, checked that first. (And Windows wouldn't write a timestamp if the access would be read-only).
Maybe I have to rebind on a new and empty file. Something which I really hate because of the chaotic settings menu.
Hmm... double check the profile name inside the file is the same as filename?

Other than that... not sure. I've been using the same custom bindings file for many years now with no issues, and I've not seen or hear others complaining about this either, so it seems like a local issue l think.
 
I encountered a weird problem when I tried to change some keybindings last night: I changed bindings in ship controls, applied the setting and moved over to SRV settings. When returning to ship controls, the changed bindings were gone. I retried a few times, restarted ED, restarted my machine, replugged the HOTAS, changed bindings for my mouse. Every time the same result: the changed binding is shown, after applying and revisiting the setting, they are gone.

Background: I use a custom bindings file (virpil4.bind). The file change timestamps did happen exactly at the time when I applied the settings.Previously (January, it was no problem to reassign bindings with exactly that file)

Any ideas?
If you haven't seen this, it may be useful...


Mine looks like this:
1709640352774.png
 
Hmm... double check the profile name inside the file is the same as filename?

Other than that... not sure. I've been using the same custom bindings file for many years now with no issues, and I've not seen or hear others complaining about this either, so it seems like a local issue l think.
will do so. Although there's only one Virpil4.bind, and I've verified that I am using it, it makes me scratch my head: From an old thread in another community, I just tried to delete the .bind file while in the editor. I set a key binding and before hitting "Apply", I deleted my old Virpil4.bind in the file system. Then "Apply" and it gets written from scratch. However, again without any changes. I tried setting modes which are joystick-unrelated such as mouse-scroll and toggle to hold. Same :D
Maybe a fresh binding file will resolve it.

Thanks to you all for quick answers! Really like this community.
 
Sounds like it is sorted but for future info anyway:

Having copies of .binds files in the same directory can cause this "changes not saving" issue* - best to keep backups in a different place.

* Presumably due to the game being confused by multiple files with the same "RootPresetName" in line 2 of the files.
good point - I have like 8 backups (generated by ED) in that folder. Will do a purge tonight and start on a clean slate. Hope this will sort out the issues.
I just wish that the whole binding management would be a bit more user-friendly: A search box to identify a binding would be awesome.
 
Try checking your BindingLoadingErrors.log file (\Bindings directory). It can help find issues you might overlook. It's helped me solve a bunch of controller issues over the years. A corruption in a binding file can cause it to not save also. I run CHKDSK every month or so to keep my disks file systems healthy. It almost always finds some thing to fix.
 
Last edited:
[....]. A corruption in a binding file can cause it to not save also. I run CHKDSK every month or so to keep my disks file systems healthy. It almost always finds some thing to fix.
THAT was the culprit which I found last night: When I used an old binding from summer last year, bindings could be changed (and saved) successfully. Sorry that I am late to update my thread.
Indeed quite surprising because I had the binding open in XMLNotepad and it could parse it without problems.

Thanks for that hint!
 
..
Indeed quite surprising because I had the binding open in XMLNotepad and it could parse it without problems.
..

I should have been more clear by saying "corruption".
File corruption comes in two flavors:
1. The file on the disk is physically damaged (something for CHKDSK to fix)
2. The file was not damaged but only improperly saved and missing some parts.

In your case it was most likely the latter, because a damaged file usually can't be
read for viewing and will return a disk read error.

Either way, glad you got it fixed. o7
 
Back
Top Bottom