BlackSpectre

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.

Ah crud. I just now viewed the page on my iPhone and the alt text (tooltip) doesn’t work. It will work for computer but not mobile. Bummer. Well, I guess the choice is made for me.

OK. Which format do you like better? The image with the popup, or just the slash command? https://homecoming.wiki/wiki/The_Players'_Guide_to_the_Cities/User_Interface/Options_Window

As long as we're thinking about the Apply button, would it be possible to fix the /FULLSCREEN command so that it activates the Apply Button? To be more specific, the /fullscreen 1 command activates the apply now button and puts the game into fullscreen mode, but /fullscreen 0 does not activate the apply button and does not put the game into windowed mode (and it really should). It would make switching between fullscreen mode and windowed mode a LOT easier, and I do that a lot, especially if I'm switching between computers or want to see other apps on my display alongside a windowed COH game. I have a set of binds made for each of my computers because I do this so often.

Oh wait! I can do it with an image!!!

OK. Thanks ATC. I'm not happy with how much space the slash commands are taking up on the page though. If I could make it into a thin column with a little text the prompted a pop-up of the entire slash command, that would rock. But dunno if that's even possible. I guess I could put a link to the Option Names List page with short text indicating a slash command. Something like this, [[Option Names List|Yes]]. I could put anchors on the Option Names page, but aside from being a lot of work , it doesn't tell the reader that they need to use /option_set, it just links to the option name. Sigh. Donno.

If what you did would work on a Mac (I know linux is similar), is there any chance you could tell me how to do it for both? I'm computer savvy, but not a professional. Well, not any more anyway. 🙂