Black_Specter

AWESOME!! Thanks Bill!

Incidentally, FSAA also makes the screen go black for me at 4x, but seems to work fine at 2x (with all your settings from the first post of this thread). Just some additional confirmation for ya. I'm using an ATI All In Wonder 9800 series AGP card.

Thanks for all your hard work and excellent explanations.

Ok, so quick question...

I have a regular (non-LCD) monitor... do I want a higher Refresh Rate than 60? Or will it be a performance hit?

Thanks

With one key press?

Try:
/macro "aimbu" powexec_auto Aim$$powexec_name Build Up

or visa versa

You could also make a toggle key text bind that would activate Build Up on key press, and then activate Aim on key release.

Personally, I'd go with the text bind above. It's likely to have less errors than any other type of bind. On the other hand, you could try this simpler bind and see if it works well enough for you if you're shy of creating text binds...

w "+forward$$powexec_name Rooted$$powexec_name Granite"
a "+left$$powexec_name Rooted$$powexec_name Granite""
d "+right$$powexec_name Rooted$$powexec_name Granite""
s "+backward$$powexec_name Rooted$$powexec_name Granite""

This bind above will toggle between the two powers depending upon their on/off state. If the powers get out of sequence during use, just click off the one you want to turn on next.

This bind also will have problems if you press two bound movement keys at the same time. Also if you encounter a lot of lag, commands bound to movement keys are likely to mess up. Personally, I wouldn't bind the A, S, or D keys, and just have the powers toggle on and off only when moving forward (on the W key only), or perhaps backward as well (the S key) since you don't ever move foward and backward at the same time. On the other hand, I don't know how Granite and Rooted work, so it might be best to bind the left and right movement keys too.

Anyway, good luck.

[ QUOTE ]
Marshal_Victory,

About the swap file. There is SOME performance gain by ridding one's self of Virtual Memory. In a nutshell, if Windows CAN swap something off to the swap file, it will. With over 1GB of RAM, there's no point in letting it.

There is a camp on the other side that says this is always a bad idea. But my take on it has always been, reading and writing to a hard drive will never be as fast as reading and writing to RAM, so you might as well leave everything you can in RAM.

[/ QUOTE ]

What if you have only 1 GIG of ram? Still disable the swap file?

[ QUOTE ]
[ QUOTE ]
Recall Friend :

IMO is a MUST Power for any Rezzer.

[/ QUOTE ]

I took both recall friend and tp foe. I'll recall friend fallen teammates into a pile preferably around a corner from any enemies, tp foe an enemy to the pile, hit him with FS or PG and use him to power the rez. Works great.

[/ QUOTE ]

I agree... especially with Howling Twilight because it can rez several team mates all at once if they're in the AOE radius. TP the toons in a pile, and then hit the rez... a team wipe, turns into a team victory!

TP Foe would be useful, but I couldn't spare the power slot for it. Would like to have it, though.

GREAT guide, btw. Where did you get the numbers for the powers, such as 25% def for Dark Embrace, etc.?

Well, new stuff just keeps on coming! And I'm thankful for everyone here who keeps bringing this stuff to my attention.

Here's a new bit that should be placed in the TEXT BINDS section and deals with the BIND_LOAD_FILE command:

For the BIND_LOAD_FILE command to work, long filename and directory names (meaning names having greater than 8 characters) may be used, but the game will not accept blank spaces in the names of the directories and files on your computer. For example, this bind will NOT work because of all of the blank spaces in the path:

/bind_load_file c:\program files\city of heroes\my binds\testing the bind length.txt

Merely one blank space in only one of the names above will spell doom for the bind, and an error like this one will pop up in the global chat window of the game:

“Usage:bindloadfile takes 1 args, you gave <#>.”

To avoid this error, the best solution would be to simply create or use directories and file names without any blank spaces in them. I’d also recommend that your directory and file names not exceed 8 characters in length, just to avoid potential complications (although at the moment this is not required). Also, if you use a sub-directory in the City of Heroes game directory for your binds, the “.\<directoryname>” switch described above will work well. Lastly, you can use the MS DOS 8.3 standard naming convention to translate the long directory/file names that contain spaces into a syntax the game can understand. To do this, shorten a long name to the first six characters of the original name, ignoring blank spaces, followed by a tilde (~) and a unique number -- plus the 3 character file extension if one exists. If the short name is a duplicate of another name in the same directory, make sure the number at the end of the name is different than the number of the duplicate directory/file (usually the next sequential number: 1, 2, 3, etc.). For example, the error-producing path “c:\program files\city of heroes\my binds\testing the bind length.txt” can be translated into a working path that looks like this:

c:\progra~1\cityof~1\mybind~1\testin~1.txt

[ QUOTE ]
The problem is that after I bind "lshift+ whatever", I can never get the "shift+ whatever" bind to work on that character again! Does anyone know how to restore the character so that "shift+ whatever" works again in a bind? Does it involve using the "nop" command?

[/ QUOTE ]

The problem is that I don't know exactly what you've done, so it's difficult to troubleshoot your bind keys. HOWEVER, try clearing the binds from all the following keys and then starting over from scratch:
LSHIFT
LBUTTON
LSHIFT+LBUTTON
LSHIFT+WHATEVER

To clear a bind from a key type:
/bind <key> " "

Make sure to inclue a blank space between the quotes.

[ QUOTE ]
Another note. In your guide you state that you need a space after the + to make press and release functionality work. Thus you need "+ $$". My binds all use "+$$" and work just fine. I hold the key, bind activates. I let go, bind activates again. Though my binds use the various shift keys (shift, ctrl, alt) so maybe it's not the case for text keys. I'll have to do some testing.

[/ QUOTE ]

Very cool! I got the info for the + prefix from a post here at the forum, but I DO remember testing this too. The results then were that without the space, the bind truncated the beginning of the next command name. However, NOW it seems that it doesn't do that anymore when the + prefix is right next to the command seperators without a space (i.e., "+$$")! Very strange. Also very cool that you caught that! :-)

I think, because of the disparity, I would still recommend adding the space between the + prefix and the command seperators, just in case the bind rules are changed back to the way they were before. But it DOES work! :-)

[ QUOTE ]

.\binds\tp0:
<font class="small">Code:[/color]<hr /><pre>
Z "+ $$bindloadfile .\binds\tp1"
LBUTTON " "
</pre><hr />

.\binds\tp1:
<font class="small">Code:[/color]<hr /><pre>
Z "+ $$bindloadfile .\binds\tp0"
LBUTTON "powexec_name teleport"
</pre><hr />

Which will make the left mouse button cause one to teleport to the spot clicked upon, if it is clicked while the Z key is held down.

[/ QUOTE ]

Functionally speaking, the way the above bind is designed, it doesnt' function any differently from the normal LSHIFT+LBUTTON teleport bind.

But get rid of the "+ " prefix, and you'd have a nice bind there! That way, hitting the Z key would turn on "teleport mode" which would let you simply left click the mouse to teleport. No holding down any keys. Then press the Z key again and you turn "teleport mode" off so that you can use the left mouse button to click things again without activating teleport.

Visit my web site or search this forum for the subject "teleport" and you'll find the very cool teleport bind I created that incorporates the above mechanism but also adds additional features that really help out.

That's a good point about the weapons being holstered and redrawn. I don't much care about that, but I guess others might, so it's useful to point out. Thanks. :-)

Well, in all modesty, the best teleport bind I've ever seen is one I designed myself. Can't really take complete credit for it, as (after the fact) I discovered that the idea for the bind had already been discussed in a post here at the Forum somewhere, but no example was given.

In any case, this bind is extremely useful for traveling long distances. What it does is toggle "teleport mode" on and off. When toggled on, all you have to do is point the mouse and click, and off you go to your destination. No need to press down the SHIFT key! Just keep clicking away like mad teleporting fiend! It might not seem like a big deal, but I don't get mis-fires like I did before with the SHIFT+LBUTTON bind. It is also, strangely, a bit faster to teleport around this way. So much so, that with this bind, I'm not sure that Hover is needed to keep you in the air (although took the power). It is simply the easiest way to teleport. Try, and let me know what you think (fyi, this bind assumes you also have the Hover power in addition to Teleport, which I highly recommend)...

/bind_load_file c:\[file location]\tpon.txt

TPON.TXT
F "emote Teleport completed.$$powexec_toggleoff hover$$bind_load_file c:\[file location]\tpoff.txt"
LSHIFT+F "tell $name, Hovering...$$powexec_toggleon hover$$bind_load_file c:\[file location]\tpoff.txt"
LBUTTON "powexec_name teleport"



TPOFF.TXT
F "emote Teleporting...$$powexec_toggleon hover$$bind_load_file c:\[file location]\tpon.txt"
LSHIFT+F "powexec_toggleoff hover"
LBUTTON " "


What this does is turn on Hover at the same time as Teleport with the F key, and then turns Hover off when done teleporting. It also allows you to turn Teleport Mode off by holding down the SHIFT key and pressing F, but still let's you hover. I found this to be very important for hunting and in other situations where you want to stop teleporting, but you still want to stay up in the air. Pressing F again will start teleport mode again so you can resume teleportation after hovering. A VERY cool bind!

As an aside, I also have the SHIFT+LBUTTON bind, which I use when in missions during combat.

Thanks for the compliments, guys! I'm glad some of this stuff was useful.

I polished and added a few things to this Advanced Bind Guide and have reposted it here as ADVANCED BIND GUIDE v1.1 .

Hopefully this second draft is clearer and easier to understand. The additional material deals with how to clear binds from keys, a new section on text binds, and a couple other small, but important things. I expect (and hope) v1.1 of this guide to be the final draft.

As an aside, yeah, the bind rules apply to macros as well. A little trick I learned regarding key binds and macros, is that you can bind a macro to a key, or rather have a key bind execute a macro by using the powexec_tray command.

ADVANCED BIND GUIDE
By BlackSpectre

The purpose for this guide is to provide more detailed information on HOW binds work so that the would-be bind designer can more intelligently craft their own binds or troubleshoot them. This guide grew out of my desire to understand why a bind I created worked, and I figured I might as well write down what I’ve learned in the hope that someone else might find the information useful. I have gathered the information in this guide from many different sources: the City of Heroes Forum, my own testing and experience, and from fellow gamers such as Innovator, Blueray, Cockaroach, and Zerotemp. It is my hope that presenting this information in one concise document will help others to create superb binds much easier than if they had to track down all this information on their own.

This guide assumes the reader is familiar with the /bind command in City of Heroes/Villains and has mastered its more common functions as detailed in other venues such as Curveball’s excellent Unofficial Guide to Binds . As such, many details on how to create and use binds are omitted from this document. If you are new to binds, please read Curveball’s guide above, read the binds section in the COH manual, and familiarize yourself with making binds before you read this guide.

Version 1.1 of this guide supercedes the first version, and includes information on Text Binds, methods to clear binds from keys, and polishes up some of the language used earlier to make it more accurate.

