Bug or limitation for Mapped Key Virtualization Actions?

I have a series of mapped keys that each have 48 Mapped Key Virtualization Actions. It appears that the last couple of actions are not being performed when I use these virtualized mapped keys. When I insert a 'debug' popup text message into the virtualized mapped keys that should be masked by the pointer to the 're-mapped' keys, I get the original mapped key operating and not the re-mapped ones, for the last couple of keys in the set. The others above them all work OK.

If I reorder the actions to move the bottom virtualization actions that are not being performed to the top of the list of actions, they then work as expected and the new "bottom of the list" virtualization actions don't work any more. So this seems to be a predictable and repeatable issue.

Before I start cutting up my config to try to get it working, I would like to check is this is a bug or known limitation I'm encountering, as logically the 48 virtualization actions belong together in my config and I would rather leave them that way if possible?

- Thanks

[lax]

There are internal size limitations on the amount of crap you can pile into a single Step. I think you're probably running into it. You can work around it in various ways, including splitting these 48+ actions into multiple Mapped Keys, and using Do Mapped Key Action.

However.... if you are hitting this limitation, there is a very good chance you can change your design to use many fewer Actions:

There's a super handy feature of Mapped Key Virtualization whereby if you do not provide a specific Mapped Key to virtualize, you can virtualize an entire Key Map instead of individual Mapped Keys within them. This maps every Mapped Key in one Key Map, to an identically-named Mapped Key in another Key Map. (To do this, just select a Key Map and leave out the Mapped Key to virtualize.)

So for example, in my configuration I have the following Key Maps set up... (and I picked a couple Mapped Key names which appear in all of them, so you can follow what's going on in my example; there's more like 10 of them)
* Combat Hotkeys
** Mapped Key: DPS Rotation
** Mapped Key: Stun
* Virtual Combat
* Holy Paladin
* Blood Death Knight
* Frost Death Knight

"Combat Hotkeys" are the masters. This is where I set up the actual Hotkeys. The "DPS Rotation" mapped key has my Hokey configured (which is on my G13 input device) and simply does Do Mapped Key Action, DPS Rotation in Virtual Combat, to all windows. The others are pretty much the same but may have slightly different mechanics; "Stun" does Do Mapped Key Action, Stun in Virtual Combat, to all windows, with round-robin checked. (If everyone doesn't have a stun, I would instead use an Action Target Group for those that do.)

"Virtual Combat" does pretty much nothing. Its entire purpose is to serve as THE KEY MAP to virtualize, for any given class. On any Holy Paladin character, I virtualize "Virtual Combat" as "Holy Paladin". On any Blood Death Knight, I virtualize "Virtual Combat" as "Blood Death Knight". So each class/spec has his own definition for what Stun means, or what DPS Rotation means. The DPS Rotation for Holy Paladin is extremely different from Frost Death Knight. My Holy Paladin might just spam heals on my tank for his rotation, and my DKs of course have many abilities to DPS with.

But what I'm getting at here is that one Mapped Key Virtualization Action can implicitly be 48+ Mapped Key Virtualization Actions, by being less specific and having purposefully designed Key Maps.

Thanks for the prompt reply Lax. I will alter my approach to avoid the internal step/action limitations.

Thank you also for the reminder about virtualizing entire key maps. I'd forgotten about that option. Time to make a cup of tea and reconsider things...

[Alge]

I've been using the method outlined by Lax above for a while now (ever since Lax put me on to it) and I would have to say it provides the best organisation and flexibility of any system I have used so far.

+1 from me