New Clan Lord Macro Features for v256 Multibutton mice To associate a macro with a specific mouse button, you now assign that macro to one of the following names: click - for button #1 only click2 - for button #2 only right-click - a synonym for "click2" click3 - for button #3 ... click8 - for button #8 Each of these macros is triggered only when the corresponding button is pushed. In particular, click is no longer a catch-all for every button. That means you can (and probably should) leave click itself unassigned, to prevent unwanted interference between macros and more important stuff, like movement and combat! This also means, however, that if you wrote a big complicated click macro that inspects the @click.button variable and does all sorts of different jobs depending on the result, then you'll need to dismantle all that hard work. But you can probably just cut and paste each separate section of your masterpiece into its own click# macro -- all you lose is unnecessary overhead. You can also include keyboard modifier prefixes, as usual; for example, shift-click4 or command-option-right-click. Note that the word "right-" has to come immediately before "click". That is, this works: control-shift-right-click but this doesn't: control-right-shift-click. If you find this confusing, just use click2 instead of right-click. The @click.button variable is now redundant, but is still available, and still holds the number of the button that was clicked. @click.chord is unchanged. Right-click and control-click OS X automatically translates a right-click to a control-click, to support contextual menus. The v254 client unintentionally disabled that. In v256, right-clicks are once again transformed into control-clicks on button #1 -- but with one exception. If you have a macro assigned to click2 (or its synonym, right-click) without any keyboard modifiers, then that macro will have priority. The macro will run and "swallow" the right-click, which won't be translated into a control-click after all. If you want right-clicks to work the way they did pre-v254, simply leave click2 and right-click unassigned, so that such clicks will be converted to control-clicks as they used to be. More generally, if you have a click2 macro that does include keyboard modifiers, then the macro system will see it if there's a macro that exactly matches. If so, the macro will run and the click will be swallowed. Otherwise, the click will be passed back to the operating system, which will (in OS X) convert it to a control-click on button #1. It then gets sent to the macro system again, in case you have a macro set up to handle the modified control-click. For example, suppose you have a macro defined for shift-control-click, and none for right-click (or click2). Now you point the mouse at someone and click button #2. Since you have no click2 macro, it will be automatically converted to a control-click. You have no plain control-click macro either, so it gets treated as a normal control-click, which cycles the player's label color. Now you shift-right-click instead. You have no shift-click2 (or shift-right-click) macro, so the right-click is converted to a control-click (on button #1), giving a shift-control-click. You do have a macro for those, so it runs. Now for the really weird stuff. What happens if you define a click2 macro that has its $no_override attribute set? In that case the macro system runs the click2 macro, but it doesn't swallow the click. The click goes on to the OS, where it's converted to a control-click and sent back to the game application again. If you happen to have a control-click macro, that'll run too -- probably not what you wanted. (For every other kind of click macro, the $no_override attribute works more sensibly. This quirk affects only click2 (or right-click) macros, because of the unique way the OS treats button #2.) Anxiously awaiting all your bug reports, we remain, Sincerely, The Committee Committed to Macros