TABLE OF CONTENTS:
1. Multiple Toggle Binds
2. Using Powexec_NAME
3. Using Powexec_TOGGLE
4. Combining Powexec_NAME and Powexec_TOGGLE
5. Understanding Multiple Powexec Commands For The SAME POWER
6. Text Binds
7. Using "Toggle Keys"
8. Toggle Key Text Binds
9. Movement Direction Commands
10. Click Power Binds
11. Using Powexec_AUTO
12. Turning Powers Off
13. Clearing Binds From Keys
14. Arranging Your Bind Commands
15. Dealing With LAG


MULTIPLE TOGGLE BINDS

Multiple toggle binds are binds that contain more than one toggle power. There are 6 commands used to activate a toggle power in a bind:
1) powexec_name [power name]
2) powexec_slot [slot#]
3) powexec_altslot [slot#]
4) powexec_alt2slot [slot#]
5) powexec_tray [slot#] [tray#]
6) powexec_toggleon [power name] (and it’s opposite, powexec_toggleoff [power name]).

The first five commands operate in the same way as powexec_name (1-5), while the powexec_toggleon command operates in a distinctly different manner.

The length of a bind can not exceed 255 characters. Omitting underscores "_" in commands such as powexec_name, powexec_toggle_on and bind_load_file, and leaving out unneeded spaces is one way to cut and decrease the character count, in order to enable longer binds. For example, "powexec_name" becomes "powexecname," "bind_load_file" becomes "bindloadfile," etc. Underscores aren't even read by the command parser, and only serve to make commands easier to read. In fact, bind_load_file is the same as bindloadfile, or bindload_file, or b_i_n_d_l_o_a_d_f_i_l_e. When your binds get lengthy, space becomes precious because of the limit to the text size of a bind, so it's a good practice to leave underscores out. However, for the purposes of this guide, the published (easier to read) form of command names will be used.

Incidentally, a list of all the slash commands in the game can be obtained by typing "/cmdlist" into the chat box. The slash command list currently used by the game pops up in the global box, and you can copy this to the clipboard using the "/copychat global" command, and then paste it into a word processing file for your future reference. Since slash command lists are often made obsolete by subsequent game updates, this method ensures you have the most current and complete list of slash commands for the game.


USING POWEXEC_NAME

The first way to create multiple toggle binds is by using the powexec_name command. For example:
/bind Y "powexec_name super jump$$powexec_name temp invulnerability$$powexec_name unyielding$$powexec_name invincibility".

The bind above attaches 4 powers to a single key: Invincibility, Unyielding, Temp Invulnerability, and Super Jump. However, only one power will turn on whenever a key is pressed, but which one?

The power activation sequence in multiple toggle binds is fairly straight forward but it is critical to understanding binds. Toggle powers in binds execute from right to left. When binds containing a string of multiple powexec_name commands is executed, the bind shuts off ALL currently active powers in the bind string, and turns on the first non-active power starting from the right or "beginning" of the bind.

For ease of explanation, the first toggle power starting from the right will be designated A, the second power from the right as B, the third C, and so on (eg., /bind &lt;key&gt; "powexec_name D$$powexec_name C$$powexec_name B$$powexec_name A").

Which toggle power turns on greatly depends upon whether or not a power is on or off at the time the bind is executed. So assuming first that all powers in the bind are off, the power activation sequence would go something like this: First the bind will attempt to turn on power A. If A is already on, then B will turn on. If B is already on, then A will turn on. If both A and B are on, C will turn on. If A, B, and C are on, then D will turn on, and so on. The bind searches for the first non-active power to turn ON starting from the right, while turning OFF all currently active powers in the bind string. So binds will always try to activate Power A first, unless it is already ON. Needless to say, if all the powers in the bind script are currently turned on, the bind will turn them all off. This bind, for example, will toggle on and off between Fly and Sprint, while turning off Unyielding and Invincibility (if they were on, otherwise no action):

/bind Y "powexec_name Invincibility$$powexec_name Unyielding$$powexec_name Sprint$$powexec_name Fly"



POWER ACTIVATION SEQUENCE
<ul type="square">IF ON --&gt;THEN --&gt; TURNS ON[*]none --&gt;THEN --&gt; A[*]A --&gt;THEN --&gt; B[*]A+B --&gt;THEN --&gt; C[*]A+B+C --&gt;THEN --&gt; D[*]B --&gt;THEN --&gt; A[*]C --&gt;THEN --&gt; A[*]D --&gt;THEN --&gt; A[/list]
The typical multiple toggle bind will usually have only 2 toggle powers in it (toggling between A and B). However, inserting more than two toggle powers in a bind can ensure that those additional powers are turned off when the desired power is turned on (useful for conserving endurance, etc.). Powerexec_name also has fewer characters than powexec_toggleoff (discussed below), and therefore may be a more efficient choice for minimizing bind string length. Further, it is sometimes necessary to have a third or even fourth power in the bind script – especially if the bind utilizes the "toggle key" function, is part of a text/toggle bind, or toggle powers are combined with movement and other types of commands within the same bind script.


USING POWEXEC_TOGGLE

The second way to create multiple command toggle binds is to string together a series of powexec_toggleon commands in the bind script (eg., /bind &lt;key&gt; "powexec_toggleon D$$powexec_toggleon C$$powexec_toggleon B$$ powexec_toggleon A"). Powexec_toggleon commands only turn powers on and can not turn off a power. Conversely, powexec_toggleoff only turns powers off.

With the powexec_toggleon command we can successively turn on several powers using only one key, but with multiple key presses. The bind will execute each command from right to left. Upon the first key press, the bind will attempt to activate power A. Upon the second key press, power B will activate. Upon the third key press, power C, and so on. Powexec_toggleon will IGNORE powers that are already on, and will seek out the next non-active power from the beginning of the chain onward with each successive key stroke. If all of the powers in the bind string are already on, no action will be taken. In addition, it appears that powexec_toggleon follows the same power activation sequence as powexec_name, with the one exception that it will not turn powers off.

Powexec_toggleon makes turning on powers using only one key much easier. Before this command existed, the only way to have one key turn on multiple toggle powers was to create a text/toggle bind that required the creation of multiple text files to operate. With this command, one bind will do it all! In addition, in some cases we may only want the bind to turn on the power so that we may turn the power off manually. In others we may use the powexec_toggleon to ensure that a toggle power is not turned off accidentally.

The corresponding command, powexec_toggleoff, works in a slightly different way. If a string of powexec_toggleoff commands are used in a single bind, the bind will turn off ALL powers in the bind script almost simultaneously. Powexec_toggleoff will never turn on a power, but will only turn powers off. The bind will also IGNORE all powexec_toggle commands for powers that are currently off, and search for the first active power from the beginning (right) of the bind string to turn off.

This feature to ignore command entries depending upon the on/off state of a power can cause some confusion if both powexec_toggleon and powexec_toggleoff are used together in the same bind. Consider this bind, for example:

/bind &lt;key&gt; "powexec_toggleon A$$powexec_toggleoff A"

This bind behaves similarly to a typical one power powexec_name bind, yet the way the commands are arranged is not at all like we would expect a powexec_name bind to look like. We might think that toggle_ON should swap places with toggle_OFF for the bind to work properly (and indeed it will work fine this way). However, because powexec_toggleoff ignores powers that are already turned off, the first command in the bind string is skipped over (assuming the desired power is already off before the bind is executed) and the next command in the string (toggle_on) is run instead. This means that when the bind key is first pressed, it will amazingly turn the power ON.


COMBINING POWEXEC_NAME and POWEXEC_TOGGLE

Multiple powexec_name and powexec_toggleon commands may be combined in the same bind. Mixed binds will operate in the same manner as described for the powexec_name command above – from right to left, with the same base power activation sequence. The only difference, and it’s a big difference, is that powers turned on with the powexec_toggleon command will remain ON, while the powers activated with powexec_name will toggle on and off. Also powexec_toggle commands may be ignored in the bind depending upon the on/off state of the power.

This makes for some interesting possibilities. For example, with the following bind we can turn two powers on, and then toggle on and off between the last two powers (C and D) instead of the first two (A and B) as is usually the case:

/bind &lt;key&gt; "powexec_name D$$powexec_name C$$powexec_toggleon B$$powexec_toggleon A".

The reason this works is because the bind will ignore any instances of powexec_toggleon whose powers are already on. So once powers A and B are turned on, the bind treats power C as if it were the first command in the bind string. This is also true for powexec_toggleoff, except it ignores powers that are already off rather than on.


UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER

Multiple powexec_name and powexec_toggle commands for the SAME POWER can cause some baffling results, behave contrary to the normal bind rules, and "lock up" a bind so that it no longer works. Believe it or not, these quirks can actually come in handy when trying to design a bind that works the way we want it to work. More importantly, understanding how multiple powexec commands for the SAME POWER affect binds is crucial for understanding how some binds behave when executed under less than optimal conditions, such as when lag is affecting game play or when a bind key is pressed too quickly. Under these poor conditions, entire bind strings are often duplicated and treated as one bind or separate text binds merged so that we end up executing multiple commands for the same power.

In most cases when two or more powexec commands for the SAME POWER are executed in a bind, a conflict between the commands takes place. The duplicated power briefly turns on, turns off, and then defaults to an ON state. When such a conflict occurs, it prevents any other powexec commands in the bind from operating. Of course, whether or not this command conflict occurs depends upon the specific combination of powexec commands and their position or sequence in the bind string upon execution. For example, combining a powexec_NAME &lt;same power&gt; command with a powexec_TOGGLEOFF &lt;same power&gt; command will have a different result than combining two powexec_NAME &lt;same power&gt; commands.

For ease of use, "A" will represent the duplicated power. I will give an example bind showing the combination and sequence of commands, and then an explanation of the bind’s behavior:

/bind &lt;key&gt; "powexec_NAME A$$powexec_NAME A"
When two or more powexec_name commands for the SAME POWER are used in a bind (eg., /bind Y "powexec_name Super Jump$$powexec_name Super Jump"), the power will be turned on if it was not already active. However, the bind will not turn the power off if the bind key is pressed again. The usual command to turn off all the powers in the bind string executes first (and the power turns off briefly – as well as any other powers in the bind string), but then a command to turn on the power occurs second almost instantly. This happens ONLY if the command to turn on the first duplicated power is executed in the bind string, following the normal power activation sequence described previously. It also does not matter where the second instance of powexec_name &lt;SAME POWER&gt; is located in the bind string for this phenomenon to occur. Further, once powexec_name &lt;SAME POWER&gt; is executed, the bind will prevent all other powers in the bind from executing – and the bind will essentially "lock up." For example, the following bind will ONLY execute Fly, will never turn it off, and will never toggle on Stealth (contrary to the normal bind rules): /bind Y "powexec_name Fly$$powexec_name Stealth$$powexec_name Fly".

