Black_Specter

Cohort
  • Posts

    124
  • Joined

  1. Oops! I noticed a couple mistakes in the list today and fixed them. The first is I changed the mouse chord name from "LBUTTON+RBUTTON" to the correct "MOUSECHORD." "LBUTTON+RBUTTON" doesn't work. Opps. Got the description and the name mixed up there.

    The second mistake was that I forgot to incude the "MOUSEWHEEL" key name. A silly mistake. I was focusing too much on keyboard names and didn't pay much attention to the mouse buttons. Interestingly, even though it's common knowledge that only the "+camdistadjust" command can be bound to the mouse wheel, I was able to bind "+forward" to it today... in a manner of fashion. It didn't work very well, but it did take. So maybe some other commands will work with the key too (although I doubt it)?
  2. THE COMPLETE LIST OF KEY NAMES
    By Black Spectre


    In order to create binds in City of Heroes/Villains, you'll need to know the names of the keys on the keyboard so you can bind commands to them. Some keys can only be bound using the designated name for the key, while other keys use their own symbol or character for binding purposes. There is often more than one name for a specific key: a primary name and a secondary name. Primary names are fully supported by the game, and I highly recommend you use those over the secondary names. The secondary names will work fine in binds, however some game features such as the ability to use the "/unbind" command to restore the default key binding to the key will not work for most secondary names (with a couple exceptions). To unbind keys where you have used the secondary name, simply unbind the key twice -- first with the secondary and then again with the primary key name.

    I have endeavored to present a complete list of all key names for every key on a standard keyboard (except for the Windows Key which appears to be unmappable in the game). This list includes key names not found in Curveball's excellent Unofficial Guide to Binds or Storyteller's Key Names. It also includes alternate key names, and descriptions for many of the more obscure or potentially confusing keys. Descriptions were not made for key names that are generally self-explanatory. The key names in this list are arranged according to the rows on the keyboard from top to bottom and/or according to specific groupings or clusters of keys on the keyboard.

    As usual, compiling this list would have been much more difficult without the trailblazing work done by those before me… work of extraordinary magnitude. They have my gratitude.


    <font class="small">Code:[/color]<hr /><pre>
    Primary Secondary Description
    Names Names





    A-Z alphabet keys
    F1-F12 "F keys" at the top of the keyboard
    ESC the Escape key
    0-9 the numbers row near the top of the keyboard
    - MINUS the (–) key on the numbers row of the keyboard
    = EQUALS the (=) and (+) key on the numbers row of the keyboard
    TILDE the (`) and (~) key, on the numbers row of the keyboard
    BACKSPACE
    TAB
    [ LBRACKET
    ] RBRACKET
    \ BACKSLASH
    CAPITAL the Caps Lock key
    ; SEMICOLON
    ' APOSTROPHE
    COMMA the comma (,) key
    . PERIOD
    / SLASH
    SPACE the space bar
    APPS the Application Menu key (if your keyboard has it, it would be
    right next to the right CTRL key)

    SYSRQ the print screen button
    SCROLL the Scroll Lock key
    PAUSE the Pause/Break button

    INSERT
    DELETE
    HOME
    END
    PAGEUP
    PAGEDOWN

    UPARROW UP the up arrow button
    DOWNARROW DOWN the down arrow button
    LEFTARROW LEFT the left arrow button
    RIGHTARROW RIGHT the right arrow button


    Chord Keys (keys used simultaneously in combination with other keys):


    SHIFT assigns both the left and right Shift keys
    LSHIFT left shift key
    RSHIFT right shift key
    ALT assigns both the left and right ALT keys
    LALT left ALT key
    RALT right ALT key
    CONTROL CTRL assigns both the left and right CTRL keys
    LCONTROL LCTRL left CTRL key
    RCONTROL RCTRL right CTRL key
    FN special key on some laptops that acts as a chord key


    Number Pad Keys

    NUMPAD0 the "0" key on the Number Pad
    NUMPAD1 the "1" key on the Number Pad
    NUMPAD2 the "2" key on the Number Pad
    NUMPAD3 the "3" key on the Number Pad
    NUMPAD4 the "4" key on the Number Pad
    NUMPAD5 the "5" key on the Number Pad
    NUMPAD6 the "6" key on the Number Pad
    NUMPAD7 the "7" key on the Number Pad
    NUMPAD8 the "8" key on the Number Pad
    NUMPAD9 the "9" key on the Number Pad
    NUMLOCK the Number Lock key on the Number Pad
    DIVIDE the (/) key on the Number Pad
    MULTIPLY the (*) key on the Number Pad
    SUBTRACT the (-) key on the Number Pad
    ADD the (+) key on the Number Pad
    DECIMAL the (.) or period on the Number Pad
    NUMPADENTER the Enter key on the Number Pad


    Mouse Buttons

    LBUTTON left mouse button
    RBUTTON right mouse button
    MBUTTON middle mouse button (for some mice, the mouse wheel also acts as
    a middle button)
    BUTTON4 usually a thumb button
    BUTTON5
    BUTTON6
    BUTTON7
    BUTTON8
    MOUSECHORD mouse chord key - both the left and right mouse buttons pressed at
    the same time
    MOUSEWHEEL This key only works with the "+camdistadjust" command


    Joystick Keys (I have not tested the joystick keys, but presume they are correct):

    Joystick Buttons

    joy1
    joy2
    joy3
    joy4
    joy5
    joy6
    joy7
    joy8
    joy9
    joy10
    joy11
    joy12
    joy13
    joy14
    joy15
    joy16
    joy17
    joy18
    joy19
    joy20
    joy21
    joy22
    joy23
    joy24
    joy25

    Joypad Names

    joypad_up
    joypad_down
    joypad_left
    joypad_right

    POV Hat Names

    pov1_up
    pov1_down
    pov1_left
    pov1_right
    pov2_up
    pov2_down
    pov2_left
    pov2_right
    pov3_up
    pov3_down
    pov3_left
    pov3_right

    X/Y Axis Joystick Controls

    joystick1_up
    joystick1_down
    joystick1_left
    joystick1_right

    Z/Zrot Controls

    joystick2_up
    joystick2_down
    joystick2_left
    joystick2_right

    Xrot/Yrot Controls

    joystick3_up
    joystick3_down
    joystick3_left
    joystick3_right
    </pre><hr />

    For a prettier version of this list visit the off-site Advanced Bind Guide
  3. [ QUOTE ]
    I'm trying to set up my left click button to move my character's view when I hold it down and move the mouse. I accomplished this with /bind lbutton "+mouse_look" but now i can no longer single left click anything to target things, scroll windows down, or drag items.

    Anyone know the extra command I need to have it do both?

    [/ QUOTE ]

    You can't. Type "/unbind lbutton" without the quotes to undo your mistake. The left mouse button is the only button/key in the game that can not be remapped, btw. The only thing you could do if you're dead set on using the left mouse button is use another key to switch the left mouse look on and then switch it off when you're done looking. This kind of bind would ulitize text files in the bind.

    I believe the right mouse button is already set up to do what you want, correct? I'm guessing your'e a lefty? If so, one possible solution would be to use your mouse software to switch the left and right mouse buttons. There might also be an option for this in the game (Menu, Options, Keymapping tab), but I'm not certain.
  4. [ QUOTE ]
    Great and informative guide. Kudos to you for pulling it all together. Adding in the Set IO bonus information may very well be helpful, but I would also link to the paragonwiki for a bulk of the information. They have done a tremendous job of listing out Set bonuses for everything known in the game.

    [/ QUOTE ]

    Well, ok... I thought maybe putting another link to ParagonWiki in addition to the 2-3 I already put in the guide might have been overkill... but, sure. I can put a link to the Set IOs page too!

    [ QUOTE ]
    One piece of info I, personally, would like to see included is how Set IO enhancement percentages scale dependent on the level of the enhancement/recipe. For example, at level 50 a dual Acc/Dam IO will be 26.5% and 26.5%. That enhancement/recipe is probably in the 30-53 band. What are the aspect modifies for a recipe at level 49? I'm sure there's a mathematical formula for it, but I've never seen it. You do list out the exemp level modifiers but I don't think the recipe values are the same table.

    Again, great guide!

    [/ QUOTE ]

    Yeah, it's a good question. I haven't seen the formula for calculating the single aspect IO by level bonuses anywhere either. I suspect the formula is based on the SO bonus numbers and then a modifier is applied that considers level. Good question though. I hope somebody better at math than me can figure this out soon.

    And thanks for the kind words.

    Edit:
    I did look at the numbers, and it looks like the devs based the numbers for the various levels of IOs on the numbers for Training Origin, Dual Origin, and Single Origin enhancements and adjusts the modifier for the levels when they are in use. For example, during the approximate time that DOs are available and in use, approximately +.013 is added to each level bonus. At level 26, about when SOs become available, +.004 is added to the previous bonus for each level after. This would all be fine except, there are hic-ups *almost* every 5 levels where only +.003 is added (for level 26+ IOs). These "hic-ups" made it impossible for me to use the compound interest formula to calculate the total bonus because they do not follow a regular pattern. However, even if we were able to use the compound interest formula to calculate the bonuses, it utilizes an exponential calculation which I think would pretty much make it inaccessible and inconvenient for most players to use. Further, we could describe the IO bonuses with multiple formulas that would reference a level chart to figure out which formula to apply, but this kind of defeats the whole idea of using a formula instead of referencing a chart for IO bonuses. So I don't know. I did my best with what little mathematics knowledge I have. Maybe someone who knows more could help?

    Generally we can keep this in mind and it might help:

    Level 10-12 IOs add +.017 to their IO bonus per level (except for level 10 which adds +.016 to get the level 11 IO bonus)

    Level 13-25 IOs add +.013 to their IO bonus per level (except for levels 13, 18, and 23 which adds +.012 to get to the next higher level bonus)

    Level 26-50 IOs add +.004 to their IO bonus per level (except for levels 28, 32, 37, 42, and 46 which add +.003 to get the next higher level bonus)

    -Black
  5. Thanks for the compliment, Memphis_Bill! I'm still thinking of ways to make this guide easier and simpler to understand and use for the casual player. I've shown it to 4 friends now, and none of them have gotten around to read it... or they attempted and got bored or overwhelmed and walked away from it. And worse, now none of them seem eager to try to read it when I prod them a little. ROFL Oh well. I think it's a disconnect at work here where some people can't get past how they thought of enhancements before I9 and how I'm suggesting they think of enhancements now. The old 3 slot rule vs my 100% bonus (or 60% if schedule B) rule. I'll probably try to bridge that divide when I revise this guide. I also know I need to include a lot more information about multi-aspect IO bonuses and set bonuses, but I didn't want to tackle those issues until I had more expeirience with them. I do now, so you'll probably see a revision of this guide within the next month if not sooner.

    Anyway, thanks again.
  6. HOW TO MAKE TABLES FOR POSTING AT THIS FORUM

    This forum is run with UBB code, which is a common message board code that is similar to HTML scripting for web pages. That said, not all of the UBB code has been enabled on the COH forum, notably the code to make tables. So what do we do? We have a great table that would really make some portion of the game easier to understand, or something that we're trying to explain more simple, but we can't make a table here... or can we? Well, kind of. We can turn our table into columns of data.

    The first step is to get your table into a word processing program like Microsoft Word. You can copy and paste a table from a web page, from Excel or some other spread-sheet program, or just make the table from scratch in MS Word. I use MS Word, so we'll go with that for examples.

    Next, convert the table into text, sperated by tabs. In MS Word, click on the Table menu item, then Convert, then Table to Text, then click the Tabs radion button, and then OK. You should have a nice looking set of data columns now seperated by tabs. You can make any adjustments to the table you need at this point, but make sure you use tabs.

    Now highlight the data columns and copy it for pasting in this forum. When you paste the data columns the tabs will also be copies into the posting window, but if you preview the post or post it, the forum will eliminate the tabs and your data columns will be a mixed up jumble.

    There is a UBB code tag, however, that can be used to retain the tabs. The tag is "code". This tag defines whatever comes after it as being scripting code (or "formatted text") and tells the forum not to interpret the various symbols and such to turn them into UBB code or to filter out code and symbols it doesn't like. The "code" tag makes it possible to show the reader the exact characters and symbols used. In other words, it tells the forum program to leave the text after the code tag alone, just as is (for the most part).

    So the next step is to place the code tag right before the table data you just pasted into the posting window. Don't forget that you'll also need to put a closing code tag at the very end of you table data as well. Like so (but without the blank spaces inside the brackets):

    <font class="small">Code:[/color]<hr /><pre>

    [ code ]
    SAMPLE TABLE
    A 1
    B 2
    C 3
    D 4
    [ /code ]

    </pre><hr />

    Now preview your message post and make sure the data columns are aligned. More than likely, something will be askew and need some minor adjusting. However, it turns out that not only does the board filter tabs, there is also no way to type a tab into the posting window (at least, none that I know of). So what do we do? How do we get extra tabs we need to align the table into the post? Simply highlight one of the tabs in the posting window and copy it using CNTRL+C. Now we can paste a tab where ever it's needed in the posting window using CNTRL+V.

    Keep editing and previewing until your table is correct and then post.

    I would think there would be an easier way to post tables at this forum, but unfortuantely this is the only method I have thus far discovered or been able to figure out. If anyone else has a better and easier method, or knows some of the details that I left out, please reply below. Otherwise, at here's one way to accomplish the goal.

    Good luck tables makers!
  7. Yep, tested and confirmed. A level 50 IO with a 42.4% bonus exemplared to level 37 would still have a 42.4% bonus. It's another perk from IOs, and another reason why IOs are superior to SOs... at least for the moment. The devs might change IOs to a more logical system like you suggest, but I wouldn't hold my breath.

    The devs didn't change anything regarding the rules by which enhancements operate. They merely made an additional enhancement type, plopped it into the game, and left everything else the same. Except, when exemplaring, it appears there is a small cap to the IO bonus percentage for at least some IOs. Whether this is intentional or a bug remains to be seen.
  8. Thanks, Red! I appreciate it.

    Incidentally, a prettier version of this same guide can be found here http://www.superheroes-inc.com/iobonus.html
  9. Black_Specter

    Guide to Guides

    The lastest revision of my bind guide is now up at the forums. Please replace the old version in the Guide To Guides with this version. Thanks.

    ADVANCED BIND GUIDE v1.3
  10. ADVANCED BIND GUIDE
    [Version 1.3, Last Updated 1/13/07]

    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, Samuel_tow, 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 The 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. STOP! READ CURVEBALL'S GUIDE ABOVE FIRST!



    TABLE OF CONTENTS:
    1. Multiple Toggle Power 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 POWER 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.

    A common mistake among players is to type "POWER_exec_name." This is not a command and will result in an error if used. The correct spelling is "POW_exec_name"

    Incidentally, a list of all the slash commands in the game can be obtained by typing "/cmdlist" into the chat box (without the quotes). 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 Powexec_name command toggles on a power if it is off, and toggles off a power if it is on. 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 activate 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 end of the bind string.

    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"

    <font class="small">Code:[/color]<hr /><pre>
    POWER ACTIVATION SEQUENCE
    If On Then Turns On
    --&gt;
    none --&gt; A
    A --&gt; B
    A+B --&gt; C
    A+B+C --&gt; D
    B --&gt; A
    C --&gt; A
    D --&gt; A
    </pre><hr />


    Power commands are activated from right to left (&lt;--) because powers interrupt each other when exectued in a series. When you activate a power, there is a slight delay between when it queues and when it activates. This time is too short for anything to happen, but it is longer than the time it takes the game to exectue the next command in the bind. Essentially, each new step interrupts the previous one, effectively working only with the last step backwards from right to left. Deactivating a toggle power, however, takes no time for the game to accomplish and therefore can not be interrupted. So a bind string that toggles, activates, or toggles off a series of active powers will be able to toggle them all off simultaneously. When taken together, the activation and deactivation behaviors of power commands determine the power activation sequence.

    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 power 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 end (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.

    <font class="small">Code:[/color]<hr /><pre>
    QUICK-CHECK TABLE FOR SAME POWER COMMAND CONFLICTS

    1st Same Power Subsequent Same Power --&gt; Result
    Command In String Command In String
    (From Far Right)
    powexec_NAME powexec_NAME --&gt; CONFLICT
    powexec_NAME powexec_TOGGLE_ON --&gt; NO CONFLICT
    powexec_NAME powexec_TOGGLE_OFF --&gt; CONFLICT
    powexec_TOGGLE_ON powexec_NAME --&gt; UNUSUAL BEHAVIOR
    powexec_TOGGLE_ON powexec_TOGGLE_ON --&gt; NO CONFLICT
    powexec_TOGGLE_ON powexec_TOGGLE_OFF --&gt; NO CONFLICT
    powexec_TOGGLE_OFF powexec_NAME --&gt; POSSIBLE CONFLICT
    powexec_TOGGLE_OFF powexec_TOGGLE_ON --&gt; NO CONFLICT
    powexec_TOGGLE_OFF powexec_TOGGLE_OFF --&gt; CONFLICT
    </pre><hr />

    From the table and information above we can draw some simple conclusions:

    1) whenever 2 instances of Powexec_NAME occur in a bind string, a conflict will always result
    2) when 2 instances of Powexec_TOGGLE_OFF occur in a bind string, a conflict will result
    2) when Powexec_NAME and Powexec_TOGGLE_OFF appear in the same bind string, a conflict will typically occur
    3) when Powexec_TOGGLE_ON is combined with any other command, a conflict will NOT occur (but the ability for the command to keep a power on will often be negated)

    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 residing on your computer 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 .

    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 &lt;#&gt;.”

    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 without actually changing the file/directory names on your computer. 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. 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


    Further, make sure there are no blank spaces or line returns (enters) at the end of the bind string in text files. They will generate an error and show up in the global chat window. You want ONLY the characters and spaces used in the bind string residing in the text file, and nothing else.

    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. To do this, use the program named Notepad (or any text editor) that comes with Windows (click Start --&gt;Programs--&gt;Accessories--&gt;Notepad).

    Then you would use the /BIND_LOAD_FILE command to load the text bind. For example, in the chat box you would type: /bind_load_file "C:\[file location]\textbind1.txt". In the example below I created 3 text files: "textbind1.txt," "textbind2.txt," and "textbind3.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; "+down$$powexec_name B$$powexec_name A"). Notice the "+" attached to the "+down" command at the beginning, far left, of the bind string example above. This tells the game to execute the whole bind on key press, and again upon the release of the key.

    Any movement or similar command that includes a "+" at the beginning will 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).

    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. The two methods above are the traditional ways to create a toggle key.

    Instead of a movement or other command, it has often been possible to simply add the "+ " tag to the beginning of a bind string in order to create a toggle key, (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 would often not work. However, it seems that with each new issue update of the game, the bind routine is altered slightly. Issue 7 allowed the "+" prefix to operate correctly without the blank space between it and the command seperator ($$), while Issue 8 seems to have eliminated completely the ability for us to use the "+" prefix alone without a command attached to it. So it appears that the "+down$$-down" approach to creating non-movement toggle keys is probably the best one at this time.

    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. This also means that, as in movement commands, the command will continue to execute until the key is pressed again.

    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.

    As an aside, in prior game updates, not only could the "+ " tag at the beginning of binds be used without a command name attached to it, but in the second bind a place holder consisting of merely a blank space after the first quotation mark and before the first command separator ($$) could often suffice IF only "+ " was used alone in the previous bind string and not attached to a movement command. The blank space before the first "$$" command separators for each text bind was often necessary for this toggle key arrangement to function properly. 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 was used to cut down or reduce the number of characters used in a bind, and also allowed us to create a toggle key without movement commands mucking up the works – but it appears that the bind routine is altered slightly with each new game update, rendering this feature unreliable at best, if not entirely non-functional.


    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 end (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 end of the bind string (far right) 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.

    It should be noted that using powexec_abort or unqueue will cause weapons and such to be put away, and force you to redraw them before attacking.


    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; " "
    /unbind &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.

    Additionally, the binding on a key can be reset by using the UNBIND command. For example: /unbind W. This will remove any bind you have placed on the key and replace it with the default key binding.

    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 Commands -- attacks, inspirations, various powers such as Build Up, Hasten, etc.
    [*]Toggle Power Commands -- powers that toggle on and off, such as Fly, Super Jump, Temporary Invulnerability, etc.
    [*]Movement Commands -- +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.

    All commands in a bind string are executed from left to right (--&gt, but power commands are activated from right to left (&lt;--). This means that the first command (from the left) in a bind string will be read and executed first, and the last (far right) command will be read and executed by the game last. However, Powexec commands in the bind string will be activated in reverse order (from right to left). This is because powers interrupt each other when exectued in a series. Text strings, emotes, movement (for non-interruptable powers) and so on will not interrupt a power before it is activated, nor will deactivating toggle powers. Taking this notion that commands can interrupt or cancel other commands into consideration, we can determine a preferred order or parsing in which to write and arrange commands in bind strings.

    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"



    Prefixes (such as + and -) or commands that contain prefixes (such as +forward and -down) that define a bind string as a "toggle key bind" must be placed first in the bind string so that the "toggle key" function will be activated. If the "toggle key" function is not desired, then the commands that contain prefixes, such as Movement commands, may be placed anywhere in the bind string.

    Next come Text and Miscellaneous commands because they take no time to execute. These are placed near the beginning to minimize their interference with other commands, but really can be placed anywhere in the bind string.

    Then Emotes are executed because their animations take time to process. Keep in mind, however, that movement commands cancel out the animations of emotes (as do the animations of powers when activated). The game can not process or combine multiple animations simultaneously, so it provides a hierarchy that determines which animations are executed and in what sequence. First come animations of powers, then come movement animations, and then come emotes (which are often simply cancelled out).

    After this come auto-fire commands so they do not interfere with click or toggle power execution (these are placed last in the power activation sequence, which means they are placed first before other power commands in the bind string).

    Next come click power commands because no toggle power command will activate after a click power has activated (think power activation sequence).

    Then come toggle power commands. These come after click power commands in the bind string so they will activate first.

    Finally, File Loading commands (such as "bind_load_file") execute last, after all of the other commands. This ensures that the other commands in the bind string are executed before the new text bind (with new bind commands) is loaded and attempts to execute. Remember, the very first command from the left is the command that will be read and executed first, even if power commands are activated in reverse sequence.

    It should be noted that whenever possible, blank spaces between commands should be avoided in bind strings, especially before or after command seperators ($$), in order to help ensure that the bind functions properly.


    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.

    For some excellent examples of binds, check out Black Spectre's Binds here.

    For a prettier presentation of this guide see this off-site version here.
  11. [mods, please delete this thread... I've created a duplicate one in the same forum under a slightly different name]
  12. GUIDE TO IOs, SOs, AND ENHANCEMENT BONUSES
    By Black Spectre (V1.0, June 22, 2007)


    Invention Origin (IO) enhancements have brought another layer of complexity to City of Heroes/Villains that can make slotting and enhancing your toon seem more difficult. This guide will try to make the whole thing easier to understand and provide you with a basic strategy for enhancing your toon.

    IOs differ from SOs (Single Origin) enhancements in some important ways. First, the buff given by the IO does not lessen or degrade as the toon levels up. Second, the percentage of buff given by IOs varies based on the level of the IO. Thrid, many IOs can enhance multiple aspects of a power with a single enhancement. And lastly, in addition to their normal enhancement bonus, IOs can often have a "set bonus."

    The first difference is important because it eliminates the need to re-slot enhancements in your toon every 5 levels. The IOs never wear out (unlike SOs), so once you have your toon slotted with IOs, you can concentrate on playing the game rather than running to buy SOs to enhance up every 5th level. Also, the cost of fully slotting a toon with equivalent IOs is significantly less than it costs to keep SOs up to date during the career of the toon. For example, to slot a toon every 5 levels with SOs from level 25-50 it would cost approximately 17 million Influence. Whereas fully slotting a toon with level 26-30 IOs would cost about 3-4 million Influence for the life of the toon. That's some big savings!


    COMMON SINGLE ASPECT IOs AND SOs
    The bonus percentage given by SOs depends on the "Schedule" of the enhancement. SOs from Schedule A give a +33.33% bonus, Schedule B enhancements give a +20% bonus, Schedule C enhancements give a +40% bonus, and Schedule D enhancements give a +60% bonus. Most enhancements are either Schedule A or B. The Schedule for a particular enhancement can be found by referencing the following chart (or simply by looking at the percentage the enhancement gives in its description if you are familiar with them):

    SCHEDULE A ENHANCEMENTS:
    Accuracy, Confusion, Damage, Defense Debuff, Endurance Modification, Endurance Reduction, Fear, Fly, Healing, Hold Duration, Immobilization Duration, Intangibility, Jumping, Recharge Time, Run Speed, Sleep, Slow, Stun, Taunt

    SCHEDULE B ENHANCEMENTS:
    Defense Buff, Range Increase, Resist Damage, To Hit Buff, To Hit Debuff

    SCHEDULE C ENHANCEMENTS:
    Interrupt Time

    SCHEDULE D ENHANCEMENTS:
    Knockback Distance


    The bonus percentage given by IOs, on the other hand, depends on the level of the IO and the Schedule of the enhancement (as well as how many "aspects" the IO has). Here's an abbreviated table for single aspect IOs:

    <font class="small">Code:[/color]<hr /><pre>
    SINGLE ASPECT IO BONUSES
    IO Schedule A Schedule B Schedule C Schedule D
    Level Bonus % Bonus % Bonus % Bonus %

    10 +11.7% +07.0% +14.0% +21.0%
    15 +19.2% +11.5% +23.1% +34.6%
    20 +25.6% +15.4% +30.8% +46.2%
    25 +32.0% +19.2% +38.5% +57.7%
    30 +34.8% +20.9% +41.8% +62.7%
    35 +36.7% +22.0% +44.1% +66.1%
    40 +38.6% +23.2% +46.4% +69.5%
    45 +40.5% +24.3% +48.6% +73.0%
    50 +42.4% +25.5% +50.9% +76.4%

    SOs +33.33% +20.0% +40.0% +60.0%
    DOs +16.66% +10.0% +20.0% +30.0%
    TOs +08.325% +05.0% +10.0% +15.0%
    </pre><hr />

    A complete table of IO scaling bonuses can be found at Paragonwiki ( http://paragonwiki.com/Invention_Ori...cement_Scaling )
    The effectiveness of IOs equals the effectiveness of SOs beginning at level 26. So if you replaced any SOs with level 26 or greater IOs, there would be no loss of power or effectiveness.

    If you don't want to hassle with all the numbers, figuring out what is what, and just want to play the game with as little additional hassle as possible, then now is the time to stop reading this guide. It's a perfectly acceptable strategy to simply use level 26 or greater IOs once your toon has reached level 24 instead of using SOs. Since using IOs are, overall, less expensive and less hassle than using SOs, I'd recommend it. However, you probably wouldn't be enhancing your toon to its fullest potential if this is all you considered.

    Enhancement Diversity (ED) adds a big layer of complexity. ED applies to IOs as it does to all other enhancements. Essentially, ED put soft caps on how much bonus multiple enhancements can give to a single power, resembling a sort of diminishing returns. The bonus caps vary depending on the Schedule of enhancements and are calculated based on formulas found at ParagonWiki.com ( http://paragonwiki.com/Enhancement_Diversification ) and listed below in the Appendix. Essentially, the final bonus to the power is determined by taking a percentage of the total, aggregate bonus of the enhancements. This means that the final, net bonus from multiple identical IOs will often vary slightly from the final, net totals for SOs because the bonuses of individual IOs differ by level. For example, a power for a level 50 toon that has been slotted with 3 level 50 SOs (+33.33% each) will receive a total buff of +95.0%, whereas that same power slotted with 3 level 50 IOs (+42.4% each) will receive a total +99.1% buff. That's a small 4.1% difference. Incidentally, 99.1% is the maximum bonus that 3 enhancements can currently offer in the game (not including set bonuses). Compare the bonuses from multiple Schedule A level 50 SOs and IOs slotted in the same power:

    <font class="small">Code:[/color]<hr /><pre>
    Level 50 Single Origin Invention Origin Difference
    1 slotted +33.3% +42.4% 9.1%
    2 slotted +66.7% +83.3% 16.6%
    3 slotted +95.0% +99.1% 4.1%
    4 slotted +100.0% +105.4% 5.4%
    5 slotted +105.0% +111.8% 6.8%
    6 slotted +110.0% +118.2% 8.2%
    </pre><hr />

    Looking at the above table you can see that it is very advantageous to slot a power with 1 or 2 higher leveled IOs, but the 3rd slot greatly reduces the net advantage of IOs over SOs. This holds true for all of the enhancement schedules. If we used diminishing returns as the basis for judging how many IOs to slot in a power (as we do with SOs), we would not slot more than 2 identical IOs in the same power. However, 2 IOs will not give as high a bonus as 3 SOs. If you are concerned about effectiveness, then you will want to slot 3 IOs in order to reach the same or greater bonus as given by 3 SOs. On the other hand, the bonus given by 2 high level IOs can come pretty close to that given by 3 SOs, which in turn may allow you to use less slots for that power or use additional enhancement types that buff different aspects of the power (eg., accuracy, damage, recharge, etc.) in exchange for slightly less effectiveness. It's a trade off, but it may be worth it.

    The following table gives the bonuses for 2 SOs, 3 SOs, 2 IOs, and 3 IOs at level 50 for each of the enhancement schedules:

    <font class="small">Code:[/color]<hr /><pre>
    LEVEL 50 ENHANCEMENT BONUSES
    Type 2 SOs 3 SOs 2 IOs 3 IOs
    Schedule A +66.7% +95% +83.3% +99.1%
    Schedule B +40% +56% +49.7% +58.5%
    Schedule C +80% +112% +99.3% +116.9%
    Schedule D +120% +168% +149% +175.4%
    </pre><hr />


    MULTIPLE ASPECT IOs

    Multiple Aspect IOs are enhancements that give a bonus for more than 1 aspect of a power. An "aspect" is the ability that the enhancement bonus applies to, such as damage, accuracy, endurance reduction, recharge reduction, etc. For example, an IO named Red Fortune gives bonuses for 2 aspects: defense and endurance reduction. The more aspects a single IO has, the less the bonus will be for each of the aspects. Let's take a quick look at some level 50 IOs:

    <font class="small">Code:[/color]<hr /><pre>
    # of Aspects IO Name Bonuses
    1 Aspect Invention: Damage +42.4% damage
    2 Aspects Mako's Bite +26.5% damage, +26.5% accuracy
    3 Aspects Mako's Bite +21.2% endurance, +21.2% accuracy, +21.2% recharge
    4 Aspects Mako's Bite +18.5% damage, +18.5% accuracy, +18.5% recharge, +18.5% endurance
    </pre><hr />

    As you can see, the bonuses for multiple aspect IOs are cut roughly in half from the bonus given by single aspect IOs. Specifically, 100%, 62.5%, 50%, and 43.75% for single-aspect, dual-aspect, tri-aspect, and quad-aspect IOs respectively. What the introduction of multiple aspect enhancements means is that we can no longer merely say that 3-slotting a power is the best way to go. Currently, it may be better to 5-slot or 6-slot slot a power, but how do we know? Will mixing multiple-aspect IOs with single-aspect IOs gimp our toons? How can we tell if the bonus will be enough to maintain our toon's effectiveness?

    Well, if we use the bonus given by 3 SOs as the standard, all you have to do is keep in mind 2 numbers… one for Schedule A and one for Schedule B enhancements (Schedules C and D are uncommon, so you can figure those out on your own):

    Schedule A: 99.3%

    Schedule B: 59.3%


    Simply add up the bonuses for a specific aspect from the individual enhancements that you will slot in the power, and if the sum matches or exceeds the above percentages, then the final bonus given by all of the slotted enhancements will equal or exceed the resulting bonus given by 3 SOs (specifically, +95% for Schedule A, +56% for Schedule B). For example, if you had 4 Schedule A enhancements with the following bonuses for damage, your final enhancement bonus would not reach the desired +95% mark:

    33.3% + 26.5% + 18.5% + 18.5% = 96.8% (this is less than the required 99.3% total needed, and would result in a final bonus of +92.8%)

    For the number crunchers among us, I used rounded numbers for the above "after ED" totals as I noticed that the game also uses rounded numbers for its final calculations. The same results should occur. However, completely accurate aggregate numbers to equal 3 SOs would be 99.99% and 60% respectively. If you like, feel free to round my numbers to 100% and 60%, it might be easier to remember. Another way to think of this is to simply make sure your total bonus matches the total bonus of 3 SOs before ED is considered: 33.33% + 33.33% + 33.33% = 99.99% for Schedule A enhancements; 20% + 20% + 20% = 60% for Schedule B enhancements. This should make figuring out if your toon's powers are effectively enhanced much easier.


    SET BONUSES AND NORMAL BONUSES

    Typically, multi-aspect IOs also offer a "set bonus" if more than one of the same "IO set" is slotted into the same power. Set bonuses are added on top of normal enhancement bonuses. Because set bonuses are applied after the ED calculations, they can enhance a power beyond the capabilities of normal enhanecment bonuses alone.

    A set bonus given by an IO is lost (deactivated) in 3 cases: 1) when the power is unavailable, 2) when you exemplar below the minimum level of the set itself (eg., if the set is available from 10-53 and you exemplar to level 9), or 3) when you exemplar more than 3 levels below the level of the set IOs you have (such as if you have two level 23 Miracle in Health and exemplar to level 19). It is important to note that this only applies to "set bonuses." The normal bonus given by the IO will remain in effect even if exemplared below the level of the IO (however the usual Exemplar Reduction Modifier applies to IOs as it does to all other enhancements, reducing the amount of bonus while exemplared down to equivalent levels of other toons at that level - see Appendix below).

    That's pretty much all you need to know. I hope this makes slotting enhancements a little easier and a lot more fun!



    APPENDIX

    Enhancement Diversity Formulas:

    The Enhancement Diversity formulas for calculating the final bonuses for enhancements can be found at paragonwiki.com, but I thought some of you might find it useful to list them here. So here they are…

    The final bonus is calculated based on the schedule of enhancements and the total sum of individual enhancement bonuses which are then compared to a chart to determine the appropriate formula to apply. Generally, the larger the total bonus, the greater the reduction to the bonus. For example, Schedule A enhancements will see about a 10% reduction when the bonus is 70% or more, a 30% reduction at a 90% bonus, and an 85% reduction at a 100% bonus or greater. Each enhancement schedule has its own "thresholds" at which different formulas are applied. E = the total sum of individual enhancement bonuses for an aspect.

    [u]Schedule A Enhancements[u]
    If E &lt; 70% then the bonus will be E
    If E &gt; or = 70% then the bonus will be ((E - 70) x 0.9) + 70
    If E &gt; or = 90% then the bonus will be ((E - 90) x 0.7) + 88
    If E &gt; or = 100% then the bonus will be ((E - 100) x 0.15) + 95

    [u]Schedule B Enhancements[u]
    If E &lt; 40% then E
    If E &gt; or = 40% then ((E - 40) x 0.9) + 40
    If E &gt; or = 50% then ((E - 50) x 0.7) + 49
    If E &gt; or = 60% then ((E - 60) x 0.15) + 56

    [u]Schedule C Enhancements[u]
    E &lt; 80% then E
    If E &gt; or = 80% then ((E - 80) x 0.9) + 80
    If E &gt; or = 100% then ((E - 100) x 0.7) + 98
    If E &gt; or = 120% then ((E - 120) x 0.15) + 112

    [u]Schedule D Enhancements[u]
    If E &lt; 120% then E
    If E &gt; or = 120% then ((E - 120) x 0.9) + 120
    If E &gt; or = 150% then ((E - 150) x 0.7) + 147
    If E &gt; or = 180% then ((E-180) x 0.15) + 168


    Exemplaring Enhancement Bonus Reduction Modifiers:

    Again, just for your information, I thought you might like to know how much your enhancement bonus is reduced while exemplaring. This information came from the following posts at the COH Forum: rjs_boy, iakona, and Corebreach.

    <font class="small">Code:[/color]<hr /><pre>
    "Ex Level" "Ex Modifier"
    1 0.022
    2 0.045
    3 0.068
    4 0.092
    5 0.116
    6 0.141
    7 0.166
    8 0.192
    9 0.219
    10 0.246
    11 0.274
    12 0.302
    13 0.331
    14 0.361
    15 0.391
    16 0.422
    17 0.454
    18 0.486
    19 0.519
    20 0.553
    21 0.587
    22 0.623
    23 0.659
    24 0.696
    25 0.733
    26 0.772
    27 0.811
    28 0.852
    29 0.893
    30 0.935
    31 0.978
    32+ 1
    </pre><hr />

    To find out how your enhancements will change when exemplared, simply find the modifier of the level you will be exemp'ing down to and divide it by the modifier of your current level .

    (Exemplar Level Modifier) / (Native Level Modifier)= Enhancement Modifier

    For instance, if you are lvl 50 and are going to be exemplaring down to lvl 25 for some fun in Bloody Bay, you would find the value for lvl 25 (73.3%) and divide it by the value for lvl 50 (100%).

    73.3% / 100% = Enhancements function at 73.3% of their normal value.

    This currently applies to all levels, at least where exemplaring is possible.

    Lvl 20 to lvl 15 for Positron TF:

    39.1% / 55.3% = Enhancements function at 70.7% of their normal value.

    There is a minor extra step involving at least some IOs above level 48 when a character exemplars to level 45 or lower. In those instances, Schedule A IOs are capped to an enhancement value of +41.67% first (rather than 42% for lvl 49 or 42.4% for lvl 50 IOs), then the exemplaring ratio is applied and then ED.

    It's interesting to note that for PvP zones and for TFs this scaling system can actually penalize players for being one level over the limit. Positron and Bloody Bay both come to mind, because a player can hit level 16 or 26 during these respectively, not gaining any slots, but the scaling system kicks in and gives them about a 92-95% function level. Not huge, but still something that shouldn't happen.

    Also, when using this system, you might notice some inconsistencies if your enhancements are being affected by ED, because the exemplar calculations take place before ED calculations do. Put another way, Exemplar Scaling affects each enhancement individually. If you have 3 SOs in a power the game will show 95%, but for the scaling calculations it sees 99%. ED is still applied to the scaled totals if they are high enough.
  13. Hi gang! I've been working on a guide to help people slot their powers, and also help them not gimp their toons (I've been running into a lot of people doing this). I'd like your input on the guide. Here it is http://www.barbariankeep.com/si/iobonus.html

    It's still a work in progress awaiting your comments, but afterward, I'd like to post it here at the forum. The problem is, I don't know how to format the various tables for posting here at the COH forum. I've tried several ways, and they all have eneded up scrambled or mixed up. Can any of you help? I know HTML, but not all of the UBB code seems to work, and I don't know how to format the dang tables.

    Thanks.

    -Black
  14. Well, I just wanted to thank you guys for helping me understand the coming nerf/buff of -Regen and the global debuff resistance. It is frankly AMAZING that you guys know so much about aspects of the game that simply aren't reported anywhere (to my knowledge anyway). For example, I would never have occured to me that -Regen had a floor or cap at 10%, and that any additional debuff would not reduce the percentage beyond that cap. I don't know how you guys know this stuff, but you are all awesome (and very helpful). And I didn't even consider the effect or how much damage the various debuffs would allow through given various situations -- I only looked at the debuff percentages. That's taking my local view and making it more of a global view. Just fantastic. Thanks.
  15. Let me just add to the above that the reason we need to know the amount of debuff resistance of various critters is to truthfully evaluate the impact that the change to the above -Regen powers will have on the game. Key non-specific questions that need to be answered are: how frequent will players go up against AV's, GMs, and other critters with high levels of debuff resistance occur in the game. If players will encounter critters with high levels of debuff resistance often then the change to the above -Regen powers is NOT "a wash," but rather a tsunami.

    If a Radiation defender went up against an AV with 95% debuff resistance prior to I9, Lingering Radiation would have debuffed the critter's regeneration rate by -500%. After I9, assuming the highest amount of debuff resistance at lvl 50 (85%), Lingering Radiation will debuff the critter's regeneration rate by -75%... instead of 500%. That's a HUGE difference, and very significant.

    In addition, to put the coming global debuff resistance reduction in perspective a bit... some players have mentioned that the reduction in critter's global debuff stats will make many debuffers 3 times more effective... as if this was a big deal. Let's run some numbers real fast assuming the highest debuff percentages and the power Enervating Field...

    Defenders used to only be able to use 5% of their power's debuffing ability, after I9 they'll be able to use 15%. Let's use Enervating Field for an example... it can debuff -30% of damage resistance. Against the old 95% debuff resistance, that means the power could only reduce a foe's damage resistance by -1.5%. Now the new numbers. Out of 85% debuff resistance , the power will reduce a foe's damage resistance by -4.5%. Yes, this is 3 times the amount previously, but look at how small the numbers are. So say a critter's damage resistance is 90% for example, before I9 a debuffer will reduce the critter's damage resistance from 90% to 88.7%; after I9 from 90% to 86.1%. It's hard to see how this will make any sort of meaningful impact on debuffers.

    Note: If you see a problem with me using -damage resistance debuff as an example (since someone in this thread mentioned damage resistance is handled seperately from the global debuff resistance system), just substitute "damage resitance" for the debuff of your choice and my will conclusions still hold true.
  16. [ QUOTE ]
    [ QUOTE ]
    So the above powers will be able to be resisted where previously these powers were not. My question is, how much will they be resisted?

    [/ QUOTE ]

    The scale was posted earlier in this thread (unless I'm thinking of another thread), but the important thing is that a level 50 AV or GM will have 85% resistance to debuffs.


    [/ QUOTE ]

    Thanks for the info. So you're not saying that _every_ level 50 AV and GM will have 85% debuff resistance, are you?

    So we need a list of AVs and GMs and other critters that use debuff resistance and how much of it they have. Does anyone have this info?
  17. [ QUOTE ]
    The global debuff resistance of AVs has always resisted -regen debuffs, there were just a couple of -regen debuffs that were specifically set to be unresistable.


    [/ QUOTE ]

    Ok, now I'm horribly confused.

    From the test server patch notes:

    [ QUOTE ]
    Many powers with regeneration debuff effects are now resistible by non-player entities. Powers effected are:
    Radiation Emissions 'Lingering Radiation' and 'EM Pulse'
    Poisons 'Envenom'
    Robotics Assault Bot 'Plasma Blast' and 'Dual Plasma Blast'
    Electric Armor 'Power Surge'
    Trick Arrow 'EMP Arrow'
    Electrical Master 'EM Pulse'


    [/ QUOTE ]

    So you're saying that -Regen was always resistable by critters' global debuff resistance, except that the above powers were made to not be resistable. So the change here is not on the critters ability to defend against -Regen, but rather on specific player powers so that they are no longer immune to critters' debuff resistance.

    Ok. I can buy this because there are other -regen debuffing powers that were not listed above, notably the 2 dark defender powers and Kinetic's Transfusion, etc. Will these powers be resistable, or are dark defenders and kinetics -regen powers unresistable?

    So the above powers will be able to be resisted where previously these powers were not. My question is, how much will they be resisted?

    What is the percentage of -regen debuff resistance that AVs and other critters have? And is the -regen debuff resistance part of critters' whole global debuff resistance, or is -regen handled differently as it's own seperate resistance?

    It may be that I don't understand "global debuff resistance." I'm assuming this is one percentage stat that resists against all debuffs. For example, if a critter's GDR was 75%, it would resist 75% of all debuffs including -regen, -acc, -rec, -dam res, -to hit, -def, etc. So one number for all these debuffs. Is this correct? Or does "global debuff resistance" merely mean that all debuff resistances have been adjusted "globally."
  18. Thanks for the info, guys!

    Well, I just went through the numbers (thanks for that link, Hudsonsmith!), and if all the reports are accurate that the changes are a wash and there are no appreciable net changes in the performance of Rads against Avs, then really Rads are still the AV killer kings... and not because of the lack of resistance to -regen debuffs.

    The amount of buff that other debuffer powers get because of the reduction in global debuff resistance is extremely small. Not nearly enough to make other powersets equal to the AV killing ability of Rads.

    I'm still a little uncertain about all this, though, and still have 2 questions... will AVs' global debuff resistance actually affect -regen debuffs, or will -regen debuff be treated seperately as their own resistance stat as I now suspect? And how much -regen debuff resistance will AVs and GMs be given?
  19. If the net result of the changes (adding resistance to -Regen and reducing resistance to damage resistance debuffs) is a wash, and considering the small amount of buff that damage resistance debuffers will be getting, the actual amount of -regen resistance the devs are giving AVs must be very small. Does anyone have these numbers?

    And am I correct in my assumption that the global debuff resistance of AVs does not resist against -regen debuffs? But rather -Regen debuffs are treated as a seperate resistance?
  20. Oh wow. Wow.

    Thanks for the info, Hudsonsmith. That info does indeed make this guide completely worthless as soon as I9 hits.

    I've never heard of debuff resistance. Didn't even know it existed. Wow. Are the mechanics of this known? Is there a guide out there somewhere that explains how debuff and debuff resistance interact to produce certain results?

    Way back in I5 my dark defender used to slap Darkest Night (a ToHit debuff) on a boss and stand right next to him in every battle. I figured it was the safest place to be due to my debuff. But now that I know critters have debuff resistance... this kind of makes things dicey.
  21. HOW TO KILL AV's, GIANT MONSTERS, AND OTHER REALLY TOUGH NASTIES – OR THE SIGNIFICANCE OF DEBUFFING REGENERATION RATES

    Welcome again fans and foes! Let me start off by telling you a little story… Once upon a time there was a game update called Issue 7. Among other things, this update significantly enhanced Arch-villain's regeneration rates (approx. +1100%). This huge increase made it IMPOSSIBLE to complete any mission that included an AV without a specialized archetype of hero on the team who also happened to have the right powers. How did it end? Well, the buff to AV regeneration rates was quickly reduced to about +300%, which made AVs tougher but not undefeatable. However, it was this event that pointed out to many of us the enormous significance of regeneration rates in the game.

    During this time, we experimented with various powers on these uber AVs for ways to defeat them. Damage boosting powers such as Fulcrum Shift and Vengeance were tried, but failed. Damage resistance reducing powers such as Enervating Field, Disruption Field, and Freezing Rain were tried, but failed. And even combinations of the two tactics proved unsuccessful. No ArchType or powerset could dent the uber AVs… no powerset, that is, except the Radiation Emission primary for Defenders and Controllers. The key here was the Rad's regeneration rate reducing (debuffing) powers, in particular Lingering Radiation. With the help of Radiation defenders and controllers, the uber AVs could actually be defeated! Since then, Radiation defenders and controllers have been appropriately dubbed the game's "arch-villain killers."

    Other powersets that had regeneration rate debuffing capabilities were tried, and although their powers did have an impact, the effects of the other powers wore off too quickly and the AVs were able to regenerate their full health back within seconds. Even Dark defenders, who come in second in regen debuffing ability, were unsuccessful. The power, Lingering Radiation, is unique in the game in that it has both a large regen debuff (-500%) and a short enough recharge time to be made almost perma. No other regen debuff power comes close to it.

    The point of this story is not to laud the virtues of Radiation defenders and controllers, but rather to bring to light the significance of having a regeneration rate debuffer on the team. There are other powersets that can debuff regen rates, and although not as good as a radiation defender at the task, they will certainly let you put a dent in an AV or Giant monster where otherwise you were powerless. These powersets are:

    1) Radiation Emission defenders and controllers
    2) Dark Miasma defenders
    3) Kinetics defenders and controllers
    4) Trick Arrow defenders and controllers
    5) Blasters with the EMP Pulse epic power

    The following is a list of all powers and hero archetypes in COH that debuff regeneration rates. The stats are taken from the City of Data web site.

    Powers that reduce the REGENERATION RATE of Foes:

    Lingering Radiation– Radiation Defenders and Controllers
    [-500% Regen, dur. 30 secs, recharge 90 secs (46 secs w/3 recharge SOs)]
    EM Pulse– Radiation Defenders and Controllers
    [-1000% Regen, dur. 15 secs, recharge 300 secs (154 secs w/3 recharge SOs)]
    Howling Twilight– Dark Miasma Defenders
    [-500% Regen, dur. 30 secs, recharge 180 secs (93 secs w/3 recharge SOs)]
    Twilight Grasp– Dark Miasma Defenders
    [-50% Regen, dur. 20 secs, recharge 8 secs (4.1 secs w/3 recharge SOs)]
    Transfusion – Kinetics Defenders and Controllers
    [-50% Regen, dur. 20 secs, recharge 8 secs (4.1 secs w/3 recharge SOs)]
    EMP Arrow – Trick Arrow Defenders and Controllers
    [-1000% Regen, dur. 15 secs, recharge 300 secs (154 secs w/3 recharge SOs)]
    EM Pulse – Blasters (Electrical Mastery epic power pool)
    [-1000% Regen, dur. 15 secs, recharge 300 secs (154 secs w/3 recharge SOs)]


    It's possible, although I do not have any data on it, that Shivans debuff regeneration rates as well.

    Well, that's it Fans and Foes! I hope you've found this guide useful.