Slight Tweak to Default Keybinds

[BlackSpectre]

If we're talking ease of use and the ability to take what you know from other games and apply it here, I highly recommend these 4 changes to the default keybinds (sorry, I feel like I'm lagging behind on all this discussion-- I need to hang out at the Beta server more often!).

 

ESC "unselect$$powexec_unqueue"

O "toggle options"

X "interact"

Z "+down"

 

Re: O   The "O" key is currently not bound by any key by default, and there is no key bound to open the Options Window. Many people use the Options window a lot, and since it starts with O, it's perfect for the Options window which, you know, starts with O.

 

Re: Z  In many games Z is the vertical down button because the vertical axis on a 3D shape is called the Z-axis. It's also fairly easy to hit with the ring finger if your fingers are resting on the WASD keys like mine are all the time.

 

Re: X  The /interact command is one of the best additions to the game and I doubt many people know about it. In most video games the interact button is either E or X.  E is used for movement in COH, so that's out. X actually does work well once you get used to it. I got so used to it playing Warframe that my hand automatically goes down to X whenever I want to interact with something. It's a great spot for it, and apparently other games agree. If you disagree with my key placement, that's fine, but please place it somewhere in the options window.

 

Re: ESC   The /powexec_unqueue command is moved from Z to ESC because there's really no reason not to execute these 2 commands together. It turns ESC into an even more powerful "No! Not that! Cancel! Cancel! Cancel!" key. Besides, who remembers that Z is the abort queued power button? Not me. Anyway, no functionality is lost by executing the 2 commands together, it's much more intuitive, and it does not cause additional problems or conflicts. I recommend you make this change to the ESC key even if you keep /powexec_unqueue on the Z key.

 

This next is already part of the default keybinds, but really needs to be put in the Options window. Maybe something like "Start Chat (emote shortcut)" - Semicolon. For the longest time I didn't even know we could do a shortcut for emotes. It's worth adding just so people know about it.

 

 

Edited February 28 by BlackSpectre

[Shenanigunner]

Well, I came into this to answer your points and throw a little good-natured argument back, but I discover that sometime between the last version of P7 and its first release on live (and I'm pretty sure it's the latter), the whole keybind management system has been "improved" — and by improved I mean "hacked at by someone who thinks keybinds are a kind of useless thing to bother with."

 

I don't think the drop-down list of options adds much of anything, but that's neither here nor there... the problem is that if you now try to save the standard keybind list, for comparison (as I was going to do here, making sure I had any very-recent changes) or as a starting point for mods... you get a one-line file with 'keyprofile classic' in it. Nothing else. This is so massively below useful I'm actually a little startled any Dev thought it was a right direction to go.

 

I realize those of us who munge the binds more than a command-line tweak here and there are in a minority, but closing up the system so that they only way to review the standard binds is by paging through the Options menu (which historically has been incomplete and sometimes even wrong) is pointlessly crippling a customization process that goes back to day one.

 

Please revert this "feature" and make keybind saves actually save the current, active key bind list, not an indirect Dev shortcut.

[Shenanigunner]

I have a dump of raw keybinds dated 30 January, which as noted was right on the cusp of release. Besides the above issue that makes any discussion here laborious, your notes indicate there have been subsequent changes, so using it to (mildly) argue my notions about basic binds would probably be useless.

 

Not happy. I don't see any actual improvement except to allow truly luddite players to switch back to the dusty, broken, original bind set from the very slightly tweaked P7 one, which doesn't lead to any reason for "boxing in" the bind list file system.

[megaericzero]

12 minutes ago, Shenanigunner said:

the problem is that if you now try to save the standard keybind list, for comparison (as I was going to do here, making sure I had any very-recent changes) or as a starting point for mods... you get a one-line file with 'keyprofile classic' in it. Nothing else.

I noticed that too.

 