/bind &lt;key&gt; "powexec_TOGGLEON A$$powexec_TOGGLEON A"
This bind above seems to behave normally, as if there was only one powexec_toggleon command. Multiple instances of powexec_toggleon &lt;same power&gt; do not seem to interfere with the bind’s operation, and the additional commands appear to be ignored.

/bind &lt;key&gt; "powexec_TOGGLEOFF A$$powexec_TOGGLEOFF A"
This bind above behaves differently depending upon the on/off state of the power. If the power is already OFF, the bind will do nothing and the commands appear to be ignored. However, if the power is already ON, then the bind will behave as two powexec_NAME &lt;same power&gt; commands – it will NOT turn the power off, and will prevent any other powexec commands in the bind string from executing. The powexec_toggleoff &lt;same power&gt; commands can be placed ANYWHERE in the bind string, but one of the commands must be executed for this behavior to occur (following the power activation sequence for multiple command binds previously described above).

/bind &lt;key&gt; "powexec_TOGGLEOFF A$$powexec_TOGGLEON A"
This bind will toggle the power on and off, and seems to behave normally according to the power activation rules for powexec_toggleon/off commands

/bind &lt;key&gt; "powexec_TOGGLEON A$$powexec_TOGGLEOFF A"
This bind will toggle the power on and off, and seems to behave normally according to the power activation rules for powexec_toggleon/off commands.

/bind &lt;key&gt; "powexec_NAME A$$powexec_TOGGLEON A"
This bind above will turn power A on, and then toggle it off upon the next key press – in short, the one instance of powexec_name &lt;same power&gt; within the bind negates the ability for powexec_toggleon to keep a power on. The powexec_name command does not need to be right next to the powexec_toggleon command for this to happen. It can be placed ANYWHERE in the bind string and this toggling on/off behavior will still occur. For example, /bind &lt;key&gt; "powexec_name Fly$$powexec_name Unyielding$$powexec_name Invincibility$$powexec_toggleon Fly". This bind will turn Fly on and off, while toggling between Fly and Invincibility. However, if two instances of powexec_name &lt;same power&gt; are placed in the bind, and one of the commands executed, the bind will turn on the power and keep it on, ignoring all other powers in the bind string.

/bind &lt;key&gt; "powexec_TOGGLEON A$$powexec_NAME A"
This bind will toggle power A on and off. In short, the powexec_toggleon command is ignored. If a powexec_toggleon &lt;same power&gt; command appears elsewhere in the bind, it will not affect it’s operation.

/bind &lt;key&gt; "powexec_TOGGLEOFF A$$powexec_NAME A"
This bind above will turn power A on, keep it on, and will never turn it off. It behaves exactly as if two powexec_name commands for the same power were placed in the same bind. The powexec_toggleoff &lt;same power&gt; command can occur ANYWHERE in the bind string and this behavior will still take place, but only if powexec_name &lt;same power&gt; is the first command in the string. Further, this combination prevents all other powers in the bind string from executing. For example, this bind will only turn Super Jump on: /bind Y " powexec_name unyielding$$powexec_toggleoff super jump$$powexec_toggleon temp invulnerability$$powexec_name super jump".

/bind &lt;key&gt; "powexec_NAME A$$powexec_TOGGLEOFF A"
This bind will turn power A on and keep it on. It behaves very similarly to when two powexec_name commands for the same power are placed in a bind. However, this only occurs if the powexec_name &lt;same power&gt; command is executed in the bind string, following the normal power activation sequence for powexec commands. Otherwise, the bind will behave normally.


In any bind string that has two commands that would create a conflict when executed, a conflict will occur regardless of what other powexec &lt;same power&gt; commands reside in the bind string. For example, when powexec_NAME &lt;same power&gt; and powexec_TOGGLEON &lt;same power&gt; are combined, the bind will function normally. But if you add another instance of powexec_NAME &lt;same power&gt;, a conflict will result when the command is executed, turning the power on and locking up the bind:

This bind will operate normally:
/bind Y "powexec_TOGGLEON fly$$powexec_NAME fly"

But this bind will create a conflict:
/bind Y "powexec_NAME fly$$powexec_TOGGLEON fly$$powexec_NAME fly"


When a conflict between two powexec commands for the same power occurs, it can often have a side effect of slowing down the execution of a power, sometimes enough to allow a different type of command (such a movement command) to execute before the power does. This might be useful in some bind applications.


TEXT BINDS

Text binds were explained fairly well in Curveball’s Guide to Binds in his "Using ‘Toggle Binds’" section. Some have used his nomenclature of "toggle binds" to describe this method of bind making, while others have used "text binds" to describe the same thing. I have chosen to refer to these types of binds as "text binds" in order to avoid confusion with both "toggle powers" and "toggle keys."

Text binds are binds imported into the game from one or more text files that replace the current key bindings. This ability to replace binds on keys with the press of a button gives us the ability to assign more than one bind to a single key. By "bind" I mean a full bind string consisting of one or more commands. We achieve this by using the BIND_LOAD_FILE command to import binds that we have placed in separate text files that reside somewhere on our computer. When a bind is imported from a text file, it overwrites (erases and then replaces) the current bind on the key with the bind that is in the text file. This allows us to execute one bind string residing in a specific text file when the key is pressed, and then another bind string from a different text file when the key is pressed again, and so on.

The easiest way to create a text file for a text bind is to use Notepad in Windows, but any text editor will do as long as the file is saved as a plain text file (.txt). Text binds must also be written in a certain format for the game to recognize them. It is essentially the same format as a normal bind, except the /BIND command is omitted. The entry starts with the name of the key you are binding, and then the bind string. So a bind in a text file would look like this:

Y "local Up, Up, and AWAY!!$$powexec_name Fly"

You can actually assign binds to several keys at once by simply adding them to the text file, like so:

Y "local Up, Up, and AWAY!!$$powexec_name Fly"
G "local Go away servant!$$release_pets"
F "emote dance$$team Let’s shake it out!$$powexec_name build up"

This would replace any binds on the Y, G, and F keys with the above binds all at the same time. Importing a text bind only affects those keys listed in the text file, and does NOT erase or impact any other binds already assigned to any other keys.

To load a text bind, type in /BIND_LOAD_FILE [drive]\[file location]\[file name]. For example, /bind_load_file C:\coh\binds\textbind1.txt. This would import the textbind1.txt file and any binds that resided in the file into the game.

A word should be said about minimizing path and filename length here. It would be best to choose a path and file name that was short, with as few characters as possible, in case the space is needed for other commands in the bind string. To minimize path length, you could create a very short directory name on the root drive, such as C:\1\bindfile.txt. Perhaps a better alternative would be to create a new sub-directory named "binds" (or anything you like) in the City of Heroes game directory for your text binds, like so: C:\program files\city of heroes\binds\. The game will automatically start in the game’s directory, so typing the drive and game directory is unnecessary. The path to a game sub-directory named "binds" can be shortened to ".\binds\" when using BIND_LOAD_FILE (note the period before the first backslash). So the full command and path would look like this: /bindloadfile .\binds\bindfile.txt .

The real value of text binds is not merely the ability to replace current key binds with binds stored in text files, but rather the ability of a text bind to replace ITSELF with a different bind when it is executed, such as the sample text bind below.

The steps to create a text bind are fairly straight forward. First, you would create the text files and write the binds you want in them. In the example below I created 3 text files: "textbind1.txt," "textbind2.txt," and "textbind3.txt."

Then you would use the /BIND command to create a new bind on a key that would load the text bind. For example, in the chat box you would type: /bind Y "bind_load_file C:\[file location]\textbind1.txt". Consider these sample text bind files:

TEXTBIND1.TXT:
Y "powexec_name sprint$$powexec_name Fly$$bind_load_file c:\[file location]\textbind2.txt"

TEXTBIND2.TXT:
Y "powexec_name Hover$$bind_load_file c:\ [file location]\textbind3.txt"

TEXTBIND3.TXT:
Y "powexec_name hover$$powexec_name Sprint$$bind_load_file c:\[file location]\textbind1.txt"

Essentially what happens is that when the "Y" key is pressed, the bind in textbind1.txt is executed, turning on Fly, but it also loads a new key binding for the "Y" key residing in textbind2.txt. It is the BIND_LOAD_FILE command at the far right of the bind string that loads the second text file. When the "Y" key is pressed again, the bind from textbind2.txt is executed, Hover turns on, and the bind replaces itself with the bind in textbind3.txt. When the key is pressed the third time, the bind in textbind3.txt is executed, Sprint turns on, and the bind from the first text file is loaded again – to loop around and start over again.

Text binds allow us to use one key to load different binds or even different sets of binds (for one or multiple keys). This can be very useful for binds where we want a different set of bind commands to execute when one key is pressed; or for a certain command to activate on the first key press, but not on the second key press; or a myriad of other invaluable uses.


USING "TOGGLE KEYS"

"Toggle Keys," for lack of a better name, are already part of City of Heroes. We use them whenever we press the movement direction keys W, A, S, D, X; the space bar, the LAlt and LControl keys, and many others. A toggle key executes every command in a bind upon key PRESS, and then executes every command in the bind again upon key RELEASE. A toggle key is created by adding the "+ " prefix command at the beginning of a bind string (eg., /bind &lt;key&gt; "+ $$powexec_name B$$powexec_name A"). Notice there is a space between the "+" and "$$". Without the space, the toggle key function will not work. In addition, any movement or similar command that includes a "+" at the beginning will also cause the key to behave as a toggle key if it is placed as the first command in the bind string (eg., /bind &lt;key&gt; "+up$$powexec_name B$$powexec_name A").

In the bind above, Jump (the "+up" command) and power A will be activated when the key is PRESSED (and will continue to activate until the key is released). When the key is RELEASED Jump and power A will be turned off, and power B will turn on. Powers A and B toggle on and off between each other because of the toggling rule and power activation sequence of the powexec_name command (see above).

Instead of a "+ " tag, a toggle key can also be made with a positive and negative movement command placed at the beginning of the bind string (eg., /bind &lt;key&gt; "+down$$-down$$powexec_name A"). The "+down" adds the functionality that causes the key pressed to be executed on both press and release, the "-down" ensures that it does not actually cause movement.

When the prefix "++" is used with a command at the beginning of a bind string (eg., /bind &lt;key&gt; "++forward$$powexec_name B$$powexec_name A"), it serves to turn the toggle key function OFF. This means that the bind string will only be executed once per keystroke, and will not be executed upon key press and again upon key release.

Toggle keys help by allowing us to activate powers quicker, using less keystrokes. For example, a bind using 6 powexec_toggleon commands would take 6 keystrokes to turn all the powers on. However, adding "+ " at the beginning of the bind would allow us to turn on all 6 powers in only 3 keystrokes – because the bind is executing twice per keystroke (once when the key is pressed, and again when the key is released).

There is one caveat, however. When using toggle keys, it is important to make sure that you don’t press and release the key too quickly. A very fast keystroke will sometimes cause the game to run the commands at key press and key release at the same time, essentially tacking on the same set of binds at the end of the original and treating the whole thing as one bind. Also, client-server-client lag (delays when your computer attempts to communicate with the game’s server, and visa versa) can cause the same error.


