This came up on the ZDF Discord earlier today, and I figure I should probably make some noise about it here.
If you're adding custom key bindings to your mod, then please, for the love of all that is unholy, use the "addkeysection" keyword in KEYCONF! I've seen a number of mods like QC:DE and Trailblazer that don't do this, because they implement their keybinds in their own MENUDEF menus instead of KEYCONF. This means that the keybindings will pollute the default [Doom.Bindings] section of the INI, meaning they'll be defined globally, meaning ugly error messages when someone presses that key while playing another mod, keys getting rebound and general inconvenience all around.
(The bottom of my [Doom.Bindings] section, with a bunch of keybinds relating to various mods both recent and long-forgotten.)
(The results of trying to press those keys without those mods loaded. Ugly!)
(A common cause: Keybinds in custom menus, instead of in the Customize Controls section)
When using the addkeysection keyword, however, the binds will be seperated into a mod-specific section of the INI. This means, most importantly of all, that users can use the same key for different purposes in different mods without having to rebind the key everytime they change mods, or without causing error messages in other mods.
(How addkeysection-effected binds are stored seperately. The "f" key bind here overrides the one in the global bindings, as a bonus.)
It takes two seconds and shows a little extra consideration for your player. There's no reason not to do it.
Reminder: "addkeysection" exists and you should use it!
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Reminder: "addkeysection" exists and you should use it!
Some additional thoughts:
1.) MENUDEF-based key binding menus totally work fine with addkeysection as long as the keys are also defined in KEYCONF. So you can have things both ways and everyone's happy! As an example, here's a quick-n-dirty fix for Trailblazer. Paste this at the start of the KEYCONF file:
2.) I'm not 100% sure on this and am not in the mood to test it at this exact moment, but depending on load order, binds from a mod without an addkeysection may potentially pollute the ini sections of mods with one. Basically creating the same problem, but specific to one mod load order combination instead of one mod, making it potentially harder to figure out and possibly resulting in false bug reports to confused modders.
1.) MENUDEF-based key binding menus totally work fine with addkeysection as long as the keys are also defined in KEYCONF. So you can have things both ways and everyone's happy! As an example, here's a quick-n-dirty fix for Trailblazer. Paste this at the start of the KEYCONF file:
Code: Select all
addkeysection "Trailblazer" TrailblazerKeybinds
addmenukey "Machete Quick-Toss" +Gimbostratus
addmenukey "Spikebomb Quick-Toss" BobsBrainBestExplosiveEver
addmenukey "Nightvision Goggles" Vision
addmenukey "Hazmat Suit" Rubberfruit
addmenukey "Whiskey" UbermenschUnlimited
addmenukey "Jetpack" FlyingDumbass
addmenukey "Blastsphere" SpontaneousExplosion
- m8f
-
- Posts: 1445
- Joined: Fri Dec 29, 2017 4:15 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Manjaro Linux
- Location: Siberia (UTC+7)
- Contact:
Re: Reminder: "addkeysection" exists and you should use it!
While I agree with the general idea to put keybinds to special ini section, I cannot say that it is a perfect solution for all the cases.
Consider the following:
1. One of my mods currently has 42 key binds (most of them are optional, and the users can decide what binds are the most convenient for them). For the reference, GZDoom has 61 key binds without mods.
2. GZDoom key section doesn't allow submenus.
So, I had to choose from:
1. polluting the GZDoom's Customize Controls menu (making the user wade through a hundred of entries just to find the one they want to change). Imagine that a couple of other mods are loaded alongside mine. The number of key binds in Customize Controls menu will grow even more.
2. polluting global key section in ini.
I chose the second way because I thought that inconvenience described in this topic is smaller than the inconvenience caused by scrolling through the overgrown controls list.
Consider the following:
1. One of my mods currently has 42 key binds (most of them are optional, and the users can decide what binds are the most convenient for them). For the reference, GZDoom has 61 key binds without mods.
2. GZDoom key section doesn't allow submenus.
So, I had to choose from:
1. polluting the GZDoom's Customize Controls menu (making the user wade through a hundred of entries just to find the one they want to change). Imagine that a couple of other mods are loaded alongside mine. The number of key binds in Customize Controls menu will grow even more.
2. polluting global key section in ini.
I chose the second way because I thought that inconvenience described in this topic is smaller than the inconvenience caused by scrolling through the overgrown controls list.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Reminder: "addkeysection" exists and you should use it!
Well, you chose wrong.
It may be more convenient while playing your mod, but it will cause problems with everything else and the result will be that people won't play your mod because it screws things up.
You have to think a bit further than the immediate needs of your own little project when designing stuff.
It may be more convenient while playing your mod, but it will cause problems with everything else and the result will be that people won't play your mod because it screws things up.
You have to think a bit further than the immediate needs of your own little project when designing stuff.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Reminder: "addkeysection" exists and you should use it!
As mentioned in my second post, you don't have to choose. As long as the binds are defined in an addkeysection, defining them through a custom menu seems to obey the addkeysection. There really isn't much of an excuse.m8f wrote:So, I had to choose from:
1. polluting the GZDoom's Customize Controls menu (making the user wade through a hundred of entries just to find the one they want to change). Imagine that a couple of other mods are loaded alongside mine. The number of key binds in Customize Controls menu will grow even more.
2. polluting global key section in ini.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Reminder: "addkeysection" exists and you should use it!
I think m8f's concern is the fact that addmenukey automatically adds the key to GZDoom's main customize controls thingy, so that menu can end up with a huge block of undifferentiated clutter.
Personally I don't see how that is at all a problem - if you've got a separate menu for all the mod-specific stuff there's no good reason even to look at the main controls menu, and even if one did it would be a fairly trivial inconvenience.
If your mod is so different that you might expect players to rebind some more basic stuff (or you need to remind them to bind those things in the first place, e.g. toggle run or user4 or something), the more basic stuff could be included in the custom menu.
Personally I don't see how that is at all a problem - if you've got a separate menu for all the mod-specific stuff there's no good reason even to look at the main controls menu, and even if one did it would be a fairly trivial inconvenience.
If your mod is so different that you might expect players to rebind some more basic stuff (or you need to remind them to bind those things in the first place, e.g. toggle run or user4 or something), the more basic stuff could be included in the custom menu.