[Bit of personal history here - go ahead and skip this: since live, I've kept binds.txt, chat.txt, options.txt, and wdw.txt in read-only mode. I found the settings I liked and made sure I couldn't accidentally overwrite them, then only unlocked the files as new settings came and, most of the time, edited the files manually in notepad instead of through the game. With all the updates to settings on P7, I figured now was a great time for a full-refresher so I moved the files out of my COH install, loaded the game with a brand-new character and saved the default files so I could see what's changed and what the game now considers default with the intent stitch the two files together (and maybe update a couple of things)... only to find that binds (and wdw) basically only list changes from the default now, though I'd have no perception of how long it's been like that since my files were untouched as read-only since like 2019. I'm guessing it's a memory or efficiency thing.]

 

What I used as a quick solution was erasing all the binds by changing everything to the same key until I was left with only one, then saving it. This way, it exports a file with all the keys that should be bound in the current profile but with "nop" (the keybind file's designation for "unbind this key"?) as a starting point.

[Shenanigunner]

28 minutes ago, megaericzero said:

What I used as a quick solution was erasing all the binds by changing everything to the same key until I was left with only one, then saving it. This way, it exports a file with all the keys that should be bound in the current profile but with "nop" (the keybind file's designation for "unbind this key"?) as a starting point.

 

Clever; kudos. But we shouldn't have to use a laborious hack to simply list a long and complex configuration setup because a Dev thought it was "better" to just export one setup directive instead... after 20 years. No one exporting the file is an anti-bind noob who is going to get confused, or appreciate that single setup keyword.

[megaericzero]

14 minutes ago, Shenanigunner said:

Clever; kudos. But we shouldn't have to use a laborious hack to simply list a long and complex configuration setup

Definitely. Just suggesting a workaround in case you needed something sooner than later.

[BlackSpectre]

Now, now, I'm sure the Devs have a good reason other than so the keybinds.txt file matches the file on the server and it looks prettier that way. From the patch notes:

• Quote

  No longer saves every single key into keybinds.txt, only the keys which the user has customized. This matches how it's always been handled on the server side when saving characters, and makes the behavior consistent after saving/loading key bindings.

Hmmmmm. Actually I'm not sure there IS a better reason than it looks prettier. OK. Let's assume there is. Are players better off or worse off? Well, again, the reasons for the change are unknown and frankly, what happens behind the scenes in the game code is not really our area of concern until it impacts us in the game... which this change has.

 

To give you a small indication of the change... I'm in the middle of updating all of the options pages at the wiki, and I ran across this page last night:  https://homecoming.wiki/wiki/The_Players'_Guide_to_the_Cities/Slash_Commands,_Macros,_Keybindings,_and_Emotes#Preset_Keybinds

 

I sat back and sighed. To update that page which has all of the default keybinds for each of the keybind profiles I now have to bother a Dev again and ask them to spend some of their time to copy the server files for the default binds in each profile. Now, for this task, I'm dependent on a Dev when previously I could just do it myself.  Removing my access to my own binds is absolutely something that's been taken away, and it stings. It makes anyone's ability to play with keybinds much harder. It might seem like a small change, but it isn't. You can look at it as a grab for power since power has been taken away. It's a valid reason to get upset and demand a justification and remediation. But...

 

I also know a bit about writing code, and it's possible that having a file in the game client mirror the same file on the game server could be a very good idea to prevent things from getting messed up in the background, to provide more stability for the players, to make it easier for the programmers when they write code, and many other possible reasons... all of which I'm willing to concede that the change might indeed be better for us, maybe even necessary. But let me spell out what has been lost:

 

1. the ability to see our own binds in a text file

2. the ability to see the default binds in a text file

3. the ability to verify that the binds we have set were actually set (and written correctly)

 

These things need to be given back to us, or let us know that something even better, that gives us more control and ability, is coming. 

 

Devs, how you fix this is up to you. There are many ways. You can write additional code that retains the changes that were made but also gives players the impression that no change was made at all. Keep all the same commands and processes that players have used for 20 years. Or you could write a new command that pulls the default binds in the selected profile, overwrites any of those binds with the keybinds that we have set, and then pushes the final document out for us to use in a different file than keybinds.txt. Maybe called "currentKeybinds.txt" or whatever. An additional command is an extra step, and makes things a tiny bit harder for us, but at least we'd still have the ability to see our binds... all of them.

  

P.S. @Number_Six, or any Dev, I still need those default keybind profile files. If you could pass them over I'd appreciate it. I already have Modern and Classic, all I need are the Joystick and Launch default keybinds. BTW, you're going to LOVE the new Options Window page at the wiki once I'm finished! 🙂

 

Edited February 28 by BlackSpectre
typo

[BlackSpectre]

2 hours ago, megaericzero said:

This way, it exports a file with all the keys that should be bound in the current profile but with "nop" (the keybind file's designation for "unbind this key"?) as a starting point.

 

Since you asked, "nop" stands for "non-operational" and has been a standard abbreviation used by devs and players alike to make sure a key has no bind on it.

[Number Six]

No, the reason is that the bind list saving was completely broken / unfinished, and that loading that saved file back in had bad effects that aren't immediately obvious but can bite you later.

 

The way key bindings work in this game is that there's a default profile -- which the user can select -- that provides the base layer. When you customize your keybinds either through the options menu or the /bind command, only the changes you make are saved as part of your character record on the server, then layered on top of the default. So if you change two of the default bindings, your character record on the server only has 2 keybinds, in addition to the reference to which profile you have set.

 

This is exactly why /unbind doesn't do what you might think and instead resets a key to default, because it's removing that saved key binding which no longer overrides the default. That's why since day one you've always had to bind something to "nop" to actually make it do nothing.

 

There's some more subtlety to that, for example the SG base editor adds another temporary layer to remap some of the keys to edit commands but be able to change them back later, but that's the basics.

 

The bind_save command on the other hand, didn't work like that at all. It scanned through every key possible and wrote out the command for that key, mashing all the layers together and saving whatever happened to be the result. You might say, that's great, it shows me what every key does and that's what I want, so give me that!

 

Sure, but think about what happens when you then load that file back in. /bindload and the automatic equivalent that happens when you create a new character is really stupid, it just reads the contents of that file, slaps a "/bind " at the start of every line, and executes it. Incidentally, that's why with careful use of the $$ token, bind files can and have sometimes been abused to work as longer macros -- for years I've had a "bind" file I load on new characters that issues all sorts of non-keybind commands to set up options and windows and stuff.

 

You're loading in all those default key bindings and then saving them to your character as if you had defined them as custom binds. That works okay so long as 99% of players use the Default profile and never change it, maybe somebody uses Joystick, but that's about it. Consider this scenario however:

1. Joey create a new character on a new account with no saved binds, they get the Modern profile by default
2. They change 1 or 2 key bindings and hit the button to save defaults, which writes out ALL the default keys, in this case the keys from the Modern profile
3. They create another character, load the bind file, and it creates custom bindings based on every single key
4. It turns out they actually played COH a lot back in 2009 and really hate all this newfangled crap, so they change the profile to Classic
5. ... nothing happens? what is wrong with this game? Turns out switching to Classic can't do anything if every single key is already overridden from the file they saved!

If Joey had never used /bind_save it would have worked fine, but because they did it invisibly broke profile selection with no obvious reason why.

 

The change to the way the file works is two-fold:

 

1. Adds a special token to actually save the profile to the file, which it wasn't doing before. This is specifically to make it possible to have your preferred choice of profile as the default for newly created characters without having to change it every time, and to make setting that up as easy as selecting Classic and clicking the "save to default" button that's right next to the dropdown.

 

2. Makes the contents of the file match what is actually saved on the server in your character. That is so that loading binds accurately recreates that state, instead of doing something completely different that just happens to kind of look the same if you squint. I can't emphasize enough that this is a fix to make the command actually do what it says it does and should have always done from the start.

 

The only real loss is the ability to easily see the default keybinds. I don't mean to downplay that because it is an inconvenience, but that's something that can be easily addressed without breaking the whole system again. There's already a separate command to print out the current state of all the keys, just like /bind_save_file used to do, but it's locked behind development mode for some weird reason. With only a few minor adjustments that could easily be adapted to be player-usable and/or save to a file -- just don't stick the entire contents of it in your keybinds.txt without being aware that it will break profile selection!

[Luminara]

8 minutes ago, Number Six said:

• Joey create a new character on a new account with no saved binds, they get the Modern profile by default
• They change 1 or 2 key bindings and hit the button to save defaults, which writes out ALL the default keys, in this case the keys from the Modern profile
• They create another character, load the bind file, and it creates custom bindings based on every single key
• It turns out they actually played COH a lot back in 2009 and really hate all this newfangled crap, so they change the profile to Classic
• ... nothing happens? what is wrong with this game? Turns out switching to Classic can't do anything if every single key is already overridden from the file they saved!

 

Joey, baby, don't get crazy.

 

 

[BlackSpectre]

2 hours ago, Number Six said:

Turns out switching to Classic can't do anything if every single key is already overridden from the file they saved!

If Joey had never used /bind_save it would have worked fine, but because they did it invisibly broke profile selection with no obvious reason why.

Cool. So really the change is meant to make sure that changing a profile actually changes something.

 

Any binds we load in using /bind_load_file and then save to keybinds.txt by using /bind_save will overwrite all profiles because custom binds take precedence over default binds. If a file that contains every key and binding is loaded into the game and then saved to keybinds.txt, the game will not be able to switch to any other keybinds in any other profile, and will only use what is in the keybinds.txt file.   Got it.  

 

So does this mean that if I bind, say, the W key to "+forward" and then save it to keybinds.txt that if I switch over to the joystick keybind profile I will be unable to move forward using my game controller because that action is already bound to the W key? I suppose, we COULD use a secondary key for the joystick binding, but that would also prevent easily switching to other profiles. 

 

So...  and please don't take this the wrong way, I think you're awesome @Number Six, but to me the system still seems broken.

 

Saving a custom keybind across all characters and profiles absolutely gets in the way of switching profiles. Instead, it seems like custom keybinds should NOT be saved for all characters and across all profiles, but rather custom keybinds need to be saved to one of the 4 specific profiles depending on which one is selected at the time. That way, the whole system would work. We would have persistent keybinds across all characters who have the specific Keybind Profile selected. Select a different profile, and you'll have different custom binds for that profile and you could do this on a single character. Switch back and forth with ease. It's kind of a cool idea! 

 

The way that I have my keybinds setup is I have a file that contains the keybinds I want all my characters to have, but it doesn't have all actions bound. Other keybind files I load in depending on what kind of character I have, ranged vs melee. Then I have another set of travel binds that I load in depending on the travel power of my character. The idea of profiles could make this a LOT easier. A Ranged profile and a melee profile that I could select depending on the kind of character that I am using, all with custom binds already set. In fact, we could have a dozen custom keybind profiles to switch between! Sorry, just thinking ahead. 

 

So... custom keybind profiles. Wow, that would be something!

 

You could still use keybinds.txt, but it would have to be segmented and tagged by profile. In the keybinds.txt file you would see all 4 Keybind Profiles, and under each would be the specific custom bindings that would be loaded in when that profile is selected (and any other custom profiles we might make in the future). We'd also need the ability to reset specific profiles rather than resetting all profiles and all binds. It also means some changes would be necessary to the /bind_save commands. A profile would need to be specified. The same for the /bind_load commands. Actually, keybinds would be saved and loaded into whatever profile your character currently has selected. Nice.

 

Please tell me you're headed in this direction... I'm getting all excited! 🙂

 

 

2 hours ago, Number Six said:

 

 

The only real loss is the ability to easily see the default keybinds. I don't mean to downplay that because it is an inconvenience, but that's something that can be easily addressed without breaking the whole system again. There's already a separate command to print out the current state of all the keys, just like /bind_save_file used to do, but it's locked behind development mode for some weird reason. With only a few minor adjustments that could easily be adapted to be player-usable and/or save to a file -- just don't stick the entire contents of it in your keybinds.txt without being aware that it will break profile selection!

Excellent! Sounds good @Number Six, and thanks.  🙂

 

 

Edited February 29 by BlackSpectre

[Shenanigunner]

Okay, thanks to @Number Six for the detailed explanation. It leaves me with two takeaways —

• That it wasn't an idle "let's tidy things up" move by a dev. (God knows any of us who have worked in a code-driven environment have seen egregious examples of such well-intended... fixes.)
• The 'differential' model of how user bind changes are stored; interesting.

But my third takeaway is this —

• because some vanishingly minor changes were made to the default bind set;, and
• because some subset of the user base will have a shrieking conniption fit because by-god something changed;
• a system of bindfile selections was added ('Modern' 'Classic' etc.);
• and to enable some stability of this new selector,
• the ability to simply export the current binds was essentially eliminated...
• even though any 20 years of "incompleteness" or hackiness to this function never caused a known problem to anyone who wasn't trying to implement a selector system to accommodate some incredibly luddite user faction.

But I guess it's a very good thing that the huge surge of new users can choose all these "Classic" throwback options despite never having had the slightest idea anything under them existed. The lunatic wonks who actually tinker with binds as one of the ways to thoroughly streamline and customize the game on a level with few equivalents will just have to settle for the "Oh, Well, Good Enough" bind setting, I guess.

 

To boil that down to one serious question: was the need to have an instant "Classic" revert-setting for this, or really for any of the other UI tweaks that were assigned this nearly meaningless label, so special and essential that breaking a key method of customizing the interface had to get scrapped?

[Shenanigunner]

Quote

Cool. So really the change is meant to make sure that changing a profile actually changes something.

 

Did we gain some new control over "profiles" that's eluded me, here? Those seem to be wholly internal, Dev-managed constructs to allow that "Classic" setback. For the 73 charter players who will use it.

 

Edited February 29 by Shenanigunner

[BlackSpectre]

No no, I'm just thinking ahead about what could be... the ghost of Christmas Yet to Come.  

[Number Six]

1 hour ago, Shenanigunner said:

Did we gain some new control over "profiles" that's eluded me, here? Those seem to be wholly internal, Dev-managed constructs to allow that "Classic" setback. For the 73 charter players who will use it.

 

The characters created in the last 2 weeks would disagree with that assumption.

 

 

And no, the selector is not new. It was always there. Just very few people used it because the options didn't really add much, and possibly also because it was somewhat broken.

 

Yes, you did gain more control. Now what's the in the saved file represents reality rather than some artificial construct, which gives you more control as well as visibility into what's really going on. That's important when you start running into things like the server-side limit on number of saved key bindings. Previously the common consensus around key bindings was that it mostly works, but behaves oddly at times and nobody really knew why.

 

1 hour ago, Shenanigunner said:

To boil that down to one serious question: was the need to have an instant "Classic" revert-setting for this, or really for any of the other UI tweaks that were assigned this nearly meaningless label, so special and essential that breaking a key method of customizing the interface had to get scrapped?

 

This is hyperbole to the extreme. Nothing is broken. All your existing hand-curated bind files still work absolutely fine and you can load them with no change whatsoever in how it works. As a bonus, you can add the KeyProfile line if you want to select a specific profile when the file is loaded, but it's optional.

 

If you want to edit the whole list at once, you can still do that too. There's a copy of the Classic keybind list on the wiki. I posted the list from Modern on the forums (exported using that existing dev-build command I mentioned earlier) and I'm sure it will be added to the wiki soon also if it hasn't already. Copy and paste it into notepad and you're good to go. I already said we're going to add a command to export it from in-game in case those defaults ever change, so that small extra step is temporary.

[Number Six]

1 hour ago, BlackSpectre said:

So does this mean that if I bind, say, the W key to "+forward" and then save it to keybinds.txt that if I switch over to the joystick keybind profile I will be unable to move forward using my game controller because that action is already bound to the W key? I suppose, we COULD use a secondary key for the joystick binding, but that would also prevent easily switching to other profiles.

 

Not quite because the profiles and the bindings describe it in two different ways and it's a bit more complex.

 

The Classic profile for instance binds w and uparrow both to +forward. That gets mapped into an internal table that manages a primary and secondary binding for the command itself (the +forward part). This mirrors how things appear in the options menu and is what drives that interface, but it's also used to manage the bindings for commands that have a specific name in the profile.

 

When you bind W to something else, the bind that gets stored in the character is a straight key to command mapping like you're used to seeing. So if you /bind W foo, "W foo" gets saved on the server in the keybinds list. The internal mapping table removes W from +forward, so the +forward command has no primary, and uparrow as its secondary bind.

 

If you then switch to the Joystick profile, it has two binds for +forward in it: w, and joystick1_up.

Those get loaded into the internal state table first, as primary and secondary. Then the game loads in your "W foo" binding on top, so it removes w from +forward, leaving just joystick1_up.

 

If you already had a manual "W +forward" binding then it would just do nothing with that one, because W is already assigned to +forward in the table. So both W and joystick1_up would work in that scenario.

 

That all sound kind of convoluted, but the end result is that when you change profiles it actually ends up doing what you intuitively want it to do. W will still be bound to what you told it to, and the joystick mapping from the profile works correctly.

[BlackSpectre]

33 minutes ago, Number Six said:

If you then switch to the Joystick profile, it has two binds for +forward in it: w, and joystick1_up.

Those get loaded into the internal state table first, as primary and secondary. Then the game loads in your "W foo" binding on top, so it removes w from +forward, leaving just joystick1_up.

Right. That's basically the same thing as I thought. So for the joystick profile, the controller buttons are all mapped to the secondary keys to try to side step any trouble from custom binds. But am I right in concluding that if two custom binds bound both the primary and secondary keys (e.g., T and O to +forward that it would prevent the controller from being able to move forward after the player changes their profile to joystick?

 

Regardless, the idea of being able to make custom keybind profiles freakin rocks! I hope you guys decide to do that.  It immediately seems like something the general player base would use, not just slash command flunkies like me.  🙂

 

[Bionic_Flea]

7 hours ago, Number Six said:

So if you /bind W foo, "W foo" gets saved on the server in the keybinds list.

 

But Six, can't you see you're making things too hard.  Can you make it so that when I press W it enters my mission, finds the next enemy, calculates the best attack chain, performs that attack chain, moves to next enemy and repeats, while adding incarnate powers to the rotation if available.  That would be much better.  Thanks!

[Shenanigunner]

Quote

This is hyperbole to the extreme. Nothing is broken.

 

But nothing was broken before, other than (apparently) some grungy internal code that affected no one in 19 years. And it's my understanding that the code is pretty far from perfect across the board. 🙂

 

I don't think that for a chain of trivial bind changes, and then support for reverting them, and making things tidier in that area of the code, removing the ability to export current bind settings without jumping through hoops is an added-value tradeoff.

 

That is, just leaving the system alone, and not putting so much emphasis on a couple of nearly invisible binding changes that might upset a few people, in return for throwing up a hurdle that makes getting started in bind tweaks and UI customization more difficult, seems more reasonable to me; if you leave the system easy to tweak even for the most casual, fix-one-key customizer, it's better than this now somewhat firewalled, opaque setup.

 

Put a third way, yes, we can still all load bindfiles of massive redefinition and fiendish complexity.  But the first step to that is now much, much higher — there's no clear connection between the rather murky presentation of the binding menu and the actual keybind pseudocode — and that will discourage/deflect many who might otherwise learn some of this useful area of tinkering.

 

Thanks for the explanation, though. Que sera, and all that.

[BlackSpectre]

What I hear you saying, SG, is that adding that one extra step to see all of your keybinds actually hinders people's ability to make connections between what they do and how the whole system works. Hmmmm. You're actually not wrong. For me, who knows a bit about binding, it's not a huge deal... but for someone new to binds... yeah, I see that. It would make it harder by not allowing them to see the whole, but only part of the system. That cause and effect link is a bit more hidden. 

 

In light of my recent testing, I think the best course of action right now is to revert the bind system back to the way it was before Page 7, then start over from scratch on how to implement keybind profiles.

 

I'd be happy to help out and lend my support to whoever is tackling this issue. I might have some good ideas (who knows?), and I can definitely help by doing some thorough testing. 

[BlackSpectre]

One of the other things I noticed while testing out the new bind system is that if you have a different profile currently selected, and you load in your binds (/bind_load), the game will automatically switch to whatever keybind profile name is saved in the keybinds.txt file and load the binds into there instead of the keybind profile you are currently set to.

 

This behavior has potential to cause trouble. What if we wanted to load custom binds into both profiles? The game would only let us alter one profile. For people like me, it's not a hugemungous problem, I'd just edit the keybinds.txt file, change or delete the profile name, and re-load my binds into the specified profile. However, for people not so bind-savvy, it's a big problem.

 

I surmise that it's designed as a safeguard to prevent people from loading their custom binds from one profile into another accidentally.  But, and hear me out, if custom binds are  intended to be copied across ALL profiles, then there's no reason for the game to switch me to another profile. It wouldn't matter what profile I loaded my binds into. All the game would be doing is switching me to a profile that I DON'T WANT TO BE SWITCHED TO. Not exactly the best design for a user friendly system.

 

On the other hand, if custom binds are loaded into only one profile, then the current behavior prevents me from loading them into a different bind profile than I want them to be loaded into. 

 

There are many possible solutions to this problem, but the easiest solution is to add all 4 keybind profiles into keybinds.txt and have the system parse the file whenever binds are saved or loaded. This way whatever binds I wanted in my currently selected profile will go into my currently selected profile. The binds would be saved under that profile section in keybinds.txt. It will potentially make keybinds.txt larger by 4x. So what?  If the bind system does not just load in the entire keybinds.txt file, but only that portion for the currently selected keybind profile, it's a wash. Negligible additional burden on the system. 

 

Even better, the bind system can be left working ALMOST as it always has. All binds could be loaded into the server, not just the custom binds. Same as before. It would not cause trouble because custom binds would no longer be saved across every keybind profile... only the selected keybind profile. SO MUCH EASIER than asking the game to filter out custom binds from default profile binds, matching them, and then loading those custom binds across all profiles without considering whether or not the user WANTS those custom binds in every profile.

 

If people accidentally load in custom binds into the wrong profile, it's really their fault... BUT all they would need to do is reset their binds for that profile. If they have the custom binds that they wanted for that profile saved, they could then just reload them.  From the user's viewpoint, it's not any different than the bind system that we've been using for 20 years... except for the addition of more profiles and keybinds in the keybinds.txt file.  If we make a mistake, opps! Then we just reset or reload our binds for that profile. Easy peasy, and it would work exactly the same as it always has except for the need to select a profile (on both the user AND server side). That's it. Nothing else would need to be changed in the bind system. 

 

As far as safeguards go, all that would be necessary is a system chat channel message telling the user which keybind profile the custom binds were just loaded into. That would tell us if we actually loaded the binds into the profile we wanted. That's it. 

 

So what would need to be done? Alter the bind system to load in ONLY those binds for the selected profile. Save the binds to ONLY the selected profile. Reset the binds to ONLY those for the selected profile. 

 

Some keybind.txt management might be put into place, maybe, but in all honesty I think a player could have a blank keybinds.txt file and everything would work fine. The only time the keybinds.txt file would need to be altered by the system is if the user asked it to copy the binds for the currently selected profile into keybinds.txt (/bind_save). Really, nothing has to be managed by the system.   

 

If users are editing the keybinds.txt file, there will probably be mistakes... maybe a typo in the profile name? When loading in binds, at minimum an error message would need to be either sent or popped-up to tell the user that the currently selected profile does not exist in keybinds.txt, and abort. Or it could ask if the user wants the currently selected profile added to their keybinds.txt file. If so, the system would just copy the default binds for the currently selected profile into the keybinds.txt file. Make sure it does not delete anything out of the keybinds.txt file. If a profile exists in the file that the system doesn't recognize, just let it lay. More than likely any custom binds under that unrecognized profile are binds the user wanted in the profile to begin with but messed up on the profile name. On second thought, the system doesn't need to do anything other than send and error message to the user. If the user wants the profile copied into their keybinds.txt file, they'll just /bind_save. Easy peasy.

 

Badly written binds can be handled the way they've always been handled. The system rejects them and that's it. Use the same system.

 

This would solve ALL of the problems that I've heard voiced, and it would setup the bind system for the future... custom keybind profiles. 🙂

 

 

 

 

Edited March 2 by BlackSpectre

[BlackSpectre]

Now let's talk CUSTOM KEYBIND PROFILES!

 

A routine would need to be setup in the Keymapping tab of the Options window that allowed users to create and name their own custom keybind profiles. A popup or merely check boxes or a drop down list would ask the user to decide on which default profile the user would like to start with... Modern, Classic, Joystick, or Launch. Then the system would write that custom profile name into Keybinds.txt along with the chosen default profile. A designation of which default profile the user chose for the custom profile would need to be noted next to the custom profile names in keybinds.txt so that the system would know which default binds to use if the user ever wanted to reset the binds of their custom profile.

 

There would need to be a way to delete custom profiles from the Options window too. The default profiles would not be able to be deleted, but they could be hidden from the list. The system would then need to find that profile in keybinds.txt and delete it and all its binds... carefully. This would be a user initiated action, so altering keybind.txt has been user authorized. 

 

Using keybinds.txt to store all the profile names and then communicate them to the bind system would let users add or delete custom profiles from the profile list in the Options window just by editing keybinds.txt. Saving the custom profile names on the server would require an extra step of going into the Options window and deleting them that way. I'm partial to allowing users to add and remove custom profiles by editing keybind.txt, but that's me. Maybe both methods could be used? The idea is to continue to make keybinds.txt central to the bind system. Maybe the server could act in a backup capacity? Making things safer.

 

Some rules would need to be set in place for naming conventions that would not conflict with the server, and that's about it. Everything else was already setup in the post above. How the system handled the custom profile names doesn't really matter much. One way would just to read the keybinds.txt file and bring up a list of existing profiles that way. Or the custom profiles names could be saved on the server in addition to keybinds.txt. It would be kind of cool to be able to just edit keybinds.txt and add our own custom profiles to it right there without needing to go through the Options window to do it. We'd need to follow the naming and other conventions but that's about it. 

 

WHY CUSTOM KEYBIND PROFILES YOU ASK? Because it would bring so much more customization, utility, and ease of play to the game. The system I laid out above is so easy that every player could take advantage of it, not just tech savvy people. Imagine the amount of keybind customization that could take place! A player could have a set of binds for every Archetype, or for individual characters. They could decide to make categories like I did, Ranged vs Melee, and use those to setup all of their characters after they create them. A profile for every use, and a use for every profile.

 

"It is a dream I have." Camelot is just ahead of us...    

Edited March 3 by BlackSpectre
My god! The amount of typos that I make... sheesh!

[BlackSpectre]

BTW, if my understanding of the main problem is correct, all that really needed to be done to the bind system in order to make profiles work is... well... nothing. We'd need to add a popup message to the profile drop down list in the Options window that warned that in order for the profile to work, the keybinds need to be reset, and ask if the user wants to reset, and then ask if the user would like to save their current keybinds first... yes or no -- yes or no.

 

With the keybinds reset, the profiles would be unhindered by custom binds and would work perfectly. After, custom binds can be loaded if desired, then saved if desired using /bind_save_file. Not super user friendly, but no worse than the bind system has been for 20 years.

 

So much easier to write this code, and you wouldn't need to touch the bind system at all. You could literally use a /bind_load_file command to load in the profile binds from the server. The only additional thing we'd be coding is a new keybind profile drop down list sequence with a couple prompts and if/then statements. Easy peasy. 

 

This is why I recommend just rolling back the bind system to pre-Page 7 and starting over... in a much simpler way, making as few changes to the system as possible. Less headaches. Less hassle. Less heated tempers. Everyone would be happy. 

 

 

 

 

[BlackSpectre]

For the keybinds limit problem due to switching profiles all the time, I'd recommend just adding a directive to the "Keybinds Limit Reached" error message that directs players to reset their binds and then reload them.

 

If I understand the way the server is working (which I might not), resetting all keybinds would reset the bind limit as well. Problem solved. No other changes necessary.