TOGGLE KEY TEXT BINDS

Perhaps the most confusing, but also the most valuable, function for toggle keys is when they are used in combination with the "bind_load_file" command to create "toggle key text binds." Text binds are binds that reside in separate text files and that utilize the BIND_LOAD_FILE command to replace the current key bind with another from the text file (see TEXT BINDS above). What adding the "+ " tag to the beginning of text binds does is to allow us to execute one bind string residing in a specific text file on key press, and then another bind string from a different text file on key release. With this, we can often circumnavigate around limitations placed on us by the game, and execute commands in combination that otherwise would be impossible.

For example, say you wanted your super hero to simultaneously leap into the air with a jump, turn on Fly with the "F" key, and make sure Sprint is turned off; but you ALSO wanted to be able to turn Fly off and Sprint on with a second stroke of the SAME key. Using a toggle key text bind we can create a bind that works in the desired manner, such as this bind below:

FLY1.TXT:
f "+up$$powexec_toggleon fly$$bind_load_file c:\[file location]\fly2.txt"

FLY2.TXT:
f "+up$$powexec_toggleoff sprint$$bind_load_file c:\ [file location]\fly3.txt"

FLY3.TXT:
f "+down$$powexec_toggleon sprint$$bind_load_file c:\ [file location]\fly4.txt"

FLY4.TXT:
f "+down$$powexec_toggleoff fly$$bind_load_file c:\ [file location]\fly1.txt"

The above toggle key text bind will execute the first bind (fly1.txt) and load the second on the key press, and execute the second bind (fly2.txt) and load the third on the key release. Then it will execute the third bind (fly3.txt) and load the fourth on the second key press, and execute the fourth bind (fly4.txt) and load the first bind again on key release – looping back to start over again. This simulates an on/off toggle key for two powers (Fly and Sprint), something impossible to do without toggle key text binds.

Notice that in each bind above there is a "+ " tag. Without a "+ " tag or a place holder at the beginning of every other bind (the bind executed on key release), the toggle key function will not work. Instead of a "+ " tag at the beginning of the second bind, a place holder consisting of a blank space after the first quotation mark and before the first command separator ($$) can often suffice IF only "+ " is used alone in the previous bind string and not attached to a movement command. For example:

TEXTBIND1.TXT:
Y "+ $$powexec_name A$$bind_load_file c:\[file location]\textbind2.txt"

TEXTBIND2.TXT:
Y " $$powexec_name B$$bind_load_file c:\ [file location]\textbind1.txt"

This method of creating a toggle key can cut down or reduce the number of characters used in a bind, and also allows us to create a toggle key without movement commands mucking up the works – but don’t forget the blank space before the first "$$" command separators for each text bind or this toggle key arrangement will not function properly.


MOVEMENT DIRECTION COMMANDS

The movement direction commands are actually toggles (eg., +forward, +backward, +left, +right, +up, etc.). This means that when a direction command is issued, it will stay on until the command is issued again to turn it off. In game, these commands appear to be special commands – turning on during key press, and off upon key release – but what is really happening is that the movement command executes upon key press (turning on the power), and then executes the same command again upon key release (turning off the power) – in short, utilizing the "+" prefix or "toggle key" function.

The "++" prefix, on the other hand, serves to turn the toggle key function OFF. When used with a movement command (eg., ++forward, ++backward, ++left, etc.), the prefix will cause the command to be toggled ON, and will continue to activate, until the button is pressed again, toggling it off.

Anything you can toggle (using ++ or +/-) you can explicitly turn on or off by adding the argument 1 (on) or 0 (off) after them (eg., /bind Y "up 1$$powexec_name"). For most commands that take a numeric argument (including the toggles), you can check the current value by issuing the command without any arguments.


CLICK POWER BINDS

Click powers can be executed using any of the powexec commands. As indicated by Curveball’s Bind Guide, only one click power can be activated at a time (unless powexec_auto is also used to activate a second click power). A mixed click and toggle bind will pretty much behave as a normal toggle bind as described above with one big exception… when a click power is executed a second time, the click power will either be activated or queued up to be activated once it has recharged – and NOT toggled on and off. This means that if a click power is placed as the first power to activate in a bind string, no other powers will be executed (excepting powexec_auto), no matter how many times the bind key is pressed. For example:

/bind &lt;key&gt; "powexec_name TOGGLE$$powexec_name TOGGLE$$powexec_name CLICK"

This bind above will only execute the click power. Therefore, it’s usually best to place a click power command after all of the toggle power commands in the bind string – or at least somewhere other than at the beginning of the string – so that toggle powers have a chance to execute before the click power.


USING POWEXEC_AUTO

This command only works for click powers, and will not work for toggle powers. Essentially, powexec_auto sets a click power on auto-fire – allowing the click power to activate automatically upon recharge until auto-fire is deselected. This command toggles auto-fire on and off, and can be placed ANYWHERE in the bind for it to work. However, if more than one powexec_auto command is included in a bind string, the command will only turn auto-fire on, and will NOT turn auto-fire off. As with other powexec commands, powexec_auto command is executed from right to left in the bind string (eg., /bind Y "powexec_auto D$$powexec_auto C$$powexec_auto B$$powexec_auto A"). So in unlikely cases where multiple powexec_auto commands are used together, only the first power (A) will be set on auto-fire. This may be useful to avoid turning auto-fire off if the same bind key is pressed again. In addition, if two powexec_auto commands are used for the SAME POWER in a bind (eg., "powexec_auto Gash$$powexec_auto Gash"), they will cancel each other out and prevent the command from executing (neither turning auto-fire on nor off).

When powexec_auto is used in the same bind with either powexec_name or powexec_toggleon/off, it will execute on every keypress regardless of it’s location in the bind string. However, it is a best practice to place powexec_auto commands at the end of the bind string, after all other powexec commands have had a chance to execute in order to avoid any potential power activation problems. (eg., /bind &lt;key&gt; "powexec_auto D$$powexec_name C$$powexec_name B$$powexec_toggleon A")



TURNING POWERS OFF

Besides the normal ways to toggle powers off using powexec_NAME and powexec_TOGGLEOFF commands, powers can also be turned off by adding the following commands to the beginning (right) of a bind string:

Powexec_unqueue -- cancels a queued power. It will also turn off any powers that are included in the same bind string, as long as the powexec_unqueue command is executed in the bind following the normal power activation sequence. So the best place to put the command, if you want to turn powers off, is at the beginning of the bind string (from right to left) to make sure it’s activated, like so: /bind Y "powexec_name invincibility$$powexec_name unyielding$$powexec_name fly$$powexec_unqueue" This bind will only turn the powers off, and will not turn them on. When used with powexec_toggleon, the unqueue command will cause the bind not to function. When used with the powexec_toggleoff command, the unqueue command will turn off all powers and cancel queues.

Powexec_abort -- cancels the auto-attack power and the queued power. It behaves exactly like powexec_unqueue above, including turning powers in the bind string off, as well as canceling queues and auto-fire.


CLEARING BINDS FROM KEYS

To clear a bind from a key use either of the following commands:
/bind &lt;key&gt; "nop"
/bind &lt;key&gt; " "

"/BIND &lt;key&gt; NOP" is the official method of getting rid of a bind on a key. "NOP" stands for "non-operation" and you can use it with or without quotes in the bind command. However, I have found this command to be inconsistent. If NOP doesn’t work, binding a blank space to the key will also erase the bind currently assigned to the key (note the space between the quotes " "). Clearing a bind from a key is not merely a tool to erase a mistake, but can come in very handy for designing text binds that assign a bind to the left mouse button and then need to remove it. The left mouse button is the only button in the game whose action can not be remapped.

You may wish to return ALL of your keys to the default key bindings that existed when you first bought the game or created the character. In this case, click on Menu in the game, then Options, then click on the Keymapping tab, and click on the "Reset Keybindings" button. In fact, I recommend you get familiar with the Keymapping tab. It can be easier to assign certain actions to keys using the Keymapping options than creating binds manually.


ARRANGING YOUR BIND COMMANDS

Types of powers/commands:

<ul type="square">[*]Click Power Command attacks, inspirations, various powers such as Build Up, Hasten, etc.[*]Toggle Power Command powers that toggle on and off, such as Fly, Super Jump, Temporary Invulnerability, etc.[*]Movement Command +up, +down, +forward, +backward, +left, +right. +turnright, +turnleft, +autorun[*]Emotes animated movements such as wave, bow, grief, etc.[*]Text Message Commands tell, team, local, broadcast, etc.[*]Variables $target, $name, $origin, $archetype, $level, $battlecry [*]File Loading Commands bind_load_file[*]Miscellaneous costume (cc 0, cc 1, etc.), map, beginchat, sgmode, follow, target_enemy_near, etc.[/list]
The order or sequence in which you arrange command types in your bind strings is crucial for the proper operation of your bind. If you were paying attention while you were reading this guide, you’d already know most of what I’m about to explain. Of course, arranging your bind commands in the order I am about to suggest is not, usually, a rule set in stone. You are free to experiment with different arrangements, many of which I suspect would work fine. Keep in mind that bind strings are executed from right to left. The following is an example bind with the preferred parsing:

/bind Y "+forward$$CC 0$$team I am ready now, $target.$$emote thumbsup$$powexec_auto Gash$$powexec_name Dark Blast$$powexec_name Fly$$bind_load_file C:\[file location]\ready.txt"

Rewriting the bind above using the command types would look like this:

/bind Y "MOVEMENT commands$$MISCELANEOUS commands$$TEXT commands$$EMOTE commands$$AUTO-FIRE commands$$CLICK POWER commands$$TOGGLE POWER commands$$FILE LOADING commands"

Having File Loading commands execute first, before any of the other commands, helps ensure that the new text bind is loaded. Remember, the very first command from the right is the command that will be executed first.

Next come toggle power commands. These come before click power commands so they will activate.

Then come click power commands because no toggle power command will active after a click power has activated.

After this come auto-fire commands so they do not interfere with click or toggle power execution.

Emotes are then executed because their animations take time to process.

Text and Miscellaneous commands take no time to execute, so these are placed last to minimize their interference with other commands, but really can be placed anywhere in the bind string.

Movement commands can be placed elsewhere in the bind string, but if you want the toggle key function to be activated with the command, the movement power must be placed at the end (far left) of the bind string so that the "+" prefix activates the toggle key function.


DEALING WITH LAG

Unfortunately, we all will encounter LAG at one time or other while playing COH, so saying a few words about how LAG adversely affects binds and what we can do to adjust our binds to ensure they operate correctly is probably worthwhile. This is especially true for me, since I’ve been playing with a low speed 56k dial-up connection. Lag seems to affect the operation of my binds far more than others who are on a broadband connection.

Lag occurs when the game’s computer (server) is having trouble communicating with your computer (client), and visa versa. There can be pauses, hiccups, and slowdowns in bind execution; and sometimes a bind might not execute at all. I am certainly no expert on this subject, but three things appear to happen to binds during lag:

