Jump to content
Hotmail and Outlook are blocking most of our emails at the moment. Please use an alternative provider when registering if possible until the issue is resolved.

BlackSpectre

Members
  • Posts

    716
  • Joined

  • Last visited

Everything posted by BlackSpectre

  1. Therein lies the rub... everything in the Unofficial Homecoming Wiki is an exact copy of Paragon Wiki, except for those pages that have been updated. So when you look at Paragon Wiki and look at Homecoming wiki, more often than not you're looking at the exact same data. Paragon Wiki was a colossal effort on the part of hundreds of players who created tens of thousands of pages. As far as I know, the Homecoming Wiki has about 15 players editing and updating it. It's a huge task to update everything, and there is really no way a small group of people can replicate what hundreds of people did in any sort of reasonable timeframe. The recent posts questioning XP gain bumped this Experience page up in priority. So the data we start with is Paragon Wiki data. This Experience page does not appear to have been closely looked at since the Paragon Wiki days. Questions were raised about its validity, so I figured I'd just ask the devs if they have a handy XP table laying around. But a sincere thank you to all of you who took it upon yourselves to go Beta and test out the XP data., especially @lemming and @AboveTheChemist. Thank you. 🙂
  2. Hey guys, I'm not really sure if the forums are the right place to ask my favorite Devs for information to update the Wiki. If there is a better method, please let me know. Anyway, I'm looking for experience gain related data. 1. The amount of experience needed to gain each level. 2. The amount of base experience earned from defeating a minion, a lieutenant, a boss, and AV, giant Monster, etc. at each level. And anything else I haven't mentioned but might bear on this topic. I know there have been many changes at Homecoming so the tables at the wiki are likely very outdated. Thanks a bunch! P.S. Here's the experience data we currently have at the wiki https://homecoming.wiki/wiki/Experience
  3. Uiskin (Command Line Parameter) - Unofficial Homecoming Wiki
  4. 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.
  5. When I was a young hero, I strove to get Invention Origin enhancements because they save you a lot of money in the long run. Changing out Single Origin enhancements every 5 levels adds up to a bunch! I was able to spend a third less on enhancements, because once you slot an IO, you don't have to upgrade it for the rest of the game it still keeps its strength. I thought I was doing great! Then I learned about power leveling, these days also called farming. Using my trusty fire/kinetics controller I mowed through fire missions with a whole team of players just sitting at the door. I charged those players to be sitters. I give them lots of xp, they give me lots of inf. The nerf bat came down on that, but there were still ways to power level using different damage types. I made tens of millions doing that. When I got to Homecoming, I re-created my characters. Then I began power leveling/farming again... but this time I discovered posts from some very smart players about how to build the ultimate power leveler. Using that as a framework, I made my own Brute and began farming in the Architect Entertainment. I usually did not bring other players with me, and had no sitters, but I made moola like you wouldn't believe! Not tens of millions... hundreds of millions very quickly!!! Then I decided to play with the market. The Auction House was a part of the game that I had never really paid attention to. The way to make money there is the same as in real life... buy low, sell high. Luckily, I had about 300 million inf by then, and I used that to start off. I tried a lot of things. Some bit me, most broke even, and some... well, some were spectacular! I made about 11 BILLION inf playing the market. I bankrolled my entire Supergroup, giving them at least 4 billion in all. Now I'm sitting in Comfy City. I don't really want for anything, but I still try to be a little frugal at least. Even a billion can go pretty fast in this game if you don't care how much you spend. I'm not the only one in this situation either. There are MANY players who have built up war chests with vaults full of inf. I only play the market now about once per year, and that's just to replenish what I have spent. If you're ever hating for cash, just yell out in broadcast or local chat and say "I need to upgrade my SOs but I can't afford it. Does anyone have any SOs or inf to spare?" You're likely to get a ton of generous responses. 🙂
  6. OK. Done! Finally done. Phew that was a lot of work! Glad it's behind me. 🙂
  7. 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.
  8. 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...
  9. 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. 🙂
  10. 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.
  11. 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.
  12. 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.
  13. 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...
  14. 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.
  15. 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.
  16. 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.
  17. 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. 😞
  18. 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.
  19. 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. 🙂
  20. No no, I'm just thinking ahead about what could be... the ghost of Christmas Yet to Come.
  21. 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. 🙂
  22. 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.
  23. 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! 🙂
  24. 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.
  25. How is LEFTDRAGWORLD different than LEFTDRAG? Nevermind. LEFTDRAG doesn't work anymore. Good to know.
×
×
  • Create New...