New Target Group Action and Round Robin

Hello,

I really liked the guide on dynamic formations posted by Ualaa which I've since implemented myself. While tooling with the idea for other things, 2 nice (I hope) ideas for future ISBoxer iterations occurred to me. It seems like a natural progression that round robin be integrated into the New Target Group Action. I guess it benefits heterogeneous groups like mine more than homogeneous groups like 5-man DKs/Shamans, but I do believe that good utility can be found by all.

As it stands, NTGA is already nifty, with the timer and all. In the whirlwind of PvP, it'd be great to have the lined-up healer on the ATG drop out of the group so as not to be inadvertently dragged, and thus, interrupted during spell casting; while a timer matching cast time runs, after which the next step regroups the caster into the ATG so he/she can run around with the pack again.

Round-robin in general could benefit from a feedback functionality, perhaps through Pop-up text, that flashes who's lined-up and next-in-line, or even says that the round-robin has reset to the first in line due to inactivity (though I'm not sure if this is how ISBoxer handles it). Using the example above, it'll be useful for knowing who to wrap the group around for casting defense etc.

I hope you don't mind the suggestions. For all I know, these are already ideas on the queue. I just like the product so much that it inspires me to think how to make it better

[lax]

I love requests and suggestions, especially those that come with Use Cases!

1. Target Group Action can get a Round-robin check box, sure. But, do note that you can Round-robin pretty much anything with a Do Mapped Key Action

2. The order of windows in an Action Target Group is completely liquid. This means that while the order might be A B C D when you first start, when you remove C it's going to become A B D and then when you add C again it might become A B D C, rather than A B C D. Additionally, removing someone from an ATG will very likely change the calculation of who is "next" to receive any particular Round-robin Action.

Who is "next" comes from keeping a simple counter attached to your Mapped Key Step: the number of times the Step has been executed and advanced past (meaning the 'Do not advance' options at the top of your Step will pause the Round-robin from advancing as well, even in a Mapped Key with 1 Step). Then we see how many times that number goes into the number of windows that match the Target (e.g. your ATG in this case), so say the count is 5, you have 4 people in your ATG, we do a division of 5/4 and find that the remainder is 1. This 1 then corresponds to which guy (0 1 2 or 3 meaning A B C or D if that is the order at the time), out of those in the Target, gets the key or whatever you sent. Now.. if you remove someone from the ATG, the division is instead 5/3, making the remainder 2 instead of 1. So if you had planned for guy 1 to be next, now guy 2 is next. And what if the order is now A C B D, or D B C A, or C A D B, etc.

That's not to say it's not doable... you can plan around that behavior.

This leads me to ...
3. I will see about implementing some new Action that can link the Round-robin counter from one Mapped Key Step to another. Adding new Actions is time consuming, so I'd love to avoid that for obscure things like this

4. I'll also see about adding an offset field to the Round-robin checkbox. This would let you offset the value of the round-robin counter for the calculation, so that within the same Step you can use the same Target and Round-robin checkbox, and have it go to the "next" guy (+1) or the "previous" guy (-1), etc.

Any of these changes would be in the ISBoxer 41 pipeline. (Alternatively, for now you would want to use one of the other methods of implementing Round-robin in order to have this degree of control.) I'm most likely going to finish the lavishsoft.com site revamp before ISBoxer 41. The new site is actually pretty far along and I really really want to push it out ASAP because the existing lavishsoft.com site is awful. Anyway, should these changes happen you will get to try it during the ISBoxer 41 Beta in a few weeks.

If you have more requests, the sooner the better

I love requests and suggestions, especially those that come with Use Cases!

This is totally awesome to hear

1. Target Group Action can get a Round-robin check box, sure. But, do note that you can Round-robin pretty much anything with a Do Mapped Key Action

I agree it's very powerful. There is still a lot I have to learn about the capabilities of ISBoxer. This might be the case with my inability to come up with a solution to doing what I outlined in this post regarding healer drop-out and rejoin. The best I could come up with is to break the whole healer ATG group up so as not to be affected by FTL follow. While I love KB+mouse control over anything, I had to lay off from heavy use due to carpal pain and switch to controller+voice which constrains the available "estate" for maps etc and, perhaps, makes it difficult for me to come up with a solution using what's available right now.

2. The order of windows in an Action Target Group is completely liquid...

Ah, thank you for the detailed explanation. It makes a lot of sense to me when you explained it that way.

3. I will see about implementing some new Action that can link the Round-robin counter from one Mapped Key Step to another. Adding new Actions is time consuming, so I'd love to avoid that for obscure things like this

I totally understand and, honestly, it's not really important; especially if the implementation requires a lot of work. I just thought when I made this post that the round-robin counter/window detail was a hidden attribute somewhere that could easily be made available, or perhaps routed to Popup Text.

4. I'll also see about adding an offset field to the Round-robin checkbox. This would let you offset the value of the round-robin counter for the calculation, so that within the same Step you can use the same Target and Round-robin checkbox, and have it go to the "next" guy (+1) or the "previous" guy (-1), etc.

Wow, I wanted to suggest this at first, but I decided it sounded like a lot of work to put into your busy schedule. Thanks so much for thinking about it

If you have more requests, the sooner the better

I'll be glad to. I did bring up something in another post. Basically, it asked about the possibility to have a toggle that prevents the current character/window from spawning a Next Click w/ Video FX window if the character is part of the ATG, and is currently the first in line on the round-robin cycle. I may have done it wrong, but right now it takes 2 clicks (one to banish the VFX window and another to fire the AoE) to get the job done in the context I just mentioned

Thank you for the insights and information, much appreciated