1. two binds are executed as one bind string,
2. the bind is truncated and/or only partial commands are communicated to the server, or
3. the bind or part of the bind is delayed in executing.

In my experience, the most common bind error when executed under lag conditions is that the bind string is duplicated, tacked onto the end of the first bind, and then both are executed as one bind string. This happens almost exclusively with toggle key binds because the bind is executed twice very quickly – once upon key press and again upon key release – which essentially duplicates the bind. So a bind such as this one:

/bind Y "+up$$powexec_name Sprint$$powexec_name Fly"

might be turned into a bind string that looks something like this one during lag conditions:

/bind Y "+up$$powexec_name Sprint$$powexec_name Fly$$+up$$powexec_name Sprint$$powexec_name Fly"

The twin instances of "powexec_NAME Fly" would cause a command conflict and the bind would malfunction (see the section UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER above).

Toggle key text binds that load multiple binds from text files add a layer of complexity to this problem that can be very confusing. Instead of loading the same bind twice (once on key press and again on key release), a toggle key text bind would load the bind string in the first text file (on key press) and in the second text file (on key release) at the same time, and then execute both as if they were one long bind string. Consider this toggle key text bind, for example:

TEXTBIND1.TXT:
Y "+up$$powexec_name Sprint$$powexec_name Fly$$bind_load_file c:\[file location]\textbind2.txt"

TEXTBIND2.TXT:
Y "+up$$powexec_toggleoff Fly$$bind_load_file c:\ [file location]\textbind1.txt"

Under LAG conditions or if the key is pressed too quickly, the commands at key press and key release from the toggle key text bind above would often be combined into one long bind string that might look something like so:

Y "+up$$powexec_toggleoff Fly$$bind_load_file c:\ [file location]\textbind1.txt$$+up$$powexec_name Sprint$$powexec_name Fly$$bind_load_file c:\[file location]\textbind2.txt"

My guess (and it is only a guess) about what is really happening behind the scenes with toggle keys and lag is that when the bind key is pressed and released, the game attempts to execute the bind but communication fails between the client/server, and the command is not processed. Instead, the first set of commands issued on key press and the second set of commands issued on key release are stored in a "queue," waiting to be executed when communication is re-established. Once communication is resumed, the game runs both bind strings at the same time as one bind.

When designing or troubleshooting a bind using the toggle key function, it’s important to take into consideration the possibility that bind commands may be duplicated sometime during game play. Creating binds that, if duplicated or combined, will not cause same-power command conflicts is easier said than done, however. Whether or not a command conflict occurs depends on the specific commands used in the bind as well as their sequence in the bind. Your best bet would be to look at the UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER section above, and see what would happen if any of your toggle key binds were duplicated or combined, and then experiment with different command arrangements that might not cause conflicts if repeated. There is, however, one saving grace here. Duplicate instances of the powexec_TOGGLEON &lt;same power&gt; command will not cause conflicts, so it may be safer to use powexec_toggleon to turn on powers instead of powexec_name.

The second thing that might happen during lag is that a bind command (or the bind string) may be truncated because of loss of communication and data. For example, "powexec_name Unyielding" might be truncated to "powexec_name Unyieldi" or "powexec_na" or "pow". Truncated or partial commands will be ignored by the game. It might mess up your power activation sequence (which power activates when), but other than this, partial commands really don’t cause any trouble, they simply will not function is all. Needless to say, a truncated command won’t turn on/off a power. The best bet to try to avoid this is simply to use multiple powexec_toggleon &lt;same power&gt; commands to make sure that at least one of the complete commands is executed. Unfortunately, duplicating other powexec commands in a bind might cause problems, depending upon the specific commands used in the bind and their location in the bind string.

The third thing that happens to binds during lag is that delays in power activation occur. You might press a key, and some commands may be executed, but a power may not turn on except after a lengthy pause. I don’t know why it works, but I’ve found that adding at least two powexec_toggleon &lt;same power&gt; commands to a bind string sometimes eliminates power activation delays in binds. For example, /bind Y "+up$$powexec_name Sprint$$powexec_toggleon Fly$$powexec_toggleon Fly". It’s odd I know. It shouldn’t work, and often it doesn’t, but what can I say? Try it and see.


Although I hope this Advanced Bind Guide goes a long way in demystifying how binds work and how to design useful binds, the act of bind creation is still somewhat of an art… or a science experiment, however you like to look at it. So much about figuring out why a bind is not working the way we would like, or trying to figure out how to get a bind to do what we want it to do is simple trial and error. Try it, see if it works, and if it doesn’t then try something else. If one powexec_toggleon doesn’t work, then add two to the bind string. IF that doesn’t work then add three into it, or take away one, or add one to a different text file, or remove them and try powexec_name, etc. I do hope this guide helps would-be bind creators to understand binds, and thereby reduce the frequency and necessity to spend hours upon hours testing binds using the "throw a dart in the dark" method. Binds do follow a logical design, for the most part… even if LAG does sometimes throw a wrench into the works.

Curveball,

Some other good things to put in a bind guide would be the perameters not only for color (color, bgcolor, border), but also for scale, duration, etc.

There's a command "speedturn 70" that I ran across, but haven't had time to test.

A bit about adding in non-standard characters or symbols into chat binds.

Maybe something on the AFK message, how we can change it, and how we can get it to stay on most of the time underneath our names.

Maybe something about using a bind to switch power trays.

How to send a chat message to yourself using $name, or any other way

Maybe something about mouseview, and changing the screen of the game with a bind (I understand a lot of people do this for teleporting)


That's about all the tricks I know of, and is all that's coming to mind at the moment. Sorry it took so long to get even these suggestions, but nothing came to mind until just now.

[ QUOTE ]
If you do repost, I just noticed one fix that's needed. Change all open and close quotes (ie “ and ”) to just a standard quote ("). Binds using the former will not work. To fix, after typing in Word, cut and paste to notepad and do a search and replace for those quotes that Word places.

[/ QUOTE ]

Oh, wow! Look at that. In the past, HTML and forums wouldn't take those open and closed quotes, and changed them to standard ones... guess times are a'changing.

Thank you again, Innovator!

Oop! Just noticed I made a mistake on the previous page of posts... the command to copy the global chat is not "/copychat_global" but rather "/copychat global". Sorry, about the silly underscore typo.

I HAVE revised this Advanced Bind Guide a bit already. I've added a bit about text binds, and another bit about clearing binds from keys, as well as clarified some language in the LAG section to make it less confusing and more accurate.

Should I just post the additions here, or create a new thread when I'm finished with the whole revision?

[ QUOTE ]
There hasn't been an update for so long because, honestly, the original was, and still is, very current. For the basics, I'd just use what's in the original version.

[/ QUOTE ]

I absolutely agree. Your guide ROCKS, Curveball!

[ QUOTE ]
The following stuff might be good to add in, however:

A complete run down on how to use the targetcustom* commands.
Teamselect and petselect commands, and other methods to select team members and pets.
How to use petsay and petcom commands.
How to use the new chat channels, and how to create binds that work with the global channels.

[/ QUOTE ]

All these would be good additions to your guide.

[ QUOTE ]
A consolidated list of all the /bind tricks discovered to date

[/ QUOTE ]

A tall order. I thought of doing something like this, but cringed at the magnitude of the task. Heck! Even a consolidted list of the best bind examples illustrating various tricks would be a herculean job! That said, wish there was such a guide!

Frankly, if Curveball really does want to revise his bind guide a bit, I'd recommend keeping it simple and for the beginner. An overview of the target_custom commands would be good, as would the new Mastermind pet commands, etc.

[ QUOTE ]
A fully updated list of keys available (one that's missing from all lists I've seen is the mousechord key, which is essentially lbutton+rbutton)

[/ QUOTE ]

Now THIS would be a good reference! Although, honestly, the list that Curveball included with his Guide is mostly complete. There are only a couple pretty important omissions such as the number pad keys, Decimal and Numpadenter... and of course the mouse chord key above (that I hadn't thought about before). If there are any other key names that were missing, it would be nice to know about them...

[ QUOTE ]
I'm sure there's more stuff I'm not considering.

[/ QUOTE ]

GREAT suggestions! Love it when people help out like this!

Right now, I'm more interested in WHY certain binds work when they shouldn't, or why they don't work when they should (and how to fix them so they do work). I've dealt with this in my own Bind Guide , but I've only scratched the surface. There's a lot going on behind the scenes with binds, and perhaps LAG, that I still don't yet understand. I don't know if I ever will understand really, as I suspect that I would need the input from a game programmer to weed out all the details. Oh well.

If anyone knows any important bind tricks that I didn't put in my guide above, please let me know...

[ QUOTE ]
I tried replacing all of the powexec_name SPRINT commands with powexectoggle_off/_on SPRINT and the results were terrible. What seems to work pretty well is using powexectoggle_on to turn sprint on and just powexecname to turn them off. I suspect that putting a unqueue after powexec_name SPRINT would be even more effective, but that would cause weapon redraws.

[/ QUOTE ]

Well, I'm glad you found an arrangement that works. Binds are quirky, especially when executed under poor conditions.

[ QUOTE ]
Great, now i've got to put another file on my favorit's list.



[/ QUOTE ]
Thanks, man! That's a REAL compliment!

[ QUOTE ]

One thing. You might want to post a link to all known slash commands.

I use this link but it's old and out of date. I have not found a new one yet.


[/ QUOTE ]

Well, I thought of that. On the second page of Curveball's Bind Guide (there's a link at the beginning of my guide) he lists not only a list of all slash commands (slightly out of date), but also the DEFAULT key binds of all keys used by the game! An invaluable resource!

That said, I was thinking about including a complete list, but I knew that any list would become obsolete fairly quickly with susequent updates, so instead I gave everyone a way to get their own, CURRENT, COMPLETE, and UP TO DATE list of slash commands by typing in /cmdlist into their text box.

The slash command list currently used by the game pops up in the global box, and you can copy this to the clipboard using the /copychat_global command, and then paste it into a word processing file for your future reference.

This way everyone can stay up to date on their own without relying the the kindness of strangers in the Forum.

Gaean_Conspiracy,

[ QUOTE ]
I don't quite see how lag induced truncation or duplication could explain this, except perhaps if the 2 binds were combined; thereby, making the duplicate powexec_name SPRINT invocations fail the powexec_toggleoff SPRINT.


[/ QUOTE ]

Right. This is EXACTLY what is happening.

The problem is the command conflict that is caused by the twin instances of powexec_name Sprint in your first text file. They will force the power to turn on and not turn off... and if the two text file binds are executed as one bind string, then the conflict will take precidence over the powexec_toggleoff... and keep the power on. So the inconsistancy is pretty much explained right there.

When the key is pressed too quickly or there is lag, the two bind files will be merged and will not behave correctly. When the key is not pressed too quickly, or there is not lag, then the bind should behave appropriately for the most part... I say for the most part becaues the two instances of powexec_name &lt;same power&gt; are still creating a command conflict that may not be able to be resolved by the time the second text file bind is executed upon key release.

