New Clan Lord Macro Features for v254 We have some new things for you in the Macro Department this update. Top of the list, the client (finally) understands macro files with Unix-style line endings, such as you might find or create on OS X. Next, we've taught it one or two new things about multi-button mice and scroll wheels. (These features only work with OS X and the carbon client: OS 9 and earlier simply don't furnish the necessary information.) So here's the scoop on multi-button mice: Inside your click macros, you can examine the new variable @click.button, which contains a small number denoting which button was clicked. The main button is invariably #1, but you'll have to experiment to find out how the remaining buttons are numbered, since that's up to the mouse manufacturer. Just as an example, on a 5-button Microsoft optical Intellimouse, the main button is #1, the secondary button is #2, the wheel button is #3, and the two small side ones are 4 and 5 respectively. This variable only exists inside click macros; if you try to access it at any other time, you won't get anything useful. Moving across the aisle here to the scroll wheel section, we've also added two new "wheel" key-macros: you can now assign macros to the pseudo-keys 'wheelleft' and 'wheelright' in addition to the previous 'wheelup' and 'wheeldown' pair. The "up" and "down" pseudo-keys continue to be sent when you roll your mouse scroll-wheel with the pointer inside the game window; but if you happen to have a second, separate horizontal scroll-wheel, it sends the "left" and "right" codes instead. OK, that may sound totally academic -- who in the world has a horizontal scroll wheel? And no fair turning your whole mouse 90 degrees! -- but it turns out not to be: Please note that, under OS X 10.2 ("Jaguar"), if you hold down the shift key while turning a (normal, vertical) scroll-wheel, the OS scrolls horizontally instead of vertically. (Try it in the Finder.) This has two consequences for CL wheel macros: First, starting with 10.2, you can't get shift-wheelup and shift-wheeldown events at all (unless you really DO have a separate horizontal mouse wheel), because the OS turns those into left/right events before the client even sees them. Second, you won't get plain 'wheelleft' and 'wheelright' events either, because, by definition, the shift key needs to be down in order for those to be sent. So what you really need to write are macros for shift-wheelleft and shift-wheelright. (And again, this doesn't apply to folks with separate horizontal wheels. Lucky them, huh?) Confused yet? Actually, the bottom line is simple: if you have any existing shift-up/down macros, you probably want to duplicate them as shift-left/right ones. That way, the intended macros will run automatically, as needed, and the duplicate set will be quietly ignored, regardless of whether you have 10.1 or 10.2. Plus things will work nicely if you share your macros with players who are using the other OS version. And maybe best of all, this setup will confuse the heck of out of those horizontal wheel snobs. Serves 'em right! If the macros to be duplicated are longer than a line or two, it's probably better to isolate their working parts into separate subroutines, and then just call them from your key handlers, like so: FancyShiftWheelMacro1 { // do amazing stuff here! } shift-wheelup call FancyShiftWheelMacro1 shift-wheelleft call FancyShiftWheelMacro1 Also, remember that this peculiarity only affects modifier key combinations that involve the shift key. You can keep on using all the remaining modifiers, like command or option, alone and in combinations, without changing a thing; they work just the same as ever. Likewise, plain wheel-up and wheel-down macros haven't changed at all. Just watch out for that shifty, pesky shift key. It needs to be mentioned that, while adding these features, the innards of the macro engine also got a bit of a general tune-up and spring cleaning. Naturally, as with any complex mechanism, both Murphy's Law and Heisenberg's are fully operative. In other words, when we got done reassembling it, we weren't completely, 100% sure we managed to put every single one of those tiny little springs, cogs and nano-gerbils back into exactly all the right places. It passes our tests, of course; but no test can quite reproduce the same stresses as actual day-to-day use. So if you encounter anything broken or more-than-usually unusual, please \BUG it! Sincerely, The Department of Client Maintenance Nitty-Gritty Underpinnings Division P.S. Oh, there's one last thing, but this is strictly for macro mavens of the most exalted order. (You know who you are.) In addition to @click.button, there's a second, related transient variable called @click.chord. Like its cousin, it exists only during the execution of a click macro. If you're clever, resourceful, and brave, you may be able to use it to find out whether multiple mouse buttons are being pressed, and if so, which ones. In the course of that detective work, you'll also discover why this variable turns out to be about 95% useless in practice, and why we nearly decided not to mention it at all -- not even in an obscure footnote like this one. And a word to the wise: if you find yourself thinking that it's broken for button #1, you're only technically right. But it has to work that way. - DoCM, N-GUD.