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.

Recommended Posts

Posted

So I have to use a gamepad to play. I just can't physically hunch over a keyboard that much, have to look at the keys while I type, and don't have the reflexes to participate in combat via keyboard controls. As a result, I use a lot of fairly complex keybinds to keep everything except chat running through my XBOX gamepad. But recently, Windows decided for some unknown reason to delete my entire hard drive, and while I had backups on another drive, they were a couple years out of date and I'd made a lot of changes in streamlining binds and other aspects of how I do things since then.

Now obviously, even if some Devs took instant notice of this request and dove in with the gumption of a prime time teen heroine on a mid season finale, it still wouldn't be in time to save me a LOT of rebuilding effort. That said, it puts it even more in the forefront of my mind how some of these commands would allow me to make more combat functions universal across alts via where powers get placed in the trays, and have to do less character specific custom binds across the 800 or so alts I have. So here's what I'd like to see:

/powexeclocationauto ~ works just like the existing powexeclocation command, with access to the same variables, but let's me schedule it as an autofire. I normally schedule a powexecname Power Name and a powexecauto Other Power Name in a bind to activate on a button press (or release), with the auto power usually being the one with the longer cooldown or similarly more complex requirements to activate. So a power goes off, and if possible, another power goes off. A lot of Location targeted powers I would like to use more have long cooldowns. As such, as it is, I can only pair them with other powers with just as long or longer cooldowns. the /powexeclocation command made a lot of powers work vastly better with keybinds, because I can combine the power activation and the target variable into the same action. Obviously, not all location powers will work optimally, or even well with this, but that's been kindof a silent disclaimer with keybinding in general since the beginning.

/powexectrayauto ~ this would allow us to set a tray/slot to autofire. It would be the real workhorse in standardizing keybinds across alts. If I can set a slot to autofire in a bind command, all I have to do is create the command for the base keybinds and not a custom one for every character, then make sure the correct power is placed in the correct slot. Behind the scenes, it should probably be incompatible with toggle powers, so if a toggle is in that slot, the autofire just has no effect. that said...

/powexectoggleontray (and powexectoggleofftray) ~ These commands would be the flip side of the /powexectrayauto in that they would only work with toggle powers, but would allow me to toggle on whatever armor powers are in a particular slot, again meaning I just need to make sure the correct power is placed in the correct slot, and be able use universal keybinds to toggle on (or off) various armor toggles or whatever, regardless of which powerset the character is running.

Obviously any powexec*tray command should have a corresponding powexec*slot command just to be thorough, though personally I find use of powexectray commands to make powexecslot commands redundant.

/alias ~ This would take two variables, and make the use of variable 1 read the same as variable 2 in keybinds. It would probably require the creation of a .txt file (or even creation of a new file type, like .costume files... say .alias, that could still be read/edited with notepad) to contain all the aliases. An alias would allow us to create shorter commands or even a mix of commands and variables, to help keep keybinds under the 255 character limit. A functioning alias should probably require a special symbol at the beginning and end, so if you were going to make a shorter toggleon command it might look like /alias powexectoggleon {tgon}. It doesn't have to be those particular brackets, but without some special character bracketing the new command, it could create problems if that were just a section of a term used normally in other aspects of keybinding, such as ect being part of powexectray, so if you wanted to use ect, it would have to be {ect} to be properly recognized. A more thorough example might be /alias powexeclocation target Combat Teleport {bamph} which could then be used as such: /bind 1 "powexecauto Cross Punch$${bamph}$$bindoadfile <path>" or, in conjunction with powexectoggleontray, we might have this: /alias powexectoggleontray 8 9 {tg9}/alias powexectoggleontray 8 8 {tg8}/alias powexectoggleontray 8 7 {tg7}, and so on, to then combine into /bind NUMPAD0 "{tg0}$${tg1}$${tg2}$${tg3}$${tg4}$${tg5}$${tg6}$${tg7}$${tg8}$${tg9}" making a short individual bind that might be useful for something like my Dark/Rad tank (that has 10 toggles). There are of course existing ways to do this, for instance I currently write a macro with all the toggleons and then incorporate a powexectray command on the same bind that I have for jumping (+up). It also has some other utilities like toggleoff Rest, so if I'm resting and I jump, I just jump instead of having to manually turn it off first. But there are times when that's not enough, and times where a more elegant option might be preferable. Especially if you have a lot of alts with their own personalized binds, and you reuse certain lengthy commands often. Obviously, such a command has great potential to break things, so it should only be used with caution, and the uses experimented with before being depended upon... But we are playing Supers after all, Great Power is kinda our thing.

Anyway, standard disclaimer... I'm not a programmer. I'm not fluent in C, C+, C-, or D-, and the only Python I'm familiar with eats mice. So I can't even guess how feasible or difficult these might be to implement... like would the /alias command even actually bypass the 255 character limit? or would the machine just translate it then impose that 255 limit after, possibly cutting off the end of a command? (Is the 255 limit even an actual requirement, or just a legacy imposition?) But lacking the skills to implement them myself, I can only express the desire to see them implemented by others, along with some justifications for why they'd be a good idea.

Posted

/show_base_entry_code ~ so in the loss of data and outdated backups, I also realized I didn't have a entry codes noted down for a couple newer bases. Now fortunately, I was able to recover them using /bindsave on a character that had them, but that might not always be an option for others in such circumstances. I suppose it should be tied to base entry permission, just in case that's an issue for anyone's base... (Does anyone use bases for anything other than decoration or transport hubs though?)

Posted

Not so much a new command, but a change to how a command works... that would also make staging power activation rotation in keybinds a lot easier... 
So normally you can "stack" more than one powexecname Power Name in a bind, and it will activate the last in the list if it's usable, if not the next to last, and so on. Very handy if you have powers from very disparate levels and want to use the highest level if possible, but still use a lesser power if it's not. Auto Attacks almost work the same way. If you don't have access to an auto attack further right in the bind, it will get passed over for the next to the left. That's great if you're writing a bind to include a power you haven't taken yet. But if you have the power, and are RSK'd too low to access it, it doesn't get passed over anymore. It just stops there and doesn't consider lower level autos you may have designated even if you have access to them.

If the powexecauto could be changed to operate the same as the powexecname, we could stage contingencies in the bind sequence while often using fewer keybinds and being less likely to disrupt power rotation.

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...