When dealing with toggle key text binds, the bind string in each text file is not duplicated, instead the bind string in the first text file is merged with the bind string in the second text file, and they are executed as if they were one long bind string.

My recommendation... replace the powexec_name commands with powexec_toggleon commands.

Let me know if this works.

Got to thank Dant3 for posting his question. I didn't think it was necessary to repeat what Curveball said about text/toggle binds in his guide. But if people have difficulty understanding something about binds even after reading both Curveball's and my guide... perhaps I should put some additional things in the guide?

Please let me know if everything makes sense, or if there is something you don't understand that I didn't address. I'll do my best to help out. Also I'll write up a revision of my guide and re-post it with credit and gratitude to you.

Also, although I really hope this guide is useful, feel free to let me know if you feel it's not very helpful. Please let me know what I can do to improve it, if anything, or if you think it's great as is?

All the best,

BlackSpectre

Dant3,

I'm not on the Forums much, so this was not intended to be an "Ask the Expert" thread. In fact, I'm hoping my guide will let everyone troubleshoot their own binds.

Try getting rid of the "+ " prefix in both text files so the bind will only execute once upon each keystroke, rather than twice -- once on key press and once again on key release. You don't need the toggle key function to use text/toggle binds.

ADVANCED BIND GUIDE
By BlackSpectre

The purpose for this guide is to provide more detailed information on HOW binds work so that the would-be bind designer can intelligently craft their own binds or troubleshoot them. This guide grew out of my desire to understand why a bind I created worked, and I figured I might as well write down what I’ve learned in the hope that someone else might find the information useful. I have gathered the information in this guide from many different sources: the City of Heroes Forum, my own testing and experience, and from fellow gamers such as Innovator, Blueray, Cockaroach, and Zerotemp. It is my hope that presenting this information in one concise document will help others to create superb binds much easier than if they had to track down all this information on their own.

This guide assumes the reader is familiar with the /bind command in City of Heroes/Villains and has mastered its more common functions as detailed in other venues such as Curveball’s excellent WHOLLY UNOFFICIAL AND FAIRLY INCOMPLETE GUIDE TO /BIND . As such, many details on how to create and use binds are omitted from this document. If you are new to binds, please read Curveball’s guide above, read the binds section in the COH manual, and familiarize yourself with making binds before you read this guide.

TABLE OF CONTENTS:
1. Multiple Toggle Binds
2. Using Powexec_NAME
3. Using Powexec_TOGGLE
4. Combining Powexec_NAME and Powexec_TOGGLE
5. Using “Toggle Keys”
6. Toggle Key Text Binds
7. Understanding Multiple Powexec Commands For The SAME POWER
8. Movement Direction Commands
9. Click Power Binds
10. Using Powexec_AUTO
11. Turning Powers Off
12. Arranging Your Bind Commands
13. Dealing With LAG


MULTIPLE TOGGLE BINDS

Multiple toggle binds are binds that contain more than one toggle power. There are 6 commands used to activate a toggle power in a bind:
1) powexec_name [power name]
2) powexec_slot [slot#]
3) powexec_altslot [slot#]
4) powexec_alt2slot [slot#]
5) powexec_tray [slot#] [tray#]
6) powexec_toggleon [power name] (and it’s opposite, powexec_toggleoff [power name]).

The first five commands operate in the same way as powexec_name (1-5), while the powexec_toggleon command operates in a distinctly different manner.

The length of a bind can not exceed 255 characters. Omitting underscores “_” in commands such as powexec_name, powexec_toggle_on and bind_load_file, and leaving out unneeded spaces is one way to cut and decrease the character count, in order to enable longer binds. For example, “powexec_name” becomes “powexecname,” “bind_load_file” becomes “bindloadfile,” etc. Underscores aren't even read by the command parser, and only serve to make commands easier to read. In fact, bind_load_file is the same as bindloadfile, or bindload_file, or b_i_n_d_l_o_a_d_f_i_l_e. When your binds get lengthy, space becomes precious because of the limit to the text size of a bind, so it's a good practice to leave underscores out. However, for the purposes of this guide, the published (easier to read) form of command names will be used.

Incidentally, a list of all the commands in the game can be seen by typing /cmdlist into the chat box.


USING POWEXEC_NAME

The first way to create multiple toggle binds is by using the powexec_name command. For example:
/bind Y "powexec_name super jump$$powexec_name temp invulnerability$$powexec_name unyielding$$powexec_name invincibility”.

The bind above attaches 4 powers to a single key: Invincibility, Unyielding, Temp Invulnerability, and Super Jump. However, only one power will turn on whenever a key is pressed, but which one?

The power activation sequence in multiple toggle binds is fairly straight forward but it is critical to understanding binds. Toggle powers in binds execute from right to left. When binds containing a string of multiple powexec_name commands is executed, the bind shuts off ALL currently active powers in the bind string, and turns on the first non-active power starting from the right or “beginning” of the bind.

For ease of explanation, the first toggle power starting from the right will be designated A, the second power from the right as B, the third C, and so on (eg., /bind &lt;key&gt; “powexec_name D$$powexec_name C$$ powexec_name B$$ powexec_name A”).

Which toggle power turns on greatly depends upon whether or not a power is on or off at the time the bind is executed. So assuming first that all powers in the bind are off, the power activation sequence would go something like this: First the bind will attempt to turn on power A. If A is already on, then B will turn on. If B is already on, then A will turn on. If both A and B are on, C will turn on. If A, B, and C are on, then D will turn on, and so on. The bind searches for the first non-active power to turn ON starting from the right, while turning OFF all currently active powers in the bind string. Needless to say, if all the powers in the bind script are currently turned on, the bind will turn them all off. This bind, for example, will toggle on and off between Fly and Sprint, while turning off Unyielding and Invincibility (if they were on, otherwise no action):

/bind Y “powexec_name Invincibility$$powexec_name Unyielding$$powexec_name Sprint$$powexec_name Fly”

The typical multiple toggle bind will usually have only 2 toggle powers in it (toggling between A and B). However, inserting more than two toggle powers in a bind can ensure that those additional powers are turned off when the desired power is turned on (useful for conserving endurance, etc.). Powerexec_name also has fewer characters than powexec_toggleoff (discussed below), and therefore may be a more efficient choice for minimizing bind string length. Further, it is sometimes necessary to have a third or even fourth power in the bind script – especially if the bind utilizes the “toggle key” function, is part of a text/toggle bind, or toggle powers are combined with movement and other types of commands within the same bind script.


USING POWEXEC_TOGGLE

The second way to create multiple command toggle binds is to string together a series of powexec_toggleon commands in the bind script (eg., /bind &lt;key&gt; “powexec_toggleon D$$powexec_toggleon C$$powexec_toggleon B$$ powexec_toggleon A”). Powexec_toggleon commands only turn powers on and can not turn off a power. Conversely, powexec_toggleoff only turns powers off.

With the powexec_toggleon command we can successively turn on several powers using only one key, but with multiple key presses. The bind will execute each command from right to left. Upon the first key press, the bind will attempt to activate power A. Upon the second key press, power B will activate. Upon the third key press, power C, and so on. Powexec_toggleon will IGNORE powers that are already on, and will seek out the next non-active power from the beginning of the chain onward with each successive key stroke. If all of the powers in the bind string are already on, no action will be taken. In addition, it appears that powexec_toggleon follows the same power activation sequence as powexec_name, with the one exception that it will not turn powers off.

Powexec_toggleon makes turning on powers using only one key much easier. Before this command existed, the only way to have one key turn on multiple toggle powers was to create a text/toggle bind that required the creation of multiple text files to operate. With this command, one bind will do it all! In addition, in some cases we may only want the bind to turn on the power so that we may turn the power off manually. In others we may use the powexec_toggleon to ensure that a toggle power is not turned off accidentally.

The corresponding command, powexec_toggleoff, works in a slightly different way. If a string of powexec_toggleoff commands are used in a single bind, the bind will turn off ALL powers in the bind script almost simultaneously. Powexec_toggleoff will never turn on a power, but will only turn powers off. The bind will also IGNORE all powexec_toggle commands for powers that are currently off, and search for the first active power from the beginning (right) of the bind string to turn off.

This feature to ignore command entries depending upon the on/off state of a power can cause some confusion if both powexec_toggleon and powexec_toggleoff are used together in the same bind. Consider this bind, for example:

/bind &lt;key&gt; “powexec_toggleon A$$powexec_toggleoff A”

This bind behaves similarly to a typical one power powexec_name bind, yet the way the commands are arranged is not at all like we would expect a powexec_name bind to look like. We might think that toggle_ON should swap places with toggle_OFF for the bind to work properly (and indeed it will work fine this way). However, because powexec_toggleoff ignores powers that are already turned off, the first command in the bind string is skipped over (assuming the desired power is already off before the bind is executed) and the next command in the string (toggle_on) is run instead. This means that when the bind key is first pressed, it will amazingly turn the power ON.


COMBINING POWEXEC_NAME and POWEXEC_TOGGLE

Multiple powexec_name and powexec_toggleon commands may be combined in the same bind. Mixed binds will operate in the same manner as described for the powexec_name command above – from right to left, with the same base power activation sequence. The only difference, and it’s a big difference, is that powers turned on with the powexec_toggleon command will remain ON, while the powers activated with powexec_name will toggle on and off. Also powexec_toggle commands may be ignored in the bind depending upon the on/off state of the power.

This makes for some interesting possibilities. For example, with the following bind we can turn two powers on, and then toggle on and off between the last two powers (C and D) instead of the first two (A and B) as is usually the case:

/bind &lt;key&gt; “powexec_name D$$powexec_name C$$powexec_toggleon B$$powexec_toggleon A”.

The reason this works is because the bind will ignore any instances of powexec_toggleon whose powers are already on. So once powers A and B are turned on, the bind treats power C as if it were the first command in the bind string. This is also true for powexec_toggleoff, except it ignores powers that are already off rather than on.


USING “TOGGLE KEYS”

“Toggle Keys,” for lack of a better name, are already part of City of Heroes. We use them whenever we press the movement direction keys W, A, S, D, X; the space bar, the LAlt and LControl keys, and many others. A toggle key executes every command in a bind upon key PRESS, and then executes every command in the bind again upon key RELEASE. A toggle key is created by adding the “+ ” prefix command at the beginning of a bind string (eg., /bind &lt;key&gt; “+ $$powexec_name B$$powexec_name A”). Notice there is a space between the “+” and “$$”. Without the space, the toggle key function will not work. In addition, any movement or similar command that includes a “+” at the beginning will also cause the key to behave as a toggle key if it is placed as the first command in the bind string (eg., /bind &lt;key&gt; “+up$$powexec_name B$$powexec_name A”).

