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.

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...

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. 🙂

The best way forward would be to re-post this question in the Help & Support section of the forum, or send in a petition while in game (/petition). My thoughts? Unless you have a bind or something that keeps loading in old options.txt settings, they shouldn't reset. I haven't played much since Page 7 hit, been doing a lot of other things, so don't have any personal experience to share. Sorry.

Maybe. It depends on whether or not the server retains your custom binds until then. There are many variables that could wipe them from the server. Look inside your keybinds.txt file, if there are custom binds in there, copy that file and save it somewhere else on your computer for safe keeping.

Not at all. When you make a new toon the game's default keybinds will be loaded onto your character. If you have any custom binds in your keybinds.txt file, then they will be loaded too. If you don't, then you'll just be using the game's default binds. If you have a lot of custom keybinds saved in keybinds.txt, it would be a good idea to make a copy of it and store it somewhere else on your computer for safe keeping.

I'm finally done with updating the Options Window page! Does anyone have any comments, critiques, suggestions before I put it to bed? https://homecoming.wiki/wiki/The_Players'_Guide_to_the_Cities/User_Interface/Options_Window P.S. Do you like the descriptions for each section under the Windows Tab? I wasn't sure, so I didn't do descriptions for the rest of the options window. What I really want to know is whether or not they're worth putting in the page...

The Keybind Profiles are in that drop down list at the top of the Keymapping tab of the Options window. It has nothing to do with accounts. Apparently, the drop down list was always there, it's just that no one paid any attention to it (there's at least two good reasons for that, but I won't get into it). I know I didn't think about them at all until Page 7 hit. Profiles are different sets of binds. You select one profile and you have its set of binds. You select another profile, and then you have its set of binds instead. For example, let's say I have 2 profiles: Ranged and Melee. If I select the Ranged profile, my F key will be bound to "target_enemy_near", but if I select the Melee profile the F key will be bound to "target_nearest_enemy$$follow". Right now at Homecoming, the keybind profiles are just different sets of default binds: Launch - the default binds as they were when the game started (Issue 0) Joystick - the recommended set of binds for game controllers Classic - the default binds before Page 7 Modern - the new default binds when Page 7 hit I've ony been able to see the binds in the Classic Profile and the Modern profile. There's not much difference. 32 changes in all, but most of them are innocuous. Here's what is different about the Modern default binds compared to the Classic default binds: ctrl+0 "powexecserverslot 10" ctrl+9 "powexecserverslot 9" ctrl+8 "powexecserverslot 8" ctrl+7 "powexecserverslot 7" ctrl+6 "powexecserverslot 6" ctrl+5 "powexecserverslot 5" ctrl+4 "powexecserverslot 4" ctrl+3 "powexecserverslot 3" ctrl+2 "powexecserverslot 2" ctrl+1 "powexecserverslot 1" shift+0 "powexecalt2slot 10" shift+9 "powexecalt2slot 9" shift+8 "powexecalt2slot 8" shift+7 "powexecalt2slot 7" shift+6 "powexecalt2slot 6" shift+5 "powexecalt2slot 5" shift+4 "powexecalt2slot 4" shift+3 "powexecalt2slot 3" shift+2 "powexecalt2slot 2" shift+1 "powexecalt2slot 1" shift+f1 "teamselect 1" shift+f2 "teamselect 2" shift+f3 "teamselect 3" shift+f4 "teamselect 4" shift+f5 "teamselect 5" shift+f6 "teamselect 6" shift+f7 "teamselect 7" shift+f8 "teamselect 8" mousechord "+forward$$playerturn" leftdragworld "+camrotate" mbutton "+camrotate$$camturn" w "+forward$$playerturn" These last 3 support a kind of gameplay that leaves the camera completely detached from the character. In my opinion, those commands are more useful in PVP than anywhere else. They are an improvement I think. The Modern profile moved the "powexecalt2slot" commands from CTRL+# to SHIFT+# Moved the "team_select" commands from SHIFT+# to SHIFT+F# All to reduce finger strain and make room for... And added the "powexecserverslot" commands as default bindings for the first time to CTRL+# All the rest of the default keybindings are the same between the two profiles. So really not too much difference between the 2 profiles. I haven't tested the new mousechord binding yet (when you press and hold both the right and left mouse buttons at the same time). So I'm not yet sure if it's an improvement over "+mouse_forward" or not. P.S. Oh! I forgot to mention one other change. You can no longer save a list of all your keybinds, nor save the default keybinds. You end up with a file that contains only your custom binds, or a blank file.

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.

