Okay, so since the day ISBoxer was created there has always been this one little problem that I’ve wanted to get rid of. It’s been on the back burner for quite a while, since it wasn’t really a major issue. Round-robin, with ISBoxer, is currently done by using multiple Steps of a Mapped Key. One Step executes each time you hit the key. That’s great, it’s a very simple concept that works extremely well, and is highly adaptable. However, implementing round-robin keys with this system comes with the assumption that you know in advance which characters can do some ability. That’s fine for the vast majority of people, but for an example of why that can be bad, on my very first team I set up a round-robin for Stomp, a Tauren racial ability in World of Warcraft. Then sometimes I want to swap in a different character, who is not a Tauren, for one of my characters. Now one of the characters can’t Stomp, but is still included as a Step in the round-robin, and I would have to hit the key an extra time to bypass this character. To make things worse, sometimes it is necessary to hit the key multiple times because of Global Cooldown, so I would use the “Do not advance” Mapped Key feature — that way, when I hit the key a few times in a row, it will go to the same character instead of rotating every single time. So now there’s a specified amount of time where that key will just do nothing.
To solve this problem, I’ve made some minor changes to Inner Space which will get used by ISB0xer 38 for new features. I’ll explain it in ISBoxer terms. Most Actions available in ISBoxer allow you to specify a Target, usually meaning the window or windows that are to perform the action. With the current software versions, you can only specify a single Target, which can be a single window, or an Action Target Group, or a few other predefined values (all windows, all windows but the current one, etc). The coming update allows multiple Targets to be combined and operated on in various ways, with Set operations including union, intersect, and not, as well as a modulo operator capable of selecting a single window out of a Set. This opens up several capabilities that were not previously available. For example, this would allow an advanced user to easily send a keystroke to all druids that are also restoration spec, and a different keystroke to all druids that are not restoration spec, or even a different keystroke to all characters who are not resto druids!
The modulo operator will be the key to the new round-robin method. Using modulo effectively for round-robin will require some minor changes to ISBoxer, but here’s a quick example to show how it works. For my Taurens and their Stomp ability, I would have an Action Target Group called Taurens, and all of my Taurens would be part of this group. To send a Stomp to the first Tauren, I use a Target like Taurens%1. The % is operating on Taurens and 1, and saying that it wants the first window of all of the Taurens. For the second Tauren, Taurens%2, and so on. If the number is higher than the number of windows in the Taurens set, it wraps around (thus the modulo operator, although it’s “backwards”). This means there will be a way to tie round-robin to Action Target Groups in ISBoxer, instead of specifying each Slot in a particular Step, and it will also make multiple Steps unnecessary.
I’m still considering my options as far as specifically how to implement this use in ISBoxer. For example, I could add a system of variables that are only useful for Target selection, with a few new types of Actions to manage them. This would give an advanced user excellent control, but a new user would be immediately turned off because that’s a speed bump and learning curve getting in the way of using an awesome feature. Speed bumps are something that need to be eliminated here, not erected. So I don’t plan to implement this idea anytime soon (perhaps down the road). Rather, I’m probably either going to add a check box to Keystroke Action and Do Mapped Key Action to selectively enable Round Robin, or new types of Keystroke Action and Do Mapped Key Actions. I imagine each Step keeping its own counter for Round Robin, and each of the Actions in that Step would use that counter for its round-robin modulo. When the Step advances, so would its modulo — meaning that it should even play nice with the “Do not advance” option.