In the bind above, Jump (the “+up” command) and power A will be activated when the key is PRESSED (and will continue to activate until the key is released). When the key is RELEASED Jump and power A will be turned off, and power B will turn on. Powers A and B toggle on and off between each other because of the toggling rule and power activation sequence of the powexec_name command (see above).

Instead of a “+ ” tag, a toggle key can also be made with a positive and negative movement command placed at the beginning of the bind string (eg., /bind &lt;key&gt; “+down$$-down$$powexec_name A”). The “+down” adds the functionality that causes the key pressed to be executed on both press and release, the “-down” ensures that it does not actually cause movement.

When the prefix “++” is used with a command at the beginning of a bind string (eg., /bind &lt;key&gt; “++forward$$powexec_name B$$powexec_name A”), it serves to turn the toggle key function OFF. This means that the bind string will only be executed once per keystroke, and will not be executed upon key press and again upon key release.

Toggle keys help by allowing us to activate powers quicker, using less keystrokes. For example, a bind using 6 powexec_toggleon commands would take 6 keystrokes to turn all the powers on. However, adding “+ ” at the beginning of the bind would allow us to turn on all 6 powers in only 3 keystrokes – because the bind is executing twice per keystroke (once when the key is pressed, and again when the key is released).

There is one caveat, however. When using toggle keys, it is important to make sure that you don’t press and release the key too quickly. A very fast keystroke will sometimes cause the game to run the commands at key press and key release at the same time, essentially tacking on the same set of binds at the end of the original and treating the whole thing as one bind. Also, client-server-client lag (delays when your computer attempts to communicate with the game’s server, and visa versa) can cause similar errors.


TOGGLE KEY TEXT BINDS

Perhaps the most confusing, but also the most valuable, function for toggle keys is when they are used in combination with the “bind_load_file” command to create “toggle key text binds.” Toggle/text binds were explained fairly well in Curveball’s Guide to Bind in his “Using ‘Toggle Binds’” section. What adding the “+ ” tag to the beginning of toggle/text binds does is to allow us to execute one bind string residing in a specific text file on key press, and then another bind string from a different text file on key release. With this, we can often circumnavigate around limitations placed on us by the game, and execute commands in combination that otherwise would be impossible.

For example, say you wanted your super hero to simultaneously leap into the air with a jump, turn on Fly with the “F” key, and make sure Sprint is turned off; but you ALSO wanted to be able to turn Fly off and Sprint on with a second stroke of the SAME key. Using a toggle key text bind we can create a bind that works in the desired manner, such as this bind below:

FLY1.TXT:
f "+up$$powexec_toggleon fly$$bind_load_file c:\[file location]\fly2.txt"

FLY2.TXT:
f "+up$$powexec_toggleoff sprint$$bind_load_file c:\ [file location]\fly3.txt"

FLY3.TXT:
f "+down$$powexec_toggleon sprint$$bind_load_file c:\ [file location]\fly4.txt"

FLY4.TXT:
f "+down$$powexec_toggleoff fly$$bind_load_file c:\ [file location]\fly1.txt"

The above toggle key text bind will execute the first bind (fly1.txt) and load the second on the key press, and execute the second bind (fly2.txt) and load the third on the key release. Then it will execute the third bind (fly3.txt) and load the fourth on the second key press, and execute the fourth bind (fly4.txt) and load the first bind again on key release – looping back to start over again. This simulates an on/off toggle key for two powers (Fly and Sprint), something impossible to do without toggle key text binds.

Notice that in each bind above there is a “+ ” tag. Without a “+ ” tag or a place holder at the beginning of every other bind (the bind executed on key release), the toggle key function will not work. Instead of a “+ ” tag at the beginning of the second bind, a place holder consisting of a blank space after the first quotation mark and before the first command separator ($$) can often suffice IF only “+ ” is used alone in the previous bind string and not attached to a movement command. For example:

TEXTBIND1.TXT:
Y "+ $$powexec_name A$$bind_load_file c:\[file location]\textbind2.txt"

TEXTBIND2.TXT:
Y " $$powexec_name B$$bind_load_file c:\ [file location]\textbind1.txt"

This method of creating a toggle key can cut down or reduce the number of characters used in a bind, and also allows us to create a toggle key without movement commands mucking up the works – but don’t forget the blank space before the first “$$” command separators for each text bind or this toggle key arrangement will not function properly.


UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER

Multiple powexec_name and powexec_toggle commands for the SAME POWER can cause some baffling results, behave contrary to the normal bind rules, and “lock up” a bind so that it no longer works. Believe it or not, these quirks can actually come in handy when trying to design a bind that works the way we want it to work. More importantly, understanding how multiple powexec commands for the SAME POWER affect binds is crucial for understanding how some binds behave when executed under less than optimal conditions, such as when lag is affecting game play or when a bind key is pressed too quickly. Under these poor conditions, entire bind strings are often duplicated and treated as one bind or separate toggle/text binds merged so that we end up executing multiple commands for the same power.

In most cases when two or more powexec commands for the SAME POWER are executed in a bind, a conflict between the commands takes place. The duplicated power briefly turns on, turns off, and then defaults to an ON state. When such a conflict occurs, it prevents any other powexec commands in the bind from operating. Of course, whether or not this command conflict occurs depends upon the specific combination of powexec commands and their position or sequence in the bind string upon execution. For example, combining a powexec_NAME &lt;same power&gt; command with a powexec_TOGGLEOFF &lt;same power&gt; command will have a different result than combining two powexec_NAME &lt;same power&gt; commands.

For ease of use, “A” will represent the duplicated power. I will give an example bind showing the combination and sequence of commands, and then an explanation of the bind’s behavior:

/bind &lt;key&gt; “powexec_NAME A$$powexec_NAME A”
When two or more powexec_name commands for the SAME POWER are used in a bind (eg., /bind Y "powexec_name Super Jump$$powexec_name Super Jump”), the power will be turned on if it was not already active. However, the bind will not turn the power off if the bind key is pressed again. The usual command to turn off all the powers in the bind string executes first (and the power turns off briefly – as well as any other powers in the bind string), but then a command to turn on the power occurs second almost instantly. This happens ONLY if the command to turn on the first duplicated power is executed in the bind string, following the normal power activation sequence described previously. It also does not matter where the second instance of powexec_name &lt;SAME POWER&gt; is located in the bind string for this phenomenon to occur. Further, once powexec_name &lt;SAME POWER&gt; is executed, the bind will prevent all other powers in the bind from executing – and the bind will essentially “lock up.” For example, the following bind will ONLY execute Fly, will never turn it off, and will never toggle on Stealth (contrary to the normal bind rules): /bind Y “powexec_name Fly$$powexec_name Stealth$$powexec_name Fly”.

/bind &lt;key&gt; “powexec_TOGGLEON A$$powexec_TOGGLEON A”
This bind above seems to behave normally, as if there was only one powexec_toggleon command. Multiple instances of powexec_toggleon &lt;same power&gt; do not seem to interfere with the bind’s operation, and the additional commands appear to be ignored.

/bind &lt;key&gt; “powexec_TOGGLEOFF A$$powexec_TOGGLEOFF A”
This bind above behaves differently depending upon the on/off state of the power. If the power is already OFF, the bind will do nothing and the commands appear to be ignored. However, if the power is already ON, then the bind will behave as two powexec_NAME &lt;same power&gt; commands – it will NOT turn the power off, and will prevent any other powexec commands in the bind string from executing. The powexec_toggleoff &lt;same power&gt; commands can be placed ANYWHERE in the bind string, but one of the commands must be executed for this behavior to occur (following the power activation sequence for multiple command binds previously described above).

/bind &lt;key&gt; “powexec_TOGGLEOFF A$$powexec_TOGGLEON A”
This bind will toggle the power on and off, and seems to behave normally according to the power activation rules for powexec_toggleon/off commands

/bind &lt;key&gt; “powexec_TOGGLEON A$$powexec_TOGGLEOFF A”
This bind will toggle the power on and off, and seems to behave normally according to the power activation rules for powexec_toggleon/off commands.

/bind &lt;key&gt; "powexec_NAME A$$powexec_TOGGLEON A"
This bind above will turn power A on, and then toggle it off upon the next key press – in short, the one instance of powexec_name &lt;same power&gt; within the bind negates the ability for powexec_toggleon to keep a power on. The powexec_name command does not need to be right next to the powexec_toggleon command for this to happen. It can be placed ANYWHERE in the bind string and this toggling on/off behavior will still occur. For example, /bind &lt;key&gt; “powexec_name Fly$$powexec_name Unyielding$$powexec_name Invincibility$$powexec_toggleon Fly”. This bind will turn Fly on and off, while toggling between Fly and Invincibility. However, if two instances of powexec_name &lt;same power&gt; are placed in the bind, and one of the commands executed, the bind will turn on the power and keep it on, ignoring all other powers in the bind string.

/bind &lt;key&gt; "powexec_TOGGLEON A$$powexec_NAME A"
This bind will toggle power A on and off. In short, the powexec_toggleon command is ignored. If a powexec_toggleon &lt;same power&gt; command appears elsewhere in the bind, it will not affect it’s operation.

/bind &lt;key&gt; "powexec_TOGGLEOFF A$$powexec_NAME A"
This bind above will turn power A on, keep it on, and will never turn it off. It behaves exactly as if two powexec_name commands for the same power were placed in the same bind. The powexec_toggleoff &lt;same power&gt; command can occur ANYWHERE in the bind string and this behavior will still take place, but only if powexec_name &lt;same power&gt; is the first command in the string. Further, this combination prevents all other powers in the bind string from executing. For example, this bind will only turn Super Jump on: /bind Y " powexec_name unyielding$$powexec_toggleoff super jump$$powexec_toggleon temp invulnerability$$powexec_name super jump".

/bind &lt;key&gt; "powexec_NAME A$$powexec_TOGGLEOFF A"
This bind will turn power A on and keep it on. It behaves very similarly to when two powexec_name commands for the same power are placed in a bind. However, this only occurs if the powexec_name &lt;same power&gt; command is executed in the bind string, following the normal power activation sequence for powexec commands. Otherwise, the bind will behave normally.


In any bind string that has two commands that would create a conflict when executed, a conflict will occur regardless of what other powexec &lt;same power&gt; commands reside in the bind string. For example, when powexec_NAME &lt;same power&gt; and powexec_TOGGLEON &lt;same power&gt; are combined, the bind will function normally. But if you add another instance of powexec_NAME &lt;same power&gt;, a conflict will result when the command is executed, turning the power on and locking up the bind:

This bind will operate normally:
/bind Y "powexec_TOGGLEON fly$$powexec_NAME fly"

But this bind will create a conflict:
/bind Y "powexec_NAME fly$$powexec_TOGGLEON fly$$powexec_NAME fly"


When a conflict between two powexec commands for the same power occurs, it can often have a side effect of slowing down the execution of a power, sometimes enough to allow a different type of command (such a movement command) to execute before the power does. This might be useful in some bind applications.


MOVEMENT DIRECTION COMMANDS

The movement direction commands are actually toggles (eg., +forward, +backward, +left, +right, +up, etc.). This means that when a direction command is issued, it will stay on until the command is issued again to turn it off. In game, these commands appear to be special commands – turning on during key press, and off upon key release – but what is really happening is that the movement command executes upon key press (turning on the power), and then executes the same command again upon key release (turning off the power) – in short, utilizing the “+” prefix or “toggle key” function.

The “++” prefix, on the other hand, serves to turn the toggle key function OFF. When used with a movement command (eg., ++forward, ++backward, ++left, etc.), the prefix will cause the command to be toggled ON, and will continue to activate, until the button is pressed again, toggling it off.

Anything you can toggle (using ++ or +/-) you can explicitly turn on or off by adding the argument 1 (on) or 0 (off) after them (eg., /bind Y “up 1$$powexec_name”). For most commands that take a numeric argument (including the toggles), you can check the current value by issuing the command without any arguments.


CLICK POWER BINDS

Click powers can be executed using any of the powexec commands. As indicated by Curveball’s Bind Guide, only one click power can be activated at a time (unless powexec_auto is also used to activate a second click power). A mixed click and toggle bind will pretty much behave as a normal toggle bind as described above with one big exception… when a click power is executed a second time, the click power will either be activated or queued up to be activated once it has recharged – and NOT toggled on and off. This means that if a click power is placed as the first power to activate in a bind string, no other powers will be executed (excepting powexec_auto), no matter how many times the bind key is pressed. For example:

/bind &lt;key&gt; “powexec_name TOGGLE$$powexec_name TOGGLE$$powexec_name CLICK”

This bind above will only execute the click power. Therefore, it’s usually best to place a click power command after all of the toggle power commands in the bind string – or at least somewhere other than at the beginning of the string – so that toggle powers have a chance to execute before the click power.


USING POWEXEC_AUTO

This command only works for click powers, and will not work for toggle powers. Essentially, powexec_auto sets a click power on auto-fire – allowing the click power to activate automatically upon recharge until auto-fire is deselected. This command toggles auto-fire on and off, and can be placed ANYWHERE in the bind for it to work. However, if more than one powexec_auto command is included in a bind string, the command will only turn auto-fire on, and will NOT turn auto-fire off. As with other powexec commands, powexec_auto command is executed from right to left in the bind string (eg., /bind Y “powexec_auto D$$powexec_auto C$$powexec_auto B$$powexec_auto A”). So in unlikely cases where multiple powexec_auto commands are used together, only the first power (A) will be set on auto-fire. This may be useful to avoid turning auto-fire off if the same bind key is pressed again. In addition, if two powexec_auto commands are used for the SAME POWER in a bind (eg., “powexec_auto Gash$$powexec_auto Gash”), they will cancel each other out and prevent the command from executing (neither turning auto-fire on nor off).

When powexec_auto is used in the same bind with either powexec_name or powexec_toggleon/off, it will execute on every keypress regardless of it’s location in the bind string. However, it is a best practice to place powexec_auto commands at the end of the bind string, after all other powexec commands have had a chance to execute in order to avoid any potential power activation problems. (eg., /bind &lt;key&gt; “powexec_auto D$$powexec_name C$$powexec_name B$$powexec_toggleon A”)



TURNING POWERS OFF

Besides the normal ways to toggle powers off using powexec_NAME and powexec_TOGGLEOFF commands, powers can also be turned off by adding the following commands to the beginning (right) of a bind string:

Powexec_unqueue -- cancels a queued power. It will also turn off any powers that are included in the same bind string, as long as the powexec_unqueue command is executed in the bind following the normal power activation sequence. So the best place to put the command, if you want to turn powers off, is at the beginning of the bind string (from right to left) to make sure it’s activated, like so: /bind Y “powexec_name invincibility$$powexec_name unyielding$$powexec_name fly$$powexec_unqueue” This bind will only turns the powers off, and will not turn them on. When used with powexec_toggleon, the unqueue command will cause the bind not to function. When used with the powexec_toggleoff command, the unqueue command will turn off all powers and cancel queues.

Powexec_abort -- cancels the auto-attack power and the queued power. It behaves exactly like powexec_unqueue above, including turning powers in the bind string off, as well as canceling queues and auto-fire.


ARRANGING YOUR BIND COMMANDS

Types of powers/commands:

Click Power Command -- attacks, inspirations, various powers such as Build Up, Hasten, etc.
Toggle Power Command -- powers that toggle on and off, such as Fly, Super Jump, Temporary Invulnerability, etc.
Movement Command -- +up, +down, +forward, +backward, +left, +right. +turnright, +turnleft, +autorun
Emotes -- animated movements such as wave, bow, grief, etc.
Text Message Commands -- tell, team, local, broadcast, etc.
Variables -- $target, $name, $origin, $archetype, $level, $battlecry
File Loading Commands -- bind_load_file
Miscellaneous -- costume (cc 0, cc 1, etc.), map, chat, sgmode, follow, target_enemy_near, etc.

The order or sequence in which you arrange command types in your bind strings is crucial for the proper operation of your bind. If you were paying attention while you were reading this guide, you’d already know most of what I’m about to explain. Of course, arranging your bind commands in the order I am about to suggest is not, usually, a rule set in stone. You are free to experiment with different arrangements, many of which I suspect would work fine. Keep in mind that bind strings are executed from right to left. The following is an example bind with the preferred parsing:

/bind Y “+forward$$CC 0$$team I am ready now, $target.$$emote thumbsup$$powexec_auto Gash$$powexec_name Dark Blast$$powexec_name Fly$$bind_load_file C:\[file location]\ready.txt”

Rewriting the bind above using the command types would look like this:

/bind Y “MOVEMENT commands$$MISCELANEOUS commands$$TEXT commands$$EMOTE commands$$AUTO-FIRE commands$$CLICK POWER commands$$TOGGLE POWER commands$$FILE LOADING commands”

Having File Loading commands execute first, before any of the other commands, helps ensure that the new text bind is loaded. Remember, the very first command from the right is the command that will be executed first.

Next comes toggle power commands such as powexec_toggleon and powxec_name. These come before click power commands so they will activate.

Then comes click power commands because no toggle power command will active after a click power has activated.

After this comes auto-fire commands so they do not interfere with click or toggle power execution.

Emotes are then executed because their animations take time to process.

Text and Miscellaneous commands take no time to execute, so these are placed last to minimize their interference with other commands, but really can be placed anywhere in the bind string.

Movement commands can be placed elsewhere in the bind string, but if you want the toggle key function to be activated with the command, the movement power must be placed at the end (far left) of the bind string so that the “+” prefix activates the toggle key function.


DEALING WITH LAG

Unfortunately, we all will encounter LAG at one time or other while playing COH, so saying a few words about how LAG adversely affects binds and what we can do to adjust our binds to ensure they operate correctly is probably worthwhile. This is especially true for me, since I’ve been playing with a low speed 56k dial-up connection. Lag seems to affect the operation of my binds far more than others who are on a broadband connection.

Lag occurs when the game’s computer (server) is having trouble communicating with your computer (client), and visa versa. There can be pauses, hiccups, and slowdowns in bind execution; and sometimes a bind might not execute at all. I am certainly no expert on this subject, but three things appear to happen to binds during lag:

1) the bind is duplicated and run as if the two bind strings were actually one bind string,
2) the bind is truncated and/or only partial commands are communicated to the server, or
3) the bind or part of the bind is delayed in executing.

In my experience, the most common bind error when executed under lag conditions is that the bind string is duplicated, tacked onto the end of the first bind string, and then executed as one bind string. This happens most often with toggle key binds. So a bind such as this one:

/bind Y “+up$$powexec_name Sprint$$powexec_name Fly”

might be turned into a bind string that looks something like this one during lag conditions:

/bind Y “+up$$powexec_name Sprint$$powexec_name Fly$$+up$$powexec_name Sprint$$powexec_name Fly”

The double movement commands (+up) would have no affect on the operation of the bind, but the twin instances of powexec_NAME Fly would cause a command conflict and the bind would malfunction (see the section UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER above).

This duplication of bind strings during lag occurs mostly for binds that utilize the toggle key function, where the bind is executed on key press, and then executed again on key release. In addition, toggle key text binds that load multiple binds from text files add a layer of complexity to this problem that can be very confusing.

My guess (and it is only a guess) about what is really happening behind the scenes with toggle keys and lag is that when the bind key is pressed and released, the game attempts to execute the bind but communication fails between the client/server, and the command is not processed. Instead, the first set of commands issued on key press and the second set of commands issued on key release are stored in a “queue,” waiting to be executed when communication is re-established. Once communication is resumed, the game runs both bind strings at the same time as one bind.

When designing or troubleshooting a toggle key bind, it’s important to take into consideration the possibility that the bind may be duplicated sometime during game play. Creating binds that, if duplicated, will not cause same-power command conflicts is easier said than done, however. Whether or not a command conflict occurs depends on the specific commands used in the bind as well as their sequence in the bind. Your best bet would be to look at the UNDERSTANDING MULTIPLE POWEXEC COMMANDS FOR THE SAME POWER section above, and see what would happen if any of your toggle key binds were duplicated, and then experiment with different command arrangements that might not cause conflicts if repeated. There is, however, one saving grace here. Duplicate instances of the powexec_TOGGLEON &lt;same power&gt; command will not cause conflicts, so whenever possible use powexec_toggleon to turn on powers instead of powexec_name.

The second thing that might happen during lag is that a bind command (or the bind string) may be truncated because of loss of communication. For example, “powexec_name Unyielding” might be truncated to “powexec_name Unyieldi” or “powexec_na” or “pow”. Truncated or partial commands will be ignored by the game, so it might mess up your power activation sequence (which power activates when). Otherwise, partial commands really don’t cause any trouble, they simply will not function is all.
The best bet to try to avoid this is simply to use multiple powexec_toggleon &lt;same power&gt; commands to make sure that at least one of the complete commands is executed. Unfortunately, duplicating other powexec commands in a bind might cause problems, depending upon the specific commands used in the bind and their location in the bind string.

The third thing that happens to binds during lag is that delays in power activation occur. You might press a key, and some commands may be executed, but a power may not turn on except after a lengthy pause. I don’t know why it works, but I’ve found that adding at least two powexec_toggleon &lt;same power&gt; commands to a bind string tends to eliminate power activation delays in binds. For example, /bind Y “+up$$powexec_name Sprint$$powexec_toggleon Fly$$powexec_toggleon Fly”.

I'm guessing that with the introduction of the Issue 6 game update and Enhancement Diversity that the best slotting for Teleport would be 3 End Red and 3 Range Enhancements, and that pretty much any other variation of 6 slots is silly (4 End and 2 Range, 2 End and 4 Range, etc.)?

Also, check out Black Spectre's Binds at this web site: http://www.barbariankeep.com/bs/

He has a new Easy Teleport bind that is FASTER and EASIER to use than the old LSHIFT+LBUTTON bind. It takes a little preparation, but it's well worth the trouble...