Until the bugs in the new keybinding system are smoothed out, I HIGHLY recommend that players avoid the "Save to Default File" button in the Keymapping tab in options and refrain from using the /bind_save slash command. Saving your keybinds will often erase the entire keybinds.txt file, wiping your custom binds from existence. Also, DO NOT SWITCH PROFILES. Pick one and stick with it. If you switch profiles twice, your custom binds will no longer work. Hopefully, you didn't save your binds in game because you will need to reload your custom binds. Otherwise, binds appear to be working normally.

OK. I have a couple friends who are miffed about the bind changes and in trying to help them, I ran across 2 bugs... 1. When /bind_save is used it SOMETIMES will erase the entire keybinds.txt file except for the profile name, including all custom keybinds. Sometimes it will save only the binds that are different than the default keybinds on the server, but then it also truncates the keybind.txt file. My keybinds.txt is 157 lines. After /bind_save, it was 63 lines AND none of the keys below CTRL+NUMPAD1 were there in the file. Of course, if you then reload keybinds.txt, it will overwrite all of the custom binds below line 63 on the server and set them all to server default. If you load in a blank keybinds.txt, it will reset all your keybinds to server default whether the server has retained your custom keybinds or not beforehand. 2. If you have made custom keybinds and you switch to a different keybind profile, SOMETIMES it will remove the custom keybind in favor of the server default. If you switch profiles twice, it will ALWAYS remove your custom keybind from the server... and this is all without touching /bind_save or /bind_load. My understanding is that: 1. When /bind_save is used, the server will match every bind in the file against the server default binds and then remove the matched binds from keybinds.txt, leaving only the custom binds in keybinds.txt. This is not happening. 2. When switching profiles, the custom keybinds will remain the same for every profile no matter what profile you have set in Options. This is also not happening. Worse, it erases your custom keybind from the server completely when you switch back to the original profile. This effectively renders the entire keybinding system non-functional. If you can't save your custom keybinds back into keybinds.txt, when switching profiles or saving binds, your custom keybinds are lost and unable to be restored. This is especially true if you are a player who only uses the Option Window to set custom keybinds. Poof! Gone. What's worse, if you do not have a backup of your finely curated keybinds.txt file, if you happen to save your binds, you're screwed. All that work is down the drain. Sorry to be the bearer of bad news. 😞

Over the years there have been attempts to restore Direct 3D Sound to older games. The most recent attempt I've found is from 2020, presumably for Windows 10 (Windows 11 didn't come out until 2021). It still might work, but I haven't tried it. https://gnd-tech.com/2020/08/how-to-enable-3d-audio-in-directsound3d-and-openal-games-without-a-sound-card/ The Direct 3D Sound, before Microsoft Windows dropped support for it in 2010, was designed to work with Dolby 5.1 surround sound systems... 2 speakers in the front and 2 in the back with a dedicated subwoofer. Enabling Direct 3D Sound while using headphones was generally considered pointless as most headphones down mix the 5.1 audio to 2 channel stereo. There are headphones on the market that can simulate a 5.1 sound system using phase shifting, but it's not as good as an actual 5.1 audio system in the room. That said, it is possible. Here's a link for a good discussion about it City of Heroes included many sounds in the 3d format such as footsteps, vehicles, citizens, flight, and swimming, but not all sounds. Still, it would be interesting to hear them. As far as I know, the old Direct 3D Sound is still part of COH.

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. 🙂

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

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! 🙂 Excellent! Sounds good @Number Six, and thanks. 🙂

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.

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: 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! 🙂

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.

How is LEFTDRAGWORLD different than LEFTDRAG? Nevermind. LEFTDRAG doesn't work anymore. Good to know.

I don't know what to tell you, my friend. I've tested it and it works for me. After binding the shift and lbutton I teleport just fine, and when I only press shift nothing happens. I used the same bind as you /bind shift+lbutton powexecname teleport. Also when I unbind them, they actually unbind. As an aside, I do know that LSHIFT and RSHIFT are merely aliases for SHIFT, so probably best jus to use SHIFT rather than the left and right versions. A long time ago I did run into your problem with the shift key holding onto a command even though it was a chord key used in combination with a mouse button, but I can't remember how I fixed it or even how it came to be. My guess is something is corrupted in your game files. So try this: 1. Save your key binds with /bindsave 2. Go to your Homecoming folder/settings/live/ and move the key binds.txt file out of the game folder (don't delete it) 3. Go into the Options window, select the Keymapping tab, and press the Reset Keybinds button. 4. Quit the game and restart it. 5. Type: /bind shift+lbutton powexecname teleport and see if it works. 6. if it works, load in your keybinds.txt file with /bindloadfile and test it again. You may have to bind the shift and left mouse button again. If it messes up after this, there is something in your keybinds.txt file that is messing things up. Could be as harmless as a blank line or an extra space (or some other character) somewhere that's causing the trouble. If you can't identify the trouble, then you'll have to move your keybinds.txt file out of your game folder again, reset keybinds again, restart again, and rebind all your keys again the old fashioned way by typing them into chat. Use your old keybind.txt file as your guide. When done, /bindsave. If it wasn't your keybinds.txt file and it still doesn't work, the last resort is to delete and reinstall your game. Start fresh. Really, it's not that big of a pain if you save all your personal game data beforehand. So copy your Homecoming/settings/live folder that includes the wdw.txt, chat.txt, options.txt, keybinds.txt, and gfx.json and client.json files. Don't forgot to also copy the Homecoming/ costumes folder, Homecoming/screenshots folder, Homecoming/powercust folder, Homecoming/accounts/<username> folder, Homecoming/data folder if you have it, and the Homecoming/logs folder if you want them. After you've reinstalled the game, start it up and test your bind, then quit. Then copy and paste the files back into your Homecoming folders... or just start fresh. Up to you.

If you're making one big table and it has 2 sections, instead of breaking it out so that each section is it's own, separate table, you can make it "look" like they are separate sections by creating a blank line between the sections of the table. To do this, you want to turn the columns in a row into one big cell with COLSPAN, then you'll need to change the background color of the cell to the same as the color of the main page (in our case usually white). Then you'll want to remove the borders on both the left and right sides of that blank line. Here's the wiki code to do it: colspan=2 style="background:white; border-left:hidden; border-right:hidden;" The wiki code for a simple table with 2 columns would look like this: {| class="wikitable" |- | Some Example Text | Some More Example Text |- | colspan=2 style="background:white; border-left:hidden; border-right:hidden;" | &nbsp; |- | Second Section Text | More Second Section Text |} The HTML code for a non-breaking space (&nbsp;) is necessary for the cell to have some height. And that's it! Fast and easy! 🙂

I don't know why this information isn't everywhere, especially in the pages about wiki tables, but I finally found the answer. Here's the problem... When you add a page header (== Header ==) inside a table, the wiki no longer recognizes it as a page header, it will not do any wiki formatting to the header text, and will not add it to the table of contents (TOC) for that page. But there's a solution... The wiki recognizes many HTML and CSS tags/code, but no where near all. Luckily, the wiki recognizes the HTML tag for a header <H2>Header</H2>. The equivalent wiki headers and HTML headers are as follows: = Page Title = <H1> (this should not be used for anything other than the title of the page, so for the most part we don't need to use it) == Header Lvl 2 == <H2> (this is the first category on the table of contents.) === Header Lvl 3 === <H3> (this is the first sub-category on the table of contents) ==== Header Lvl 4 ==== <H4> (this is the second sub-category on the table of contents) So a simple table with a page header (that is a different thing than a "table header") would look like this: {| class="wikitable" |- | <H2>Page Header</H2> |} And that's it. A simple answer that was really hard to find!

If one change was made to popmenus I’d love to see them be able to activate other popmenus or even themselves to create loops for helpful info and clicking. Right now if you do that for any other level than the second, sub-menus activating a popmenu will lock it up. After that, ability to color titles and text, ability to write comments without having to resort to activating fake badges to do so would would be great. After that, the ability to use images or emojis would do wonders. Just the basics.

Yes, this would be SUPER HELPFUL for many, many people, and yes it’s beyond criticism. Along with power icons there are also macro buttons. We definitely need an easy way to save our macros and macro commands, Similar to the /bind_save and /bindsave_file family of commands. /macro_save, /macro_load, /macro_save_file, macro_load_file. Depending on how the Macros.txt default file is formatted, the /bind_load_file command can step in as a working substitute for the /macro_load_file command since it currently works well to load in macros.

However, when the keybinds are reset (with with the options window button or the /unbind_all slash command) the team member selection bindings are set to Shift+1-Shift+8 P.S. Oh! This is due to the Keybind Profile setting being set to Classic. Got it.